Táboa de enrutamento fronte á consulta real: a onde vai o tráfico VPN
Parta dun destino e da súa orixe, e comprobe despois que regra e que táboa deciden realmente a ruta. Un volcado completo da táboa sen ese contexto engana.
Un volcado da táboa de enrutamento é o diagnóstico menos útil na resolución de problemas de VPN e o que máis se pega. Corenta liñas de prefixos dinlle que podería facer a máquina, non que fixo para a solicitude que fallou. O mecanismo que realmente quere é a consulta: dados esta orixe e este destino, que regra coincidiu, que táboa se consultou e que interface e seguinte salto saíron. Parta dun destino e dunha orixe, lea despois a táboa con esa pregunta na man, e a mesma saída convértese en evidencia en lugar de ruído.
Unha táboa é un conxunto de candidatos, non unha decisión
Cada entrada describe un prefixo e que facer co tráfico que coincide con el: envialo a unha interface, entregalo a un seguinte salto ou descartalo. Nada nesa lista está ordenado por intención, e a entrada que a unha persoa lle parece máis específica non sempre é a que o kernel selecciona, porque a selección segue a coincidencia de prefixo máis longa e, entre prefixos iguais, a métrica.
Así que o primeiro paso é preguntarlle ao kernel en lugar de ler a lista. O comando de consulta responde para un destino, e cun argumento de orixe responde para o par exacto que usaría unha conexión reenviada ou vinculada:
ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40
Cada enderezo anterior é un exemplo de documentación. O punto é a forma da resposta: interface, enderezo de orixe escollido, porta de enlace e a táboa de onde veu a entrada. Se esa saída non coincide coa interface que esperaba, localizou o problema cun só comando, e ningunha cantidade de lectura da táboa completa lle diría que candidato gañou.
A consulta percorre primeiro regras e despois táboas
En Linux a decisión é en dúas etapas. As regras de política avalíanse por orde de prioridade, e a primeira regra que coincide nomea unha táboa que consultar; esa táboa fai entón a coincidencia de prefixo máis longa. Unha regra pode coincidir por orixe, destino, marca de devasas, interface ou unha combinación, e por iso un volcado da táboa principal pode ser perfectamente exacto e completamente irrelevante para o paquete que investiga.
ip rule show
ip route show table all | head -40
ip route show table 100
Se unha regra envía o tráfico do seu grupo VPN á táboa 100, entón a táboa 100 é a que importa, e a táboa principal é un señuelo. Este é tamén o mecanismo detrás do enrutamento baseado en orixe nun enrutador: o mesmo destino pode ter dúas respostas distintas segundo de onde veña o paquete, e só a consulta cun argumento de orixe revela cal se aplica.
IPv6 ten as súas propias regras e táboas. Un deseño que executa ambas as familias necesita ambas as consultas, e unha resposta IPv4 que funciona non di nada sobre a ruta v6 que un cliente de dobre pila pode preferir.
Que instala o cliente VPN
Os clientes normalmente non substitúen a ruta predeterminada, porque facelo rompería a propia ruta exterior do túnel. Instalan algo máis específico que gaña por lonxitude de prefixo: un par de medias rutas predeterminadas que cobren 0.0.0.0/1 e 128.0.0.0/1 é o truco clásico, xa que ambas son prefixos máis longos que 0.0.0.0/0 e xuntas cobren todo o espazo. Outros instalan prefixos privados concretos máis unha regra de política, e algúns engaden unha marca para que só se capture o tráfico seleccionado.
Por iso "a VPN non cambiou a miña ruta predeterminada" non é proba de fallo. Comprobe que engadiu de feito e se o destino en cuestión cae dentro deses prefixos:
ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25
Dúas medias rutas son fáciles de pasar por alto nun volcado porque non parecen unha ruta predeterminada. Unha configuración de túnel dividido que esqueceu incluír un prefixo produce exactamente o síntoma que persegue: a aplicación que debería usar o túnel resolve e conéctase localmente no seu lugar. Compare os prefixos instalados cos destinos que o usuario realmente necesita, non cos enderezos que probou por casualidade. Unha lista de túnel dividido que cobre o servidor de ficheiros pero non o seu resolvedor produce unha conexión que resolve a un enderezo público e despois falla a autenticación, o que parece un problema de contrasinal e é un problema de ruta.
A ruta exterior tamén ten que sobrevivir
O túnel é á súa vez tráfico. Os paquetes que levan a carga encapsulada van ao enderezo do par pola interface física, e esa ruta non debe enrutarse de volta ao túnel. Cando o fai, obtén o fallo característico no que o túnel se establece e despois deixa de pasar tráfico, porque o transporte do túnel está agora dentro do túnel.
Comprobe o enderezo do par tal como comprobou o destino interior, e confirme que resolve á interface física en lugar do túnel:
ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10
Unha ruta recursiva, unha regra de política que atrapa o par ou unha ruta predeterminada substituída por un cliente de túnel completo son as tres causas habituais. As tres son visibles na consulta exterior, e ningunha é visible nun volcado da táboa principal tomado a posteriori.
Que non lle pode dicir a saída de enrutamento
Unha consulta correcta significa que o kernel enviaría o paquete a un lugar sensato. Non significa que o devasas o permita, a política IPsec o cubra, a regra NAT o traduza ou o lado remoto teña unha ruta de retorno. Cada unha delas é unha etapa posterior, e as notas de reenvío de strongSwan describen a cadea que un paquete debe atravesar nos dous extremos.
Tampouco ten en conta a vinculación a nivel de aplicación. Un proceso pode vincularse a unha interface, establecer unha marca ou usar o seu propio resolvedor e conectarse cun nome que resolve de forma distinta ao que probou. Cando a consulta é correcta e a conexión segue fallando, a seguinte pregunta é que proceso a realiza e se ese proceso ve a mesma táboa que vostede.
Así que manteña o diagnóstico ordenado: nomee o destino e a orixe, execute a consulta, lea só a táboa e a regra que a consulta nomeou, e logo probe a etapa seguinte. Esa secuencia mantén unha investigación de enrutamento en minutos e deixa un rexistro que outra persoa pode seguir, algo que unha táboa pegada nunca fai.