Nästlad VPN: vilken tunnel bär den yttre anslutningen?

Två VPN-klienter som körs samtidigt ger ingen nästlad tunnel; de ger två tunnlar och ett gräl om routingen. En nästlad tunnel finns när den inre klientens anslutning till sin egen server själv bärs av den yttre tunneln, och det är ett arrangemang du bygger med avsikt. Blir det rätt ser den inre servern den yttre serverns adress; blir det fel återansluter en klient tyst runt den andra. Tre villkor avgör om nästlingen är verklig eller tillfällig.

Tre villkor avgör nästlingen

Det första är vilken slutpunkt som behöver vilken väg. Namnge den inre serverns adress, namnge den yttre serverns adress och slå uttryckligen fast att den inre servern bara nås genom den yttre tunneln. Allt annat följer av den meningen, även vilka rutter som hör hemma i vilken tabell.

Det andra är om du kan se vägen på varje lager. Om du inte kan fråga kärnan vilken rutt ett visst mål skulle använda, härleder du kedjan från en slutlig utgångs-IP, och det är precis det bevis som inte kan skilja nästling från slump.

Det tredje är vad som händer när den yttre tunneln faller. Den inre tunneln kan stanna med den, återansluta över det vanliga nätet eller förbli blockerad tills den yttre vägen kommer tillbaka, och alla tre är försvarbara policyer. De är inte samma policy, och standardbeteendet hos de flesta klienter är den andra. En klient som återansluter sin slutpunkt över det fysiska nätet medan den visar en frisk anslutning är det vanligaste sättet en avsedd kedja tyst blir två oberoende tunnlar.

Villkor ett: vilken slutpunkt behöver vilken väg

ip route get 203.0.113.10 svarar direkt på den frågan: kommandot skriver ut rutten, källadressen och det gränssnitt som kärnan just nu skulle använda för det målet.

Kör det för den inre servern innan den inre klienten startar och igen efteråt, och jämför. Om svaret ändras från det fysiska gränssnittet till den yttre tunnelns gränssnitt är nästlingen verklig i det ögonblicket. Om det inte ändras ansluter den inre klienten direkt, oavsett vad instrumentpanelen säger. Upprepa för den yttre serverns adress, som fortfarande måste lösas via det fysiska gränssnittet, eftersom en rutt som fångar båda slutpunkterna rekursivt är felet som tar maskinen helt ur nätet.

Villkor två: granska vägen på varje lager

Ruttval är mer än huvudtabellen på en modern klient. Policyregler kan skicka märkta paket till en annan tabell, en klient kan binda sin socket till ett gränssnitt, och en container eller namespace har egna tabeller helt och hållet. Med ip rule och ip route show table all tar du reda på vilket av detta som är i spel.

En klient som sätter SO_MARK på sin egen socket, eller är konfigurerad att binda till en viss enhet, kringgår den standardrutt du trodde att du hade ordnat. Det är en funktion och inte en bugg, och det betyder att den enda tillförlitliga kontrollen är en som körs i samma namespace som klienten. Om klienterna körs i containrar ska du köra kontrollerna i de containrarna i stället för på värden.

Villkor tre: vad som händer när den yttre tunneln faller

Förbeteende kräver ett beslut, inte en standard. Skriv ned vad som ska hända med den inre tunneln när den yttre försvinner och få sedan klienterna att göra det.

Alternativen är konkreta. Att stoppa den inre klienten när den yttre vägen försvinner ger en ren kedja och ett tydligt avbrott. Att låta den återansluta direkt ger tillgänglighet och tar tyst bort den egenskap som kedjan byggdes för. Att blockera tills den yttre vägen kommer tillbaka är det strängaste och mest besvärliga att driva, eftersom varje fladder i den yttre tunneln blir en synlig incident.

Testa alla tre med ofarlig trafik och ett avsiktligt avbrott på den yttre tunneln, för att läsa konfigurationen säger dig inte vilken du har. Döda den yttre tunneln, se vad den inre klienten gör och kontrollera rutten igen medan den är nere. Ta sedan tillbaka den yttre tunneln och bekräfta att kedjan återbildas i stället för att lämna den inre klienten på den direkta väg den valde under tiden.

Vad kedjan inte ger dig

Extra lager lägger till slutpunkter, nycklar och fellägen; de lägger inte till någon anonymitetsgaranti och de gör inte den yttre operatören oförmögen att se att en tunnel finns. Varje påstående om vad nästling skyddar måste namnge den betraktare den skyddar mot.

Leveransen är ett kort dokument och inte en fungerande anslutning: vilken slutpunkt som använder vilken väg, vad som händer vid ett avbrott på den yttre tunneln och de tre kommandon som visar det aktuella läget. strongSwans dokumentation om vidarebefordran är en användbar referens för hur tunneltrafik vidarebefordras mellan gränssnitt på en Linux-värd. Kör kontrollerna igen efter varje klientuppgradering, för de standardvärden som skapade din kedja är inget kontrakt. En nästlad tunnel du inte kan inspektera är ett rykte med en statuslampa.