VPN connessa ma il firewall blocca ancora: come capire quale

Il client dice connesso, la risorsa continua a rifiutare, e il solito passo successivo è disattivare qualcosa. I due controlli in quella frase fanno mestieri diversi: la VPN costruisce un percorso per il traffico coperto, e un firewall decide per connessione se il traffico può passare. Un tunnel funzionante con una politica che rifiuta sembra esattamente un tunnel rotto dalla sedia dell'utente, quindi il compito è capire quale livello risponde. Questo è l'ordine che seguo, con la lettura che ti dice di fermarti.

Separa il percorso dalla politica

Parti dalla forma del guasto, perché è informazione gratuita. Un pacchetto scartato produce un timeout: il client ritenta, non torna nulla e il comando resta appeso finché non si arrende. Un rifiuto produce una negazione o un reset: qualcosa ha risposto e ha detto no. Un servizio che non ascolta rifiuta sull'host stesso, senza alcun firewall.

Quei tre esiti indicano livelli diversi. Il timeout significa che una politica da qualche parte scarta in silenzio, oppure che la rotta non lascia mai la macchina. Rifiutato significa che hai raggiunto l'host e il suo stack o il suo firewall locale ha detto no. Silenzio totale, con l'interfaccia del tunnel attiva e nessuna rotta verso la destinazione, significa che il percorso è sbagliato e nessuna regola di firewall lo sistemerà.

Leggi il percorso in una passata

Verifica che il tunnel copra la destinazione prima di guardare una sola regola. Un tunnel diviso che porta solo la sottorete dell'ufficio non instraderà una richiesta verso un'altra gamma, e allora il guasto sembra un blocco del firewall che non lo è:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

L'output della rotta nomina l'interfaccia da cui il pacchetto uscirà e l'indirizzo sorgente che porterà. Se quell'interfaccia è la tua scheda di rete fisica e non il tunnel, il problema è nell'instradamento o nelle gamme consentite del tunnel, e appartiene alla configurazione della VPN e non al firewall.

Una trappola specifica della VPN merita un controllo a parte. In WireGuard, AllowedIPs di un pari è insieme una rotta e un filtro crittografico: un pacchetto il cui indirizzo sorgente non rientra nell'insieme consentito del pari viene scartato prima che sia consultata qualsiasi regola di firewall. Quindi un firewall locale perfettamente corretto può stare dietro uno scarto silenzioso che sembra una politica, e la correzione è una riga di configurazione della chiave e non una regola.

Leggi la politica al livello che risponde

Una volta che il percorso è corretto, percorri la politica dall'host verso l'esterno e osserva l'unico livello i cui contatori si muovono:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

Il socket in ascolto risponde a una domanda diversa da quella delle regole. Se nulla ascolta sulla porta, il kernel rifiuta la connessione e nessuna regola in ingresso è pertinente. Se il socket esiste e la connessione da un client remoto scade, uno scarto sta avvenendo da qualche parte sul percorso, e i contatori delle regole ti dicono se avviene qui.

Attiva la registrazione per il profilo o la catena che sospetti invece di indovinare dall'esterno. Un solo scarto registrato che nomina sorgente, destinazione e porta identifica il livello e la regola, e dimostra anche che il pacchetto è arrivato, cosa che nessun test lato client può stabilire.

Leggi la decisione del gateway quando il tunnel finisce lì

Su un gateway site-to-site o ad accesso remoto, la VPN autentica un utente e la politica autorizza una risorsa, e sono concessioni separate. Un utente ammesso nel tunnel non è ammesso automaticamente su ogni host interno, e il rifiuto spesso arriva da una regola di inoltro mentre il tunnel stesso è sano. La stessa separazione compare in IPsec, dove la politica di sicurezza che seleziona il traffico è distinta dal filtro che lo ammette, ed è per questo che i due sono documentati come meccanismi diversi in RFC 4301.

Controlla il percorso di ritorno con la stessa cura di quello di andata. Il filtraggio con stato deve vedere la risposta, quindi l'instradamento asimmetrico attraverso il tunnel in una direzione e attorno a esso nell'altra produce scarti che sembrano casuali e si riproducono solo da alcuni client. Se il traffico raggiunge il gateway e si ferma, leggi la regola di inoltro e la rotta di ritorno insieme prima di allargare qualcosa.

Il gateway è anche il punto in cui una regola NAT o di mascheramento può nascondere la vera sorgente. Se gli host interni vedono l'indirizzo del gateway invece del client, le loro regole di firewall locale che devono corrispondere al pool di client non corrisponderanno mai, e la correzione spetta al gateway e non a ogni server.

Cambia il livello più stretto, poi verifica

Resisti alla riparazione ampia. Disattivare il firewall locale, aggiungere una regola che consente tutto o forzare ogni interfaccia in un profilo fidato elimina ogni volta il controllo che faceva il suo lavoro, e la modifica sopravvive all'incidente. Una regola limitata alla gamma sorgente e alla porta in questione è più facile da riesaminare, più facile da rimuovere, e lascia intatto il resto della politica della macchina.

Verifica con lo stesso test che ha fallito, dallo stesso client, e poi ancora una volta dopo la riconnessione, perché una regola che corrisponde prima che il tunnel rinegozi può smettere di corrispondere dopo:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Prima di chiuderlo:

• La rotta verso la destinazione esce dall'interfaccia del tunnel, e l'indirizzo sorgente corrisponde a ciò che la politica si aspetta.
• Qualcosa ascolta sulla porta, e il rifiuto o il timeout è attribuito a una regola nominata invece che supposto.
• Il gateway inoltra in entrambe le direzioni, e la destinazione vede la sorgente per cui sono state scritte le tue regole.
• Nessun controllo è stato disattivato per far passare il test, e la modifica che hai fatto nomina una sola gamma sorgente e una sola porta.