O cifrado comeza nunha fronteira, e esa fronteira é unha decisión de encamiñamento que toma o punto final antes de que se encapsule calquera paquete. Unha rede que nunca ve as túas claves pode aínda así entregar á túa máquina unha ruta que lle gusta máis que a do propio túnel. Aquí confúndense dous fallos: ler un paquete que xa está dentro do túnel e desviar un paquete que nunca se puxo alí.

A distinción importa porque o segundo fallo é máis barato de montar e moito máis fácil de pasar por alto. Maniféstase como unha petición que saíu pola interface equivocada mentres o cliente seguía informando dunha conexión san.

Dúas formas en que unha rede pode afectarte

Un paquete que chega ao túnel ten a súa carga útil oculta para cada salto que cruza, e esa protección mantense mesmo cando o camiño te sorprende. Un paquete que nunca chega ao túnel é unha petición corrente desde o teu enderezo, enviada ata onde apuntaba a táboa de rutas. O primeiro fallo necesita un cifrado roto ou un par comprometido, mentres que o segundo só necesita unha mensaxe de configuración na que a túa máquina decidiu confiar. Esa asimetría é a razón pola que a metade do encamiñamento merece a súa propia revisión.

O equipo que está no camiño non necesita as túas claves para influír no segundo caso. Só necesita que o teu punto final acepte unha ruta, un resolutor ou unha regra de política que produza unha.

expected:  app -> tunnel device -> encapsulation -> internet
observed:  app -> wlan0        -> plaintext     -> internet

De onde pode vir unha ruta antes de que exista o túnel

DHCP reparte máis que unha concesión de enderezo. A opción de ruta estática sen clases pode levar prefixos de destino e saltos seguintes, e RFC 3442 analiza as consecuencias de seguridade dun enderezo de encamiñador incorrecto: tráfico desviado, unha denegación de servizo ou un observador apostado no camiño. Un cliente que acepta esas rutas antes de que o túnel estea levantado pode acabar cun camiño preferido que non ten nada que ver co teu provedor.

Nada diso fai universal a inxección de rutas. O cliente ten que aceptar a opción, o prefixo ten que cubrir o tráfico que che importa, o seguinte salto elixido ten que ser alcanzable e a política de aplicación ten que permitir que o paquete saia por ese camiño. Quita calquera delas e a mesma resposta é inocua. Por iso tamén dúas máquinas nunha mesma rede poden comportarse de forma distinta, xa que non executan o mesmo cliente, a mesma política nin sequera a mesma familia de enderezos.

IPv6 merece a súa propia pasada, porque os anuncios de encamiñador levan unha ruta por defecto mediante un código distinto ao da opción DHCPv4. Unha proba que só inspecciona a táboa v4 non o cubriu.

Comproba o camiño que o núcleo elixe de verdade

As consultas de ruta pódense responder, así que pregúntalles en lugar de deducilo dunha luz de estado. Os comandos de abaixo mostran a ruta e a fonte elixidas para un destino, ademais das regras que poden prevalecer sobre a táboa principal. Execútaos mentres estás conectado e outra vez tras reconectar, porque unha renovación da concesión pode cambiar a resposta.

ip route get 203.0.113.10
ip route show table all | grep -E '^(default|203\.0\.113)'
ip rule show
resolvectl query example.com

Le a saída buscando dúas cousas: a interface nomeada na ruta e o enderezo de orixe elixido. Unha ruta de túnel nomea o dispositivo de túnel, unha ruta filtrada nomea o físico, e a diferenza vese sen descifrar nada. Se a resposta cambia entre execucións, garda ambas as saídas e compara as regras que as produciron.

Non te deteñas na ruta por defecto. Unha excepción de aplicación, un prefixo de túnel dividido ou unha segunda regra de política poden levar un destino concreto arredor do túnel mentres a ruta por defecto segue apuntando dentro.

Decide onde debe vivir a aplicación

Tres condicións deciden se a aplicación no lado do cliente abonda ou se necesitas algo fóra dela. Se o cliente instala e defende rutas para cada familia de enderezos que usas, un túnel que posúe a ruta por defecto adoita ser suficiente. Se a máquina ten que chegar a recursos locais mentres todo o demais queda dentro do túnel, esas excepcións deben enumerarse e posuírse en lugar de deixalas ao que anuncie a rede de acceso. E se a plataforma pode ligar o tráfico a unha interface por aplicación, esa ligazón é unha garantía máis forte que unha ruta que calquera cousa pode prevalecer.

Elixas o que elixas, escribe a decisión onde vive a configuración. Unha regra que existe porque alguén a tecleou durante un incidente non sobrevivirá ao seguinte reinicio, así que mantén estreitas as excepcións locais e de arranque e anota por que existe cada unha.

Volve executar os comandos de consulta despois de cada actualización do cliente e de cada cambio de rede, e compárao coa última saída rexistrada. A táboa de rutas é a fronteira de aplicación, así que trátaa como tal.

Artigos relacionados