Raggiungere un client IKEv2 sul suo IP virtuale assegnato

Un gateway deve avviare una connessione verso un portatile collegato a lui tramite IKEv2, usando l’indirizzo virtuale assegnato a quel client. Il tunnel è attivo, il client raggiunge tutto ciò che sta dietro il gateway e la direzione inversa continua a fallire. Questa asimmetria è normale: la politica negoziata descrive quali indirizzi possono parlare, non quale lato può iniziare. Tre cose devono allinearsi prima che una richiesta avviata dal gateway funzioni.

Il tunnel non corregge l’indirizzo di origine

Una CHILD SA copre una coppia di selettori di traffico, uno per lato, e consente traffico in entrambe le direzioni di quella coppia. Non dice nulla su quale peer abbia aperto per primo lo scambio IKE. Un gateway che in origine ascoltava per il tunnel può comunque inviare il primo pacchetto applicativo, a condizione che l’origine e la destinazione scelte cadano dentro i selettori installati. Quando la richiesta esce dall’interfaccia sbagliata, semplicemente non è idonea al tunnel.

L’instradamento verso il client è necessario e non sufficiente. La politica deve ammettere l’origine che hai realmente usato.

Leggi la politica installata, non il file di configurazione

Parti dall’associazione attiva e dai suoi selettori, perché l’assegnazione dinamica cambia ciò che è installato nel kernel.

ipsec statusall
ip xfrm policy

L’output di stato nomina la connessione, l’indirizzo virtuale assegnato e i selettori attualmente in vigore per quel peer. Il dump della politica mostra gli stessi selettori come stato del kernel, ed è quello che la selezione dei pacchetti consulta davvero. Confronta il selettore lato gateway con l’origine che userà la tua applicazione, perché una discrepanza spiega subito il fallimento. Leggi l’indirizzo attuale del client e non uno di una sessione precedente, perché un VIP riassegnato invalida la vecchia politica.

Il client deve ascoltare dove arriva il pacchetto

Anche una politica perfetta arriva a una porta chiusa quando il servizio si lega solo al loopback. L’ascoltatore deve stare sull’indirizzo assegnato o su un indirizzo locale jolly.

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

L’elenco dei socket mostra se la porta è legata all’indirizzo virtuale, e le regole del firewall mostrano se le nuove connessioni sono accettate dall’origine protetta. Una regola scritta per connessioni stabilite non ammette una connessione che il gateway avvia. Mantieni l’autenticazione propria del servizio, perché arrivare attraverso il tunnel stabilisce solo da quale rete è arrivato il pacchetto. Un client dietro il proprio NAT non ha ancora bisogno di port forwarding in ingresso, perché queste richieste viaggiano dentro il tunnel esistente.

Prova la nuova direzione da sola

Una richiesta funzionante da client a server non esercita mai questo percorso. Genera la richiesta dal gateway e osserva entrambe le estremità.

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 ricerca della rotta risponde quale origine e interfaccia userebbe il gateway, ed è il valore che la politica deve ammettere. La cattura dovrebbe mostrare la richiesta uscire dentro ESP e non come TCP semplice sull’interfaccia pubblica. Sul client, cattura il traffico decifrato per confermare l’arrivo e se il servizio ha risposto. Se la richiesta sparisce senza ESP sul collegamento, sospetta l’indirizzo di origine prima del firewall del client.

Ripeti il test dopo un cambio di chiavi o una riconnessione, perché il VIP può cambiare. Un percorso che funziona solo fino alla sessione successiva non è un percorso che funziona.