Perché i client OpenVPN mancano i selettori IPsec del gateway

Esegui un ping verso un host dietro il tunnel IPsec remoto dal gateway e risponde in modo pulito, quindi il tunnel sembra sano e il ticket prosegue. Poi un client connesso prova lo stesso host e non riceve nulla. Quel ping non è mai stato una prova per il flusso del client, perché è partito con l’indirizzo sorgente del gateway stesso e ha corrisposto a un altro selettore IPsec. Capire perché i due casi divergono è la maggior parte della correzione.

Il ping del gateway verifica un flusso che il tuo client non usa mai

L’indirizzo sorgente decide quale politica si applica. Un pacchetto generato sul gateway parte con un indirizzo della sua LAN locale o del suo endpoint del tunnel, e la politica che vi corrisponde è stata scritta esattamente per quel caso. Il pacchetto di un client arriva sull’interfaccia OpenVPN con un indirizzo del pool di client, che è un selettore del tutto diverso.

Per questo il guasto sembra un problema di routing quando in realtà è un problema di ambito della politica. La raggiungibilità dal gateway dimostra che il peer è attivo e che le proposte sono state negoziate, e non dimostra nulla sul fatto che il pool sia protetto.

Invia il prefisso remoto di cui l’applicazione ha davvero bisogno

Prendi la coppia illustrativa 10.8.0.0/24 per i client connessi e 172.30.239.0/25 per la rete remota protetta. Ciò di cui un client ha bisogno è una rotta verso quel secondo prefisso, non verso la LAN del gateway e non verso qualche altro indirizzo di tunnel. Una rotta inviata al pool è ciò che fa consegnare quel traffico al gateway. Senza di essa il pacchetto non raggiunge mai la decisione di politica che stai debuggando.

Su un server Community che accetta rotte inviate, la direttiva prende la maschera reale: push "route 172.30.239.0 255.255.255.128". Access Server configura la stessa destinazione tramite le impostazioni di rete privata o di regole di accesso della versione installata, con la modalità routed o tradotta scelta deliberatamente. Modificare le catene firewall generate invece della configurazione proprietaria è il modo in cui un’installazione funzionante diventa impossibile da riprodurre.

Dopo la connessione leggi la tabella di routing del client e non l’intenzione del server. Una rotta che copre solo il pool significa che l’invio non è mai arrivato, e una rotta predefinita attraverso il tunnel è più ampia di questo requisito e ti sorprenderà più avanti. Controlla la maschera oltre al prefisso, perché un /25 inviato come /24 manda il traffico degli indirizzi vicini su un percorso che non può portarlo. Poi conferma che il client abbia scelto l’interfaccia del tunnel per quella destinazione.

Fai includere il pool di client nei selettori

Per un accesso routed che preserva gli indirizzi dei client, la politica IPsec deve proteggere il traffico tra il pool e il prefisso remoto. I selettori scritti per la LAN del gateway stesso ammettono il ping e scartano la richiesta del client, ed è esattamente l’asimmetria che ha avviato questa indagine.

Ispeziona la politica negoziata e anche le proposte configurate, per esempio con ipsec statusall su strongSwan o il comando di stato equivalente per la tua implementazione. Con IPsec basato su politiche la rotta ordinaria può puntare a un’interfaccia fisica mentre il traffico corrispondente resta cifrato, quindi l’assenza di un dispositivo di tunnel non dimostra nulla. Confronta le coppie di selettori con il pool e il prefisso che hai annotato.

Un NAT sorgente generico sul gateway può rompere la corrispondenza. Se una regola di masquerade riscrive la sorgente del client prima del controllo di politica, il pacchetto non somiglia più al selettore che hai scritto. È una ragione per cui una regola di masquerade ampia è una cattiva correzione per un secondo VPN: cambia quale politica si applica e quale indirizzo registra il lato remoto. Esenta il traffico che intendi instradare, oppure traducilo deliberatamente e aggiorna i selettori.

Scegli routing o traduzione di proposito

Il routing mantiene l’indirizzo del client visibile al lato remoto, così i log remoti e le regole per sorgente restano significativi, e richiede che il gateway remoto conosca il percorso di ritorno al pool. La traduzione nasconde il pool dietro un solo indirizzo, il che elimina il problema della rotta di ritorno e distrugge l’identità per client.

Scegli un solo progetto e scrivilo, perché i due richiedono selettori diversi e un ordine del firewall diverso. Un masquerade applicato a metà finisce tra i due e non soddisfa nessuno. La scelta scritta è anche ciò che permette al prossimo ingegnere di distinguere un bug da una decisione deliberata.

Chiudi il ciclo su inoltro e risposta

Il gateway deve inoltrare il protocollo e la destinazione che intendi, il che significa inoltro IP abilitato e una catena di inoltro che consenta la coppia. Poi il lato remoto deve rispedire le risposte lungo il percorso IPsec, ed è una decisione di routing sul loro gateway e non sul tuo. Entrambe le metà sono configurazione ordinaria, ed entrambe restano facilmente a metà. Provalo separatamente, così una regola di inoltro mancante non viene scambiata per un tunnel rotto.

Verifica con una vera richiesta da client ad applicazione, guardandola attraversare l’interfaccia OpenVPN, la decisione IPsec e l’host remoto. Ispeziona la risposta come osservazione separata, perché una richiesta che arriva e una risposta che non torna mai appaiono identiche dal posto del client. Una richiesta tracciata vale più di qualsiasi numero di ping dal gateway.

Mantieni stretta l’autorizzazione della destinazione durante i test, e conferma che un client senza la regola non possa raggiungere il servizio. Una rotta installata più un’associazione stabilita non è la stessa cosa di un accesso concesso.