Hosto srauto maršrutizavimas per VPN VM: šeši patikrinimai

Šeši iš eilės atlikti patikrinimai nusprendžia, ar VM gali būti VPN tinklų sietuvas savo pačios hostui. Hipervizorius nieko to už jus nedaro: tunelis priklauso svečiui, maršrutas priklauso hostui, o tinklas tarp jų yra įprastas maršrutizavimas. Laikausi šio sąrašo, nes praleidus vieną žingsnį visada gaunamas tas pats simptomas, tyla, kai hostas linksmai pingina svečią ir nepasiekia nieko vidinio.

Pradėkite nuo priežasties. Arba įmonės klientas įdiegiamas tik svečio viduje, arba politika jį ten laiko, o jums vis tiek reikia vidinio build serverio iš hosto. Jei hostui leidžiamas savas klientas, darykite būtent tai: vienas tunelis hoste visada nugali du tinklus plius NAT.

Patikrinimas 1: hostui reikia sąsajos, kuriai jis gali priskirti adresą

Hostas turi turėti sąsają tame pačiame prefikse kaip antrasis svečio adapteris. Host-only VirtualBox, host-only arba pasirinktinis VMnet VMware Workstation, vidinis tiltas arba tap įrenginys QEMU/KVM ir Internal komutatorius Hyper-V — visi tinka. Svečias 192.168.56.2, hostas 192.168.56.1, prefiksas 192.168.56.0/24 yra išdėstymas, kurį naudoju laboratorijose.

QEMU vartotojo režimo tinklas (-netdev user, numatytasis SLIRP backend) ir VirtualBox NAT visiškai nepraeina šio patikrinimo. Svečio paketai pasiekia tarpinio serverio procesą hosts, todėl hostas niekada nemato įrenginio, kuris neštų svečio adresus, ir neturi į ką nukreipti maršruto. Hyper-V Default Switch yra ta pati istorija. Jei ping 192.168.56.2 iš hosto nepavyksta, sustokite: joks vėliau pridėtas maršrutas to nesutvarkys.

Patikrinimas 2: svečias persiunčia ir išverčia

Paketai iš hosto ateina su host-only šaltinio adresu ir vidine paskirtimi, todėl svečias turi juos persiųsti ir paskui paslėpti už savo tunelio adreso. Linux svečiame tai reiškia persiuntimą, FORWARD accept porą ir source NAT link tunelio:

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 taisyklė yra ta dalis, kurią žmonės praleidžia. Įmonių maršrutizatoriai retai žino, kad 192.168.56.0/24 egzistuoja; su taisykle vidiniai serveriai mato svečio tunelio adresą ir į jį atsako, o atsakymas randa kelią atgal į svečią.

Windows svečias yra nepatogesnis. IPEnableRouter=1 po SYSTEM\CurrentControlSet\Services\Tcpip\Parameters įjungia persiuntimą be vertimo, todėl jis veikia tik ten, kur įmonės maršrutizavimas jau nurodo atgal į jūsų host-only prefiksą. Internet Connection Sharing verčia, tačiau bendrinamą adapterį pernumeruoja į 192.168.137.1, tad perskaitykite adresą, kurį jis iš tikrųjų paėmė, prieš rašydami hosto maršrutus.

Patikrinimas 3: hosto maršrutai įvardija svečią, o ne tunelį

Per svečią siųskite tik tuos prefiksus, kurių reikia hostui. Linux vieno maršruto prefiksui pakanka, ir jis švariai atsukamas:

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

Windows atitikmuo yra route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Testuodami palikite -p išjungtą, kad blogas maršrutas mirtų perkraunant, ir pridėkite jį, kai kelias veiks. Nepašalinkite numatytojo hosto maršruto, nebent kiekviena hosto programa turėtų naudoti tunelį; jei pilnas tunelis tikrai yra reikalavimas, pridėkite du /1 maršrutus ir palikite tiesioginį maršrutą į hipervizoriaus tinklą:

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 hoste patikrinkite ir sąsajos metriką. Maršrutas, pridėtas, kai host-only adapteris buvo išjungtas, lieka lentelėje, bet niekada neperduoda srauto, o antras adapteris su mažesne metrika gali laimėti to paties prefikso paiešką.

