Gjest-VPN og verts-VPN: kva rute som faktisk vinn

To klientar køyrer samstundes, kvar av dei overtydd om at han eig standardruta, og symptomet kjem fram som noko merkeleg: éin gjesteapplikasjon verkar, ein annan blir løyst til feil stad. Ein VPN inne i ein gjest og ein VPN på verten kan finnast side om side, men berre når den ytre vegen og den indre politikken er samde om kven som ber kva. Å starte begge lagar ikkje ei kjede av seg sjølv. Skriv fyrst ned tilkoplinga, og endra så éin ting om gongen.

Skriv fyrst ned tilkoplinga til gjesten

Gjesten når VPN-tenaren sin via den vegen hypervisoren gav han: NAT bak verten, ei bru til det fysiske segmentet eller eit nettverk berre for verten med ruting lagt oppå. Kvar tilkopling endrar kva gjesten kan sjå og kva verten kan gjere med trafikken hans. Under NAT ser pakkane til gjesten ut til å kome frå verten, så den eigne tunnelen til verten kan bere dei utan at gjesten veit noko om det. Under ei bru har gjesten si eiga tilstadevære på segmentet og si eiga standardgateway.

Skriv ned tilkoplinga før du rører nokon konfigurasjon, saman med kva klient som skal bere kva applikasjon. Den setninga løyser dei fleste av desse sakene, fordi dei to klientane vanlegvis er bygde på ulike føresetnader. Ein gjest som er venta å bruke tunnelen til verten må ikkje òg ha si eiga konkurrerande standardrute.

Følg endepunktet til gjesten utover

Ein gjeste-VPN treng ein brukande veg til sin eigen tenar før noko anna kan verke. Når tunnelen til verten er oppe og gjesten sit bak NAT, går handtrykket til gjesten ut gjennom tunnelen til verten, noko som anten er designet eller ei ulukke ingen har dokumentert. Når tunnelen til verten fell og gjesten var avhengig av han, mistar gjesten tilkoplinga utan éi einaste endring på si side. Å følgje endepunktet utover fortel deg kva av dei to du faktisk har.

Ei brei rute i kva som helst av dei to samanhengane fangar trafikk den andre klienten venta. Ei 0.0.0.0/0-rute inne i gjesten og ein vertsklient med full tunnel krev begge alt, og den som gjeld sist vinn. Overlapp mellom dei virtuelle netta til gjesten, det lokale LAN-et og fjernnett gjev same effekt for private prefiks, med feil som liknar autentiseringsproblem; åtferda til adresseomsetjinga er den same som skildra for containarnettverk.

Samanlikn ei registrering før og etter

Ta ei grunnlinje med tunnelen til verten av, eller i kva som helst kontrollert tilstand politikken din tillèt, og skriv ned ruta og resolvaren til gjesten. Bruk så den kombinerte konfigurasjonen og samanlikn dei to registreringane, med personvernkrava intakte. Viss ei direkte grunnlinje ikkje er høveleg, skriv den avgrensinga i registreringa i staden for å hoppe over samanlikninga.

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

Rutespørjinga nemner grensesnittet og kjeldadressa som ville bere ein bestemd destinasjon, og det er den mest nyttige einskildlinja i denne undersøkinga. Regellista viser om policy-ruting sender nokre destinasjonar gjennom ein andre tabell. Utdata frå resolvaren viser om DNS følgde tunnelen til gjesten eller vart på vegen til verten. Køyr dei same tre kommandoane før og etter endringa, og skilnaden nemner syndaren.

Hald eigarskapet klart gjennom omstartar

Avgrensinga på lokal tilgang for ein vertsklient kan blokkere trafikk til ein virtuell NAT eller bru, og den avgrensinga blir rutinemessig forveksla med eit problem med påloggingsinformasjonen til gjesten. Les den dokumenterte åtferda til klienten i staden for å slå av avgrensinga for å få ein test til å gå gjennom. Etter ei støtta retting, test gjesteapplikasjonen og feilpolitikken du krev på nytt. Ein vert som koplar til på nytt med suksess provar ingenting om ruta eller resolvaren til gjesten.

Bestem kva side som eig standardruta, og skriv det i driftshandboka. Ein omstart av gjesten eller eit nettverksbyte på verten som stille snur eigarskapet, produserer ein feilrapport om ein VPN som aldri var skuldig. Ordninga bør overleve ein omstart utan at nokon hugsar kvifor ho verka.