Genestelde VPN: welke tunnel draagt de buitenste verbinding?

Twee VPN-clients die tegelijk draaien leveren geen genestelde tunnel op; ze leveren twee tunnels en een ruzie over de routing op. Een genestelde tunnel bestaat wanneer de verbinding van de binnenste client met zijn eigen server zelf door de buitenste tunnel wordt gedragen, en dat is een opzet die je met opzet bouwt. Klopt het, dan ziet de binnenste server het adres van de buitenste server; klopt het niet, dan verbindt één client zich stilletjes opnieuw om de andere heen. Drie voorwaarden bepalen of de nesting echt of toevallig is.

Drie voorwaarden bepalen de nesting

De eerste is welk eindpunt welk pad nodig heeft. Noem het adres van de binnenste server, noem het adres van de buitenste server en stel uitdrukkelijk vast dat de binnenste server alleen via de buitenste tunnel bereikbaar is. Al het andere volgt uit die zin, ook welke routes in welke tabel horen.

De tweede is of je het pad op elke laag kunt zien. Als je de kernel niet kunt vragen welke route een bepaald doel zou gebruiken, leid je de keten af uit een laatste exit-IP, en dat is precies het bewijs dat nesting niet van toeval kan onderscheiden.

De derde is wat er gebeurt als de buitenste tunnel wegvalt. De binnenste tunnel kan ermee stoppen, zich via het gewone netwerk opnieuw verbinden of geblokkeerd blijven tot het buitenste pad terugkeert, en alle drie zijn verdedigbare keuzes. Het zijn niet dezelfde keuzes, en het standaardgedrag van de meeste clients is de tweede. Een client die zijn eindpunt via het fysieke netwerk opnieuw verbindt terwijl hij een gezonde verbinding toont, is de meest voorkomende manier waarop een bedoelde keten stilletjes twee losse tunnels wordt.

Voorwaarde één: welk eindpunt welk pad nodig heeft

ip route get 203.0.113.10 beantwoordt die vraag rechtstreeks: het drukt de route, het bronadres en de interface af die de kernel voor dat doel op dit moment zou gebruiken.

Voer het uit voor de binnenste server voordat de binnenste client start en daarna nog eens, en vergelijk. Verandert het antwoord van de fysieke interface naar de interface van de buitenste tunnel, dan is de nesting op dat moment echt. Verandert het niet, dan verbindt de binnenste client zich rechtstreeks, wat het dashboard ook zegt. Herhaal het voor het adres van de buitenste server, dat nog steeds via de fysieke interface moet worden opgelost, want een route die beide eindpunten recursief vangt is de fout die de machine volledig van het netwerk haalt.

Voorwaarde twee: bekijk het pad op elke laag

Routekeuze is op een moderne client meer dan de hoofdtabel. Policyregels kunnen gemarkeerde pakketten naar een andere tabel sturen, een client kan zijn socket aan een interface binden, en een container of namespace heeft sowieso eigen tabellen. Met ip rule en ip route show table all kom je erachter welke daarvan in het spel is.

Een client die SO_MARK op zijn eigen socket zet, of die zo is ingesteld dat hij aan een bepaald apparaat bindt, omzeilt de standaardroute waarvan je dacht dat je die had geregeld. Dat is een functie en geen fout, en het betekent dat de enige betrouwbare controle er een is die in dezelfde namespace als de client draait. Draaien de clients in containers, voer de controles dan in die containers uit in plaats van op de host.

Voorwaarde drie: wat er gebeurt als de buitenste tunnel wegvalt

Foutgedrag vraagt om een beslissing, niet om een standaard. Schrijf op wat er met de binnenste tunnel moet gebeuren als de buitenste verdwijnt, en laat de clients dat vervolgens doen.

De opties zijn concreet. De binnenste client stoppen wanneer het buitenste pad wegvalt, geeft een schone keten en een duidelijke storing. Hem zich rechtstreeks laten herverbinden geeft beschikbaarheid en haalt stilletjes de eigenschap weg waarvoor de keten is gebouwd. Blokkeren tot het buitenste pad terugkeert is de strengste en de vervelendste om te beheren, omdat elke hapering van de buitenste tunnel een zichtbaar incident wordt.

Test alle drie met onschadelijk verkeer en een opzettelijke storing van de buitenste tunnel, want de configuratie lezen vertelt je niet welke je hebt. Breek de buitenste tunnel af, kijk wat de binnenste client doet en controleer de route opnieuw terwijl hij weg is. Breng de buitenste tunnel dan terug en bevestig dat de keten zich opnieuw vormt in plaats van de binnenste client op het directe pad te laten dat hij intussen koos.

Wat de keten je niet geeft

Extra lagen voegen eindpunten, sleutels en faalwijzen toe; ze voegen geen anonimiteitsgarantie toe en ze zorgen er niet voor dat de buitenste operator niet kan zien dat er een tunnel bestaat. Elke bewering over waar nesting tegen beschermt, moet de waarnemer noemen waartegen ze beschermt.

Het opleveringsproduct is een kort document en geen werkende verbinding: welk eindpunt welk pad gebruikt, wat er bij een storing van de buitenste tunnel gebeurt en de drie opdrachten die de huidige toestand tonen. De documentatie van strongSwan over forwarding is een nuttige referentie voor hoe tunnelverkeer op een Linux-host tussen interfaces wordt doorgestuurd. Voer de controles na elke client-upgrade opnieuw uit, want de standaardwaarden die je keten hebben opgeleverd, zijn geen contract. Een genestelde tunnel die je niet kunt inspecteren, is een gerucht met een statuslampje.