Per què un servidor darrere d'un client VPN respon pel túnel

Les connexions entrants a un amfitrió que també executa un client VPN fallen d'una manera molt concreta: l'handshake arriba, el dimoni respon i el client no rep res de tornada. Res no bloqueja el port. La resposta va sortir pel túnel, perquè el túnel posseeix la ruta per defecte i el nucli encamina les respostes per destinació, no pel record d'on va venir la petició. El dimoni està bé i el port és obert.

La resposta s'encamina, no es recorda

Un client VPN que instal·la una ruta per defecte afegeix una entrada que supera la passarel·la LAN, ja sigui per mètrica o dividint l'espai en dues meitats més específiques. Els paquets sortints ara trien la interfície del túnel. El nucli mai no pregunta d'on va arribar originalment el paquet que s'està responent. Aquesta única omissió explica tots els símptomes que segueixen.

La direcció d'anada s'encamina per destinació, i la de tornada també. La resposta s'adreça a un client públic, que el túnel portarà de bon grat. L'extrem llunyà rep un paquet de què no posseeix l'origen, el descarta, i el client original espera fins que s'esgota el temps.

El filtratge estricte del camí invers pot descartar el paquet entrant abans que el dimoni el llegeixi. Comproveu primer aquest comptador, perquè un descart per filtratge i un error d'encaminament es veuen idèntics des de fora.

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

La primera ordre mostra quina ruta per defecte guanya ara. La segona informa si el filtratge estricte s'aplica globalment o per interfície, i la tercera mostra qualsevol regla de la cadena de reenviament que hi pugui intervenir.

Tres maneres de conservar el camí de tornada

Excloure la destinació del servei del túnel és l'opció més estreta. Una ruta d'amfitrió apuntada a la passarel·la LAN, més un dimoni lligat a l'adreça física en lloc de totes les adreces, manté aquest únic flux fora del túnel. El canvi és local i fàcil de revertir.

L'encaminament per polítiques és la resposta general. Una regla basada en l'adreça d'origen o en una marca de tallafoc tria una taula la ruta per defecte de la qual apunta a la passarel·la WAN, mentre les connexions pròpies de l'amfitrió continuen usant el túnel. Mantingueu la prioritat explícita perquè la regla no quedi eclipsada més endavant.

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

Les dues primeres ordres construeixen el camí alternatiu per a les respostes amb origen a l'adreça pública. La tercera pregunta al nucli quin camí prendria exactament aquest origen i destinació, i així confirmeu que la regla té algun efecte.

La traducció d'origen és la tercera opció i l'única que sobreviu a un encaminador que ja fa NAT davant del servei. La resposta ha de tornar a aquest encaminador, i l'emmascarament cap a la interfície WAN ho aconsegueix mentre amaga el client dels registres del servei. Substituir la ruta per defecte a mà després de connectar és un diagnòstic, perquè el client reescriu la taula a la propera reconnexió.

Quan la caixa també encamina per a una LAN

La mateixa fallada apareix un salt més enllà quan l'amfitrió encamina per als dispositius que té darrere. Una connexió entrant es reenvia a un dispositiu intern l'únic camí de tornada del qual és el túnel, i la resposta arriba al client extern des de l'adreça del proveïdor. El dispositiu intern funciona correctament tot el temps.

El seguiment de connexions veu llavors una resposta d'un flux que mai no va registrar i la descarta. La traducció de destinació lliura la connexió entrant al dispositiu, i la traducció d'origen fa que la resposta sembli venir del mateix encaminador.

Una ruta de política que manté el port reenviat a la WAN mentre el trànsit propi de l'encaminador usa el túnel és l'equivalent més net. Sense traducció d'origen la resposta s'adreça al client extern, i el dispositiu intern no té cap ruta per a aquesta adreça.

Tres proves que separen les causes

Feu tres proves: una connexió cap a la caixa des d'internet, una connexió des d'ella a un amfitrió públic i una consulta de nom. Quan les dues primeres discrepen, el camí de tornada és el culpable. Quan els noms fallen en tots dos sentits, el resolutor és una fallada diferent que només comparteix el túnel.

Arregleu primer la qüestió d'encaminament, després mireu els noms. Barrejar les dues coses és com un servidor que funciona és culpat d'un resolutor espatllat.

Anoteu quina interfície nomena l'excepció i manteniu la configuració sota control de versions. Una regla escrita contra una interfície que es reanomena després d'una actualització passa avui i falla després del proper reinici.