Hosti liikluse suunamine VPN-i kaudu VM-is: kuus kontrolli

Kuus järjestikku tehtud kontrolli otsustavad, kas VM saab olla oma hosti VPN-lüüs. Hüpervisor ei tee sellest midagi teie eest: tunnel kuulub külalisele, marsruut hostile ja nende vaheline võrk on tavaline marsruutimine. Hoian nimekirja, sest ühe sammu vahelejätmine annab alati sama sümptomi, vaikuse, kus host pingib külalist rõõmsalt ega jõua mitte millegi sisemiseni.

Alustage põhjusest. Kas ettevõtte klient paigaldatakse ainult külalise sisse või hoiab poliitika seda seal, ja teil on ikkagi vaja sisemist build-serverit hostist. Kui hostil on lubatud oma klient, tehke seda selle asemel: üks tunnel hostis võidab iga kord kaks võrku pluss NAT.

Kontroll 1: hostil on vaja linki, millele saab aadressi anda

Hostil peab olema liides samas prefiksis kui külalise teine adapter. Host-only VirtualBoxis, host-only või kohandatud VMnet VMware Workstationis, sisemine sild või tap-seade QEMU/KVM-is ja Internal-lüliti Hyper-V-s kvalifitseeruvad kõik. Külaline 192.168.56.2, host 192.168.56.1, prefiks 192.168.56.0/24 on paigutus, mida laborites kasutan.

QEMU kasutajarežiimi võrk (-netdev user, vaikimisi SLIRP-taustaprogramm) ja VirtualBoxi NAT kukuvad selles kontrollis täielikult läbi. Külalise paketid jõuavad hostis puhverserveri protsessini, nii et host ei näe kunagi seadet, mis kannab külalise aadresse, ja tal pole midagi, millele marsruuti osutada. Hyper-V Default Switch on sama lugu. Kui ping 192.168.56.2 hostist ebaõnnestub, lõpetage: ükski hiljem lisatud marsruut ei paranda seda.

Kontroll 2: külaline edastab ja tõlgib

Hostist saabuvad paketid host-only lähteaadressi ja sisemise sihtkohaga, seega peab külaline need edastama ja seejärel oma tunneli aadressi taha peitma. Linuxi külalises tähendab see edastamist, FORWARD accept paari ja source NAT-i tunneli suunas:

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 reegel on see osa, mille inimesed välja jätavad. Ettevõtte ruuterid teavad harva, et 192.168.56.0/24 olemas on; reegliga näevad sisemised serverid külalise tunneli aadressi ja vastavad sellele, ning vastus leiab tee tagasi külalise juurde.

Windowsi külaline on kohmakam. IPEnableRouter=1 jaotises SYSTEM\CurrentControlSet\Services\Tcpip\Parameters lülitab sisse edastamise ilma tõlkimiseta, seega töötab see ainult seal, kus ettevõtte marsruutimine osutab juba tagasi teie host-only prefiksile. Internet Connection Sharing tõlgib, kuid nummerdab ühise adapteri ümber 192.168.137.1-ks, seega lugege aadress, mille see tegelikult võttis, enne kui kirjutate hosti marsruute.

Kontroll 3: hosti marsruudid nimetavad külalist, mitte tunnelit

Laske läbi külalise ainult need prefiksid, mida host vajab. Linuxis piisab ühest marsruudist prefiksi kohta ja see pöördub puhtalt tagasi:

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

Windowsis on vaste route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Jätke -p testimise ajaks välja, et halb marsruut sureks taaskäivitusel, ja lisage see, kui tee töötab. Ärge eemaldage hosti vaikemarsruuti, kui just iga hosti rakendus ei peaks tunnelit kasutama; kui täistunnel on tõesti nõue, lisage kaks /1 marsruuti ja jätke otsene marsruut hüpervisori võrku:

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

