A política de IPsec está a tragar o teu tráfico local: como sabelo

A impresora do escritorio deixa de responder no momento en que o túnel sobe, e nada na configuración do túnel menciona a impresora. O que adoita pasar é que se escribiu un rango protexido o bastante amplo como para incluíla, así que a máquina agora intenta cifrar tráfico que debía quedar no segmento local. Ler a política instalada explica a captura; estreitala no lugar correcto mantén protexido o tráfico remoto. O percorrido desde a petición que falla ata a política coincidente leva uns minutos.

Segue o fluxo antes de cambiar un selector

Comeza pola petición que falla e anota catro valores: o enderezo de orixe que usa a máquina, o destino exacto, a ruta que escolle o núcleo e a política que coincide con ese par.

Eses catro feitos deciden se a captura é deliberada ou accidental. Un destino que cae dentro do selector remoto está protexido por deseño, aínda que o deseño fose erróneo. Un destino fóra del que aínda así se captura significa que outra cousa está a coincidir, e cambiar o selector non axudará. Ambos os casos son habituais, e un só comando distíngueos.

Fai isto antes de editar nada, porque o caso interesante é a subrede local que se solapa cun rango privado que a conexión protexe. Prefixos coñecidos como 192.168.0.0/16 aparecen en moitas redes, e un selector escrito para un deles pode cubrir o teu sen que o notes.

Tres tipos de local que se comportan distinto

Un destino asignado a este host, un destino na mesma ligazón e un destino detrás doutra interface son tres casos diferentes. O núcleo trata cada un de forma distinta cando decide se o tráfico necesita protección.

O tráfico xerado pola propia pasarela tampouco é o mesmo que o tráfico reenviado desde un cliente. Unha política que parece correcta para o tráfico reenviado pode capturar a propia sesión de xestión da pasarela, e así é como un administrador perde o acceso mentres arranxa o túnel.

O hábito útil é nomear o caso en voz alta: este paquete vén de min, vai á miña ligazón ou pasa por min? Cada resposta apunta a un lugar distinto onde estreitar. Escribir o caso tamén impide que a seguinte persoa repita o mesmo traballo.

Cando o rango protexido é todo un espazo privado, os tres casos poden caer dentro á vez, e o síntoma pasa a ser unha máquina que non alcanza nada agás o extremo do túnel.

Le a política instalada, non o ficheiro

Os ficheiros de configuración describen a intención; o núcleo garda as políticas que coinciden de verdade. Mostra os dous e trata unha discrepancia como o primeiro achado.

Estes comandos mostran a ruta escollida para o destino e as políticas instaladas en cada dirección:

ip route get 192.168.50.20
ip xfrm policy list
sudo swanctl --list-conns

A ruta diche que interface usaría o paquete. A lista de políticas diche se despois se aplica un modelo a ese paquete, e a lista de conexións mostra que selectores cre o daemon que instalou. Se o destino aparece nun selector remoto, atopaches a captura sen adiviñar.

Estreita o selector ou evita o destino

Hai dúas reparacións admitidas e responden a preguntas diferentes. Estreitar o selector di que esta conexión só protexe un rango menor, o que é correcto cando o rango máis amplo foi un erro. Engadir unha excepción di que este destino concreto nunca debe protexerse, o que é correcto cando o rango protexido é realmente amplo e un destino é a excepción.

Escolle a primeira cando poidas, porque un selector máis pequeno é máis doado de razoar e aparece na definición da conexión. Escolle a segunda cando o rango amplo sexa intencionado e a excepción sexa un só host ou unha subrede que poidas nomear.

Ambas pertencen á configuración que posúe a conexión. Unha regra en tempo de execución engadida á man desaparece na seguinte reconexión, e o fallo volve nun momento en que ninguén lembra a solución temporal.

Excepcións que sobreviven a unha reinstalación

Despois do cambio, repite a mesma petición inofensiva e mira os mesmos contadores. O destino local debería responder, e o destino remoto previsto debería seguir mostrando tráfico cifrado.

Estas dúas comprobacións confirman que a excepción sobreviviu e que a protección non:

ip xfrm policy list | grep -c out
ping -c 3 192.168.50.20

Despois desconecta e reconecta o túnel a propósito, e repite as dúas. Unha excepción que funciona antes da reconexión e falla despois aplicouse na capa equivocada, e é a forma máis habitual de que este problema volva.