Que cambia o encamiñamento por políticas no tráfico VPN e que non

O encamiñamento por políticas responde a unha pregunta distinta da que formulan a maioría das notas de resolución de problemas. A táboa principal di a onde vai un destino; as regras de políticas din que táboa se consulta sequera, e poden decidilo a partir do enderezo de orixe, dunha marca de paquete, ou da interface pola que chegou un paquete. Cando un túnel se comporta de xeito inconsistente, o conxunto de regras adoita ser a causa e a táboa de encamiñamento adoita non.

As regras elixen a táboa e despois a táboa elixe a ruta

Cada regra leva unha prioridade, unha condición de coincidencia e unha táboa de destino. O núcleo percorre as regras por orde de prioridade e detense na primeira coincidencia, logo realiza unha busca ordinaria do prefixo máis longo nesa táboa. Unha regra que apunta a unha táboa baleira cae ao que seleccione a regra seguinte, e así é como unha regra escrita con coidado pode parecer que non fai nada.

Por iso volcar a táboa principal raramente explica un cliente VPN que funciona. Os clientes adoitan inserir regras con números de prioridade baixos, moito antes da regra predeterminada da táboa principal, de modo que o paquete nunca chega á ruta que estaba mirando. Baixar unha métrica na táboa principal non cambia nada para o tráfico que xa se desviara.

Unha regra tamén pode converter un prefixo nun burato negro ou facelo inalcanzable a propósito. Algúns clientes engaden esa regra como interruptor de seguridade, e entón a caída parece un túnel roto en lugar dun configurado.

Lea o conxunto de regras como unha secuencia, non como unha lista

Imprima as regras coas súas prioridades e as táboas ás que fan referencia, e despois imprima cada táboa que leve unha ruta predeterminada ou unha ruta de túnel. A orde é a parte que importa, e é a parte que unha captura de pantalla adoita omitir:

ip rule show
ip route show table all | sed -n '1,60p'
ip route get 198.51.100.20 from 10.8.0.2
ip route get 198.51.100.20 from 10.8.0.2 mark 0x1

Os dous últimos comandos son os que converten unha teoría nunha observación, porque preguntan que faría o núcleo para esa orixe e esa marca. Se a resposta cambia cando cambia a marca, hai unha regra baseada na marca en xogo e calquera proba que omita a marca está probando un paquete distinto. A conexión exterior merece unha regra propia. Un túnel que encamiña todo o tráfico a través de si mesmo debe excluír o enderezo de punto final ao que se conecta, ou os paquetes cifrados envíanse de volta ao túnel que acaban de abandonar. A maioría dos clientes insiren esa exclusión automaticamente, e un conxunto de regras editado a man é onde desaparece.

Marcas e sockets: dúas formas en que os clientes dividen o tráfico

Algúns clientes marcan paquetes na devasa e engaden unha regra que coincide coa marca. Outros usan encamiñamento a nivel de socket, poñendo unha ruta no socket antes de que se conecte. O primeiro é visible en ip rule; o segundo non, e non aparecerá nunha busca xenérica.

Se un programa de proba se comporta de xeito distinto da aplicación que debe representar, comprobe se a aplicación pon unha marca ou se liga a un dispositivo. Esa diferenza non é un misterio unha vez que se nomea o mecanismo, e explica por que un curl desde un shell e unha lapela do navegador poden tomar camiños distintos na mesma máquina. Ambas as técnicas son encamiñamento por políticas en sentido amplo: elixen un camiño con algo distinto do destino. Ningunha das dúas autoriza o tráfico, e ningunha substitúe as regras da devasa nin as credenciais que espera o par.

Rastree a propiedade antes de engadir outra regra

As regras instálaas algo. Un cliente VPN, un xestor de rede e un script escrito a man poden engadir regras ao arrancar, e a lóxica de reconexión pode deixar atrás o conxunto anterior. Dúas regras obsoletas dun perfil anterior seguirán dirixindo o tráfico moito despois de que se eliminase o perfil.

Averigüe que proceso posúe a regra pola súa prioridade e a súa forma, e comprobe se ese propietario reescribe o conxunto en cada conexión. Se o fai, unha regra manual engadida hoxe desaparece mañá, e a corrección pertence á configuración do cliente e non a un ficheiro de historial do shell. Limpar todo o conxunto de regras para probar é un atallo tentador cun custo previsible: tamén elimina as regras que o cliente necesita para manter o seu propio túnel funcionando. Borre unha regra á vez, ou probe nunha máquina que poida reiniciar.

Demostre o alcance con dous fluxos, non con un

Unha corrección só se verifica cun fluxo que debería verse afectado e un fluxo que non. Escolla un destino que a política encamiñe ao túnel, e un que deba quedar fóra, e logo compare as buscas e as capturas de ambos:

ip route get 198.51.100.20 from 192.0.2.44
ip route get 198.51.100.21 from 192.0.2.44
tcpdump -ni any host 198.51.100.21 and port 443

Cando as dúas buscas devolven interfaces diferentes, a regra fai algo. Cando devolven a mesma interface, a regra coincide máis amplamente do previsto, e ese é o fallo que envía en silencio unha subrede enteira por un túnel pensado para unha soa aplicación.

Anote as prioridades das regras e o servizo propietario no ticket, xunto cos dous enderezos de proba. A persoa seguinte terá entón un par reproducible en lugar dunha descrición dun síntoma, e poderá dicir nun minuto se o encamiñamento por políticas segue en xogo.