Arribar a un client IKEv2 a la seva IP virtual assignada

Una passarel·la ha d’iniciar una connexió cap a un portàtil connectat a ella per IKEv2, fent servir l’adreça virtual assignada d’aquest client. El túnel està aixecat, el client arriba a tot el que hi ha darrere la passarel·la i la direcció inversa encara falla. Aquesta asimetria és normal: la política negociada descriu quines adreces poden parlar, no quin costat pot iniciar. Tres coses han de coincidir abans que funcioni una petició iniciada per la passarel·la.

El túnel no arregla l’adreça d’origen

Una CHILD SA cobreix una parella de selectors de trànsit, un per costat, i permet trànsit en totes dues direccions d’aquesta parella. No diu res sobre quin igual va obrir primer l’intercanvi IKE. Una passarel·la que inicialment escoltava el túnel encara pot enviar el primer paquet d’aplicació, sempre que l’origen i la destinació triats caiguin dins dels selectors instal·lats. Quan la petició surt de la interfície equivocada, simplement no és elegible per al túnel.

L’encaminament cap al client és necessari i no suficient. La política ha d’admetre l’origen que realment has fet servir.

Llegeix la política instal·lada, no el fitxer de configuració

Comença per l’associació activa i els seus selectors, perquè l’assignació dinàmica canvia què hi ha instal·lat al nucli.

ipsec statusall
ip xfrm policy

La sortida d’estat anomena la connexió, l’adreça virtual assignada i els selectors vigents en aquest moment per a aquest igual. L’abocament de política mostra els mateixos selectors com a estat del nucli, i és el que consulta realment la selecció de paquets. Compara el selector del costat de la passarel·la amb l’origen que farà servir la teva aplicació, perquè una discrepància explica la fallada de seguida. Llegeix l’adreça actual del client i no una d’una sessió anterior, perquè una VIP reassignada invalida la política antiga.

El client ha d’escoltar on arriba el paquet

Fins i tot una política perfecta arriba a un port tancat quan el servei només s’enllaça a loopback. L’oient ha de ser a l’adreça assignada o en una adreça local comodí.

ss -ltnp 'sport = :9090'
iptables -S INPUT

El llistat de sockets mostra si el port està enllaçat a l’adreça virtual, i les regles del tallafocs mostren si s’accepten connexions noves des de l’origen protegit. Una regla escrita per a connexions establertes no admet una connexió que inicia la passarel·la. Conserva l’autenticació pròpia del servei, perquè arribar pel túnel només estableix de quina xarxa ha vingut el paquet. Un client darrere del seu propi NAT encara no necessita cap redirecció de port entrant, perquè aquestes peticions viatgen dins del túnel existent.

Prova la nova direcció per si sola

Una petició correcta de client a servidor mai no recorre aquest camí. Genera la petició des de la passarel·la i observa tots dos extrems.

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

La consulta de ruta respon quin origen i quina interfície faria servir la passarel·la, i aquest és el valor que la política ha d’admetre. La captura hauria de mostrar la petició sortint dins d’ESP i no com a TCP pla a la interfície pública. Al client, captura el trànsit desxifrat per confirmar l’arribada i si el servei ha respost. Si la petició desapareix sense ESP al cable, sospita de l’adreça d’origen abans que del tallafocs del client.

Repeteix la prova després d’una renegociació de claus o d’una reconnexió, perquè la VIP pot canviar. Un camí que només funciona fins a la propera sessió no és un camí que funcioni.