VirtualBox VPN લેબ: ગેટવે VM વિરુદ્ધ ફક્ત-હોસ્ટ નેટવર્ક
VirtualBox VPN લેબ માટે રાઉટેડ ગેટવે VM અને ફક્ત-હોસ્ટ સેગમેન્ટ વચ્ચે પસંદ કરો, પછી ટનલ પડે ત્યારે ગેસ્ટને બંધ રીતે નિષ્ફળ થવા દો.
તમારી VPN લેબને કેટલી મશીનરી લાયક છે તે નક્કી કરવું પડશે. બે VirtualBox સેગમેન્ટ વચ્ચેની રાઉટેડ ગેટવે VM એ સરનામાનું ભાષાંતર, પરતનો માર્ગ અને તે ફાયરવોલની સ્થિતિ ફરી ઉત્પન્ન કરે છે જેની પાછળ સાચો ક્લાયન્ટ બેસે છે. એક જ ફક્ત-હોસ્ટ સેગમેન્ટ તમને એક નિયંત્રિત દરવાજો આપે છે અને બીજું કંઈ નહીં. ગેટવે આવૃત્તિ ત્રણ ગેસ્ટ અને તમે જાળવો છો તે રાઉટિંગ કોષ્ટકનો ખર્ચ કરે છે; ફક્ત-હોસ્ટ આવૃત્તિ એક ગેસ્ટ અને એક નીતિનો ખર્ચ કરે છે. ત્રણ પ્રશ્નો તેમને અલગ પાડે છે, અને ત્રીજો નક્કી કરે છે કે તમારી કસોટી બિલકુલ પાસ થઈ શકે છે કે નહીં.
કંઈપણ ક્લોન કરતા પહેલાં ત્રણ પ્રશ્નોના જવાબ આપો
VPN સર્વરે શું અવલોકન કરવું પડશે તેનાથી શરૂ કરો. જો સર્વરને એવું સ્રોત સરનામું જોવું પડે જે પરીક્ષણ ગેસ્ટનું ન હોય, તો તેમની વચ્ચે કંઈક ભાષાંતર કરવું પડે, અને તે કંઈક તમે નિયંત્રિત કરો તે રાઉટર હોવું જોઈએ. ફક્ત-હોસ્ટ નેટવર્કિંગ હોસ્ટને ગેસ્ટના સેગમેન્ટ પર એડાપ્ટર આપે છે, અનુવાદક નહીં. પછી જ્યારે ગેસ્ટને બહારનું કંઈક સુધી પહોંચવું હોય, ત્યારે તમે NAT એડાપ્ટર જોડો છો, અને VirtualBoxનું પોતાનું NAT એન્જિન તમને પૂછ્યા વિના સ્રોત ફરીથી લખે છે.
પછી પૂછો કે ગેસ્ટ ટનલ સિવાય બીજું કંઈક સુધી પહોંચી શકે છે કે નહીં. તે જવાબ આંતરિક અથવા ફક્ત-હોસ્ટ પસંદ કરે છે, અને તે જ પ્રશ્ન છે જે મોટાભાગના લેબ-લખાણો છોડી દે છે. અંતે પૂછો કે ટનલ પડે ત્યારે શું થવું જોઈએ, કારણ કે તે ટોપોલોજીને બદલે નીતિ નક્કી કરે છે, અને જે લેબ ફક્ત સુખદ માર્ગ સાબિત કરે છે તેણે લગભગ કંઈ જ પરીક્ષણ કર્યું નથી.
| What the test requires | Routed gateway VM | Host-only guest |
|---|---|---|
| Server sees a translated source address | Yes, from your own MASQUERADE rule | No, VirtualBox NAT does it instead |
| The guest has exactly one egress | Yes, while the second adapter faces the tunnel | Only until a NAT adapter is attached |
| Policy is testable during a tunnel failure | Rules live in one place | Rules live on each guest |
ત્રણ ભૂમિકાઓને આંતરિક નેટવર્ક સાથે જોડો
ત્રણ ગેસ્ટ અને બે નામવાળા સેગમેન્ટ વાપરો, ગેટવે એ જ એકમાત્ર મશીન હોવું જોઈએ જેની પાસે બંને પર એડાપ્ટર હોય:
VBoxManage modifyvm lab-client --nic1 intnet --intnet1 WAN
VBoxManage modifyvm lab-server --nic1 intnet --intnet1 LAN
VBoxManage modifyvm lab-gw --nic1 intnet --intnet1 WAN --nic2 intnet --intnet2 LANઆંતરિક નેટવર્ક માટે અલગ બનાવવાનું પગલું નથી. --intnet1 માંની શબ્દમાળા એ જ સેગમેન્ટ છે: બે મશીન તેને ફક્ત ત્યારે જ વહેંચે છે જ્યારે નામ બરાબર મળે, અને હોસ્ટ પર કંઈપણ તેની સાથે જોડાયેલું નથી. તે જ છેલ્લો ગુણધર્મ લેબ સ્વચ્છ રીતે પુનરાવર્તન થવાનું કારણ છે, કારણ કે હોસ્ટના રૂટ, તેનો પોતાનો VPN ક્લાયન્ટ અને તેનો ફાયરવોલ અકસ્માતે ગેસ્ટ સુધી પહોંચી શકતા નથી. આંતરિક સેગમેન્ટમાં પણ DHCP સર્વર હોતું નથી જ્યાં સુધી તમે એક ઉમેરો નહીં, તેથી સ્થિર સરનામાં સૌથી ટૂંકો માર્ગ છે.
ક્લાયન્ટને ફક્ત તેનું WAN સરનામું આપો, ડિફૉલ્ટ ગેટવે ગેટવેના WAN સરનામા તરફ દોરતું હોવું જોઈએ. સર્વરને LAN સરનામું મળે છે અને ગેટવેના LAN સરનામાને તેના ડિફૉલ્ટ ગેટવે તરીકે વાપરે છે. જે ગેસ્ટ એક સેગમેન્ટ પર બે સરનામાં રાખે છે, અથવા બીજા સેગમેન્ટ તરફ ભટકતો રૂટ ધરાવે છે, તેની પાસે રાઉટરની આસપાસનો માર્ગ છે, અને નીચેની કસોટીઓ તમને ખોટું કહેશે.
VM નામોની બાજુમાં મેં ચાર સરનામાં અને બે સેગમેન્ટ નામોવાળી ટેક્સ્ટ ફાઇલ રાખું છું અને તેને દરેક શેલમાં પેસ્ટ કરું છું. અઠવાડિયા પછી, જ્યારે પ્રોફાઇલ ફેરફાર કંઈક તોડે છે, ત્યારે તે ફાઇલ પ્રોફાઇલ ડિબગ કરવા અને મારી પોતાની સ્મૃતિ ડિબગ કરવા વચ્ચેનો તફાવત છે.
જે સેગમેન્ટ લીક ન થવું જોઈએ તેના માટે આંતરિક અથવા ફક્ત-હોસ્ટ પસંદ કરો
ફક્ત-હોસ્ટ મોડ હોસ્ટ પર જ વર્ચ્યુઅલ એડાપ્ટર બનાવે છે, સામાન્ય રીતે vboxnet0, અને હોસ્ટને ગેસ્ટના સેગમેન્ટ પર સરનામું આપે છે. તે વ્યવસ્થાપન માટે અનુકૂળ છે અને અલગતા કસોટી માટે ઘાતક છે, કારણ કે હોસ્ટ હવે ગેસ્ટ સુધી સીધું પહોંચી શકે છે અને હોસ્ટ બાજુની દરેક સેવા સંભવિત માર્ગ બની જાય છે. આંતરિક મોડમાં હોસ્ટ એડાપ્ટર બિલકુલ હોતું નથી. બંને મોડ નેટવર્ક સેટિંગ્સ પેનલમાં સરળતાથી ભળી જાય છે, તેથી લેબલને બદલે દસ્તાવેજીકૃત તફાવત તપાસો (VirtualBox નેટવર્કિંગ વિગતો પૃષ્ઠ જુઓ).
જે ગેસ્ટને ટનલ વાપરવી જ પડે તેના માટે આંતરિક વધુ સુરક્ષિત ડિફૉલ્ટ છે, ગેટવે એકમાત્ર આઉટલેટ છે. જો તમે ફક્ત-હોસ્ટ રાખો છો, તો હોસ્ટ એડાપ્ટરને વ્યવસ્થાપન માર્ગ ગણો અને તે મોટેથી કહો: હોસ્ટ ગેસ્ટ સુધી પહોંચી શકે છે, અને ગેસ્ટ હોસ્ટને આઉટલેટ તરીકે વાપરી શકવો ન જોઈએ.
VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0તમે સાબિત કરી શકો તે અલગતા એ જ છે જે તમે રૂપરેખાંકિત કરી છે. એક આંતરિક એડાપ્ટર, ગેટવે પર ડિફૉલ્ટ રૂટ અને કોઈ NAT એડાપ્ટર ન ધરાવતા ગેસ્ટ પાસે ગેટવેને ટાળતો કોઈ માર્ગ નથી. ફક્ત-હોસ્ટ એડાપ્ટર અને NAT એડાપ્ટર ધરાવતા ગેસ્ટ પાસે બે માર્ગ છે, અને તેમાંથી ફક્ત એક જ તે માર્ગ છે જે તમે પરીક્ષણ કરવા માગતા હતા.
ગેટવે પર રાઉટ અને ભાષાંતર કરો, પછી તેને બંધ રીતે નિષ્ફળ થવા દો
VirtualBox સેગમેન્ટ વચ્ચે ફોરવર્ડ કરતું નથી; ગેસ્ટ કરે છે. VPN સર્વર VM ગેટવેની પાછળ હોય ત્યારે ફોરવર્ડિંગ સક્ષમ કરો અને ક્લાયન્ટનું ટ્રાફિક સર્વર તરફ નીકળતી વખતે ભાષાંતર કરો:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADEતે નિયમ સાથે સર્વર ક્લાયન્ટને બદલે ગેટવેનું LAN સરનામું જુએ છે, અને કેરિયર NAT પાછળનો સાચો ક્લાયન્ટ હેડ-એન્ડને આવો જ દેખાય છે. sysctl મૂલ્ય /etc/sysctl.d/ માં અને નિયમ ડિસ્ટ્રિબ્યુશન જે ફાયરવોલ સેવા વાપરે તેમાં સાચવો, નહીં તો રીબૂટ લેબને ચૂપચાપ રાઉટેડ પણ અનુવાદિત ન હોય તેવી સ્થિતિમાં પાછી લાવે છે.
ફોરવર્ડિંગ એ અધિકૃતિ નથી. ACCEPT ની ડિફૉલ્ટ FORWARD નીતિ હેઠળ, જે ગેસ્ટનો ડિફૉલ્ટ રૂટ ગેટવે તરફ દોરે છે તે રાઉટિંગ કોષ્ટક જે ઇન્ટરફેસ પસંદ કરે તેમાંથી નીકળે છે, ટનલ હોય કે ન હોય. જો ગેટવેમાં પેકેજ ઇન્સ્ટોલ માટે NAT એડાપ્ટર પણ હોય, તો તે એડાપ્ટર ટનલ પડે તે ક્ષણે કાર્યરત અનએન્ક્રિપ્ટેડ આઉટલેટ છે, અને તમારી ફક્ત-VPN કસોટી ક્યારેય ફક્ત-VPN કસોટી નહોતી.
જ્યારે સર્વર દૂર હોય અને ટનલ ગેટવે પોતે સમાપ્ત કરે, ત્યારે એ જ નિર્ણય ટનલ ઇન્ટરફેસ તરફ દોરે છે, ઇન્ટરનેટ સુધી પહોંચતા NIC તરફ નહીં:
iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTટનલના પોતાના બહારના પરિવહન અને આઉટ-ઓફ-બેન્ડ વ્યવસ્થાપન રૂટને ફોરવર્ડ થતા ટ્રાફિકથી અલગ રાખો. જો ગેટવે સુધારવાનો એકમાત્ર રસ્તો તમે ડિબગ કરી રહ્યા છો તે ટનલ દ્વારા જાય, તો લેબ લોકઆઉટ કસરત બની જાય છે. સીરિયલ કન્સોલ, ફક્ત-હોસ્ટ વ્યવસ્થાપન એડાપ્ટર અથવા જાણીતી સારી સ્થિતિનું સ્નેપશોટ હાથથી તૂટેલા રાઉટરને પુનઃપ્રાપ્ત કરવા કરતાં સસ્તું છે.
માર્ગને હોસ્ટથી નહીં, ગેસ્ટથી ચકાસો
બહારની દિશામાં કામ કરો. ખાતરી કરો કે ક્લાયન્ટ ગેટવેના WAN સરનામા સુધી પહોંચે છે, પછી ગેટવે દ્વારા સર્વર સુધી, પછી VPN પોર્ટ સુધીનું જોડાણ નીકળે છે અને પાછું આવે છે. ગેટવેના બંને ઇન્ટરફેસ પર કેપ્ચર બતાવે છે કે જવાબ આવે છે કે નહીં અને પરત માર્ગ પર છોડી દેવાય છે કે નહીં, જે ફક્ત ક્લાયન્ટ પર કેપ્ચર અલગ તારવી શકતું નથી:
tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194પછી આઉટલેટ સાબિત કરો. ગેસ્ટથી સરનામા-પ્રતિબિંબ સેવાને પૂછો કે તે કયો સ્રોત જુએ છે અને તેને ગેટવેના પોતાના આઉટલેટ સરનામા સાથે સરખાવો; જો જવાબ હોસ્ટના સરનામા સાથે મળે, તો ટનલની આસપાસનો માર્ગ છે. ગેસ્ટ ખરેખર કયો રિઝોલ્વર વાપરે છે તે તપાસો, અને IPv6 અલગથી તપાસો, કારણ કે જે સેગમેન્ટમાં IPv6 સક્ષમ છે જ્યારે ટનલ ફક્ત IPv4 વહન કરે છે તે અકસ્માતે નહીં, ડિઝાઇનથી લીક થાય છે.
અંતે, તેને જાણી જોઈને તોડો. ટનલ બંધ કરો, અથવા તેનો બહારનો પોર્ટ અવરોધો, અને ગેસ્ટથી નવું જોડાણ ખોલો. તે નિષ્ફળ થવું જ જોઈએ, અને કારણ એવું હોવું જોઈએ જેનું તમે નામ આપી શકો: કોઈ રૂટ નથી, અસ્વીકાર નિયમ છે, અથવા રિઝોલ્વર મૃત છે. ટનલ ફરી શરૂ કરો અને ખાતરી કરો કે ગેસ્ટ નેટવર્ક ફરીથી બાંધ્યા વિના સાજો થાય છે. જો Hamachi અથવા ZeroTier જેવું મેશ VPN લેબ વહેંચે છે, તો યાદ રાખો કે બ્રિજ્ડ એડાપ્ટર એડાપ્ટરનું નામ અનુસરે છે, મેશ નહીં, તેથી ક્લાયન્ટ તેનું પોતાનું વર્ચ્યુઅલ એડાપ્ટર ઇન્સ્ટોલ કર્યા પછી બ્રિજ ફરીથી નિર્દેશ કરવું પડશે.
VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>ગેસ્ટની ટનલ હોસ્ટ સાથે વહેંચવી સમસ્યાને પ્રતિબિંબિત કરે છે. હોસ્ટનો ડિફૉલ્ટ રૂટ ગેસ્ટ તરફ દોરવો કામ કરે છે, અને ગેસ્ટની અંદર પ્રોક્સી પણ કામ કરે છે; હોસ્ટ દ્વારા NAT હોસ્ટે શરૂ કરેલા ટ્રાફિક માટે ગેસ્ટની ટનલ વહન કરતું નથી. સેગમેન્ટના નામ અને ફાયરવોલ નિયમો એક જગ્યાએ સાચવો, કાર્યરત સ્થિતિનું સ્નેપશોટ લો, અને સર્વરે અવલોકન કરેલું સ્રોત સરનામું નોંધો. પછીનો પ્રોફાઇલ ફેરફાર ફરીથી બાંધેલી લેબને બદલે એક સ્ક્રિપ્ટ રનનો ખર્ચ કરે છે.