Indlejret VPN: hvilken tunnel bærer den ydre forbindelse?

To VPN-klienter, der kører samtidig, giver ikke en indlejret tunnel; de giver to tunneler og en strid om routingen. En indlejret tunnel findes, når den indre klients forbindelse til dens egen server selv bæres af den ydre tunnel, og det er et arrangement, du bygger med vilje. Bliver det rigtigt, ser den indre server den ydre servers adresse; bliver det forkert, genopretter en klient stille forbindelsen uden om den anden. Tre betingelser afgør, om indlejringen er reel eller tilfældig.

Tre betingelser afgør indlejringen

Den første er, hvilket endepunkt der har brug for hvilken vej. Navngiv den indre servers adresse, navngiv den ydre servers adresse, og slå udtrykkeligt fast, at den indre server kun kan nås gennem den ydre tunnel. Alt andet følger af den sætning, også hvilke ruter der hører i hvilken tabel.

Den anden er, om du kan se vejen på hvert lag. Hvis du ikke kan spørge kernen, hvilken rute en bestemt destination ville bruge, udleder du kæden fra en endelig udgangs-IP, og det er netop det bevis, der ikke kan skelne indlejring fra tilfælde.

Den tredje er, hvad der sker, når den ydre tunnel falder. Den indre tunnel kan stoppe med den, genoprette forbindelsen over det almindelige netværk eller forblive blokeret, indtil den ydre vej vender tilbage, og alle tre er forsvarlige politikker. De er ikke den samme politik, og standardadfærden hos de fleste klienter er den anden. En klient, der genopretter sin endepunktsforbindelse over det fysiske netværk, mens den viser en sund forbindelse, er den mest almindelige måde, hvorpå en tilsigtet kæde stille bliver to uafhængige tunneler.

Betingelse et: hvilket endepunkt har brug for hvilken vej

ip route get 203.0.113.10 besvarer det spørgsmål direkte: kommandoen udskriver ruten, kildeadressen og det interface, kernen ville bruge til den destination lige nu.

Kør den for den indre server, før den indre klient starter, og igen bagefter, og sammenlign. Ændrer svaret sig fra det fysiske interface til den ydre tunnels interface, er indlejringen reel i det øjeblik. Ændrer det sig ikke, forbinder den indre klient direkte, uanset hvad dashbordet siger. Gentag for den ydre servers adresse, som stadig skal slås op via det fysiske interface, fordi en rute, der fanger begge endepunkter rekursivt, er den fejl, der tager maskinen helt af nettet.

Betingelse to: undersøg vejen på hvert lag

Rutevalg er mere end hovedtabellen på en moderne klient. Politikregler kan sende markerede pakker til en anden tabel, en klient kan binde sin socket til et interface, og en container eller namespace har sine helt egne tabeller. Med ip rule og ip route show table all finder du ud af, hvilket af det der er i spil.

En klient, der sætter SO_MARK på sin egen socket eller er konfigureret til at binde til en bestemt enhed, omgår den standardrute, du troede, du havde arrangeret. Det er en funktion og ikke en fejl, og det betyder, at den eneste pålidelige kontrol er en, der kører i samme namespace som klienten. Kører klienterne i containere, skal du køre kontrollerne i de containere i stedet for på værten.

Betingelse tre: hvad der sker, når den ydre tunnel falder

Fejladfærd kræver en beslutning, ikke en standard. Skriv ned, hvad der skal ske med den indre tunnel, når den ydre forsvinder, og få derefter klienterne til at gøre det.

Mulighederne er konkrete. At stoppe den indre klient, når den ydre vej forsvinder, giver en ren kæde og et tydeligt udfald. At lade den genoprette forbindelsen direkte giver tilgængelighed og fjerner stille den egenskab, kæden blev bygget til. At blokere, indtil den ydre vej vender tilbage, er det strengeste og mest besværlige at drive, fordi hvert flag i den ydre tunnel bliver en synlig hændelse.

Test alle tre med harmløs trafik og et bevidst udfald på den ydre tunnel, for at læse konfigurationen fortæller dig ikke, hvilken du har. Dræb den ydre tunnel, se hvad den indre klient gør, og kontroller ruten igen, mens den er nede. Bring derefter den ydre tunnel tilbage og bekræft, at kæden genopstår i stedet for at lade den indre klient blive på den direkte vej, den valgte imens.

Hvad kæden ikke giver dig

Ekstra lag tilføjer endepunkter, nøgler og fejlmåder; de tilføjer ingen anonymitetsgaranti, og de gør ikke den ydre operatør ude af stand til at se, at en tunnel findes. Enhver påstand om, hvad indlejring beskytter, skal navngive den betragter, den beskytter imod.

Leverancen er et kort dokument og ikke en fungerende forbindelse: hvilket endepunkt der bruger hvilken vej, hvad der sker ved et udfald på den ydre tunnel, og de tre kommandoer, der viser den aktuelle tilstand. strongSwans dokumentation om videresendelse er en nyttig reference til, hvordan tunneltrafik videresendes mellem interfaces på en Linux-vært. Kør kontrollerne igen efter hver klientopgradering, for de standardværdier, der skabte din kæde, er ikke en kontrakt. En indlejret tunnel, du ikke kan inspicere, er et rygte med en statuslampe.