Benotzt Är VM de VPN vum Host? Test et vun bannen am Guest
D'Exit-Adress vum Host seet näischt iwwer d'Routen vum Guest. Notéiert de Netzwierkmode, kontrolléiert d'Route an de Resolver vum Guest, an test dann de Fehlerfall.
Dir kontrolléiert déi ëffentlech IP vum Host, si weist de VPN, an Dir schléisst, datt d'VM ofgedeckt ass. Dëse Schluss gëtt vum Test net gestëtzt. E Guest huet seng eege Routingtabell, säin eegene Resolver a seng eegen Interfaceen, an d'Exit-Adress vum Host seet näischt iwwer si.
Den Test muss am Guest lafen, an en muss nennen, wat en gemooss huet.
Fänkt am Guest un, net am Browser vum Host
Notéiert als éischt den Netzwierkmode vum Hypervisor: NAT, bridged, host-only oder macvtap. Am NAT-Mode routet den Host den Traffic vum Guest, dofir kann den Tunnel vum Host gëllen oder och net, jee nodeem wéi de Client d'Routen installéiert. Am bridged-Mode ass de Guest e Peer am physesche LAN an den Tunnel vum Host ass irrelevant. Dës zwee Moden ginn ënnerschiddlech Äntwerten aus der selwechter Host-Konfiguratioun.
Schreift de Mode op, ier Dir eppes ännert, well hien entscheet, wat d'Resultat ka bedeiten.
Maacht eng Ufro, där hiren Zil Dir kennt
Benotzt eng harmlos Ufro un e Service, deen d'Quelladress mellt, déi en gesinn huet. Kontrolléiert dann dem Guest seng eege Routingentscheedung fir dëst Zil: ip route get 203.0.113.5 dréckt d'Interface an de Gateway aus, déi de Guest wäert benotzen.
Wann d'Interface dem Guest seng normal NIC ass, geet den Traffic net duerch en Tunnel am Guest.
En zweeten Adapter, eng Proxy-Astellung oder e VPN-Client op der Guest-Säit kann d'Äntwert fir eng Applikatioun änneren an net fir eng aner. Test déi Applikatioun, déi Dir wierklech braucht, an net eng generesch Ufro aus enger Shell.
Kontrolléiert de Resolver getrennt
Eng geännert Exit-Adress seet Iech net, wéi ee Resolver den Hostnumm behandelt huet. Frot den Numm explizit mat dem Tool, deen zur Plattform passt, a notéiert, wéi ee Server geäntwert huet. Split DNS bedeit, datt d'Resolver-Fro an d'Routing-Fro verschidden Äntwerten hunn.
Déi zwee kënnen a béid Richtungen divergéieren, an dës Divergenz ass dacks de richtige Bug.
Op engem systemd-Host nennt resolvectl query d'Interface an den DNS-Server hannert der Äntwert. Méi al Konfiguratiounen weisen de Server an der Ausgab vum dig. Op jiddwer Fall ass de Punkt, ze gesinn, wéi ee Server geäntwert huet, net just ob eng Äntwert ukomm ass.
Test d'Fehlerpolitik, net just de Succès
Wann d'Ufuerderung ass, datt keen Traffic baussent dem Tunnel erausgeet, beweist eng erfollegräich Ufro näischt. Benotzt de kontrolléierte Fehlertest, deen de Client ënnerstëtzt: stoppt den Tunnel op déi ënnerstëtzte Manéier a kuckt, ob eng nei Ufro vum Guest blockéiert gëtt. Gitt net dovun aus, datt de Kill Switch vum Host-Client all virtuell Forwarding-Arrangement deckt. Säin dokumentéierte Geltungsberäich ass dat eenzegt, op dat Dir Iech verloosse kënnt.
E Guest, deen op d'physesch NIC zréckfällt, wann den Tunnel fällt, mécht genee dat, wat den NAT-Mode erlaabt.
Notéiert de Mode an de Geltungsberäich
Schreift de Mode vum Hypervisor op, d'Interface an d'Route vum Guest, de Resolver an d'Applikatioun, déi Dir getest hutt. Füügt den Datum bäi, well eng Snapshot-Restauration oder en Hypervisor-Update all véier ka änneren.
Wann IPv4 dem Tunnel gefollegt huet, sot dat. Extendéiert d'Aussag net op IPv6, en aneren Namespace oder eng aner VM op engem aneren Netzwierk.