Gæste-VPN og vært-VPN: hvilken rute vinder egentlig

To klienter kører samtidig, hver overbevist om at den ejer standardruten, og symptomet dukker op som noget mærkeligt: én gæsteapplikation virker, en anden opløses til det forkerte sted. En VPN inde i en gæst og en VPN på værten kan eksistere side om side, men kun når den ydre vej og den indre politik er enige om, hvem der bærer hvad. At starte begge skaber ikke en kæde i sig selv. Skriv først tilkoblingen ned, og skift så én ting ad gangen.

Skriv gæstens tilkobling ned først

Gæsten når sin VPN-server ad den vej, som hypervisoren gav den: NAT bag værten, en bro til det fysiske segment eller et netværk kun til værten med routing lagt ovenpå. Hver tilkobling ændrer, hvad gæsten kan se, og hvad værten kan gøre ved dens trafik. Under NAT ser gæstens pakker ud til at komme fra værten, så værtens egen tunnel kan bære dem, uden at gæsten ved noget om det. Under en bro har gæsten sin egen tilstedeværelse på segmentet og sin egen standardgateway.

Skriv tilkoblingen ned, før du rører nogen konfiguration, sammen med hvilken klient der skal bære hvilken applikation. Den sætning løser de fleste af disse sager, fordi de to klienter normalt er bygget på forskellige antagelser. En gæst, der forventes at bruge værtens tunnel, må ikke også have sin egen konkurrerende standardrute.

Følg gæstens endepunkt udad

En gæste-VPN har brug for en brugbar vej til sin egen server, før noget andet kan virke. Når værtens tunnel er oppe, og gæsten sidder bag NAT, forlader gæstens håndtryk værtens tunnel, hvilket enten er designet eller et uheld, som ingen har dokumenteret. Når værtens tunnel falder, og gæsten var afhængig af den, mister gæsten forbindelsen uden en enkelt ændring på sin side. At følge endepunktet udad fortæller dig, hvilken af de to du faktisk har.

En bred rute i enhver af de to sammenhænge fanger trafik, som den anden klient forventede. En 0.0.0.0/0-rute inde i gæsten og en værtklient med fuld tunnel kræver begge alt, og den, der gælder sidst, vinder. Overlap mellem gæstens virtuelle netværk, det lokale LAN og fjernnetværk giver samme effekt for private præfikser, med fejl der ligner godkendelsesproblemer; adresseoversættelsens adfærd er den samme, som beskrives for container-netværk.

Sammenlign en registrering før og efter

Tag en baseline med værtens tunnel slukket, eller i hvilken som helst kontrolleret tilstand din politik tillader, og skriv gæstens rute og resolver ned. Anvend derefter den kombinerede konfiguration, og sammenlign de to registreringer, mens privatlivskravene holdes intakte. Hvis en direkte baseline ikke er passende, så skriv den begrænsning ind i registreringen i stedet for at springe sammenligningen over.

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

Ruteopslaget angiver det interface og den kildeadresse, der ville bære en bestemt destination, og det er den enkelt linje, der er mest nyttig i denne undersøgelse. Regellisten viser, om policy-routing sender nogle destinationer gennem en anden tabel. Resolverens output viser, om DNS fulgte gæstens tunnel eller blev på værtens vej. Kør de samme tre kommandoer før og efter ændringen, og deltaet udpeger synderen.

Hold ejerskabet klart hen over genstarter

En værtklients begrænsning af lokal adgang kan blokere trafik til en virtuel NAT eller bro, og den begrænsning bliver rutinemæssigt forvekslet med et problem med gæstens legitimationsoplysninger. Læs klientens dokumenterede adfærd i stedet for at slå begrænsningen fra for at få en test til at bestå. Efter en understøttet rettelse skal du teste gæsteapplikationen og den fejlpolitik, du kræver, igen. En vært, der genopretter forbindelsen, beviser intet om gæstens rute eller resolver.

Beslut, hvilken side der ejer standardruten, og skriv det i driftshåndbogen. En genstart af gæsten eller et netværksskift på værten, som lydløst vender ejerskabet, producerer en fejlrapport om en VPN, der aldrig var skyld i noget. Arrangementet bør overleve en genstart, uden at nogen husker hvorfor det virkede.