હોસ્ટનો ટ્રાફિક VMમાં VPN દ્વારા રૂટ કરવો: છ તપાસ

છ તપાસ, ક્રમમાં ચલાવવામાં આવે તો, નક્કી કરે છે કે VM તેના પોતાના હોસ્ટ માટે VPN ગેટવે તરીકે કામ કરી શકે છે કે નહીં. હાઇપરવાઇઝર તમારા માટે આમાંથી કંઈ કરતું નથી: ટનલ ગેસ્ટની છે, રૂટ હોસ્ટનો છે, અને તેમની વચ્ચેનું નેટવર્ક સામાન્ય રૂટિંગ છે. હું આ યાદી રાખું છું કારણ કે એક પગલું છોડવાથી હંમેશા એ જ લક્ષણ આવે છે, મૌન, જ્યાં હોસ્ટ ખુશીથી ગેસ્ટને પિંગ કરે છે અને અંદર કંઈ પણ સુધી પહોંચતું નથી.

કારણથી શરૂ કરો. કાં તો કોર્પોરેટ ક્લાયન્ટ ફક્ત ગેસ્ટની અંદર ઇન્સ્ટોલ થાય છે, અથવા નીતિ તેને ત્યાં જ રાખે છે, અને તમને હોસ્ટથી અંદરનું બિલ્ડ સર્વર હજી પણ જોઈએ છે. જો હોસ્ટને પોતાનો ક્લાયન્ટ રાખવાની મંજૂરી હોય, તો તેના બદલે એ કરો: હોસ્ટ પર એક ટનલ હંમેશા બે નેટવર્ક વત્તા NAT કરતાં સારી છે.

તપાસ 1: હોસ્ટને એવી કડી જોઈએ જેને તે સરનામું આપી શકે

હોસ્ટ પાસે ગેસ્ટના બીજા એડેપ્ટર જેવા જ પ્રીફિક્સમાં આવેલું ઇન્ટરફેસ હોવું જોઈએ. VirtualBoxમાં host-only, VMware Workstationમાં host-only અથવા કસ્ટમ VMnet, QEMU/KVMમાં આંતરિક બ્રિજ અથવા tap ઉપકરણ, અને Hyper-Vમાં Internal સ્વિચ — બધા લાયક છે. ગેસ્ટ 192.168.56.2, હોસ્ટ 192.168.56.1, પ્રીફિક્સ 192.168.56.0/24 એ ગોઠવણી છે જે હું લેબમાં વાપરું છું.

QEMUનું યુઝર-મોડ નેટવર્કિંગ (-netdev user, ડિફોલ્ટ SLIRP બેકએન્ડ) અને VirtualBox NAT આ તપાસમાં સંપૂર્ણ નિષ્ફળ જાય છે. ગેસ્ટના પેકેટ હોસ્ટ પરની પ્રોક્સી પ્રક્રિયા સુધી પહોંચે છે, તેથી હોસ્ટ ક્યારેય ગેસ્ટના સરનામાં ધરાવતું ઉપકરણ જોતું નથી અને રૂટ દર્શાવવા માટે તેની પાસે કંઈ નથી. Hyper-Vનું Default Switch પણ એ જ વાર્તા છે. જો હોસ્ટથી ping 192.168.56.2 નિષ્ફળ જાય, તો થોભો: પછી ઉમેરાયેલો કોઈ રૂટ તેને સુધારશે નહીં.

તપાસ 2: ગેસ્ટ ફોરવર્ડ કરે છે અને અનુવાદ કરે છે

હોસ્ટથી આવતા પેકેટ host-only સ્રોત સરનામા અને આંતરિક ગંતવ્ય સાથે આવે છે, તેથી ગેસ્ટે તેમને ફોરવર્ડ કરવા પડે અને પછી પોતાના ટનલ સરનામા પાછળ છુપાવવા પડે. Linux ગેસ્ટમાં તેનો અર્થ ફોરવર્ડિંગ, FORWARD accept જોડી, અને ટનલ તરફ source NAT છે:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.168.56.0/24 -o tun0 -j MASQUERADE

MASQUERADE નિયમ એ ભાગ છે જે લોકો છોડી દે છે. કોર્પોરેટ રાઉટરને ભાગ્યે જ ખબર હોય છે કે 192.168.56.0/24 અસ્તિત્વમાં છે; નિયમ સાથે, આંતરિક સર્વર ગેસ્ટનું ટનલ સરનામું જુએ છે અને તેને જવાબ આપે છે, અને જવાબ ગેસ્ટ સુધી પાછો રસ્તો શોધી લે છે.

