Por que unha ruta VPN non mostra ningunha porta de enlace na saída de ip route
Unha liña cun dispositivo e sen porta de enlace é unha ruta directa, non unha rota. Le destino, dev e scope, e despois confirma con ip route get.
As táboas de encamiñamento lense como rotas cada vez que a columna da porta de enlace queda baleira, cando a liña adoita estar completa por si soa. O campo via aparece só cando o núcleo entrega o paquete a un enderezo de seguinte salto; unha ruta ligada a unha interface alcanza os seus destinos mediante resolución de capa de enlace ou mediante un par punto a punto. Ler as columnas de esquerda a dereita diche en que caso estás, e esa lectura debería ocorrer antes de que alguén edite unha ruta predeterminada. A maioría dos tickets sobre unha porta de enlace ausente rematan nesta distinción.
Le unha liña de ruta columna por columna
Cada entrada comeza co destino e a lonxitude do seu prefixo, e despois engade modificadores nun vocabulario fixo: via, dev, proto, scope, src e metric. Unha liña como 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 é densa pero está completamente especificada. Non lle falta nada e non se implica ningún enderezo de router.
A ausencia de via é a parte interesante. Sen un seguinte salto, o núcleo resolve o destino directamente na interface indicada, o que para un túnel significa entregar o marco ao dispositivo de túnel e deixar que a encapsulación se encargue a partir de aí. proto kernel rexistra que a entrada se instalou automaticamente cando se asignou un enderezo, non que a escribise un administrador. scope link di que o destino é alcanzable nesa ligazón sen pasar por un router, e src nomea o enderezo que o núcleo preferirá como orixe para o tráfico que coincida.
Agora le unha ruta predeterminada do mesmo xeito: default via 192.0.2.254 dev eth0 proto static metric 100. Aquí via está presente porque o paquete si necesita un seguinte salto, e ese salto debe ser alcanzable el mesmo en eth0. As dúas liñas non son variantes unha da outra; responden a preguntas distintas sobre onde vai o tráfico.
Dúas formas de ruta que se confunden entre si
Unha ruta de subrede de túnel e unha ruta predeterminada parécense nunha captura de pantalla e compórtanse de xeito totalmente distinto. Usa a táboa de abaixo como axuda de lectura para os campos e despois confirma os números reais na máquina que estás depurando en lugar de fiarte dunha mostra dunha guía.
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
O que a táboa non pode dicirche é a intención. Unha ruta directa a un rango privado a través dun túnel é un deseño deliberado de túnel dividido; a mesma forma nun host que debería enviar todo pola VPN é un síntoma. A intención vive na configuración que produciu a entrada, así que mira a ferramenta que a instalou antes de concluír que o núcleo se equivocou.
Do mesmo xeito, que falte unha porta de enlace non é permiso para inventar unha. Se unha ruta necesita de verdade un seguinte salto, ese salto ten que ser alcanzable na interface que o transporta, e para un túnel punto a punto o enderezo do par non é o mesmo obxecto que o enderezo local. Tratar o enderezo local do túnel como un router Ethernet é unha forma habitual de producir unha ruta que parece correcta e non reenvía nada.
Pregúntalle ao núcleo que liña vai usar realmente
Ler a táboa non é o mesmo que realizar a consulta, porque o núcleo consulta regras de política, varias táboas e entradas na caché antes de responder. O verbo que realiza a consulta real é ip route get, e imprime a ruta que tomaría un paquete con esas propiedades.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0Substitúe o destino que de verdade che importa e despois engade from ou iif cando o tráfico se selecciona por orixe ou se reenvía, porque unha consulta local ordinaria pode escoller un camiño distinto do que escolle un cliente reenviado. A resposta nomea a interface, o enderezo de orixe escollido e calquera seguinte salto, que é a mesma información coa que se encamiñaría un paquete nese momento.
Se a resposta te sorprende, imprime as regras antes de cambiar nada: ip -4 rule show enuméraas por orde de prioridade, e un cliente VPN que instale a súa propia táboa ou unha regra para paquetes marcados non aparecerá en absoluto na táboa principal. Enumerar todas as táboas pecha ese oco.
ip -4 route show table all | grep -E 'tun|default'Comproba a capa subxacente antes de substituír a ruta predeterminada
Os paquetes propios do túnel teñen que chegar ao extremo remoto, e fanllo pola interface física usando a ruta que existía antes de que se levantase a VPN. Substituír toda a ruta predeterminada sen fixar ese extremo envía os paquetes encapsulados ao túnel que se supón que deben construír, e a conexión derrúbase. Confirma primeiro o camiño ao extremo cunha consulta só do seu enderezo.
Mantén tres cousas separadas cando fagas o cambio: a ruta ao extremo que debe quedar na interface física, os rangos privados que deberían entrar no túnel e a ruta predeterminada que decide todo o demais. Sepáraas nesa orde, aplica unha á vez e volve executar a consulta despois de cada paso. Un ping fallido despois demostra moi pouco por si só, xa que os permisos, o encamiñamento de respostas, o DNS e o propio servizo quedan todos augas abaixo dunha ruta correcta.
Anota os catro valores que che deu a liña antes da edición: destino, seguinte salto ou a súa ausencia, dispositivo e orixe escollida. Se un cambio posterior move calquera deles, sabes que decisión se alterou en realidade, e podes restaurar unha entrada en lugar de adiviñar toda a táboa.