Il tunnel VPN non si connette mai: dove si fermano davvero i pacchetti

Il client continua a riprovare, il registro si ferma prima che l'handshake sia completo e il server non registra proprio nulla. Questo schema allontana dalle credenziali e punta al percorso: qualcosa tra le due estremità rifiuta di trasportare il protocollo di cui il tunnel ha bisogno. Determinate dove si fermano i pacchetti prima di toccare una delle due configurazioni, perché un protocollo filtrato e una password errata producono lo stesso errore cortese nella maggior parte dei client. I test sono ordinati per costo, il più economico per primo.

Dimostrate dove si ferma il traffico

Catturate contemporaneamente sull'interfaccia in uscita del client e sul server. Confrontate ciò che è partito con ciò che è arrivato e annotate in quale direzione compare la differenza.

Nulla sul server significa che il percorso o il primo NAT scarta il traffico, mentre gli arrivi senza risposte indicano un firewall sul server o una rotta di ritorno inesistente. Un router che termina spesso tunnel non tiene quasi mai un registro utile, quindi la cattura diventa il registro. Annotate la porta di destinazione e il numero di protocollo, perché entrambi i guasti appaiono identici in una finestra del client.

PPTP muore senza il protocollo 47

PPTP porta il controllo su TCP 1723 e i dati dentro GRE, che è il protocollo IP 47 e non un numero di porta. Inoltrare solo il 1723 produce il risultato classico: la connessione si autentica e poi tace, perché non esiste alcuna regola per il protocollo che trasporta il carico utile. Il client non può distinguerlo da una password rifiutata, per questo la cattura deve precedere le modifiche alla configurazione.

Il passthrough funziona nella direzione opposta a un inoltro in entrata, e il firmware usa abbastanza spesso un'unica etichetta per entrambi da confondere tutti. Su un client Linux il firewall locale può scartare GRE molto prima che il router sia coinvolto, quindi il protocollo 47 ha bisogno di una regola propria e l'aiutante conntrack deve essere caricato. L'ufw di Ubuntu conserva queste regole nel file before, perché le normali regole allow non possono esprimere un numero di protocollo. Ricaricate poi il firewall invece di riavviare la macchina.

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

L2TP e IPsec dietro due NAT

L2TP dentro IPsec richiede UDP 500 per lo scambio delle chiavi, UDP 4500 quando viene rilevato il NAT e ESP come protocollo 50. Ciascuno viene filtrato in modo indipendente, quindi una regola che ne consente uno non dimostra nulla sugli altri due. Due router in serie traducono ogni pacchetto due volte e le estremità non concordano più su ciò che è stato negoziato.

Mettete in bridge il modem esterno, o disattivate il NAT sul router interno, così che l'indirizzo pubblico raggiunga il dispositivo che termina il tunnel. Dove nessuna delle due è possibile, il tunnel deve essere avviato dall'interno del confine del doppio NAT, non terminato lì.

Reti degli operatori e condivisione degli indirizzi

Un indirizzo WAN dentro 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 o 100.64.0.0/10 significa che il router non ha un indirizzo pubblico e nessun inoltro in entrata da internet può raggiungerlo. Il NAT di livello operatore filtra inoltre i protocolli che non si aspetta, e GRE è una vittima frequente sui collegamenti mobili. Confrontate l'indirizzo WAN sul router stesso, non quello che un sito di ricerca riporta per un client dietro di esso.

Eseguire lo stesso router su una linea via cavo separa un riscontro sull'operatore da un errore di configurazione in un solo test. Dove l'operatore rifiuta il protocollo, le opzioni rimaste sono un altro trasporto sulla 443 o un tunnel avviato dall'interno.

Leggete l'elenco degli ascoltatori prima di chiudere porte

Una scansione di porte allarmante spesso è solo l'insieme di funzioni fornito attivo. Inventariate gli ascoltatori, associate ogni socket a una funzione, poi disattivate la funzione invece di bloccare la porta, così che le due viste non divergano.

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

I valori predefiniti di SoftEther sono un buon esempio: TCP 443, 992 e 5555, con le funzioni L2TP/IPsec e tunnel DNS che aggiungono i propri socket. Disattivare queste funzioni rimuove gli ascoltatori invece di nasconderli, e la prova da un host esterno dice se l'operatore lascia passare la porta. Un ascoltatore che risponde localmente può restare chiuso più a monte, quindi confrontate l'indirizzo WAN del router stesso con ciò che riporta un servizio esterno.