IPsec baseado en rutas entrega á táboa de encamiñamento unha decisión que antes tomaban os selectores de política. En Linux, a peza que o fai posible é a interface XFRM: un dispositivo virtual cuxo tráfico se empareja co estado de IPsec mediante un identificador de interface en lugar dun selector. Crear unha require unha soa orde e non demostra nada sobre se existe un túnel. O dispositivo é un gancho entre o encamiñamento e a política de seguridade, e ambos os lados dese gancho deben configurarse antes de que nada quede protexido.

Que é o dispositivo e que non é

Unha interface XFRM é unha asa de encamiñamento. Os paquetes encamiñados cara a ela emparellanse con políticas XFRM que fan referencia ao mesmo identificador de interface, e se existen unha política e un estado, encapsúlanse. Sen eles, a interface existe, os contadores quedan quietos e o tráfico vai a un lugar inútil.

Esa é a primeira división diagnóstica. Unha ruta cara ao dispositivo é un feito de encamiñamento, un estado instalado é un feito de seguridade, e un contador que sobe no dispositivo non é nin unha cousa nin a outra. Cando a xente di que o túnel está arriba porque a interface mostra UP, está a describir os indicadores de enlace dun dispositivo virtual que non ten par propio. O indicador só significa que o dispositivo se creou e se habilitou, nada máis.

Outra fronteira: o identificador de interface non é un nome. Dous dispositivos con nomes parecidos e identificadores distintos non comparten estado, e unha conexión configurada co identificador equivocado instala un estado que ningunha ruta usará xamais.

Constrúe unha na orde correcta

Comeza polo dispositivo exterior e un número que tamén poñerás na configuración do daemon. O exemplo usa eth0 como interface exterior e 42 como identificador, enderezos que deberías substituír polos teus.

Sobe o dispositivo e despois confirma o identificador que o núcleo rexistrou antes de tocar a configuración de VPN:

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip link set xfrm0 up
ip -d link show xfrm0 | grep -o 'if_id [0-9]*'

Agora configura a conexión en strongSwan co mesmo identificador, xa que o daemon debe instalar políticas e estados que o referencian. Fixa os selectores de tráfico local e remoto ao rango que pretendes encamiñar e despois encamiña ese rango cara ao dispositivo. A configuración do daemon e a táboa de encamiñamento deben coincidir tanto no identificador como nos destinos, e ningunha das dúas achega a outra.

Mantén IKE e ESP fóra da ruta do túnel

Unha ruta por defecto apuntada cara ao dispositivo XFRM captura os paquetes encapsulados así como o tráfico que transportan. O resultado é un bucle: a pasarela intenta enviar o seu propio ESP polo túnel que se supón que ESP debe construír.

A solución é unha ruta máis específica para o enderezo exterior do par a través da interface física, que gaña á ruta por defecto porque coincide en máis bits. O encamiñamento baseado en marcas fai o mesmo traballo cando varios túneles comparten unha táboa, e strongSwan documenta ambos os enfoques para despregamentos baseados en rutas.

Elixas o que elixas, verifica que o paquete exterior sae sen encapsular. Unha comprobación rápida é facer ping ao enderezo exterior do par unha vez que o túnel está arriba; se falla mentres a interface está arriba, sospeita de captura e non de alcanzabilidade. O mesmo razoamento se aplica á porta IKE, porque o tráfico UDP do propio daemon non debe encamiñarse cara ao dispositivo que intenta establecer.

Comproba os contadores en dous sitios antes de culpar o cifrado

Os contadores de interface e os contadores de estado miden etapas distintas. Os paquetes encamiñados cara ao dispositivo incrementan o dispositivo aínda que ningún estado coincida, mentres que os contadores de estado só se moven para o tráfico que realmente se encapsulou.

Le ambos e despois le a visión do daemon sobre a asociación filla:

ip -s link show xfrm0
sudo ip xfrm state list | grep -E 'src|proto|mode'
sudo swanctl --list-sas

Contadores do dispositivo que soben cunha saída de estado baleira significan que o encamiñamento funciona e a política non coincide, normalmente un erro de identificador ou de selector. Contadores de estado que soben mentres o lado remoto non informa de nada significan que os paquetes saen pero non chegan ou fallan a autenticación, o que apunta ao camiño ou á configuración do par. Unha asociación filla listada con cero tráfico é un problema de selector nun extremo, non un cifrador roto.

Decide quen instala as rutas

Dous propietarios para unha táboa de encamiñamento son a fonte habitual de oscilación. Se o daemon instala rutas automaticamente, o teu xestor de rede non debe instalar tamén unha ruta por defecto polo mesmo dispositivo, e unha ruta manual engadida por un script de arranque eliminarase a próxima vez que o daemon se reconfigure.

Escolle un propietario e escíbeo. Cando o daemon posúe as rutas, mantén o script de arranque fóra da táboa e deixa que a definición da conexión describa os selectores de tráfico. Cando as posúe o xestor de rede, desactiva a instalación automática e acepta que o daemon non reparará unha ruta que falte ao reconectar.

As regras de reenvío e de cortafuegos son unha decisión aparte por riba, porque unha pasarela que deixa pasar o tráfico doutros equipos necesita ambas. IPsec baseado en rutas fai que ese tráfico sexa fácil de expresar con ferramentas de encamiñamento correntes; non fai que a capa de política sexa opcional.

Artigos relacionados