Kvifor ein tenar bak ein VPN-klient svarar gjennom tunnelen

Innkomande tilkoplingar til ein vert som òg køyrer ein VPN-klient, feilar på ein svært spesifikk måte: handtrykket kjem inn, daemonen svarar, og klienten får ingenting tilbake. Ingenting blokkerer porten. Svaret forlét tunnelen, fordi tunnelen eig standardruta og kjernen rutar svar etter destinasjon, ikkje etter minnet om kvar førespurnaden kom frå. Den eine utelatinga forklarer kvart symptom som følgjer.

Svaret blir ruta, ikkje hugsa

Ein VPN-klient som installerer ei standardrute, legg til ei oppføring som overgår LAN-gatewayen, anten ved metrikk eller ved å dele rommet i to meir spesifikke halvdelar. Utgåande pakkar vel no tunnelgrensesnittet. Kjernen spør aldri kvar pakken som blir svara opphavleg kom inn. Den eine utelatinga forklarer kvart symptom som følgjer.

Framoverretninga blir ruta etter destinasjon, og det same blir retninga tilbake. Svaret er adressert til ein offentleg klient, som tunnelen gjerne ber. Den fjerne enden tek imot ein pakke han ikkje eig kjelda til, kastar han, og den opphavlege klienten ventar til tida renn ut.

Streng reverse-path-filtrering kan sleppe den innkomande pakken før daemonen i det heile les han. Sjekk den teljaren først, fordi eit filterdropp og ein rute feil ser identiske ut utanfrå.

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

Den første kommandoen viser kva standardrute som vinn no. Den andre rapporterer om streng filtrering gjeld globalt eller per grensesnitt, og den tredje viser kvar ein einaste regel i videresendingskjeda som kan vere involvert.

Tre måtar å halde på returvegen

Å utelate destinasjonen til tenesta frå tunnelen er det smalaste alternativet. Ei vertsrute peikt mot LAN-gatewayen, pluss ein daemon bunden til den fysiske adressa i staden for alle adresser, held den eine straumen utanfor tunnelen. Endringa er lokal og lett å reversere.

Policy-ruting er det generelle svaret. Ein regel knytt til kjeldeadressa eller til eit brannmurmerke vel ei tabell der standarden peikar mot WAN-gatewayen, medan dei eigne tilkoplingane til verten held fram med å bruke tunnelen. Hald prioriteten eksplisitt slik at regelen ikkje kan bli overskugga seinare.

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

Dei to første kommandoane byggjer den alternative vegen for svar med kjelde i den offentlege adressa. Den tredje spør kjernen kva veg nett den kjelda og destinasjonen ville ta, og slik stadfestar du at regelen har nokon effekt.

Kjeldeomsetjing er det tredje alternativet og det einaste som overlever ein ruter som allereie gjer NAT framfor tenesta. Svaret må tilbake til den ruteren, og maskering til WAN-grensesnittet oppnår det medan klienten blir skjult frå tenesteloggane. Å byte ut standardruta manuelt etter tilkopling er diagnostikk, fordi klienten skriv om tabellen ved neste gjenoppkopling.

Når boksen òg rutar for eit LAN

Den same feilen dukkar opp eitt hopp lenger ute når verten rutar for einingar bak seg. Ei innkomande tilkopling blir videresend til ei intern eining der den einaste returvegen er tunnelen, og svaret når den eksterne klienten frå adressa til leverandøren. Den interne eininga fungerer rett heile tida.

Tilkoplingssporing ser då eit svar for ein straum ho aldri registrerte, og kastar det. Destinasjonsomsetjing leverer den innkomande tilkoplinga til eininga, og kjeldeomsetjing får svaret til å sjå ut som det kjem frå ruteren sjølv.

Ein policyrute som held den videresende porten på WAN medan den eigne trafikken til ruteren brukar tunnelen, er den penare ekvivalenten. Utan kjeldeomsetjing er svaret adressert til den eksterne klienten, og den interne eininga har inga rute til den adressa i det heile.

Tre undersøkingar som skil årsakene

Køyr tre undersøkingar: ei tilkopling inn til boksen frå internett, ei tilkopling ut av han til ein offentleg vert og eit namneoppslag. Når dei to første er ueinige, er returvegen skulda. Når namn feilar begge vegar, er resolvaren ein annan feil som berre deler tunnelen.

Fiks først routing-spørsmålet, sjå deretter på namn. Å blande dei to er korleis ein fungerande tenar blir skulda for ein øydelagd resolvar.

Noter kva grensesnitt unntaket nemner, og hald konfigurasjonen under versjonskontroll. Ein regel skriven mot eit grensesnitt som får nytt namn etter ei oppgradering, held i dag og feilar etter neste omstart.