Tunnel attivo, niente internet: dove si ferma l’inoltro

Il client si connette, il tunnel trasporta ping verso il gateway e nulla oltre risponde. Quello stato è normale per un gateway che doveva solo fornire accesso a reti protette, ed è un guasto per uno pubblicizzato come uscita a tunnel completo. Prima di cambiare regole, conferma quale servizio è stato promesso. Poi segui una sola richiesta pubblica nei quattro punti in cui può fermarsi. Una richiesta e una cattura di pacchetti risolvono più di una pagina di supposizioni.

Conferma se l’uscita su internet è mai stata il progetto

Un profilo split tunneling instrada solo le sottoreti protette nella VPN, quindi la navigazione pubblica continua sul collegamento locale e non tocca mai il gateway. Un profilo a tunnel completo installa una rotta predefinita nel tunnel, il che rende il gateway responsabile dell’intero percorso. Entrambi sono progetti legittimi, e confonderli produce un rapporto di guasto dove non c’è. Leggi le rotte annunciate dal client prima di testare qualsiasi altra cosa, perché la tabella di routing risponde alla domanda che il ticket di solito sbaglia.

Ciò che il client installa non è sempre ciò che il profilo intende. Una rotta inviata può essere sovrascritta da una rotta locale con metrica più bassa, e un client che mantiene la rotta LAN aggiungendo una rotta predefinita si comporta come uno split tunnel per quella sottorete.

Segui una sola richiesta pubblica

Scegli una sola destinazione e seguila dal client verso l’esterno. Sul client, controlla che il pacchetto scelga davvero il tunnel e quale indirizzo locale usi come origine. Poi controlla il gateway: il pacchetto arriva, ed esce dall’interfaccia pubblica. Ognuna di quelle risposte elimina un’intera categoria di cause.

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

Se il gateway non vede mai il pacchetto, la rotta del client o la scelta del tunnel è sbagliata. Se arriva e non esce, il problema è sul gateway, e valgono i tre controlli rimanenti.

Controlla inoltro, rotta e traduzione

La guida all’inoltro fornita con strongSwan vale per un gateway di qualsiasi tipo di tunnel: il kernel deve poter spostare pacchetti tra interfacce, e una rotta utilizzabile deve puntare verso internet. La politica del firewall deve poi consentire il traffico, e l’indirizzo di origine deve essere uno a cui il lato pubblico possa rispondere. Un indirizzo client privato inoltrato senza modifiche su internet non riceve mai risposta.

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

La traduzione di origine è il pezzo mancante abituale. Con essa il gateway riscrive l’origine del client sul suo indirizzo pubblico e tiene traccia del flusso; senza, la risposta non ha dove andare. Le piattaforme cloud aggiungono un secondo confine, dove la tabella di routing o il gruppo di sicurezza dell’istanza possono scartare traffico che il firewall ospite consente. Quel confine è facile da mancare perché il sistema ospite sembra configurato correttamente dall’interno.

Il filtro sul percorso inverso in una configurazione asimmetrica può anche scartare pacchetti validi. Leggi il contatore di quella regola invece di dare per scontato che vada bene, perché un’impostazione rigida sull’interfaccia pubblica rifiuta il traffico che arriva da un percorso diverso da quello previsto dalla tabella di routing.

Percorso di risposta e resolver sono due risposte diverse

Osserva anche la risposta, non solo la richiesta. Se la richiesta esce tradotta e la risposta torna nel flusso tradotto, l’inoltro funziona anche quando l’applicazione continua a fallire, e l’indagine successiva spetta all’applicazione o al DNS.

Un sito che restituisce un errore HTTP è prova che l’inoltro su internet funziona. Un nome che non si risolve mentre l’accesso per indirizzo funziona è un problema di resolver, non di NAT.

Dopo una correzione mirata, riprova il client e ogni risorsa privata volutamente limitata. Concedere l’accesso a internet non deve ampliare silenziosamente l’accesso a ogni rete collegata al gateway.