Hvorfor en fuld tunnelrute afskærer den server, der bærer den

Slå en fuld tunnel til, og hver destination tilhører nu VPN-interfacet, inklusive den maskine, der terminerer det. De ydre pakker, der bærer tunnelen, er adresseret til den maskine, så ruten ender med at fortære den transport, den afhænger af. Én ekstra specifik rute løser det, og grunden er værd at forstå. Uden den grund genindfører den næste genopbygning fejlen.

En rute, der spiser sin egen transport

Indkapsling pakker hver pakke ind i et andet hoved. Det ydre er adresseret fra den lokale fysiske adresse til serverens offentlige adresse, og det skal krydse det fysiske led, før nogen tunnel kan eksistere.

Lad nu opslaget efter den offentlige adresse vælge tunnelen. For at sende pakken skal maskinen indkapsle den, hvilket kræver en rute til den samme adresse, som returnerer tunnelen. Klienter håndterer dette på en af to måder. En forsigtig nægter at installere standardruten og rapporterer en fejl, mens en mindre forsigtig rapporterer succes og derefter ikke flytter noget. Den stille fejl er den, der koster en eftermiddag.

Det længste præfiks afgør opslaget, før nogen metrik konsulteres, så en rute til én adresse overgår enhver standardrute på maskinen. Det er hele mekanismen bag reparationen.

Installer undtagelsen før standardruten

Opret en rute til én adresse for serveren med den fysiske gateway som næste hop, før standardruten flyttes. Rækkefølgen betyder noget: at installere den bagefter betyder at leve med en brudt tunnel, mens du skriver.

De fleste klienter gør dette uopfordret. OpenVPN slår den fjerne adresse op og fastgør den, før standardgatewayen omskrives, og dens route-delay-indstilling findes til platforme, hvor den sekvens kappes. wg-quick vælger en helt anden vej, markerer pakker og konsulterer en politikregel i stedet for at tilføje en undtagelse. Forskellige mekanismer, samme krav: den ydre pakke skal undslippe den tunnel, den skaber.

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

Opslagets output er accepttesten. Det skal navngive den fysiske enhed og det fysiske næste hop. En tunnelenhed i det svar betyder, at undtagelsen mangler eller blev placeret efter noget, der tilsidesætter den.

Spejlbilledet på serveren

Den samme fælde venter på den anden side, omvendt. Giv serveren en standardrute gennem en anden tunnel, eller skub en rute til den, der dækker klienternes offentlige adresser, så får dens svar en vane med at gå den forkerte vej.

Forestil dig en klient, der forbinder og sender en anmodning. Svaret er adresseret til den klients offentlige adresse, som nu matcher en tunnelrute, så det forlader et andet interface med en kilde, klienten aldrig har ringet til. Klienten kan modtage pakken og alligevel kassere den, fordi intet binder den til den anmodning, den sendte. Arbejd ud fra serverens routingbeslutning i stedet for fra klientens timeout, da kun én af dem viser det faktiske valg.

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

Der findes tre reparationer, og de er ikke ens. At fastgøre tjenesten til den fysiske adresse eller oversætte kilden skjuler begge routingbeslutningen i stedet for at rette den. At sende svarstrafik for tunnelpuljen gennem en dedikeret tabel retter årsagen, og de to andre er kun acceptable, så længe routingdesignet er frosset.

Undtagelser, som tunnelen bliver ved med at stjæle

En håndfuld opgaver har brug for det åbne internet, selv mens tunnelen ejer standardruten, og hver især har brug for sin egen undtagelse. Den dynamiske DNS-opdatering er normalt den første, der brækker.

Den opløser udbyderen, åbner en forbindelse og opdager, at dens egne pakker rejser gennem en tunnel, hvis adresse ændrede sig for sekunder siden, så opdateringen fejler eller offentliggør den forkerte adresse. Tre veje ud: fastgør udbyderen med en værtsrute gennem den fysiske gateway, kør opdateringen før tunnelen rejser sig, eller giv opdateringen en politikstabel, som tunnelen aldrig rører. Tidssynkronisering har samme eksponering på en enhed, der starter uden en resolver, og certifikatvalideringsendepunkter hører på listen af samme grund.

En undtagelse, som ingen skrev ned, er en undtagelse, som den næste genopbygning lydløst dropper.

Bevis det efter en genopkobling, ikke før

Test tre destinationer, ikke én: endepunktet, en privat adresse bag tunnelen og en offentlig adresse ud over den. Et enkelt vellykket opslag siger næsten intet 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

Så genstart forbindelsen, fordi en klient, der genopbygger sin tabel ved genopkobling, smider en rute væk, som du skrev i hånden. Med en kill switch i spil skal du kontrollere, at endepunktet er tilladt, ellers kan tunnelen ikke vende tilbage efter en netværksændring, og symptomet ligner en afbrydelse. Gem undtagelsen i profilen eller unit-filen i stedet for i en shell-historik, så genopkoblingen genskaber den i stedet for at slette den.