Enkursigado de gastiga trafiko tra VPN en VM: ses kontroloj

Ses kontroloj, plenumitaj laŭ ordo, decidas ĉu VM povas roli kiel VPN-enirejo por sia propra gastiganto. La hipervizoro faras nenion el tio por vi: la gasto posedas la tunelon, la gastiganto posedas vojon, kaj la reto inter ili estas ordinara enkursigado. Mi tenas la liston ĉar preterlasi unu paŝon ĉiam donas la saman simptomon, silenton, kie la gastiganto ĝoje pings la gaston kaj atingas nenion internan.

Komencu per la kialo. Aŭ la kompania kliento instaliĝas nur ene de la gasto, aŭ la politiko tenas ĝin tie, kaj vi ankoraŭ bezonas la internan konstruan servilon de la gastiganto. Se la gastiganto rajtas havi sian propran klienton, faru tion anstataŭe: unu tunelo en la gastiganto ĉiam superas du retojn plus NAT.

Kontrolo 1: la gastiganto bezonas ligon, al kiu ĝi povas doni adreson

La gastiganto devas posedi interfacon en la sama prefikso kiel la dua adaptilo de la gasto. Host-only en VirtualBox, host-only aŭ propra VMnet en VMware Workstation, interna ponto aŭ tap-aparato en QEMU/KVM, kaj Internal-ŝaltilo en Hyper-V ĉiuj taŭgas. Gasto 192.168.56.2, gastiganto 192.168.56.1, prefikso 192.168.56.0/24 estas la aranĝo, kiun mi uzas en laboratorioj.

QEMU-retado en uzantreĝimo (-netdev user, la defaŭlta SLIRP-motoro) kaj VirtualBox NAT tute malsukcesas ĉi tiun kontrolon. La pakaĵoj de la gasto atingas prokuran procezon en la gastiganto, do la gastiganto neniam vidas aparaton portantan la adresojn de la gasto kaj havas nenion, al kio direkti vojon. La Default Switch de Hyper-V estas la sama historio. Se ping 192.168.56.2 de la gastiganto malsukcesas, haltu: neniu vojo aldonita poste riparos tion.

Kontrolo 2: la gasto plusendas kaj tradukas

Pakaĵoj de la gastiganto alvenas kun host-only fontadreso kaj interna celo, do la gasto devas plusendi ilin kaj poste kaŝi ilin malantaŭ sia tunela adreso. En Linux-gasto tio signifas plusendadon, paron da FORWARD accept reguloj kaj source NAT direkte al la tunelo:

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

La regulo MASQUERADE estas la parto, kiun homoj preterlasas. Kompaniaj enkursigiloj malofte scias, ke 192.168.56.0/24 ekzistas; kun la regulo, internaj serviloj vidas la tunelan adreson de la gasto kaj respondas al ĝi, kaj la respondo trovas sian vojon reen al la gasto.

Windows-gasto estas pli mallerta. IPEnableRouter=1 sub SYSTEM\CurrentControlSet\Services\Tcpip\Parameters ŝaltas plusendadon sen tradukado, do ĝi funkcias nur tie, kie kompania enkursigado jam montras reen al via host-only prefikso. Internet Connection Sharing ja tradukas, sed ĝi renumeras la kunhavatan adaptilon al 192.168.137.1, do legu la adreson, kiun ĝi efektive prenis, antaŭ ol skribi gastigantajn vojojn.

Kontrolo 3: gastigantaj vojoj nomas la gaston, ne la tunelon

Sendu tra la gasto nur la prefiksojn, kiujn la gastiganto bezonas. En Linux unu vojo po prefikso sufiĉas kaj ĝi renversiĝas pure:

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

En Windows la ekvivalento estas route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Lasu eksteren -p dum vi ankoraŭ testas, por ke malbona vojo mortu ĉe restartiĝo, kaj aldonu ĝin, kiam la vojo funkcias. Ne forigu la defaŭltan vojon de la gastiganto krom se ĉiu aplikacio en la gastiganto devus uzi la tunelon; se plena tunelo vere estas la postulo, aldonu la du /1 vojojn kaj konservu la rektan vojon al la hipervizora reto:

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

