VPN sul router o inoltro di porta: quale vince?

Il router termina il VPN da solo, e una vecchia regola di inoltro invia ancora la stessa porta UDP a una macchina sulla LAN. Solo una delle due può essere il vero punto di arrivo, e il kernel non arbitra. La traduzione di destinazione riscrive il pacchetto prima che il servizio locale venga consultato, quindi il processo VPN attende traffico già inviato altrove. Il compito è stabilire chi possiede la porta, poi far concordare le regole.

Una porta, due proprietari rivendicati

Un server VPN in esecuzione dentro il router ha bisogno di un permesso in ingresso che porti alla propria socket. Una voce NAT di destinazione per la stessa porta porta altrove: un indirizzo LAN e una decisione di inoltro. Sono punti di arrivo diversi con log diversi e modalità di errore diverse. L’indizio abituale è che una famiglia di indirizzi funziona e l’altra no, perché la voce rimasta è stata scritta per una sola famiglia e non è mai stata rivista.

Annota la pretesa prima di modificare: famiglia, indirizzo esterno, trasporto, porta e destinazione tradotta.

La traduzione passa prima del controllo locale

Il NAT di destinazione cambia la destinazione del pacchetto nella fase di prerouting, prima che il kernel scelga tra consegna locale e inoltro. Quando la destinazione è un host della LAN, il pacchetto prende il percorso di inoltro. Le regole di ingresso per la socket del router non vengono mai consultate, per questo il registro VPN resta vuoto mentre il client scade.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Quest’ordine è l’intero meccanismo, e le interfacce degli apparati lo nascondono dietro caselle di spunta senza cambiarlo. Il proprietario della destinazione decide ancora quale percorso prende un pacchetto.

Se l’host della LAN è il punto di arrivo previsto, l’inoltro è corretto e il router non dovrebbe ascoltare anche su quella porta.

Tieni una mappatura e rimuovi l’altra

Elenca le voci NAT per quella porta e famiglia e scegli il sopravvissuto:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

Una voce TCP con lo stesso numero è irrilevante per un guasto UDP, e trattarle come un unico oggetto porta a cancellare la regola sbagliata. Quando la socket locale deve vincere, il proprietario della mappatura in conflitto rimuove o riscrive quella singola voce, e il permesso in ingresso per la porta del router resta al suo posto. Gli inoltri non correlati, il percorso di gestione e una copia dell’insieme di regole dovrebbero tutti sopravvivere alla modifica.

Se il VPN vive su un host separato, l’inoltro è l’oggetto giusto. Un servizio in un container o in una macchina virtuale può aver bisogno di una porta pubblicata anche quando la scatola si chiama router, quindi segui la socket e il suo spazio dei nomi, non l’etichetta sull’involucro.

Conferma il proprietario dall’esterno

Prova ogni famiglia separatamente, perché una connessione IPv6 che termina sul router non dice nulla di una connessione IPv4 che una regola obsoleta reindirizza. Leggi il registro del servizio ricevente per vedere quale punto di arrivo ha risposto, e considera il messaggio di successo del client una prova debole. Serve un nuovo flusso per un test significativo. Invia una sonda da un host esterno con nc -zvu 203.0.113.7 1194 e leggi il registro del vincitore con journalctl -u openvpn@server -n 20. L’ascoltatore del router registra la connessione da solo, mentre un host della LAN la registra nel proprio servizio.

Il tracciamento delle connessioni mantiene i flussi esistenti sulla loro mappatura originale, quindi una sessione stabilita può sopravvivere alla regola appena corretta.

Quando il punto di arrivo previsto risponde con i suoi normali controlli d’identità, prova una risorsa privata dietro il tunnel. Raggiungere l’ascoltatore esterno è solo il primo salto; l’instradamento interno e l’autorizzazione dell’applicazione sono esiti separati.