Nesta VPN: kva tunnel ber den ytre sambindinga?

To VPN-klientar som køyrer samstundes gjev ingen nesta tunnel; dei gjev to tunnelar og ein krangel om rutinga. Ein nesta tunnel finst når sambindinga til den indre klienten til sin eigen tenar sjølv blir boren av den ytre tunnelen, og det er eit arrangement du byggjer med vilje. Blir det rett, ser den indre tenaren adressa til den ytre tenaren; blir det feil, koplar ein klient stille til på nytt rundt den andre. Tre vilkår avgjer om nestinga er ekte eller tilfeldig.

Tre vilkår avgjer nestinga

Det fyrste er kva endepunkt som treng kva veg. Namngje adressa til den indre tenaren, namngje adressa til den ytre tenaren, og slå uttrykkeleg fast at den indre tenaren berre er nåbar gjennom den ytre tunnelen. Alt anna følgjer av den setninga, òg kva ruter som høyrer i kva tabell.

Det andre er om du kan sjå vegen på kvart lag. Viss du ikkje kan spørje kjernen kva rute ein bestemt destinasjon ville bruke, utleier du kjeda frå ein endeleg utgangs-IP, og det er nettopp beviset som ikkje kan skilje nesting frå tilfeldigheit.

Det tredje er kva som skjer når den ytre tunnelen fell. Den indre tunnelen kan stoppe med han, kople til på nytt over det vanlege nettet eller halde fram med å vere blokkert til den ytre vegen kjem tilbake, og alle tre er forsvarlege retningslinjer. Dei er ikkje den same retningslinja, og standardåtferda til dei fleste klientar er den andre. Ein klient som koplar endepunktet sitt til på nytt over det fysiske nettet medan han viser ei frisk sambinding, er den vanlegaste måten ei tilsikta kjede stille blir to uavhengige tunnelar.

Vilkår éin: kva endepunkt treng kva veg

ip route get 203.0.113.10 svarar på det spørsmålet direkte: kommandoen skriv ut ruta, kjeldeadressa og grensesnittet kjernen ville bruke for den destinasjonen akkurat no.

Køyr han for den indre tenaren før den indre klienten startar og igjen etterpå, og samanlikn. Endrar svaret seg frå det fysiske grensesnittet til grensesnittet til den ytre tunnelen, er nestinga ekte i det augeblikket. Endrar det seg ikkje, koplar den indre klienten til direkte, uansett kva dashbordet seier. Gjenta for adressa til den ytre tenaren, som framleis må slåast opp via det fysiske grensesnittet, fordi ei rute som fangar begge endepunkta rekursivt er feilen som tek maskinen heilt av nettet.

Vilkår to: gransk vegen på kvart lag

Ruteval er meir enn hovudtabellen på ein moderne klient. Policyreglar kan sende merkte pakkar til ein annan tabell, ein klient kan binde sockelen sin til eit grensesnitt, og ein container eller namespace har heilt eigne tabellar. Med ip rule og ip route show table all finn du ut kva av dette som er i spel.

Ein klient som set SO_MARK på sin eigen socket, eller er konfigurert til å binde til ei bestemt eining, går utanom standardruta du trudde du hadde ordna. Det er ein funksjon og ikkje ein feil, og det tyder at den einaste pålitelege kontrollen er ein som køyrer i same namespace som klienten. Køyrer klientane i containerar, køyr kontrollane i dei containerane i staden for på verten.

Vilkår tre: kva som skjer når den ytre tunnelen fell

Feilåtferd krev ei avgjerd, ikkje ein standard. Skriv ned kva som skal skje med den indre tunnelen når den ytre forsvinn, og få deretter klientane til å gjere det.

Alternativa er konkrete. Å stoppe den indre klienten når den ytre vegen forsvinn gjev ei rein kjede og eit tydeleg avbrot. Å la han kople til direkte på nytt gjev tilgjenge og fjernar stille eigenskapen kjeda var bygd for. Å blokkere til den ytre vegen kjem tilbake er det strengaste og det mest plagsame å drive, fordi kvar forstyrring i den ytre tunnelen blir ei synleg hending.

Test alle tre med ufarleg trafikk og eit medvite avbrot på den ytre tunnelen, for å lese konfigurasjonen fortel deg ikkje kva du har. Drep den ytre tunnelen, sjå kva den indre klienten gjer, og kontroller ruta igjen medan han er nede. Ta deretter den ytre tunnelen tilbake og stadfest at kjeda blir danna på nytt i staden for å la den indre klienten bli på den direkte vegen han valde i mellomtida.

Kva kjeda ikkje gjev deg

Ekstra lag legg til endepunkt, nøklar og feilmodusar; dei legg ikkje til noka anonymitetsgaranti, og dei gjer ikkje den ytre operatøren ute av stand til å sjå at det finst ein tunnel. Kvar påstand om kva nestinga vernar mot, må namngje observatøren ho vernar mot.

Leveransen er eit kort dokument og ikkje ei fungerande sambinding: kva endepunkt som brukar kva veg, kva som skjer ved eit avbrot på den ytre tunnelen, og dei tre kommandoane som viser den gjeldande tilstanden. dokumentasjonen til strongSwan om vidaresending er ei nyttig referanse for korleis tunneltrafikk blir vidaresend mellom grensesnitt på ein Linux-vert. Køyr kontrollane på nytt etter kvar klientoppgradering, for standardverdiane som skapte kjeda di er ikkje ein kontrakt. Ein nesta tunnel du ikkje kan inspisere, er eit rykte med ei statuslampe.