Rompe un cliente VPN no teu servidor web as súas respostas?

O sitio cárgase desde un portátil na mesma rede e esgota o tempo desde calquera outro lugar, e o servidor tamén executa un cliente VPN para o seu propio tráfico de saída. Esa combinación produce un fallo concreto: chega a conexión entrante, a resposta sae pola ruta equivocada e o cliente de fóra nunca ve unha resposta. As dúas metades aparecen na mesma captura de paquetes, así que a orde dos acontecementos é a parte que merece a pena ler.

Unha regra de enrutamento baseada na orixe adoita corrixir o síntoma. Tamén adoita eximir máis tráfico que o sitio que a motivou, e esa é a parte que convén entender antes de gardar a regra.

O síntoma: responde localmente e non desde fóra

Dentro da rede a resposta non ten que cruzar o túnel, así que a páxina carga e o servizo parece san. Desde fóra, a petición chega ao servidor e a resposta enrútase cara á VPN, onde o extremo remoto non ten motivo para aceptala. O navegador ve un tempo de espera en lugar dun rexeitamento, que é a sinatura dunha ruta dun só sentido e non dun porto pechado.

Confirma a forma antes de cambiar o enrutamento: o escoitador está activo, a petición local ten éxito e a petición externa non produce ningunha resposta. Esas tres observacións xuntas apuntan á ruta de retorno e non á configuración do servidor web. Unha asimetría tan limpa é máis útil que calquera liña de rexistro, porque descarta o escoitador antes de que leas unha soa mensaxe de erro.

Mantén aberta unha ruta de administración independente mentres traballas. Unha regra que rompe a túa propia sesión SSH converte unha corrección de dez minutos nunha visita física.

Que fai coincidir realmente un selector de orixe

No enrutamento de políticas de Linux, unha regra como from 192.168.50.2 fai coincidir paquetes cuxa orixe é ese enderezo. Non codifica o feito de que o paquete continúa unha conversa que entrou polo router doméstico, e non sabe que proceso o creou. O enderezo dese exemplo é ilustrativo; substitúeo polo enderezo que o teu servidor usa realmente. Trata a liña como unha afirmación sobre enderezos e nada máis.

Se a táboa seleccionada fornece unha ruta predeterminada ordinaria, cada paquete que leve esa orixe pode tomar a mesma excepción. Outro servizo ligado ao mesmo enderezo hérdana, e unha aplicación que se liga deliberadamente a ese enderezo tamén a herda. A referencia de regras de política enumera orixe, destino, protocolo, porto, marca e prioridade como selectores separados, o que lembra que a orixe por si soa é o máis groso dos dispoñibles.

A prioridade decide o resultado. As buscas execútanse en orde e a primeira táboa que produce un resultado pode rematar a busca, así que unha regra colocada demasiado pronto pode ocultar unha ruta máis específica que unha táboa posterior tería fornecido. Le toda a lista ordenada en lugar da única liña que engadiches. Unha regra que nunca coincide non custa nada, mentres que unha que coincide demasiado pronto cambia silenciosamente todo o que hai detrás.

Comproba a ruta de retorno e o tráfico que non pretendías

Le as regras e as táboas, e logo pregunta ao núcleo que ruta tomaría un par concreto de orixe e destino. Probar desde o propio servidor non é o mesmo que probar desde fóra, así que fai ambas as cousas.

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

Despois acepta unha conexión externa nova e, por separado, unha petición que aínda debe saír pola VPN. Se a segunda agora sae directamente, a excepción é máis ampla que o problema que estabas resolvendo, e a proba que importa é a que non pensabas cambiar.

Unha comprobación de enderezo público nun navegador só informa das peticións que fixo ese navegador. Non di nada sobre as respostas do servidor web, sobre a selección de orixe doutra aplicación local nin sobre que ocorre co tráfico de xestión tras a seguinte reconexión da VPN.

Decide ata que punto pode ser estreita a excepción

Dous deseños son defendibles e deben elixirse deliberadamente. Se o servidor existe para publicar este servizo e o seu tráfico de saída non é importante, un enderezo local dedicado cunha política só para WAN é un arranxo razoable sempre que aceptes todo o alcance. Se só deben cualificar conexións entrantes concretas, a selección de enderezo é demasiado grosa e diante dela corresponde un deseño consciente das conexións.

Rexistra o contrato no que te apoias: o mapeo público, o enderezo do servidor ao que se entrega a petición e a ruta que se espera que tome a resposta. Un servizo entrante publicado a través dun provedor de VPN é un contrato distinto do publicado a través dun router doméstico, e unha excepción copiada dun exemplo adoita ser errónea para o outro.

Persiste a política no compoñente que posúe o enrutamento en lugar de pegar un comando nun ficheiro de inicio. A orde das regras, a limpeza tras un cambio de rede e a repetición tras un reinicio teñen que sobrevivir, e un ficheiro de inicio non probado adoita fallar no momento en que non miras. Remata co resultado de aceptación que poidas defender: un sitio publicado restaurado e un fluxo non relacionado sen cambios.