Två VPN-hopp på en Pi: vilken rutt bär vilken motpart

Två tunneladresser på ett litet kort ser ut som ett misstag, och reflexen är att ta bort en. Den reflexen förstör det den skulle städa. En värd med två hopp håller en adress per anslutning, och varje adress väljs av en annan rutt. Frågan som är värd att ställa är vilken rutt som väljer vilken bärare för vilken destination, inte hur många adresser som finns.

Tre destinationer som behöver olika bärare

En kedja med två hopp är tre destinationstyper staplade på varandra, och var och en bärs av en annan anslutning. Den yttre motparten måste nås över den fysiska länken. Den inre motparten måste nås genom den yttre tunneln. Destinationen för den täckta applikationen måste nås genom den inre tunneln, vars egen transport bärs av den yttre.

Fyll i raderna med läsarens verkliga adresser innan du rör en rutt, eftersom tabellen bara är användbar när den är konkret. En fungerande kedja uppfyller alla fyra raderna samtidigt, och en halvfungerande kedja uppfyller vanligtvis en av dem med fel bärare. Det är läsningen av fel rad som felet som gör ett ruttproblem till en hel eftermiddag av ändringar.

Adresser har roller, inte ett antal

Linux tillåter flera adresser på ett gränssnitt och flera tunnlar på en värd, så ett antal säger ingenting om korrekthet. Det som spelar roll är vilken adress som hör till vilken anslutning, och om rutten för en given motpart väljer den anslutning du menade. Tre vyer svarar på det från tre håll, och de är värda att läsa i samma ordning varje gång.

Adressförteckningen visar vad som finns och vilken anslutning som äger det. Ruttabellen svarar på bärarfrågan för vanlig destinationstrafik. Policyvyn svarar på den igen för trafik som valts efter källa eller märke, vilket är den normala ordningen när två klienter delar en värd.

ip -4 addr show
ip -4 route show table all
ip rule show

Att ta bort en adress för att listan ser lång ut kan ta bort en del av vägen, och att ta bort en rutt för att den ser överflödig ut gör samma sak tystare. Ingen av dem ger ett fel; motparten slutar bara svara på vägen du menade medan den förblir nåbar via en annan. En applikation som rapporterar den inre motpartens utgångsadress bevisar inte att trafiken korsade den yttre tunneln, eftersom direkt åtkomst ger samma observation. Just denna klyfta mellan en observation och ett bevis är anledningen till att bäraren kontrolleras på ruttlagret.

Aktiveringsordning slår en fast väntan

Om den inre klienten är beroende av en adress eller en rutt som den yttre klienten tillhandahåller, måste aktiveringen vänta på den resursen i stället för på en fördröjning. En väntan fungerar till den dag den yttre tunneln är långsam, och då misslyckas den periodiskt på ett sätt som ingen kan återskapa. Beroendebaserad ordning tar bort gissningen och kostar inget utöver att beskriva beroendet en gång. Gränssnittsnamn är inte heller en ordningsmekanism.

Kärnan delar ut namn som tun0 och tun1 i skapelseordning, och den ordningen kan ändras mellan omstarter eller återanslutningar. Bind konfigurationen till en identitet som verktyget tillhandahåller, eller till ett namn du tilldelar medvetet. Ett namn du väljer är ett kontrakt; ett namn kärnan väljer är en slump.

Håll varje klients transport utanför den andras applikationsrutt, och var precis om vad OpenVPN 2.6-ruttalternativen faktiskt lovar. Den dokumenterade standardomdirigeringsmekanismen håller en klient i stånd att nå sin egen fjärrmotpart genom den gateway som redan fanns, vilket skär bort en specifik rekursionsloop. Den gör inte en klient till en annan klients bärare, så resten av kedjan är fortfarande din design. Där kedjan behöver en policy i stället för en rutt, skriv en uttrycklig käll- eller märkesregel och testa den med den trafik den ska matcha.

Vad som händer när det yttre hoppet dör

Innan kedjan räknas som komplett, bestäm vad som händer när det yttre hoppet försvinner. Den inre klientens transport dör med det, och nästa steg är en policyfråga snarare än en teknisk: misslyckas, försöka igen eller ansluta direkt över den fysiska länken. Det tredje utfallet är det som är värt att tänka på. Det förvandlar tyst en design med två hopp till en design med ett hopp i det ögonblick användaren tror att täckningen fortfarande är intakt.

Om två hopp är obligatoriska får den inre klienten inte kunna upprätta en direkt väg när den yttre är borta, och sättet att veta det är att bryta det yttre hoppet och se vad det inre gör. En godkänd reserv är ett legitimt svar, men den måste skrivas ned, testas och kommuniceras. En reserv som ingen har dokumenterat går inte att skilja från en läcka vid en incidentgranskning.

DNS och den andra adressfamiljen hör till samma beslut. En lokalt genererad uppslagning följer värden egna policy och inte en vidarebefordrad klients, så resolvern som fungerar för vidarebefordrad trafik är kanske inte den som värden själv använder.

Acceptera varje lager i den ordning du byggde det

Testa i den ordning kedjan byggdes: först den yttre tunneln ensam, sedan den inre klientens transport genom den yttre tunneln, sedan applikationen genom den inre tunneln. Varje acceptans måste vara en ny anslutning i stället för en sida som redan var öppen. Bryt och återställ sedan varje lager för sig och se vad nästa gör.

Reservresultatet är den mest värdefulla observationen här, och den som en offentlig IP-sida aldrig visar. Spara motparternas vägar, adresserna de använder och det utfallet bredvid konfigurationen, eftersom den lyckliga vägen inte är den del som ifrågasätts senare.