Gjest-VPN og verts-VPN: hvilken rute vinner egentlig

To klienter kjører samtidig, hver overbevist om at den eier standardruten, og symptomet dukker opp som noe merkelig: én gjesteapplikasjon virker, en annen løses til feil sted. En VPN inne i en gjest og en VPN på verten kan eksistere side om side, men bare når den ytre veien og den indre politikken er enige om hvem som bærer hva. Å starte begge lager ikke en kjede i seg selv. Skriv først ned tilkoblingen, og endre så én ting om gangen.

Skriv først ned gjestens tilkobling

Gjesten når VPN-serveren sin via den veien hypervisoren ga den: NAT bak verten, en bro til det fysiske segmentet eller et nettverk bare for verten med ruting lagt oppå. Hver tilkobling endrer hva gjesten kan se og hva verten kan gjøre med trafikken dens. Under NAT ser gjestens pakker ut til å komme fra verten, så vertens egen tunnel kan bære dem uten at gjesten vet noe om det. Under en bro har gjesten sin egen tilstedeværelse på segmentet og sin egen standardgateway.

Skriv ned tilkoblingen før du rører noen konfigurasjon, sammen med hvilken klient som skal bære hvilken applikasjon. Den setningen løser de fleste av disse sakene, fordi de to klientene vanligvis er bygget på ulike antakelser. En gjest som forventes å bruke vertens tunnel må ikke også ha sin egen konkurrerende standardrute.

Følg gjestens endepunkt utover

En gjeste-VPN trenger en brukbar vei til sin egen server før noe annet kan virke. Når vertens tunnel er oppe og gjesten sitter bak NAT, forlater gjestens håndtrykk vertens tunnel, noe som enten er designet eller en ulykke ingen har dokumentert. Når vertens tunnel faller og gjesten var avhengig av den, mister gjesten tilkoblingen uten en eneste endring på sin side. Å følge endepunktet utover forteller deg hvilken av de to du faktisk har.

En bred rute i hvilken som helst av de to sammenhengene fanger trafikk den andre klienten forventet. En 0.0.0.0/0-rute inne i gjesten og en vertsklient med full tunnel krever begge alt, og den som gjelder sist vinner. Overlapp mellom gjestens virtuelle nettverk, det lokale LAN-et og fjernnettverk gir samme effekt for private prefikser, med feil som ligner autentiseringsproblemer; adresseoversettelsen oppfører seg som den som er beskrevet for containernettverk.

Sammenlign en registrering før og etter

Ta en baseline med vertens tunnel av, eller i hvilken som helst kontrollert tilstand politikken din tillater, og skriv ned gjestens rute og resolver. Bruk deretter den kombinerte konfigurasjonen og sammenlign de to registreringene, mens personvernkravene holdes intakte. Hvis en direkte baseline ikke er passende, skriv den begrensningen i registreringen i stedet for å hoppe over sammenligningen.

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

Rutespørringen navngir grensesnittet og kildeadressen som ville bære en bestemt destinasjon, og det er den mest nyttige enkeltlinjen i denne undersøkelsen. Regellisten viser om policy-ruting sender noen destinasjoner gjennom en andre tabell. Resolverens utdata viser om DNS fulgte gjestens tunnel eller ble på vertens vei. Kjør de samme tre kommandoene før og etter endringen, og differansen navngir synderen.

Hold eierskapet klart gjennom omstarter

En vertsklients begrensning på lokal tilgang kan blokkere trafikk til en virtuell NAT eller bro, og den begrensningen blir rutinemessig forvekslet med et problem med gjestens påloggingsinformasjon. Les klientens dokumenterte oppførsel i stedet for å slå av begrensningen for å få en test til å bestå. Etter en støttet rettelse, test gjesteapplikasjonen og feilpolitikken du krever på nytt. En vert som kobler til på nytt med suksess beviser ingenting om gjestens rute eller resolver.

Bestem hvilken side som eier standardruten, og skriv det i driftshåndboken. En omstart av gjesten eller et nettverksbytte på verten som stille snur eierskapet, produserer en feilrapport om en VPN som aldri var skyldig. Ordningen bør overleve en omstart uten at noen husker hvorfor den virket.