Windows ગેસ્ટ વધુ અણઘડ છે. SYSTEM\CurrentControlSet\Services\Tcpip\Parameters હેઠળ IPEnableRouter=1 અનુવાદ વિના ફોરવર્ડિંગ ચાલુ કરે છે, તેથી તે ફક્ત ત્યાં જ કામ કરે છે જ્યાં કોર્પોરેટ રૂટિંગ પહેલેથી તમારા host-only પ્રીફિક્સ તરફ પાછું દર્શાવે છે. Internet Connection Sharing અનુવાદ કરે છે, પણ વહેંચાયેલા એડેપ્ટરને 192.168.137.1 પર ફરી ક્રમાંકિત કરે છે, તેથી હોસ્ટ રૂટ લખતા પહેલા તેણે ખરેખર લીધેલું સરનામું વાંચો.

તપાસ 3: હોસ્ટ રૂટ ગેસ્ટનું નામ લે છે, ટનલનું નહીં

ફક્ત એ પ્રીફિક્સ ગેસ્ટ દ્વારા મોકલો જે હોસ્ટને જોઈએ છે. Linux પર પ્રતિ પ્રીફિક્સ એક રૂટ પૂરતો છે અને તે સ્વચ્છ રીતે પાછો ફરે છે:

sudo ip route add 10.20.0.0/16 via 192.168.56.2
ip route get 10.20.30.40

Windows પર સમાન છે route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. પરીક્ષણ દરમિયાન -p છોડી દો, જેથી ખરાબ રૂટ રીબૂટ પર મરી જાય, અને રસ્તો કામ કરે ત્યારે તે ઉમેરો. હોસ્ટનો ડિફોલ્ટ રૂટ દૂર કરશો નહીં જ્યાં સુધી હોસ્ટની દરેક એપ્લિકેશને ટનલ વાપરવાની હોય; જો ખરેખર ફુલ ટનલ જરૂરી હોય, તો બે /1 રૂટ ઉમેરો અને હાઇપરવાઇઝર નેટવર્ક તરફનો સીધો રૂટ રાખો:

sudo ip route add 0.0.0.0/1 via 192.168.56.2
sudo ip route add 128.0.0.0/1 via 192.168.56.2

Windows હોસ્ટ પર ઇન્ટરફેસ મેટ્રિક પણ તપાસો. host-only એડેપ્ટર નિષ્ક્રિય હતું ત્યારે ઉમેરાયેલો રૂટ ટેબલમાં રહે છે પણ ક્યારેય ટ્રાફિક વહન કરતો નથી, અને ઓછી મેટ્રિક ધરાવતો બીજો એડેપ્ટર એ જ પ્રીફિક્સ માટેની શોધ જીતી શકે છે.

તપાસ 4: DNS રૂટને અનુસરે છે, ટનલના ડિફોલ્ટને નહીં

રૂટ પેકેટ ખસેડે છે; રિઝોલ્વર નક્કી કરે છે કે કયા નામ પેકેટ બનાવે છે. હોસ્ટના રિઝોલ્વરને બદલવાને બદલે કોર્પોરેટ રિઝોલ્વરને કોર્પોરેટ ઝોન સુધી મર્યાદિત કરો, અને તેને એવા DNS સર્વર તરફ દર્શાવો જ્યાં નવો રૂટ પહેલેથી પહોંચે છે. હોસ્ટ પર systemd-resolved સાથે:

resolvectl dns eth1 10.20.0.53
resolvectl domain eth1 '~corp.example.com'

Windows પર નામ રિઝોલ્યુશન પોલિસી ટેબલની એક એન્ટ્રી એ જ કામ કરે છે: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. જો ગેસ્ટ host-only સરનામા પર પોતાનું રિઝોલ્વર ચલાવે છે, તો તેના બદલે એ સરનામું વાપરો, પણ તે loopback પર નહીં, 192.168.56.2 પર જવાબ આપે છે તેની ખાતરી કર્યા પછી જ.

