Waarom een server achter een VPN-client via de tunnel antwoordt

Inkomende verbindingen naar een host die ook een VPN-client draait, mislukken op een heel specifieke manier: de handshake komt aan, de daemon antwoordt en de client krijgt niets terug. Niets blokkeert de poort. Het antwoord verliet de tunnel, omdat de tunnel de standaardroute bezit en de kernel antwoorden op bestemming routeert, niet op de herinnering waar het verzoek vandaan kwam. Die ene weglating verklaart elk volgend symptoom.

Het antwoord wordt gerouteerd, niet onthouden

Een VPN-client die een standaardroute installeert, voegt een vermelding toe die de LAN-gateway overtreft, hetzij via metriek, hetzij door de ruimte in twee specifiekere helften te splitsen. Uitgaande pakketten kiezen nu de tunnelinterface. De kernel vraagt nooit waar het pakket dat wordt beantwoord oorspronkelijk aankwam. Die ene weglating verklaart elk volgend symptoom.

De heenrichting wordt op bestemming gerouteerd, en de terugrichting ook. Het antwoord is geadresseerd aan een openbare client, die de tunnel graag vervoert. Het verre uiteinde ontvangt een pakket waarvan het de bron niet bezit, gooit het weg, en de oorspronkelijke client wacht tot de tijd verstrijkt.

Strikte reverse-path-filtering kan het inkomende pakket laten vallen voordat de daemon het ooit leest. Controleer die teller eerst, want een filterdrop en een routeringsfout zien er van buiten identiek uit.

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

De eerste opdracht toont welke standaardroute nu wint. De tweede meldt of strikte filtering wereldwijd of per interface geldt, en de derde toont elke doorstuurkettingsregel die erbij betrokken kan zijn.

Drie manieren om het terugpad te behouden

De bestemming van de dienst van de tunnel uitsluiten is de smalste optie. Een hostroute naar de LAN-gateway, plus een daemon die aan het fysieke adres is gebonden in plaats van aan elk adres, houdt die ene stroom buiten de tunnel. De wijziging is lokaal en gemakkelijk terug te draaien.

Policy-routing is het algemene antwoord. Een regel op basis van het bronadres of van een firewallmarkering kiest een tabel waarvan de standaard naar de WAN-gateway wijst, terwijl de eigen verbindingen van de host de tunnel blijven gebruiken. Houd de prioriteit expliciet zodat de regel later niet kan worden overschaduwd.

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 eerste twee opdrachten bouwen het alternatieve pad voor antwoorden met als bron het openbare adres. De derde vraagt de kernel welk pad precies die bron en bestemming zouden nemen, en zo bevestig je dat de regel enig effect heeft.

Bronvertaling is de derde optie en de enige die een router overleeft die al NAT doet vóór de dienst. Het antwoord moet naar die router terug, en masquerading naar de WAN-interface bereikt dat terwijl de client uit de dienstlogboeken wordt verborgen. De standaardroute na het verbinden handmatig vervangen is een diagnose, omdat de client de tabel bij de volgende herverbinding herschrijft.

Wanneer de doos ook voor een LAN routeert

Dezelfde fout verschijnt een hop verder weg wanneer de host routeert voor apparaten achter zich. Een inkomende verbinding wordt doorgestuurd naar een intern apparaat waarvan het enige terugpad de tunnel is, en het antwoord bereikt de externe client vanaf het adres van de provider. Het interne apparaat werkt de hele tijd correct.

Verbindingsregistratie ziet dan een antwoord voor een stroom die het nooit vastlegde en laat het vallen. Bestemmingsvertaling levert de inkomende verbinding bij het apparaat af, en bronvertaling laat het antwoord lijken alsof het van de router zelf komt.

Een policyroute die de doorgestuurde poort op de WAN houdt terwijl het eigen verkeer van de router de tunnel gebruikt, is het nettere equivalent. Zonder bronvertaling is het antwoord geadresseerd aan de externe client, en het interne apparaat heeft helemaal geen route naar dat adres.

Drie onderzoeken die de oorzaken scheiden

Voer drie onderzoeken uit: een verbinding naar de doos vanaf internet, een verbinding van daaruit naar een openbare host en een naamopzoeking. Wanneer de eerste twee het oneens zijn, is het terugpad schuldig. Wanneer namen in beide richtingen falen, is de resolver een andere fout die alleen de tunnel deelt.

Repareer eerst de routeringsvraag, kijk daarna naar namen. De twee mengen is hoe een werkende server de schuld krijgt van een kapotte resolver.

Noteer welke interface de uitzondering noemt en houd de configuratie onder versiebeheer. Een regel tegen een interface die na een upgrade wordt hernoemd, slaagt vandaag en faalt na de volgende herstart.