Windowsi hostis kontrollige ka liidese meetrikat. Marsruut, mis lisati, kui host-only adapter oli välja lülitatud, jääb tabelisse, kuid ei kanna kunagi liiklust, ja madalama meetrikaga teine adapter võib sama prefiksi otsingus võita.

Kontroll 4: DNS järgib marsruuti, mitte tunneli vaikeväärtust

Marsruudid liigutavad pakette; resolver otsustab, millised nimed pakette tekitavad. Piirake ettevõtte resolver ettevõtte tsooniga, selle asemel et hosti resolverit asendada, ja suunake see DNS-serverile, kuhu uus marsruut juba jõuab. Kui hostis töötab systemd-resolved:

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

Windowsis teeb sama töö nimeresolutsiooni poliitikatabeli kirje: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Kui külaline käivitab oma resolveri host-only aadressil, kasutage selle asemel seda aadressi, kuid alles pärast kinnitamist, et see vastab aadressil 192.168.56.2, mitte loopbackil.

Seejärel kontrollige MTU-d, enne kui süüdistate DNS-i aeglastes lehtedes. Tunneli liides on väiksem kui hosti 1500-baidine liides, seega host, mis saadab täissuuruses segmente DF-bitiga seatud, laseb need kusagil külalise sees maha visata. Klassikaline sümptom on töötav ping ja sisemine veebirakendus, mis jääb pärast TLS-kätlust seisma. Pingutage MSS-i külalise edastusteed:

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

Kontroll 5: kontrollige mõlemast otsast

Hostist peaks traceroute või tracert sisemisele aadressile näitama esimese hüppena 192.168.56.2, mitte füüsilist lüüsi. Külalises jälgige, kuidas sama katse väljub: tcpdump -ni any host 10.20.30.40 näitab edastatud päringut host-only poolel ja tõlgitud päringut tunnelis. Päring, mis väljub, naaseb ja jätab hosti ikkagi vaikseks, osutab tagasiteele.

Kaks tõrget seletavad suuremat osa sellest. Kas külalise tunnel ei kanna host-only prefiksi jaoks tagasiteed, sest NAT-reegel puudub, või osutab hosti marsruut aadressile, mida külalisel pärast taaskäivitust enam pole. Lugege aadressid uuesti ip -br addr ja ip route get abil, selle asemel et usaldada eelmise seansi märkmeid.

Kontroll 6: tehke see vastupidavaks taaskäivitusele ja hüpervisori uuendusele

Hoidke mõlemad pooled püsivana: netplan- või NetworkManageri marsruudikonfiguratsioon hostis, route add ... -p Windowsis ja net.ipv4.ip_forward=1 failis /etc/sysctl.d/ pluss tulemüürireeglite kogum, mis külalises uuesti laaditakse. Tehke külalisest snapshot kohe, kui konfiguratsioon on kontrollitud, enne kui saabub järgmine ettevõtte kliendi uuendus.

Host-only võrgud nummerdatakse ümber, kui hüpervisor oma adapterid uuesti loob, mis muudab vaikselt kehtetuks iga marsruudi ja NAT-reegli, mis on ehitatud 192.168.56.0/24 peale. Pärast uuendust korrake kolme esimest kontrolli järjekorras; see võtab minuti ja püüab kinni juhtumi, kus hostil on oma marsruut alles, samal ajal kui külaline on liikunud uude alamvõrku.

IPv6 vajab omaette läbivaatust. ip6tables reeglid, AAAA-kirjed ja teine hosti marsruudiperekond ei järgi IPv4 seadistust, ja IPv6 kaudu kättesaadav ettevõtte teenus näeb püsivalt katkine välja, samal ajal kui IPv4 töötab.

Läbitud või mitte, järjekorras: host saab pingida külalise host-only aadressi; külaline edastab ja teeb MASQUERADE tunneli suunas; ip route get tagastab külalise sisemise prefiksi lüüsina; ettevõtte nimed lahendatakse piiratud resolveri kaudu; traceroute näitab külalist esimesena; ja samad kuus vastust elavad üle taaskäivituse.