Hvorfor en server bag en VPN-klient svarer gennem tunnelen

Indgående forbindelser til en vært, der også kører en VPN-klient, fejler på en meget specifik måde: håndtrykket ankommer, daemonen svarer, og klienten får intet tilbage. Intet blokerer porten. Svaret forlod tunnelen, fordi tunnelen ejer standardruten, og kernen ruter svar efter destination frem for efter hukommelse om, hvor anmodningen kom fra. Daemonen er i orden, og porten er åben.

Svaret rutes, det huskes ikke

En VPN-klient, der installerer en standardrute, tilføjer en post, der overgår LAN-gatewayen, enten efter metrik eller ved at dele rummet i to mere specifikke halvdele. Udgående pakker vælger nu tunnelinterfacet. Kernen spørger aldrig, hvor den pakke, der svares på, oprindeligt ankom. Den ene udeladelse forklarer hvert efterfølgende symptom.

Fremadgående retning rutes efter destination, og det samme gør den omvendte. Svaret er adresseret til en offentlig klient, som tunnelen gerne bærer. Den fjerne ende modtager en pakke, hvis kilde den ikke ejer, kasserer den, og den oprindelige klient venter, til den løber tør for tid.

Streng reverse-path-filtrering kan droppe den indgående pakke, før daemonen overhovedet læser den. Kontrollér den tæller først, for et filterdrop og en rutefejl ser ens ud udefra.

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 kommando viser, hvilken standardrute der vinder nu. Den anden rapporterer, om streng filtrering gælder globalt eller pr. interface, og den tredje viser enhver videresendelseskæderegel, der kan være involveret.

Tre måder at bevare returvejen

At udelukke tjenestens destination fra tunnelen er den snævreste mulighed. En værtsrute peget på LAN-gatewayen plus en daemon bundet til den fysiske adresse i stedet for alle adresser holder den ene strøm uden for tunnelen. Ændringen er lokal og let at rulle tilbage.

Policy routing er det generelle svar. En regel bundet til kildeadressen eller til et firewall-mærke vælger en tabel, hvis standard peger på WAN-gatewayen, mens værtens egne forbindelser fortsat bruger tunnelen. Hold prioriteten eksplicit, så reglen ikke senere kan overskygges.

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 første to kommandoer opbygger den alternative vej for svar med kilde i den offentlige adresse. Den tredje spørger kernen, hvilken vej netop den kilde og destination ville tage, og sådan bekræfter du, at reglen har nogen effekt.

Kildeoversættelse er den tredje mulighed og den eneste, der overlever en router, som allerede laver NAT foran tjenesten. Svaret skal tilbage til den router, og maskering til WAN-interfacet opnår det, mens klienten skjules i tjenestens logge. Manuelt at erstatte standardruten efter forbindelse er diagnostik, fordi klienten omskriver tabellen ved næste genopkobling.

Når boksen også ruter for et LAN

Den samme fejl dukker op et hop længere ude, når værten ruter for enheder bag sig. En indgående forbindelse videresendes til en intern enhed, hvis eneste returvej er tunnelen, og svaret når den eksterne klient fra udbyderens adresse. Den interne enhed fungerer korrekt hele tiden.

Forbindelsessporing ser så et svar på en strøm, den aldrig registrerede, og dropper det. Destinationsoversættelse leverer den indgående forbindelse til enheden, og kildeoversættelse får svaret til at se ud, som om det stammer fra routeren selv.

En policyrute, der holder den videresendte port på WAN, mens routerens egen trafik bruger tunnelen, er det pænere ækvivalent. Uden kildeoversættelse er svaret adresseret til den eksterne klient, og den interne enhed har slet ingen rute til den adresse.

Tre undersøgelser, der skiller årsagerne

Kør tre undersøgelser: en forbindelse ind til boksen fra internettet, en forbindelse ud af den til en offentlig vært og et navneopslag. Når de to første er uenige, er returvejen skyld i det. Når navne fejler begge veje, er resolveren en anden fejl, der blot deler tunnel.

Ret først routing-spørgsmålet, se så på navne. At blande de to er, hvordan en fungerende server bliver bebrejdet for en brudt resolver.

Notér, hvilket interface undtagelsen nævner, og hold konfigurationen under versionskontrol. En regel skrevet mod et interface, der omdøbes efter en opgradering, består i dag og fejler efter næste genstart.