To VPN-hop på én Pi: hvilken rute bærer hvilken modpart

To tunneladresser på ét lille kort ligner en fejl, og refleksen er at slette den ene. Den refleks ødelægger det, den skulle rydde op i. En vært med to hop har én adresse per tilkobling, og hver adresse vælges af en forskellig rute. Spørgsmålet, der er værd at stille, er hvilken rute der vælger hvilken bærer til hvilken destination, ikke hvor mange adresser der findes.

Tre destinationer, der kræver forskellige bærere

En kæde med to hop er tre destinationstyper stablet oven på hinanden, og hver af dem bæres af en forskellig tilkobling. Den ydre modpart skal nås over det fysiske link. Den indre modpart skal nås gennem den ydre tunnel. Den dækkede applikations destination skal nås gennem den indre tunnel, hvis egen transport bæres af den ydre.

Udfyld rækkerne med læserens rigtige adresser, før du rører en rute, for tabellen er kun nyttig, når den er konkret. En fungerende kæde opfylder alle fire rækker på samme tid, og en halvt fungerende kæde opfylder normalt én af dem med den forkerte bærer. Det er læsningen af den forkerte række som fejlen, der gør et ruteproblem til en hel eftermiddag med rettelser.

Adresser har roller, ikke et antal

Linux tillader flere adresser på én grænseflade og flere tunneler på én vært, så et antal siger intet om korrekthed. Det afgørende er, hvilken adresse der hører til hvilken tilkobling, og om ruten for en given modpart vælger den tilkobling, du mente. Tre visninger besvarer det fra tre retninger, og de er værd at læse i samme rækkefølge hver gang.

Adresseoversigten viser, hvad der findes, og hvilken tilkobling der ejer det. Rutetabellen besvarer bærerspørgsmålet for almindelig destinationstrafik. Politikvisningen besvarer det igen for trafik valgt efter kilde eller mærke, som er den normale ordning, når to klienter deler én vært.

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

At slette en adresse, fordi listen ser lang ud, kan fjerne en del af stien, og at slette en rute, fordi den ser overflødig ud, gør det samme mere lydløst. Ingen af dem giver en fejl; modparten holder bare op med at svare på den sti, du havde tænkt, mens den forbliver tilgængelig ad en anden. En applikation, der rapporterer den indre modparts udgangsadresse, beviser ikke, at trafikken krydsede den ydre tunnel, da direkte adgang giver samme observation. Netop det gab mellem en observation og et bevis er grunden til, at bæreren tjekkes på rutelaget.

Aktiveringsrækkefølge slår en fast søvn

Hvis den indre klient afhænger af en adresse eller en rute, som den ydre klient leverer, skal aktiveringen vente på den ressource i stedet for på en forsinkelse. En søvn virker indtil den dag, hvor den ydre tunnel er langsom, og så fejler den periodisk på en måde, ingen kan genskabe. Afhængighedsbaseret rækkefølge fjerner gætteriet og koster intet ud over at beskrive afhængigheden én gang. Grænsefladenavne er heller ikke en rækkefølgemekanisme.

Kernen uddeler navne som tun0 og tun1 i oprettelsesrækkefølge, og den rækkefølge kan ændre sig mellem genstarter eller genforbindelser. Bind konfigurationen til en identitet, som værktøjet giver, eller til et navn, du tildeler bevidst. Et navn, du vælger, er en kontrakt; et navn, kernen vælger, er et tilfælde.

Hold hver klients transport ude af den andens applikationsrute, og vær præcis om, hvad OpenVPN 2.6-ruteindstillingerne faktisk lover. Den dokumenterede standardomdirigeringsmekanisme holder en klient i stand til at nå sin egen fjernmodpart gennem den gateway, der allerede fandtes, hvilket skærer én bestemt rekursionsløkke væk. Den gør ikke én klient til en anden klients bærer, så resten af kæden er fortsat dit design. Hvor kæden har brug for en politik i stedet for en rute, skriv en udtrykkelig kilde- eller mærkeregel og test den med den trafik, den skal matche.

Hvad sker der, når det ydre hop dør

Før kæden tæller som fuldstændig, skal du beslutte, hvad der sker, når det ydre hop forsvinder. Den indre klients transport dør med det, og det næste træk er et politisk spørgsmål snarere end et teknisk: fejle, prøve igen eller genoprette direkte over det fysiske link. Det tredje udfald er det, der er værd at tænke over. Det forvandler lydløst et design med to hop til et design med ét hop i det øjeblik, hvor brugeren tror, at dækningen stadig er intakt.

Hvis to hop er obligatoriske, må den indre klient ikke kunne etablere en direkte sti, når den ydre er væk, og måden at vide det på er at bryde det ydre hop og se, hvad det indre gør. En godkendt fallback er et legitimt svar, men den skal skrives ned, testes og kommunikeres. En fallback, som ingen har dokumenteret, kan ikke skelnes fra en lækage under en hændelsesgennemgang.

DNS og den anden adressefamilie hører til samme beslutning. Et lokalt genereret opslag følger værtens egen politik og ikke en videresendt klients, så den resolver, der virker for videresendt trafik, er måske ikke den, værten selv bruger.

Accepter hvert lag i den rækkefølge, du byggede det

Test i den rækkefølge, kæden blev bygget: først den ydre tunnel alene, derefter den indre klients transport gennem den ydre tunnel, derefter applikationen gennem den indre tunnel. Hver accept skal være en frisk forbindelse i stedet for en side, der allerede var åben. Bryd og genskab derefter hvert lag for sig og se, hvad det næste gør.

Fallback-resultatet er den mest værdifulde observation her, og den, en offentlig IP-side aldrig viser. Gem modparternes stier, de adresser, de bruger, og det udfald ved siden af konfigurationen, fordi den lykkelige vej ikke er den del, der bliver sat spørgsmålstegn ved senere.