Kuelekeza trafiki ya mwenyeji kupitia VPN katika VM: ukaguzi sita

Ukaguzi sita, unaofanywa kwa mfuatano, huamua kama VM inaweza kuwa lango la VPN kwa mwenyeji wake mwenyewe. Hypervisor haifanyi lolote la haya kwa ajili yako: tunnel ni mali ya mgeni, njia ni mali ya mwenyeji, na mtandao kati yao ni uelekezaji wa kawaida. Ninalinda orodha hii kwa sababu kuruka hatua moja daima hutoa dalili hiyo hiyo, ukimya, ambapo mwenyeji anapinga mgeni kwa furaha na hafiki kwenye kitu chochote cha ndani.

Anza na sababu. Ama mteja wa kampuni husakinishwa ndani ya mgeni pekee, au sera humweka hapo, na bado unahitaji seva ya ndani ya build kutoka kwa mwenyeji. Iwapo mwenyeji anaruhusiwa kuwa na mteja wake mwenyewe, fanya hivyo badala yake: tunnel moja kwa mwenyeji hushinda kila mara mitandao miwili na NAT.

Ukaguzi 1: mwenyeji anahitaji kiungo anachoweza kukipa anwani

Mwenyeji lazima awe na kiungo cha mtandao katika kiambishi sawa na adapta ya pili ya mgeni. Host-only katika VirtualBox, host-only au VMnet maalum katika VMware Workstation, daraja la ndani au kifaa cha tap katika QEMU/KVM, na swichi ya Internal katika Hyper-V zote zinatoshea. Mgeni 192.168.56.2, mwenyeji 192.168.56.1, kiambishi 192.168.56.0/24 ndiyo mpangilio ninaotumia maabara.

Mtandao wa QEMU wa hali ya mtumiaji (-netdev user, backend ya SLIRP chaguo-msingi) na NAT ya VirtualBox hushindwa kabisa ukaguzi huu. Pakiti za mgeni hufika kwenye mchakato wa proksi kwenye mwenyeji, kwa hivyo mwenyeji huwa haoni kifaa kinachobeba anwani za mgeni na hana mahali pa kuelekeza njia. Default Switch ya Hyper-V ni hadithi hiyo hiyo. Iwapo ping 192.168.56.2 kutoka kwa mwenyeji inashindwa, simama: hakuna njia itakayoongezwa baadaye itakayorekebisha hilo.

Ukaguzi 2: mgeni hupeleka na hutafsiri

Pakiti kutoka kwa mwenyeji hufika na anwani chanzo ya host-only na marudio ya ndani, kwa hivyo mgeni lazima azipitishe kisha azifiche nyuma ya anwani ya tunnel yake. Kwenye mgeni wa Linux hiyo inamaanisha upelekaji, jozi ya FORWARD accept, na source NAT kuelekea tunnel:

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

Kanuni ya MASQUERADE ndiyo sehemu ambayo watu huiacha. Ruta za kampuni mara chache hujua kwamba 192.168.56.0/24 ipo; pamoja na kanuni, seva za ndani huona anwani ya tunnel ya mgeni na kujibu, na jibu hupata njia ya kurudi kwa mgeni.

Mgeni wa Windows ni mzito zaidi. IPEnableRouter=1 chini ya SYSTEM\CurrentControlSet\Services\Tcpip\Parameters huwasha upelekaji bila tafsiri, kwa hivyo hufanya kazi tu pale uelekezaji wa kampuni tayari unaelekeza kurudi kwenye kiambishi chako cha host-only. Internet Connection Sharing hutafsiri, lakini huweka nambari mpya kwa adapta iliyoshirikiwa kuwa 192.168.137.1, kwa hivyo soma anwani ambayo imechukua kwa kweli kabla ya kuandika njia za mwenyeji.

Ukaguzi 3: njia za mwenyeji humtaja mgeni, si tunnel

Tuma kupitia mgeni viambishi pekee ambavyo mwenyeji anahitaji. Kwenye Linux njia moja kwa kila kiambishi inatosha na hurudi kwa usafi:

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

Kwenye Windows kifananisho ni route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Acha -p nje wakati bado unajaribu, ili njia mbaya ikate wakati wa kuwasha upya, na uiongeze njia ikifanya kazi. Usiondoe njia chaguo-msingi ya mwenyeji isipokuwa kila programu kwenye mwenyeji itumie tunnel; ikiwa tunnel kamili ndiyo sharti kweli, ongeza njia mbili za /1 na uendelee na njia ya moja kwa moja kuelekea mtandao wa hypervisor:

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

