Por que un servidor detrás dun cliente VPN responde polo túnel

As conexións entrantes a un host que tamén executa un cliente VPN fallan dun xeito moi concreto: o handshake chega, o demo responde e o cliente non recibe nada de volta. Nada bloquea o porto. A resposta saíu polo túnel, porque o túnel posúe a ruta predeterminada e o núcleo enruta as respostas por destino, non polo recordo de onde veu a petición. O demo está ben e o porto está aberto.

A resposta enrútase, non se lembra

Un cliente VPN que instala unha ruta predeterminada engade unha entrada que supera a pasarela LAN, xa sexa por métrica ou dividindo o espazo en dúas metades máis específicas. Os paquetes saíntes agora elixen a interface do túnel. O núcleo nunca pregunta de onde chegou orixinalmente o paquete que se está a responder. Esa única omisión explica todos os síntomas que seguen.

A dirección de ida enrútase por destino, e a de volta tamén. A resposta diríxese a un cliente público, que o túnel levará de bo grado. O extremo remoto recibe un paquete cuxa orixe non posúe, descártao, e o cliente orixinal espera ata que se esgota o tempo.

O filtrado estrito da ruta inversa pode descartar o paquete entrante antes de que o demo o lea. Comproba ese contador primeiro, porque un descarte por filtro e un erro de enrutamento vense idénticos desde fóra.

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

O primeiro comando mostra que ruta predeterminada gaña agora. O segundo informa se o filtrado estrito se aplica globalmente ou por interface, e o terceiro mostra calquera regra da cadea de reenvío que poida estar implicada.

Tres xeitos de conservar o camiño de volta

Excluír o destino do servizo do túnel é a opción máis estreita. Unha ruta de host apuntada á pasarela LAN, máis un demo ligado ao enderezo físico en lugar de a todos os enderezos, mantén ese único fluxo fóra do túnel. O cambio é local e fácil de reverter.

O enrutamento por políticas é a resposta xeral. Unha regra baseada no enderezo de orixe ou nunha marca de devasas escolle unha táboa cuxa ruta predeterminada apunta á pasarela WAN, mentres as conexións propias do host seguen usando o túnel. Mantén a prioridade explícita para que a regra non quede eclipsada máis adiante.

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

Os dous primeiros comandos constrúen o camiño alternativo para as respostas con orixe no enderezo público. O terceiro pregunta ao núcleo que camiño tomaría exactamente esa orixe e destino, e así confirmas que a regra ten algún efecto.

A tradución de orixe é a terceira opción e a única que sobrevive a un router que xa fai NAT diante do servizo. A resposta ten que volver a ese router, e o enmascaramento cara á interface WAN conségueo mentres agocha o cliente dos rexistros do servizo. Substituír a ruta predeterminada a man tras conectarse é un diagnóstico, porque o cliente reescribe a táboa na próxima reconexión.

Cando a máquina tamén enruta para unha LAN

O mesmo fallo aparece un salto máis alá cando o host enruta para os dispositivos que ten detrás. Unha conexión entrante reenvíase a un dispositivo interno cuxo único camiño de volta é o túnel, e a resposta chega ao cliente externo desde o enderezo do provedor. O dispositivo interno funciona correctamente todo o tempo.

O seguimento de conexións ve entón unha resposta dun fluxo que nunca rexistrou e descártaa. A tradución de destino entrega a conexión entrante ao dispositivo, e a tradución de orixe fai que a resposta pareza vir do propio router.

Unha ruta de política que mantén o porto reenviado na WAN mentres o tráfico propio do router usa o túnel é o equivalente máis limpo. Sen tradución de orixe a resposta diríxese ao cliente externo, e o dispositivo interno non ten ningunha ruta para ese enderezo.

Tres sondas que separan as causas

Executa tres sondas: unha conexión cara á máquina desde internet, unha conexión desde ela a un host público e unha consulta de nome. Cando as dúas primeiras discrepan, o camiño de volta é o culpable. Cando os nomes fallan en ambos os sentidos, o resolutor é outro fallo que só comparte o túnel.

Arranxa primeiro a cuestión de enrutamento, despois mira os nomes. Mesturar os dous é como se culpa a un servidor que funciona dun resolutor roto.

Anota que interface nomea a excepción e mantén a configuración baixo control de versións. Unha regra escrita contra unha interface que se renomea tras unha actualización pasa hoxe e falla tras o próximo reinicio.