Host-Trafic duerch eng VPN an enger VM leeden: sechs Kontrollen

Sechs Kontrollen, déi an der Rei gemaach ginn, entscheeden, ob eng VM als VPN-Gateway fir hiren eegene Host ka schaffen. Den Hypervisor mécht näischt dovun fir iech: den Tunnel gehéiert dem Gast, d'Route gehéiert dem Host, an d'Netz tëscht hinnen ass gewéinlech Routing. Ech halen d'Lëscht fest, well ee Schrëtt ausloossen ëmmer dat selwecht Symptom gëtt, Stëllt, wou den Host de Gast glécklech pingt an näischt internes erreecht.

Fänkt mam Grond un. Entweder gëtt de Firmen-Client just am Gast installéiert, oder d'Politik hält en do, an dir braucht nach ëmmer den internen Buildserver vum Host. Wann den Host säin eegene Client däerf hunn, maacht dat amplaz: een Tunnel um Host schléit ëmmer zwee Netzwierker plus eng NAT.

Kontroll 1: den Host brauch eng Verbindung, déi en adresséiere kann

Den Host muss eng Interface hunn, déi am selwechte Prefix wéi den zweeten Adapter vum Gast läit. Host-only am VirtualBox, host-only oder eng personaliséiert VMnet am VMware Workstation, eng intern Bréck oder en tap-Gerät am QEMU/KVM an en Internal-Switch am Hyper-V qualifizéieren alleguer. Gast 192.168.56.2, Host 192.168.56.1, Prefix 192.168.56.0/24 ass d'Layout, dat ech a Laboe benotzen.

QEMU seng Benotzermodus-Netzwierker (-netdev user, de Standard-SLIRP-Backend) an VirtualBox NAT falen dës Kontroll komplett duerch. D'Pakete vum Gast erreechen e Proxyprozess um Host, sou datt den Host ni en Apparat gesäit, deen d'Adresse vum Gast dréit, an näischt huet, fir eng Route drop ze weisen. Den Default Switch vum Hyper-V ass déi selwecht Geschicht. Wann ping 192.168.56.2 vum Host aus feelt, stoppt: keng Route, déi méi spéit bäigesat gëtt, reparéiert dat.

Kontroll 2: de Gast gëtt weider an iwwersetzt

D'Pakete vum Host kommen mat enger host-only Quelladress an engem internen Destinatioun un, also muss de Gast se weiderginn an duerno hannert senger Tunneladress verstoppen. Op engem Linux-Gast heescht dat Weidergabe, en FORWARD accept-Puer a source NAT a Richtung 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

D'MASQUERADE-Regel ass deen Deel, deen d'Leit ewech loossen. Firmenroutere wëssen et seelen, datt et 192.168.56.0/24 gëtt; mat der Regel gesinn intern Serveren d'Tunneladress vum Gast a äntweren drop, an d'Äntwert fënnt de Wee zréck zum Gast.

En Windows-Gast ass méi ongeschéckt. IPEnableRouter=1 ënner SYSTEM\CurrentControlSet\Services\Tcpip\Parameters schalt d'Weidergabe ouni Iwwersetzung an, dofir funktionéiert et nëmme wou d'Firmenrouting schonn zréck op ären host-only Prefix weist. Internet Connection Sharing iwwersetzt, awer et renumeréiert den gedeelten Adapter op 192.168.137.1, also liest d'Adress, déi en tatsächlech geholl huet, ier dir Host-Routen schreift.

Kontroll 3: d'Host-Route nennen de Gast, net den Tunnel

Schéckt just d'Prefix duerch de Gast, déi den Host brauch. Op Linux ass eng Route pro Prefix genuch an et geet propper zréck:

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

Op Windows ass d'Entspriechung route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Loosst -p ewech, während dir nach test, sou datt eng schlecht Route beim Neistart stierft, a setzt se bäi, wann de Wee funktionéiert. Huelt net d'Standardroute vum Host ewech, ausser all Uwendung um Host soll den Tunnel benotzen; wann de kompletten Tunnel wierklech d'Ufuerderung ass, setzt déi zwou /1-Routen bäi an haalt déi direkt Route op d'Hypervisor-Netzwierk:

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

