To VPN-hopp på éin Pi: kva rute ber kva motpart

To tunneladresser på eit lite kort ser ut som ein feil, og refleksen er å sletta éi. Den refleksen øydelegg det han skulle rydda opp i. Ein vert med to hopp held éi adresse per tilkopling, og kvar adresse vert vald av ei anna rute. Spørsmålet som er verdt å stilla, er kva rute som vel kva berar for kva destinasjon, ikkje kor mange adresser som finst.

Tre destinasjonar som treng ulike berarar

Ei kjede med to hopp er tre destinasjonsklassar stabla oppå kvarandre, og kvar av dei vert boren av ei anna tilkopling. Den ytre motparten må ein nå over den fysiske lenkja. Den indre motparten må ein nå gjennom den ytre tunnelen. Destinasjonen til den dekte applikasjonen må ein nå gjennom den indre tunnelen, der eigen transport vert boren av den ytre.

Fyll ut radene med dei verkelege adressene til lesaren før du rører ei rute, fordi tabellen berre er nyttig når han er konkret. Ei fungerande kjede oppfyller alle fire radene samstundes, og ei halvfungerande kjede oppfyller vanlegvis éi av dei med feil berar. Det er lesinga av feil rad som feilen som gjer eit ruteproblem til ein heil ettermiddag med endringar.

Adresser har rollar, ikkje eit tal

Linux tillèt fleire adresser på eitt grensesnitt og fleire tunnelar på éin vert, så eit tal seier ingenting om korrektheit. Det som tel, er kva adresse som høyrer til kva tilkopling, og om ruta for ein gitt motpart vel tilkoplinga du meinte. Tre visingar svarar på det frå tre retningar, og dei er verdt å lesa i same rekkjefølgje kvar gong.

Adresseoversikta viser kva som finst og kva tilkopling som eig det. Rutetabellen svarar på berarspørsmålet for vanleg destinasjonstrafikk. Retningslinjevisninga svarar på det igjen for trafikk vald etter kjelde eller merke, som er den vanlege ordninga når to klientar deler éin vert.

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

Å sletta ei adresse fordi lista ser lang ut, kan fjerna ein del av vegen, og å sletta ei rute fordi ho ser overflødig ut, gjer det same meir lydlaust. Ingen av dei gjev ein feil; motparten sluttar berre å svara på vegen du meinte, medan han er framleis tilgjengeleg via ein annan. Ein applikasjon som rapporterer utgangsadressa til den indre motparten, beviser ikkje at trafikken kryssa den ytre tunnelen, sidan direkte tilgang gjev same observasjon. Nettopp dette gapet mellom ein observasjon og eit bevis er grunnen til at beraren vert kontrollert på rutelaget.

Aktiveringsrekkjefølgje slår ei fast venting

Viss den indre klienten er avhengig av ei adresse eller ei rute som den ytre klienten leverer, må aktiveringa venta på den ressursen i staden for på ei forseinking. Ei venting verkar til den dagen den ytre tunnelen er treg, og då feilar ho periodisk på ein måte ingen kan gjenskapa. Rekkjefølgje basert på avhengnader fjernar gjettinga og kostar ingenting utover å skildra avhengnaden éin gong. Grensesnittnamn er heller ikkje ein rekkjefølgjemekanisme.

Kjernen deler ut namn som tun0 og tun1 i opprettingsrekkjefølgje, og den rekkjefølgja kan endra seg mellom omstartar eller attoppkoplingar. Bind konfigurasjonen til ein identitet verktøyet tilbyr, eller til eit namn du tildeler medvite. Eit namn du vel, er ein kontrakt; eit namn kjernen vel, er eit tilfelle.

Hald transporten til kvar klient utanfor applikasjonsruta til den andre, og ver presis på kva OpenVPN 2.6-rutevala faktisk lovar. Den dokumenterte standardomdirigeringsmekanismen held ein klient i stand til å nå sin eigen eksterne motpart gjennom gatewayen som allereie fanst, noko som kuttar éi bestemd rekursjonsløkke. Han gjer ikkje éin klient til ein annan klients berar, så resten av kjeda er framleis ditt design. Der kjeda treng ein politikk i staden for ei rute, skriv ein uttrykkeleg kjelde- eller merkeregel og test han med trafikken han skal matcha.

Kva som skjer når det ytre hoppet døyr

Før kjeda vert rekna som komplett, må du avgjera kva som skjer når det ytre hoppet forsvinn. Transporten til den indre klienten døyr med det, og neste trekk er eit spørsmål om politikk snarare enn teknikk: feila, prøva på nytt eller kopla direkte til over den fysiske lenkja. Det tredje utfallet er det som er verdt å tenkja på. Det gjer lydlaust eit design med to hopp om til eit design med eitt hopp i det augneblinken brukaren trur at dekninga framleis er intakt.

Viss to hopp er obligatoriske, må den indre klienten ikkje kunna etablera ein direkte veg når den ytre er borte, og måten å vita det på er å bryta det ytre hoppet og sjå kva det indre gjer. Ein godkjend reserve er eit legitimt svar, men han må skrivast ned, testast og kommuniserast. Ein reserve ingen har dokumentert, kan ikkje skiljast frå ein lekkasje under gjennomgang av ei hending.

DNS og den andre adressefamilien høyrer til same avgjerd. Eit lokalt generert oppslag følgjer politikken til verten sjølv og ikkje politikken til ein vidaresend klient, så resolvaren som verkar for vidaresend trafikk, er kanskje ikkje den verten sjølv brukar.

Godta kvart lag i den rekkjefølgja du bygde det

Test i den rekkjefølgja kjeda vart bygd: først den ytre tunnelen åleine, deretter transporten til den indre klienten gjennom den ytre tunnelen, deretter applikasjonen gjennom den indre tunnelen. Kvar godtaking må vera ei fersk tilkopling i staden for ei side som allereie var open. Bryt og gjenopprett deretter kvart lag for seg og sjå kva det neste gjer.

Reserveresultatet er den mest verdfulle observasjonen her, og den ein offentleg IP-side aldri viser. Lagre vegane til motpartane, adressene dei brukar og det utfallet ved sida av konfigurasjonen, fordi den lukkelege vegen ikkje er den delen som vert stilt spørsmål ved seinare.