Kvifor ei full tunnel-rute kuttar ut serveren som ber henne

Slå på ein full tunnel, og kvar destinasjon høyrer no til VPN-grensesnittet, inkludert maskinen som avsluttar han. Dei ytre pakkane som ber tunnelen, er adresserte til den maskinen, så ruta endar med å eta opp transporten ho er avhengig av. Éi ekstra spesifikk rute løyser det, og grunnen er verd å forstå. Utan den grunnen innfører neste gjenoppbygging feilen på nytt.

Ei rute som et sin eigen transport

Innkapsling pakkar kvar pakke inn i eit andre hovud. Det ytre er adressert frå den lokale fysiske adressa til den offentlege adressa til serveren, og det må krysse den fysiske sambindinga før nokon tunnel kan finst.

Lat no oppslaget etter den offentlege adressa velje tunnelen. For å sende pakken må maskinen kapsle han inn, noko som krev ei rute til same adresse, som returnerer tunnelen. Klientar handterer dette på ein av to måtar. Ein forsiktig nektar å installere standardruta og rapporterer ein feil, medan ein mindre forsiktig rapporterer suksess og flyttar så ingenting. Den stille feilen er den som kostar ein ettermiddag.

Det lengste prefikset avgjer oppslaget før nokon metrikk blir konsultert, så ei rute for éi adresse overgår kvar standardrute på maskinen. Det er heile mekanismen bak reparasjonen.

Installer unntaket før standardruta

Lag ei rute for éi adresse for serveren, med den fysiske gatewayen som neste hopp, før standardruta flyttar seg. Rekkjefølgja har noko å seie: å installere ho etterpå tyder å leve med ein øydelagd tunnel medan du skriv.

Dei fleste klientar gjer dette uoppfordra. OpenVPN slår opp den eksterne adressa og festar ho før standardgatewayen blir skriven om, og route-delay-valet finst for plattformer der den sekvensen kappast om. wg-quick vel ein heilt annan veg, ved å merke pakkar og rådspørje ei policyregel i staden for å leggje til eit unntak. Ulike mekanismar, same krav: den ytre pakken må sleppe unna tunnelen han skaper.

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

Utdataa frå oppslaget er aksepttesten. Han må namngje den fysiske eininga og det fysiske neste hoppet. Ei tunneleining i det svaret tyder at unntaket manglar, eller vart plassert etter noko som overstyrer det.

Spegelbildet på serveren

Den same fella ventar på den andre sida, omvendt. Gi serveren ei standardrute gjennom ein annan tunnel, eller dytt ei rute til han som dekkjer dei offentlege adressene til klientane, og svara hans får ein vane med feil veg.

Sjå føre deg ein klient som koplar til og sender ein førespurnad. Svaret er adressert til den offentlege adressa til den klienten, som no svarar til ei tunnelrute, så det forlèt eit anna grensesnitt med ein kjelde klienten aldri har slått. Klienten kan ta imot pakken og likevel kaste han, fordi ingenting bind han til førespurnaden han sende. Arbeid frå rutingsavgjerda til serveren i staden for frå tidsavbrotet til klienten, sidan berre éin av dei viser det faktiske valet.

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 finst tre reparasjonar, og dei er ikkje like. Å feste tenesta til den fysiske adressa eller omsetje kjelda skjuler begge rutingsavgjerda i staden for å rette ho. Å sende svar-trafikk for tunnelbassenget gjennom ein dedikert tabell rettar årsaka, og dei to andre er berre akseptable så lenge rutingsdesignet er frose.

Unntak tunnelen held fram med å stele

Ein handfull oppgåver treng det opne internettet sjølv medan tunnelen eig standardruta, og kvar av dei treng sitt eige unntak. Den dynamiske DNS-oppdateraren er vanlegvis den første som bryt saman.

Han slår opp leverandøren, opnar ei sambinding og oppdagar at hans eigne pakkar reiser gjennom ein tunnel der adressa endra seg for sekund sidan, så oppdateringa mislykkast eller publiserer feil adresse. Tre vegar ut: fest leverandøren med ei vertsrute gjennom den fysiske gatewayen, køyr oppdateringa før tunnelen reiser seg, eller gi oppdateraren ein policytabell som tunnelen aldri rører. Tidssynkronisering har same eksponering på ei eining som startar utan resolver, og endepunkt for sertifikatvalidering høyrer heime på lista av same grunn.

Eit unntak ingen skreiv ned, er eit unntak som neste gjenoppbygging stille slepp.

Prov det etter ein gjenoppkopling, ikkje før

Test tre destinasjonar, ikkje éin: endepunktet, ei privat adresse bak tunnelen og ei offentleg adresse utanfor. Eitt vellukka oppslag seier nesten ingenting om dei 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 så sambindinga på nytt, fordi ein klient som byggjer opp tabellen sin på nytt ved gjenoppkopling, vil kaste ei rute du skreiv for hand. Med ein kill switch i spel, kontroller at endepunktet er tillate, elles kan ikkje tunnelen kome tilbake etter ei nettverksendring, og symptomet ser ut som eit avbrot. Lagre unntaket i profilen eller unit-fila i staden for i ein shell-historie, slik at gjenoppkoplinga gjenopprettar det i staden for å slette det.