To VPN-hopp på én Pi: hvilken rute bærer hvilken motpart

To tunneladresser på ett lite kort ser ut som en feil, og refleksen er å slette én. Den refleksen ødelegger det den skulle rydde opp i. En vert med to hopp holder én adresse per tilkobling, og hver adresse velges av en forskjellig rute. Spørsmålet som er verdt å stille, er hvilken rute som velger hvilken bærer for hvilken destinasjon, ikke hvor mange adresser som finnes.

Tre destinasjoner som trenger forskjellige bærere

En kjede med to hopp er tre destinasjonsklasser stablet oppå hverandre, og hver av dem bæres av en annen tilkobling. Den ytre motparten må nås over den fysiske lenken. Den indre motparten må nås gjennom den ytre tunnelen. Destinasjonen til den dekkede applikasjonen må nås gjennom den indre tunnelen, hvis egen transport bæres av den ytre.

Fyll ut radene med leserens virkelige adresser før du berører en rute, fordi tabellen bare er nyttig når den er konkret. En fungerende kjede oppfyller alle fire radene samtidig, og en halvfungerende kjede oppfyller vanligvis én av dem med feil bærer. Det er lesingen av feil rad som feilen som gjør et ruteproblem til en hel ettermiddag med endringer.

Adresser har roller, ikke et antall

Linux tillater flere adresser på ett grensesnitt og flere tunneler på én vert, så et antall sier ingenting om korrekthet. Det som betyr noe, er hvilken adresse som hører til hvilken tilkobling, og om ruten for en gitt motpart velger tilkoblingen du mente. Tre visninger svarer på det fra tre retninger, og de er verdt å lese i samme rekkefølge hver gang.

Adresseoversikten viser hva som finnes og hvilken tilkobling som eier det. Rutetabellen svarer på bærerspørsmålet for vanlig destinasjonstrafikk. Policyvisningen svarer på det igjen for trafikk valgt etter kilde eller merke, som er den vanlige ordningen når to klienter deler én vert.

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

Å slette en adresse fordi listen ser lang ut, kan fjerne en del av veien, og å slette en rute fordi den ser overflødig ut, gjør det samme mer lydløst. Ingen av dem gir en feil; motparten slutter bare å svare på veien du mente, mens den forblir tilgjengelig via en annen. En applikasjon som rapporterer utgangsadressen til den indre motparten, beviser ikke at trafikken krysset den ytre tunnelen, siden direkte tilgang gir samme observasjon. Nettopp dette gapet mellom en observasjon og et bevis er grunnen til at bæreren kontrolleres på rutelaget.

Aktiveringsrekkefølge slår en fast venting

Hvis den indre klienten avhenger av en adresse eller en rute som den ytre klienten leverer, må aktiveringen vente på den ressursen i stedet for på en forsinkelse. En venting virker til den dagen den ytre tunnelen er treg, og da feiler den periodisk på en måte ingen kan gjenskape. Avhengighetsbasert rekkefølge fjerner gjetningen og koster ingenting utover å beskrive avhengigheten én gang. Grensesnittnavn er heller ikke en rekkefølgemekanisme.

Kjernen deler ut navn som tun0 og tun1 i opprettelsesrekkefølge, og den rekkefølgen kan endre seg mellom omstarter eller gjenoppkoblinger. Bind konfigurasjonen til en identitet verktøyet tilbyr, eller til et navn du tildeler bevisst. Et navn du velger, er en kontrakt; et navn kjernen velger, er et tilfelle.

Hold transporten til hver klient utenfor den andres applikasjonsrute, og vær presis på hva OpenVPN 2.6-rutevalgene faktisk lover. Den dokumenterte standardomdirigeringsmekanismen holder en klient i stand til å nå sin egen eksterne motpart gjennom gatewayen som allerede fantes, noe som kutter én bestemt rekursjonsløkke. Den gjør ikke én klient til en annen klients bærer, så resten av kjeden er fortsatt ditt design. Der kjeden trenger en policy i stedet for en rute, skriv en uttrykkelig kilde- eller merkeregel og test den med trafikken den skal matche.

Hva som skjer når det ytre hoppet dør

Før kjeden regnes som komplett, må du bestemme hva som skjer når det ytre hoppet forsvinner. Transporten til den indre klienten dør med det, og neste trekk er et spørsmål om policy snarere enn teknikk: feile, prøve på nytt eller koble direkte til over den fysiske lenken. Det tredje utfallet er det som er verdt å tenke på. Det gjør lydløst et design med to hopp om til et design med ett hopp i det øyeblikket brukeren tror at dekningen fortsatt er intakt.

Hvis to hopp er obligatoriske, må den indre klienten ikke kunne etablere en direkte vei når den ytre er borte, og måten å vite det på er å bryte det ytre hoppet og se hva det indre gjør. En godkjent reserve er et legitimt svar, men den må skrives ned, testes og kommuniseres. En reserve ingen har dokumentert, kan ikke skilles fra en lekkasje under gjennomgang av en hendelse.

DNS og den andre adressefamilien hører til samme beslutning. Et lokalt generert oppslag følger vertens egen policy og ikke en videresendt klients, så resolveren som virker for videresendt trafikk, er kanskje ikke den verten selv bruker.

Aksepter hvert lag i den rekkefølgen du bygde det

Test i den rekkefølgen kjeden ble bygget: først den ytre tunnelen alene, deretter transporten til den indre klienten gjennom den ytre tunnelen, deretter applikasjonen gjennom den indre tunnelen. Hver aksept må være en fersk tilkobling i stedet for en side som allerede var åpen. Bryt og gjenopprett deretter hvert lag for seg og se hva det neste gjør.

Reserveresultatet er den mest verdifulle observasjonen her, og den en offentlig IP-side aldri viser. Lagre motpartenes veier, adressene de bruker og det utfallet ved siden av konfigurasjonen, fordi den lykkelige veien ikke er den delen som blir stilt spørsmål ved senere.