Nestet VPN: hvilken tunnel bærer den ytre forbindelsen?

To VPN-klienter som kjører samtidig gir ingen nestet tunnel; de gir to tunneler og en krangel om rutingen. En nestet tunnel finnes når den indre klientens forbindelse til sin egen server selv bæres av den ytre tunnelen, og det er et arrangement du bygger med vilje. Blir det riktig, ser den indre serveren adressen til den ytre serveren; blir det feil, kobler én klient stille til på nytt rundt den andre. Tre vilkår avgjør om nestingen er ekte eller tilfeldig.

Tre vilkår avgjør nestingen

Det første er hvilket endepunkt som trenger hvilken vei. Navngi adressen til den indre serveren, navngi adressen til den ytre serveren, og slå uttrykkelig fast at den indre serveren bare er nåbar gjennom den ytre tunnelen. Alt annet følger av den setningen, også hvilke ruter som hører i hvilken tabell.

Det andre er om du kan se veien på hvert lag. Hvis du ikke kan spørre kjernen om hvilken rute en bestemt destinasjon ville bruke, utleder du kjeden fra en endelig utgangs-IP, og det er nettopp beviset som ikke kan skille nestingen fra tilfeldighet.

Det tredje er hva som skjer når den ytre tunnelen faller. Den indre tunnelen kan stoppe med den, koble til på nytt over det vanlige nettverket eller forbli blokkert til den ytre veien kommer tilbake, og alle tre er forsvarlige retningslinjer. De er ikke den samme retningslinjen, og standardoppførselen til de fleste klienter er den andre. En klient som kobler endepunktet sitt til på nytt over det fysiske nettverket mens den viser en frisk forbindelse, er den vanligste måten en tilsiktet kjede stille blir to uavhengige tunneler.

Vilkår én: hvilket endepunkt trenger hvilken vei

ip route get 203.0.113.10 svarer på det spørsmålet direkte: kommandoen skriver ut ruten, kildeadressen og grensesnittet kjernen ville brukt for den destinasjonen akkurat nå.

Kjør den for den indre serveren før den indre klienten starter og igjen etterpå, og sammenlign. Endrer svaret seg fra det fysiske grensesnittet til grensesnittet til den ytre tunnelen, er nestingen ekte i det øyeblikket. Endrer det seg ikke, kobler den indre klienten til direkte, uansett hva dashbordet sier. Gjenta for adressen til den ytre serveren, som fortsatt må slås opp via det fysiske grensesnittet, fordi en rute som fanger begge endepunktene rekursivt er feilen som tar maskinen helt av nettet.

Vilkår to: undersøk veien på hvert lag

Rutevalg er mer enn hovedtabellen på en moderne klient. Policyregler kan sende merkede pakker til en annen tabell, en klient kan binde sockelen sin til et grensesnitt, og en container eller namespace har helt egne tabeller. Med ip rule og ip route show table all finner du ut hvilket av disse som er i spill.

En klient som setter SO_MARK på sin egen socket, eller er konfigurert til å binde til en bestemt enhet, omgår standardruten du trodde du hadde ordnet. Det er en funksjon og ikke en feil, og det betyr at den eneste pålitelige kontrollen er en som kjører i samme namespace som klienten. Kjører klientene i containere, kjør kontrollene i de containerne i stedet for på verten.

Vilkår tre: hva som skjer når den ytre tunnelen faller

Feiloppførsel krever en beslutning, ikke en standard. Skriv ned hva som skal skje med den indre tunnelen når den ytre forsvinner, og få deretter klientene til å gjøre det.

Alternativene er konkrete. Å stoppe den indre klienten når den ytre veien forsvinner gir en ren kjede og et tydelig avbrudd. Å la den koble til direkte på nytt gir tilgjengelighet og fjerner stille egenskapen kjeden var bygget for. Å blokkere til den ytre veien kommer tilbake er det strengeste og det mest plagsomme å drifte, fordi hver forstyrrelse i den ytre tunnelen blir en synlig hendelse.

Test alle tre med ufarlig trafikk og et bevisst avbrudd på den ytre tunnelen, for å lese konfigurasjonen forteller deg ikke hvilken du har. Drep den ytre tunnelen, se hva den indre klienten gjør, og kontroller ruten igjen mens den er nede. Ta deretter den ytre tunnelen tilbake og bekreft at kjeden dannes på nytt i stedet for å la den indre klienten bli på den direkte veien den valgte i mellomtiden.

Hva kjeden ikke gir deg

Ekstra lag legger til endepunkter, nøkler og feilmoduser; de legger ikke til noen anonymitetsgaranti, og de gjør ikke den ytre operatøren ute av stand til å se at det finnes en tunnel. Enhver påstand om hva nestingen beskytter mot, må navngi observatøren den beskytter mot.

Leveransen er et kort dokument og ikke en fungerende forbindelse: hvilket endepunkt som bruker hvilken vei, hva som skjer ved et avbrudd på den ytre tunnelen, og de tre kommandoene som viser den gjeldende tilstanden. strongSwans dokumentasjon om videresending er en nyttig referanse for hvordan tunneltrafikk videresendes mellom grensesnitt på en Linux-vert. Kjør kontrollene på nytt etter hver klientoppgradering, for standardverdiene som skapte kjeden din er ikke en kontrakt. En nestet tunnel du ikke kan inspisere, er et rykte med en statuslampe.