Por que o seu servizo público de Linux responde a través da VPN

Nada no socket recorda que interface transportou a solicitude, así que unha ruta predeterminada de VPN de túnel completo pode capturar unha resposta que pertence á WAN. O servizo non ignora a interface de entrada; Linux encamiña unha resposta xerada localmente segundo o destino e a política de orixe. Unha regra baseada na orixe pode enviar só as respostas do servizo por unha táboa WAN completa, deixando a saída ordinaria no túnel. O porto permanece aberto mentres a resposta sae pola ruta incorrecta, e por iso o síntoma parece unilateral.

A idea errónea: as respostas seguen a interface pola que chegaron

Parece lóxico que un paquete que chega por eth0 deba saír por eth0. Os filtros de paquetes sen estado poden escribirse así, e tcpdump no lado de entrada mostra a solicitude exactamente onde se espera. O encamiñamento non funciona así para o tráfico que orixina o propio host.

Unha vez que o servizo acepta a conexión, a súa resposta é un novo paquete xerado localmente. O núcleo consulta as regras de encamiñamento para o destino e a orixe da resposta, e a ruta predeterminada da VPN é unha resposta perfectamente válida. Nada no socket recorda que interface transportou a solicitude.

Por iso o síntoma parece unilateral: chegan solicitudes, desaparecen respostas. Por iso tamén engadir unha regra de cortafogos para o porto de entrada non cambia nada. O paquete non se bloquea á entrada; encamíñase a outro lugar á saída. Siga a resposta cunha busca cualificada por orixe e o desvío faise visible.

O que realmente encamiña o núcleo: o enderezo de orixe

A asa que necesita é o enderezo local que o servizo usa para as respostas. Nun host co enderezo eth0 ilustrativo 192.0.2.10/24 e a pasarela 192.0.2.1, ese enderezo está presente na interface. Nunha VM na nube, o enderezo público pode estar traducido augas arriba e ausente no convidado, así que use o enderezo que o host realmente ten.

Inspeccione o estado actual antes de reservar un número de táboa ou unha prioridade de regra. As regras de política existentes poden eclipsar unha nova, e unha táboa antiga co mesmo número pode xa levar rutas non relacionadas:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

Despois seleccione unha táboa por orixe. A regra coincide coas respostas que xa levan 192.0.2.10, exactamente o tráfico terminado localmente que quere eximir. O tráfico reenviado e os paquetes doutros enderezos locais non coinciden.

Construa unha táboa de retorno completa, non media ruta predeterminada

Unha táboa só cunha ruta predeterminada non abonda. O núcleo aínda ten que resolver a pasarela, e esa resolución necesita o prefixo conectado na mesma táboa. Unha táboa á que lle falta ese prefixo falla na resolución da pasarela aínda que a súa ruta predeterminada pareza correcta. Engada ambas e logo apunte a regra de orixe á táboa:

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Use o prefixo e a pasarela reais en lugar de copiar o exemplo. Unha interface na nube configurada como /32 cunha pasarela no enlace necesita unha ruta conectada distinta, e unha táboa construída co prefixo incorrecto falla no primeiro salto. O atributo src indica a orixe preferida para esa ruta; non substitúe a regra de orixe.

A orde tamén importa. Unha regra ampla cun número de prioridade máis baixo avalíase primeiro, así que a regra de orixe debe acadarse antes que calquera regra que devolvese este tráfico á táboa principal. Comprobe as prioridades con ip rule show despois de engadila, non só no arranque.

Verifique cunha busca cualificada por orixe

Pida ao núcleo que encamiñe un destino de proba desde o enderezo do servizo. A resposta debería nomear eth0 e a pasarela WAN, non o túnel:

ip -4 route get 198.51.100.25 from 192.0.2.10

Despois estableza unha nova conexión autorizada e observe ambas direccións. Unha busca que selecciona a táboa correcta mentres a conexión real segue fallando apunta ao filtrado de ruta inversa ou a unha regra de cortafogos, non á táboa. Comprobe eses controis antes de desactivar nada globalmente.

Poña as rutas finais e a regra baixo o xestor de rede que posúe a interface. Os cambios de enderezo, a renovación de DHCP e as reconexións de VPN reescriben todo o estado do núcleo, e unha regra engadida á man desaparece ou apunta a unha pasarela obsoleta despois do seguinte evento.

Onde se detén esta excepción

A regra exime o tráfico terminado localmente dun enderezo de orixe. Non cobre os portos publicados por Docker, o DNAT nin os servizos reenviados a través do host, porque eses paquetes encamíñanse como tráfico reenviado e nunca levan a orixe local do host do mesmo xeito. Eses deseños adoitan necesitar unha marca posta na entrada e unha regra que coincida coa marca.

Tampouco fai que o enderezo público do host apareza na interface. Cando un NAT augas arriba posúe ese enderezo, a resposta aínda ten que saír pola ruta que ese NAT espera, e por iso a táboa WAN debe reflectir a pasarela e o prefixo orixinais en lugar dun rango público adiviñado.

Manteña a excepción documentada co seu número de táboa, a prioridade da regra e o enderezo de orixe exacto. O próximo cambio na VPN ou na interface pode rompela en silencio, e unha nota que nomee os tres valores compróbase máis rápido que redescubrir o síntoma nun informe de cliente.

Se o servizo segue respondendo pola ruta incorrecta despois de que a busca cualificada por orixe pase, compare o enderezo de orixe do socket activo co da regra. Un servizo ligado a un enderezo comodín pode escoller unha orixe distinta da que probou, e esa discrepancia é a fenda restante.