Hvorfor en full tunnel-rute kutter ut serveren som bærer den

Slå på en full tunnel, og hver destinasjon tilhører nå VPN-grensesnittet, inkludert maskinen som avslutter den. De ytre pakkene som bærer tunnelen, er adressert til den maskinen, så ruten ender opp med å fortære transporten den er avhengig av. Én ekstra spesifikk rute løser det, og grunnen er verdt å forstå. Uten den grunnen gjeninnfører neste gjenoppbygging feilen.

En rute som spiser sin egen transport

Innkapsling pakker hver pakke inn i et andre hode. Det ytre er adressert fra den lokale fysiske adressen til serverens offentlige adresse, og det må krysse den fysiske forbindelsen før noen tunnel kan eksistere.

La nå oppslaget etter den offentlige adressen velge tunnelen. For å sende pakken må maskinen kapsle den inn, noe som krever en rute til samme adresse, som returnerer tunnelen. Klienter håndterer dette på en av to måter. En forsiktig nekter å installere standardruten og rapporterer en feil, mens en mindre forsiktig rapporterer suksess og deretter ikke flytter noe. Den stille feilen er den som koster en ettermiddag.

Det lengste prefikset avgjør oppslaget før noen metrikk konsulteres, så en rute for én adresse overgår enhver standardrute på maskinen. Det er hele mekanismen bak reparasjonen.

Installer unntaket før standardruten

Lag en rute for én adresse for serveren, med den fysiske gatewayen som neste hopp, før standardruten flyttes. Rekkefølgen betyr noe: å installere den etterpå betyr å leve med en ødelagt tunnel mens du skriver.

De fleste klienter gjør dette uoppfordret. OpenVPN slår opp den eksterne adressen og fester den før standardgatewayen skrives om, og route-delay-valget finnes for plattformer der den sekvensen kappes. wg-quick velger en helt annen vei, ved å merke pakker og konsultere en policyregel i stedet for å legge til et unntak. Ulike mekanismer, samme krav: den ytre pakken må unnslippe tunnelen den skaper.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

Utdataene fra oppslaget er aksepttesten. Den må navngi den fysiske enheten og det fysiske neste hoppet. En tunnelenhet i det svaret betyr at unntaket mangler, eller ble plassert etter noe som overstyrer det.

Speilbildet på serveren

Den samme fellen venter på den andre siden, omvendt. Gi serveren en standardrute gjennom en annen tunnel, eller dytt en rute til den som dekker klientenes offentlige adresser, og svarene får en vane med feil vei.

Se for deg en klient som kobler til og sender en forespørsel. Svaret er adressert til den klientens offentlige adresse, som nå samsvarer med en tunnelrute, så det forlater et annet grensesnitt med en kilde klienten aldri har slått. Klienten kan motta pakken og likevel forkaste den, fordi ingenting binder den til forespørselen den sendte. Arbeid fra serverens rutingsbeslutning i stedet for fra klientens tidsavbrudd, siden bare én av dem viser det faktiske valget.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

Det finnes tre reparasjoner, og de er ikke like. Å feste tjenesten til den fysiske adressen eller oversette kilden skjuler begge rutingsbeslutningen i stedet for å rette den. Å sende svar-trafikk for tunnelbassenget gjennom en dedikert tabell retter årsaken, og de to andre er bare akseptable så lenge rutingsdesignet er frosset.

Unntak tunnelen fortsetter å stjele

En håndfull oppgaver trenger det åpne internettet selv mens tunnelen eier standardruten, og hver av dem trenger sitt eget unntak. Den dynamiske DNS-oppdatereren er vanligvis den første som bryter sammen.

Den slår opp leverandøren, åpner en forbindelse og oppdager at dens egne pakker reiser gjennom en tunnel hvis adresse endret seg for sekunder siden, så oppdateringen mislykkes eller publiserer feil adresse. Tre veier ut: fest leverandøren med en vertsrute gjennom den fysiske gatewayen, kjør oppdateringen før tunnelen reiser seg, eller gi oppdatereren en policytabell som tunnelen aldri berører. Tidssynkronisering har samme eksponering på en enhet som starter uten resolver, og endepunkter for sertifikatvalidering hører hjemme på listen av samme grunn.

Et unntak ingen skrev ned, er et unntak som neste gjenoppbygging stille slipper.

Bevis det etter en gjenoppkobling, ikke før

Test tre destinasjoner, ikke én: endepunktet, en privat adresse bak tunnelen og en offentlig adresse utenfor. Ett vellykket oppslag sier nesten ingenting om de to andre.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Start deretter forbindelsen på nytt, fordi en klient som bygger opp tabellen sin på nytt ved gjenoppkobling, vil forkaste en rute du skrev for hånd. Med en kill switch i spill, kontroller at endepunktet er tillatt, ellers kan ikke tunnelen komme tilbake etter en nettverksendring, og symptomet ser ut som et avbrudd. Lagre unntaket i profilen eller unit-filen i stedet for i en shell-historikk, slik at gjenoppkoblingen gjenoppretter det i stedet for å slette det.