પછી ધીમા પૃષ્ઠો માટે DNSને દોષ આપતા પહેલા MTU તપાસો. ટનલ ઇન્ટરફેસ હોસ્ટના 1500-બાઇટ ઇન્ટરફેસ કરતાં નાનું છે, તેથી DF બિટ સેટ કરીને પૂર્ણ-માપના સેગમેન્ટ મોકલતા હોસ્ટને તે ગેસ્ટની અંદર ક્યાંક પડી જતા દેખાય છે. ક્લાસિક લક્ષણ કામ કરતું ping અને TLS હેન્ડશેક પછી અટકી જતી આંતરિક વેબ એપ્લિકેશન છે. ગેસ્ટના ફોરવર્ડ માર્ગમાં MSS ક્લેમ્પ કરો:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

તપાસ 5: બંને છેડેથી ચકાસો

હોસ્ટથી, આંતરિક સરનામા તરફ traceroute અથવા tracert પ્રથમ હોપ તરીકે ભૌતિક ગેટવે નહીં, 192.168.56.2 દર્શાવવું જોઈએ. ગેસ્ટમાં, એ જ પ્રયાસ બહાર જતો જુઓ: tcpdump -ni any host 10.20.30.40 host-only બાજુ પર ફોરવર્ડ થયેલી વિનંતી અને ટનલ પર અનુવાદિત વિનંતી દર્શાવે છે. જે વિનંતી બહાર જાય, પાછી આવે અને છતાં હોસ્ટને મૌન રાખે તે પરત માર્ગ તરફ ઈશારો કરે છે.

બે નિષ્ફળતાઓ તેમાંથી મોટા ભાગની સમજૂતી આપે છે. કાં તો ગેસ્ટની ટનલ host-only પ્રીફિક્સ માટે પરત રૂટ ધરાવતી નથી કારણ કે NAT નિયમ ખૂટે છે, અથવા હોસ્ટ રૂટ એવા સરનામા તરફ દર્શાવે છે જે રીબૂટ પછી ગેસ્ટ પાસે રહેતું નથી. ગયા સત્રની નોંધો પર ભરોસો કરવાને બદલે ip -br addr અને ip route get સાથે સરનામાં ફરી વાંચો.

તપાસ 6: તેને રીબૂટ અને હાઇપરવાઇઝર અપગ્રેડમાં ટકી રહેવા દો

બંને અર્ધ ટકાવો: હોસ્ટ પર netplan અથવા NetworkManager રૂટ ગોઠવણી, Windows પર route add ... -p, અને /etc/sysctl.d/ માં net.ipv4.ip_forward=1 ઉપરાંત ગેસ્ટમાં ફરી લોડ થતો ફાયરવોલ નિયમસેટ. ગોઠવણી ચકાસાય કે તરત જ, આગામી કોર્પોરેટ ક્લાયન્ટ અપડેટ આવતા પહેલા ગેસ્ટનો સ્નેપશોટ લો.

હાઇપરવાઇઝર તેના એડેપ્ટર ફરી બનાવે ત્યારે host-only નેટવર્ક ફરી ક્રમાંકિત થાય છે, જે 192.168.56.0/24 પર બનેલા દરેક રૂટ અને NAT નિયમને ચૂપચાપ અમાન્ય કરે છે. અપગ્રેડ પછી પહેલી ત્રણ તપાસ ક્રમમાં ફરી ચલાવો; તે એક મિનિટ લે છે અને એ કિસ્સો પકડે છે જ્યાં હોસ્ટ પાસે તેનો રૂટ હજી છે જ્યારે ગેસ્ટ નવા સબનેટ પર ગયું છે.

IPv6ને પોતાનો પાસ જોઈએ. ip6tables નિયમો, AAAA રેકોર્ડ અને બીજો હોસ્ટ રૂટ પરિવાર IPv4 ગોઠવણીને અનુસરતા નથી, અને IPv6 દ્વારા પહોંચી શકાય તેવી કોર્પોરેટ સેવા IPv4 કામ કરતી હોય ત્યારે કાયમ તૂટેલી દેખાશે.

પાસ થાય કે નહીં, ક્રમમાં: હોસ્ટ ગેસ્ટના host-only સરનામાને પિંગ કરી શકે છે; ગેસ્ટ ટનલ તરફ ફોરવર્ડ અને MASQUERADE કરે છે; ip route get આંતરિક પ્રીફિક્સ માટે ગેટવે તરીકે ગેસ્ટ પરત આપે છે; કોર્પોરેટ નામો મર્યાદિત રિઝોલ્વર દ્વારા રિઝોલ્વ થાય છે; traceroute ગેસ્ટને પ્રથમ દર્શાવે છે; અને એ જ છ જવાબ રીબૂટમાં ટકી રહે છે.