Hvorfor en server bak en VPN-klient svarer gjennom tunnelen

Innkommende tilkoblinger til en vert som også kjører en VPN-klient, feiler på en svært spesifikk måte: håndtrykket ankommer, daemonen svarer, og klienten mottar ingenting tilbake. Ingenting blokkerer porten. Svaret forlot tunnelen, fordi tunnelen eier standardruten og kjernen ruter svar etter destinasjon, ikke etter minnet om hvor forespørselen kom fra. Den ene utelatelsen forklarer hvert symptom som følger.

Svaret rutes, det huskes ikke

En VPN-klient som installerer en standardrute, legger til en oppføring som overgår LAN-gatewayen, enten ved metrikk eller ved å dele rommet i to mer spesifikke halvdeler. Utgående pakker velger nå tunnelgrensesnittet. Kjernen spør aldri hvor pakken som besvares opprinnelig ankom. Den ene utelatelsen forklarer hvert symptom som følger.

Fremoverretningen rutes etter destinasjon, og det samme gjør retningen tilbake. Svaret er adressert til en offentlig klient, som tunnelen gjerne bærer. Den fjerne enden mottar en pakke hvis kilde den ikke eier, forkaster den, og den opprinnelige klienten venter til tiden løper ut.

Streng reverse-path-filtrering kan slippe den innkommende pakken før daemonen i det hele tatt leser den. Sjekk den telleren først, fordi et filterdropp og en rute feil ser identiske ut utenfra.

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 hvilken standardrute som vinner nå. Den andre rapporterer om streng filtrering gjelder globalt eller per grensesnitt, og den tredje viser enhver videresendingskjederegel som kan være involvert.

Tre måter å beholde returveien på

Å utelukke tjenestens destinasjon fra tunnelen er det smaleste alternativet. En vertsrute pekt mot LAN-gatewayen, pluss en daemon bundet til den fysiske adressen i stedet for alle adresser, holder den ene strømmen utenfor tunnelen. Endringen er lokal og lett å reversere.

Policy-ruting er det generelle svaret. En regel knyttet til kildeadressen eller til et brannmurmerke velger en tabell hvis standard peker mot WAN-gatewayen, mens vertens egne tilkoblinger fortsetter å bruke tunnelen. Hold prioriteten eksplisitt slik at regelen ikke kan overskygges senere.

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

De to første kommandoene bygger den alternative veien for svar med kilde i den offentlige adressen. Den tredje spør kjernen hvilken vei akkurat den kilden og destinasjonen ville ta, og slik bekrefter du at regelen har noen effekt.

Kildeoversettelse er det tredje alternativet og det eneste som overlever en ruter som allerede gjør NAT foran tjenesten. Svaret må tilbake til den ruteren, og maskering til WAN-grensesnittet oppnår det mens klienten skjules fra tjenesteloggene. Å erstatte standardruten manuelt etter tilkobling er diagnostikk, fordi klienten skriver om tabellen ved neste gjenoppkobling.

Når boksen også ruter for et LAN

Den samme feilen dukker opp ett hopp lenger ute når verten ruter for enheter bak seg. En innkommende tilkobling videresendes til en intern enhet hvis eneste returvei er tunnelen, og svaret når den eksterne klienten fra leverandørens adresse. Den interne enheten fungerer riktig hele tiden.

Tilkoblingssporing ser da et svar for en strøm den aldri registrerte, og forkaster det. Destinasjonsoversettelse leverer den innkommende tilkoblingen til enheten, og kildeoversettelse får svaret til å se ut som det kommer fra ruteren selv.

En policyrute som holder den videresendte porten på WAN mens ruterens egen trafikk bruker tunnelen, er den penere ekvivalenten. Uten kildeoversettelse er svaret adressert til den eksterne klienten, og den interne enheten har ingen rute til den adressen i det hele tatt.

Tre undersøkelser som skiller årsakene

Kjør tre undersøkelser: en tilkobling inn til boksen fra internett, en tilkobling ut av den til en offentlig vert og et navneoppslag. Når de to første er uenige, er returveien skylden. Når navn feiler begge veier, er resolveren en annen feil som bare deler tunnelen.

Fiks først routing-spørsmålet, se deretter på navn. Å blande de to er hvordan en fungerende server blir beskyldt for en ødelagt resolver.

Noter hvilket grensesnitt unntaket nevner, og hold konfigurasjonen under versjonskontroll. En regel skrevet mot et grensesnitt som får nytt navn etter en oppgradering, består i dag og feiler etter neste omstart.