Kwenye mwenyeji wa Windows, angalia pia metriki ya kiungo. Njia iliyoongezwa wakati adapta ya host-only ilikuwa imezimwa hubaki kwenye jedwali lakini haibebi trafiki kamwe, na adapta ya pili yenye metriki ndogo inaweza kushinda utafutaji wa kiambishi kimoja.

Ukaguzi 4: DNS hufuata njia, si chaguo-msingi la tunnel

Njia husogeza pakiti; kitatuzi huamua majina yapi huzalisha pakiti. Punguza kitatuzi cha kampuni kwenye eneo la kampuni badala ya kubadilisha kitatuzi cha mwenyeji, na uelekeze kwenye seva ya DNS ambayo njia mpya tayari inaifikia. Ukiwa na systemd-resolved kwenye mwenyeji:

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

Kwenye Windows ingizo kwenye jedwali la sera ya utatuzi wa majina hufanya kazi hiyo hiyo: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Iwapo mgeni anaendesha kitatuzi chake kwenye anwani ya host-only, tumia anwani hiyo badala yake, lakini tu baada ya kuthibitisha kwamba inajibu kwenye 192.168.56.2 na si kwenye loopback.

Kisha angalia MTU kabla ya kulaumu DNS kwa kurasa za polepole. Kiungo cha tunnel ni kidogo kuliko kiungo cha baiti 1500 cha mwenyeji, kwa hivyo mwenyeji anayetuma sehemu za ukubwa kamili akiwa amewasha biti ya DF huona zikitupwa mahali fulani ndani ya mgeni. Dalili ya kawaida ni ping inayofanya kazi na programu ya wavuti ya ndani inayokwama baada ya kupeana mkono wa TLS. Kaza MSS kwenye njia ya upelekaji wa mgeni:

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

Ukaguzi 5: thibitisha kutoka pande zote mbili

Kutoka kwa mwenyeji, traceroute au tracert kuelekea anwani ya ndani inapaswa kuonyesha 192.168.56.2 kama hop ya kwanza, si lango la kimwili. Ndani ya mgeni, tazama jaribio hilo hilo likitoka: tcpdump -ni any host 10.20.30.40 huonyesha ombi lililopitishwa upande wa host-only na lile lililotafsiriwa kwenye tunnel. Ombi linalotoka, likarudi na bado likamwacha mwenyeji kimya linaelekeza kwenye njia ya kurudi.

Vikosa viwili hufafanua sehemu kubwa ya hilo. Ama tunnel ya mgeni haibebi njia ya kurudi kwa kiambishi cha host-only kwa sababu kanuni ya NAT haipo, au njia ya mwenyeji inaelekeza kwenye anwani ambayo mgeni hana tena baada ya kuwasha upya. Soma tena anwani kwa ip -br addr na ip route get badala ya kuamini maelezo ya kikao kilichopita.

Ukaguzi 6: ifanye istahimili kuwasha upya na kuboreshwa kwa hypervisor

Weka sehemu zote mbili kudumu: usanidi wa njia za netplan au NetworkManager kwenye mwenyeji, route add ... -p kwenye Windows, na net.ipv4.ip_forward=1 ndani ya /etc/sysctl.d/ pamoja na seti ya kanuni za firewall zinazopakiwa upya ndani ya mgeni. Chukua snapshot ya mgeni mara tu usanidi unapothibitishwa, kabla ya sasisho lijalo la mteja wa kampuni kufika.

Mitandao ya host-only hupewa nambari mpya wakati hypervisor inaunda upya adapta zake, jambo ambalo hubatilisha kwa kimya kila njia na kanuni ya NAT iliyojengwa juu ya 192.168.56.0/24. Baada ya kuboresha, endesha tena ukaguzi tatu wa kwanza kwa mfuatano; hiyo huchukua dakika moja na hukamata hali ambapo mwenyeji bado ana njia yake wakati mgeni amehamia subnet mpya.

IPv6 inahitaji mzunguko wake yenyewe. Kanuni za ip6tables, rekodi za AAAA na familia ya pili ya njia za mwenyeji hazifuati usanidi wa IPv4, na huduma ya kampuni inayofikiwa kwa IPv6 itaonekana imevunjika daima wakati IPv4 inafanya kazi.

Imefaulu au la, kwa mfuatano: mwenyeji anaweza kupinga anwani ya host-only ya mgeni; mgeni hupeleka na kufanya MASQUERADE kuelekea tunnel; ip route get hurudisha mgeni kama lango la kiambishi cha ndani; majina ya kampuni hutatuliwa kupitia kitatuzi kilichopunguzwa; traceroute huonyesha mgeni kwanza; na majibu yale yale sita hustahimili kuwasha upya.