Patikrinimas 4: DNS seka maršrutą, o ne tunelio numatytąjį

Maršrutai judina paketus; sprendėjas nusprendžia, kurie vardai sukuria paketus. Apribokite įmonės sprendėją įmonės zonai, užuot pakeitę hosto sprendėją, ir nukreipkite jį į DNS serverį, kurį naujas maršrutas jau pasiekia. Kai hosts veikia systemd-resolved:

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

Windows vardo sprendimo politikos lentelės įrašas atlieka tą patį darbą: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Jei svečias savo sprendėją paleidžia host-only adresu, naudokite tą adresą, bet tik patikrinę, kad jis atsako 192.168.56.2, o ne loopback.

Tada patikrinkite MTU, prieš kaltindami DNS lėtais puslapiais. Tunelio sąsaja mažesnė už hosto 1500 baitų sąsają, todėl hostas, siunčiantis viso dydžio segmentus su įjungtu DF bitu, juos kažkur svečio viduje pameta. Klasikinis simptomas yra veikiantis ping ir vidinė žiniatinklio programa, kuri sustoja po TLS rankos paspaudimo. Suveržkite MSS svečio persiuntimo kelyje:

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

Patikrinimas 5: patikrinkite iš abiejų galų

Iš hosto traceroute arba tracert į vidinį adresą turėtų rodyti 192.168.56.2 kaip pirmą šuolį, o ne fizinį tinklų sietuvą. Svečiame stebėkite, kaip tas pats bandymas išeina: tcpdump -ni any host 10.20.30.40 rodo persiųstą užklausą host-only pusėje ir išverstą tunelyje. Užklausa, kuri išeina, grįžta ir vis tiek palieka hostą tylų, nurodo atgalinį kelią.

Du gedimai paaiškina didžiąją dalį to. Arba svečio tunelis neturi atgalinio maršruto host-only prefiksui, nes trūksta NAT taisyklės, arba hosto maršrutas nurodo adresą, kurio svečias po perkrovimo nebeturi. Perskaitykite adresus dar kartą su ip -br addr ir ip route get, užuot pasitikėję praėjusios sesijos užrašais.

Patikrinimas 6: padarykite, kad jis išgyventų perkrovimą ir hipervizoriaus atnaujinimą

Išsaugokite abi puses: netplan arba NetworkManager maršrutų konfigūraciją hosts, route add ... -p Windows ir net.ipv4.ip_forward=1 faile /etc/sysctl.d/ bei ugniasienės taisyklių rinkinį, kuris svečiame įkeliamas iš naujo. Padarykite svečio snapshot, kai tik konfigūracija patvirtinama, prieš ateinant kitam įmonės kliento atnaujinimui.

Host-only tinklai pernumeruojami, kai hipervizorius iš naujo sukuria savo adapterius, ir tai tyliai panaikina kiekvieną maršrutą bei NAT taisyklę, pastatytą ant 192.168.56.0/24. Po atnaujinimo pakartokite pirmus tris patikrinimus iš eilės; tai užima minutę ir pagauna atvejį, kai hostas dar turi savo maršrutą, o svečias persikėlė į naują potinklį.

IPv6 reikia atskiro praėjimo. ip6tables taisyklės, AAAA įrašai ir antroji hosto maršrutų šeima neseka IPv4 sąrankos, o įmonės paslauga, pasiekiama per IPv6, atrodys visam laikui sugedusi, kol IPv4 veikia.

Praėjo ar ne, iš eilės: hostas gali pinginti svečio host-only adresą; svečias persiunčia ir atlieka MASQUERADE link tunelio; ip route get grąžina svečią kaip tinklų sietuvą vidiniam prefiksui; įmonės vardai išsprendžiami per apribotą sprendėją; traceroute rodo svečią pirmą; ir tie patys šeši atsakymai išgyvena perkrovimą.