Varför en server bakom en VPN-klient svarar genom tunneln

Inkommande anslutningar till en värd som också kör en VPN-klient misslyckas på ett mycket specifikt sätt: handskakningen anländer, daemonen svarar och klienten får ingenting tillbaka. Ingenting blockerar porten. Svaret lämnade tunneln, eftersom tunneln äger standardrutten och kärnan routar svar efter destination, inte efter minnet av var förfrågan kom ifrån. Den enda utelämningen förklarar varje följande symptom.

Svaret routas, det kommer inte ihåg

En VPN-klient som installerar en standardrutt lägger till en post som överträffar LAN-gatewayen, antingen via metrik eller genom att dela utrymmet i två mer specifika halvor. Utgående paket väljer nu tunnelns gränssnitt. Kärnan frågar aldrig var paketet som besvaras ursprungligen anlände. Den enda utelämningen förklarar varje följande symptom.

Framåtriktningen routas efter destination, och detsamma gäller returriktningen. Svaret är adresserat till en offentlig klient, som tunneln gärna bär. Den bortre änden tar emot ett paket vars källa den inte äger, kastar det, och den ursprungliga klienten väntar tills tiden tar slut.

Strikt reverse-path-filtrering kan släppa det inkommande paketet innan daemonen ens läser det. Kontrollera den räknaren först, eftersom ett filtertapp och ett routingfel ser identiska ut utifrån.

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

Det första kommandot visar vilken standardrutt som vinner nu. Det andra rapporterar om strikt filtrering gäller globalt eller per gränssnitt, och det tredje visar varje vidarebefordringskedjeregel som kan vara inblandad.

Tre sätt att behålla returvägen

Att utesluta tjänstens destination från tunneln är det smalaste alternativet. En värdrutt riktad mot LAN-gatewayen, plus en daemon bunden till den fysiska adressen i stället för alla adresser, håller det enda flödet utanför tunneln. Ändringen är lokal och lätt att återställa.

Policy-routing är det allmänna svaret. En regel knuten till källadressen eller till en brandväggsmarkering väljer en tabell vars standard pekar mot WAN-gatewayen, medan värdens egna anslutningar fortsätter använda tunneln. Håll prioriteten explicit så att regeln inte kan skuggas senare.

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 två första kommandona bygger den alternativa vägen för svar med källa i den offentliga adressen. Det tredje frågar kärnan vilken väg just den källan och destinationen skulle ta, och så bekräftar du att regeln har någon effekt.

Källöversättning är det tredje alternativet och det enda som överlever en router som redan gör NAT framför tjänsten. Svaret måste tillbaka till den routern, och maskering mot WAN-gränssnittet åstadkommer det medan klienten döljs från tjänstens loggar. Att byta ut standardrutten manuellt efter anslutning är diagnostik, eftersom klienten skriver om tabellen vid nästa återanslutning.

När lådan också routar för ett LAN

Samma fel dyker upp ett hopp längre bort när värden routar för enheter bakom sig. En inkommande anslutning vidarebefordras till en intern enhet vars enda returväg är tunneln, och svaret når den externa klienten från leverantörens adress. Den interna enheten fungerar korrekt hela tiden.

Anslutningsspårning ser då ett svar för ett flöde som den aldrig registrerade och kastar det. Destinationsöversättning levererar den inkommande anslutningen till enheten, och källöversättning får svaret att se ut som om det kommer från routern själv.

En policyrutt som håller den vidarebefordrade porten på WAN medan routerns egen trafik använder tunneln är den prydligare motsvarigheten. Utan källöversättning är svaret adresserat till den externa klienten, och den interna enheten har ingen rutt till den adressen alls.

Tre undersökningar som skiljer orsakerna

Kör tre undersökningar: en anslutning in till lådan från internet, en anslutning ut från den till en offentlig värd och en namnsökning. När de två första inte stämmer är returvägen skyldig. När namn misslyckas åt båda hållen är resolvern ett annat fel som bara delar tunneln.

Fixa routingfrågan först, titta sedan på namn. Att blanda de två är hur en fungerande server får skulden för en trasig resolver.

Anteckna vilket gränssnitt undantaget nämner och håll konfigurationen under versionskontroll. En regel skriven mot ett gränssnitt som får nytt namn efter en uppgradering fungerar i dag och misslyckas efter nästa omstart.