Gäst-VPN och värd-VPN: vilken rutt som faktiskt vinner

Två klienter körs samtidigt, var och en övertygad om att den äger standardrutten, och symptomet dyker upp som något märkligt: en gästapplikation fungerar, en annan löses till fel plats. En VPN inuti en gäst och en VPN på värden kan samexistera, men bara när den yttre vägen och den inre policyn är överens om vem som bär vad. Att starta båda skapar inte en kedja i sig. Skriv först ned anslutningen och ändra sedan en sak i taget.

Skriv först ned gästens anslutning

Gästen når sin VPN-server via den väg som hypervisorn gav den: NAT bakom värden, en brygga till det fysiska segmentet eller ett nätverk bara för värden med routing lagt ovanpå. Varje anslutning ändrar vad gästen kan se och vad värden kan göra med dess trafik. Under NAT ser gästens paket ut att komma från värden, så värdens egen tunnel kan bära dem utan att gästen vet något om det. Under en brygga har gästen sin egen närvaro i segmentet och sin egen standardgateway.

Skriv ned anslutningen innan du rör någon konfiguration, tillsammans med vilken klient som ska bära vilken applikation. Den meningen löser de flesta av dessa ärenden, eftersom de två klienterna vanligtvis är byggda på olika antaganden. En gäst som förväntas använda värdens tunnel får inte också ha sin egen konkurrerande standardrutt.

Följ gästens ändpunkt utåt

En gäst-VPN behöver en användbar väg till sin egen server innan något annat kan fungera. När värdens tunnel är uppe och gästen sitter bakom NAT lämnar gästens handskakning värdens tunnel, vilket antingen är designen eller en olycka som ingen har dokumenterat. När värdens tunnel faller och gästen var beroende av den tappar gästen anslutningen utan en enda ändring på sin sida. Att följa ändpunkten utåt berättar vilket av de två du faktiskt har.

En bred rutt i vilken som helst av de två kontexterna fångar trafik som den andra klienten förväntade. En 0.0.0.0/0-rutt inne i gästen och en värdklient med full tunnel gör båda anspråk på allt, och den som gäller sist vinner. Överlapp mellan gästens virtuella nätverk, det lokala LAN:et och fjärrnätverk ger samma effekt för privata prefix, med fel som liknar autentiseringsproblem; adressöversättningens beteende är detsamma som beskrivs för containernätverk.

Jämför en registrering före och efter

Ta en baslinje med värdens tunnel avstängd, eller i vilket kontrollerat tillstånd din policy tillåter, och skriv ned gästens rutt och resolver. Använd sedan den kombinerade konfigurationen och jämför de två registreringarna, med integritetskraven intakta. Om en direkt baslinje inte är lämplig, skriv den begränsningen i registreringen i stället för att hoppa över jämförelsen.

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

Ruttfrågan namnger gränssnittet och källadressen som skulle bära en viss destination, och det är den mest användbara enskilda raden i den här utredningen. Regelistan visar om policy-routing skickar vissa destinationer genom en andra tabell. Resolverns utdata visar om DNS följde gästens tunnel eller stannade på värdens väg. Kör samma tre kommandon före och efter ändringen, och skillnaden namnger boven.

Håll ägandet tydligt genom omstarter

En värdklients begränsning av lokal åtkomst kan blockera trafik till en virtuell NAT eller brygga, och den begränsningen förväxlas rutinmässigt med ett problem med gästens inloggningsuppgifter. Läs klientens dokumenterade beteende i stället för att stänga av begränsningen för att få ett test att gå igenom. Efter en stödd rättelse, testa gästapplikationen och felpolicyn du kräver igen. En värd som återansluter framgångsrikt bevisar ingenting om gästens rutt eller resolver.

Bestäm vilken sida som äger standardrutten och skriv det i driftmanualen. En omstart av gästen eller ett nätverksbyte på värden som tyst vänder ägandet producerar en felrapport om en VPN som aldrig var skyldig. Arrangemanget bör överleva en omstart utan att någon minns varför det fungerade.