En Windows-gastiganto kontrolu ankaŭ la interfacan metrikon. Vojo aldonita dum la host-only adaptilo estis malŝaltita restas en la tabelo sed neniam portas trafikon, kaj dua adaptilo kun pli malalta metriko povas gajni la serĉon por la sama prefikso.

Kontrolo 4: DNS sekvas la vojon, ne la tunelan defaŭlton

Vojoj movas pakaĵojn; la solvilo decidas, kiuj nomoj produktas pakaĵojn. Limigu la kompanian solvilon al la kompania zono anstataŭ anstataŭigi la solvilon de la gastiganto, kaj direktu ĝin al DNS-servilo, kiun la nova vojo jam atingas. Kun systemd-resolved en la gastiganto:

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

En Windows, ero en la nomrezolucia politika tabelo faras la saman laboron: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Se la gasto funkciigas sian propran solvilon ĉe la host-only adreso, uzu tiun adreson anstataŭe, sed nur post konfirmi, ke ĝi respondas ĉe 192.168.56.2 kaj ne ĉe loopback.

Poste kontrolu la MTU antaŭ ol kulpigi DNS pri malrapidaj paĝoj. La tunela interfaco estas pli malgranda ol la 1500-bajta interfaco de la gastiganto, do gastiganto, kiu sendas plengrandajn segmentojn kun la DF-bito ŝaltita, vidas ilin faligitaj ie ene de la gasto. La klasika simptomo estas funkcianta ping kaj interna retaplikaĵo, kiu haltas post la TLS-manpremo. Limigu la MSS en la plusenda vojo de la gasto:

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

Kontrolo 5: kontrolu de ambaŭ flankoj

De la gastiganto, traceroute aŭ tracert al interna adreso devus montri 192.168.56.2 kiel la unuan salteton, ne la fizikan enirejon. En la gasto, observu la saman provon eliri: tcpdump -ni any host 10.20.30.40 montras la plusenditan peton ĉe la host-only flanko kaj la tradukitan ĉe la tunelo. Peto, kiu eliras, revenas kaj tamen lasas la gastiganton silenta, indikas la revenan vojon.

Du malsukcesoj klarigas la plej grandan parton de tio. Aŭ la tunelo de la gasto portas neniun revenan vojon por la host-only prefikso ĉar mankas la NAT-regulo, aŭ la gastiganta vojo montras al adreso, kiun la gasto jam ne havas post restartiĝo. Relu la adresojn per ip -br addr kaj ip route get anstataŭ fidi notojn el la antaŭa seanco.

Kontrolo 6: igi ĝin postvivi restartiĝon kaj hipervizoran ĝisdatigon

Daŭrigu ambaŭ duonojn: netplan aŭ NetworkManager voja agordo en la gastiganto, route add ... -p en Windows, kaj net.ipv4.ip_forward=1 en /etc/sysctl.d/ plus fajroŝirma regularo, kiu reŝargiĝas en la gasto. Faru snapshot de la gasto tuj kiam la agordo kontroliĝas, antaŭ ol alvenos la sekva kompania klienta ĝisdatigo.

Host-only retoj renumeriĝas kiam hipervizoro rekreas siajn adaptilojn, kio silente malvalidigas ĉiun vojon kaj NAT-regulon konstruitan sur 192.168.56.0/24. Post ĝisdatigo, ripetu la unuajn tri kontrolojn laŭ ordo; tio kostas minuton kaj kaptas la kazon, kiam la gastiganto ankoraŭ havas sian vojon dum la gasto transiris al nova subreto.

IPv6 bezonas sian propran trapason. Reguloj de ip6tables, AAAA-rikanoj kaj dua gastiganta voja familio ne sekvas la IPv4-agordon, kaj kompania servo atingebla per IPv6 aspektos konstante rompita dum IPv4 funkcias.

Pasita aŭ ne, laŭ ordo: la gastiganto povas pings la host-only adreson de la gasto; la gasto plusendas kaj faras MASQUERADE direkte al la tunelo; ip route get redonas la gaston kiel enirejon por la interna prefikso; kompaniaj nomoj solviĝas per la limigita solvilo; traceroute montras la gaston unue; kaj la samaj ses respondoj postvivas restartiĝon.