Op engem Windows-Host kontrolléiert och d'Metrik vun der Interface. Eng Route, déi bäigesat gouf, wéi den host-only Adapter aus war, bleift an der Tabell, dréit awer ni Verkéier, an en zweeten Adapter mat enger méi niddereger Metrik kann d'Sich fir de selwechte Prefix gewannen.

Kontroll 4: DNS suivéiert d'Route, net den Standard vum Tunnel

Routen beweegen Paketen; de Resolver entscheet, wéi eng Nimm Paketen erzeugen. Beschränkt de Firmenresolver op d'Firmenzone amplaz de Resolver vum Host z'ersetzen, a weist en op en DNS-Server, deen déi nei Route schonn erreecht. Mat systemd-resolved um Host:

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

Op Windows mécht en Entrée an der Numm-Opléisungspolitikstabelle déi selwecht Aarbecht: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Wann de Gast säin eegene Resolver op der host-only Adress lafe léisst, benotzt där Adress amplaz, awer eréischt nodeems dir confirméiert hutt, datt en op 192.168.56.2 äntwert an net op loopback.

Dann kontrolléiert d'MTU, ier dir DNS fir lues Säiten d'Schold gitt. D'Tunnelinterface ass méi kleng wéi dem Host seng 1500-Byte-Interface, also gëtt e Host, dee Segmenter a voller Gréisst mam DF-Bit gesat schéckt, se iergendwou am Gast fale gelooss. D'klassesch Symptom ass eng funktionéierend ping an eng intern Webapp, déi no dem TLS-Handshake stoe bleift. Klemmen de MSS um Weidergabewee vum Gast:

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

Kontroll 5: verifizéiert vun zwou Säiten

Vum Host aus soll traceroute oder tracert op eng intern Adress 192.168.56.2 als éischten Hop weisen, net de physesche Gateway. Am Gast kuckt, wéi dee selwechte Versuch erausgeet: tcpdump -ni any host 10.20.30.40 weist d'ugesoten Ufro op der host-only Säit an déi iwwersaten um Tunnel. Eng Ufro, déi erausgeet, zréckkënnt an den Host trotzdem stëll léisst, weist op de Retourwee.

Zwee Feeler erklären dat meescht dovun. Entweder dréit den Tunnel vum Gast keng Retourroute fir den host-only Prefix, well d'NAT-Regel feelt, oder d'Host-Route weist op eng Adress, déi de Gast no engem Neistart net méi huet. Liest d'Adressen nach eng Kéier mat ip -br addr an ip route get, amplaz Notizen aus der leschter Sëtzung ze vertrauen.

Kontroll 6: maacht et iwwerliewe vun engem Neistart an engem Hypervisor-Upgrade

Halt béid Hälften permanent: netplan- oder NetworkManager-Routekonfiguratioun um Host, route add ... -p op Windows, an net.ipv4.ip_forward=1 an /etc/sysctl.d/ plus e Set Firewall-Regelen, deen am Gast nei gelueden gëtt. Maacht en Snapshot vum Gast, soubal d'Konfiguratioun verifizéiert ass, ier déi nächst Firmen-Client-Aktualiséierung kënnt.

Host-only-Netzwierker ginn nei numeréiert, wann en Hypervisor seng Adapter nei erstellt, wat all Route an NAT-Regel, déi op 192.168.56.0/24 opgebaut ass, stëll ongëlteg mécht. No engem Upgrade widderhëlt déi éischt dräi Kontrollen an der Rei; dat kascht eng Minutt a fänkt de Fall, wou den Host seng Route nach huet, während de Gast an en neien Subnet geplënnert ass.

IPv6 brauch säin eegene Passage. ip6tables-Regelen, AAAA-Entréen an eng zweet Host-Routefamill suivéieren dem IPv4-Setup net, an eng Firmesleeschtung, déi iwwer IPv6 erreechbar ass, wäert permanent futti ausgesinn, während IPv4 funktionéiert.

Bestanen oder net, an der Rei: den Host kann d'host-only Adress vum Gast pingen; de Gast gëtt weider a mécht MASQUERADE a Richtung Tunnel; ip route get gëtt de Gast als Gateway fir den internen Prefix zréck; Firmennimm ginn duerch de limitéierte Resolver opgeléist; traceroute weist de Gast als éischten; an déiselwecht sechs Äntwerten iwwerliewe en Neistart.