Chegar a un cliente IKEv2 no seu IP virtual asignado

Unha pasarela debe iniciar unha conexión cara a un portátil conectado a ela por IKEv2, usando o enderezo virtual asignado a ese cliente. O túnel está activo, o cliente chega a todo o que hai detrás da pasarela e a dirección inversa segue fallando. Esa asimetría é normal: a política negociada describe que enderezos poden falar, non que lado pode iniciar. Tres cousas deben aliñarse antes de que funcione unha petición iniciada pola pasarela.

O túnel non corrixe o enderezo de orixe

Unha CHILD SA cobre un par de selectores de tráfico, un por lado, e permite tráfico nas dúas direccións dese par. Non di nada sobre que par abriu primeiro o intercambio IKE. Unha pasarela que orixinalmente escoitaba o túnel aínda pode enviar o primeiro paquete de aplicación, sempre que a orixe e o destino escollidos caian dentro dos selectores instalados. Cando a petición sae pola interface equivocada, simplemente non é apta para o túnel.

O encamiñamento cara ao cliente é necesario e non suficiente. A política ten que admitir a orixe que realmente usaches.

Le a política instalada, non o ficheiro de configuración

Comeza pola asociación activa e os seus selectores, porque a asignación dinámica cambia o que está instalado no núcleo.

ipsec statusall
ip xfrm policy

A saída de estado nomea a conexión, o enderezo virtual asignado e os selectores vixentes neste momento para ese par. O volcado de política mostra os mesmos selectores como estado do núcleo, e é o que consulta realmente a selección de paquetes. Compara o selector do lado da pasarela coa orixe que usará a túa aplicación, porque unha discrepancia explica o fallo de inmediato. Le o enderezo actual do cliente e non un dunha sesión anterior, porque unha VIP reasignada invalida a política antiga.

O cliente debe escoitar onde chega o paquete

Mesmo unha política perfecta chega a un porto pechado cando o servizo só se enlaza con loopback. O oínte ten que estar no enderezo asignado ou nun enderezo local comodín.

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

A listaxe de sockets mostra se o porto está enlazado co enderezo virtual, e as regras da devasa mostran se se aceptan conexións novas desde a orixe protexida. Unha regra escrita para conexións establecidas non admite unha conexión que inicia a pasarela. Conserva a autenticación propia do servizo, porque chegar polo túnel só establece de que rede veu o paquete. Un cliente detrás do seu propio NAT segue sen necesitar redirección de porto entrante, porque estas peticións viaxan dentro do túnel existente.

Proba a nova dirección por separado

Unha petición correcta de cliente a servidor nunca percorre este camiño. Xera a petición desde a pasarela e observa ambos extremos.

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

A consulta de ruta responde que orixe e interface usaría a pasarela, e este é o valor que a política debe admitir. A captura debería mostrar a petición saíndo dentro de ESP e non como TCP simple na interface pública. No cliente, captura o tráfico descifrado para confirmar a chegada e se o servizo respondeu. Se a petición desaparece sen ESP no cable, sospeita do enderezo de orixe antes que da devasa do cliente.

Repite a proba tras unha renovación de chaves ou unha reconexión, porque a VIP pode cambiar. Un camiño que só funciona ata a próxima sesión non é un camiño que funcione.