OpenVPN funziona a casa ma non su una rete: UDP o TCP?

Lo stesso profilo si connette da casa e si blocca su una rete di hotel, campus o filiale. Le credenziali non sono cambiate, quindi la variabile interessante è il percorso: cosa succede ai pacchetti prima che OpenVPN li legga. Confrontare quattro possibili cause nell'ordine in cui possono essere testate è meglio che tirare a indovinare sui certificati. Ognuna lascia una traccia diversa, ed è la traccia a distinguerle.

Quale stadio ha fallito dice quale confronto conta

Il log del client registra già fin dove sei arrivato. Una riga che dice che la negoziazione della chiave TLS non è avvenuta entro il timeout significa che un primo pacchetto è partito e non è tornato nulla di utilizzabile, il che punta al percorso. Il rifiuto di un certificato non somiglia affatto a questo: arriva una risposta, poi uno specifico errore di verifica ne indica il motivo. Annota l'ultima riga prima del ciclo di retry, perché è il valore che confronti tra reti.

Cattura mentre riprovi, non dopo. Sul client, tcpdump -ni any udp port 1194 mostra se torna qualche risposta. Ripetilo sull'interfaccia WAN di un server che controlli, il che rivela se quei pacchetti raggiungono del tutto l'altro capo.

Il traffico unilaterale è il risultato più utile disponibile qui, perché trasforma un lamento intermittente in una direzione da investigare. Conserva i file di cattura, perché la prossima segnalazione dello stesso problema è più facile da chiudere con prove che con una descrizione.

Filtraggio UDP contro porta chiusa

Molte reti di accesso considerano sospetto l'UDP prolungato, e alcuni ISP sono d'accordo. Una porta chiusa produce lo stesso silenzio dal lato del client. La differenza è la selettività: un filtro tende a essere schizzinoso su quali destinazioni o porte scarta, mentre una porta chiusa rifiuta tutto ciò che è diretto a quella porta.

Un profilo TCP sulla porta 443 è la soluzione abituale, perché assomiglia a un normale flusso HTTPS e supera la maggior parte dei portali captive e dei filtri in uscita. Due condizioni devono valere. Il server deve ascoltare con proto tcp-server e il client deve corrispondere con proto tcp-client, e l'operatore deve pubblicare quell'endpoint alternativo. Riscrivere un profilo UDP funzionante per dichiarare TCP 443 non porta da nessuna parte quando dall'altra parte non c'è nulla in ascolto.

Una porta chiusa è un problema di configurazione, non di censura. Un server dietro un router domestico ha bisogno che la sua porta UDP sia inoltrata, e il firewall del router deve consentirlo. Quando la porta non è mai stata permessa, ogni client fallisce alla negoziazione indipendentemente dalle credenziali, e il guasto segue il server invece della rete.

I protocolli più vecchi si comportano male su questo asse. PPTP richiede TCP 1723 più GRE, e GRE è il protocollo IP 47, non una porta, quindi nessun normale port forward lo esprime.

Quando è lo switch a scartare i pacchetti

Uno switch gestito può scartare il tunnel di proposito. Alcuni modelli HPE e Aruba espongono un controllo di protezione flood UDP, a volte etichettato Prevent UDP Blat Attack, nella sezione di sicurezza avanzata. Una volta attivo, un server dietro lo switch non risponde a nulla e ogni client va in timeout allo stesso modo. Disattivarlo e salvare la configurazione corrente è tutta la riparazione, ma solo dopo aver stabilito che lo switch è davvero nel percorso.

La controprova è ciò che distingue uno scarto dello switch da un blocco del provider. Leggi i contatori dell'interfaccia e il log di protezione flood prima di aprire un ticket con l'ISP. I router consumer con protezione DoS o flood falliscono nello stesso modo, e così qualsiasi middlebox con un breve timeout di inattività UDP. Un handshake che non si completa mai suggerisce uno scarto, mentre un tunnel che muore dopo minuti di silenzio suggerisce il timeout.

Annota ogni dispositivo tra client e server prima di cambiare un profilo. Una correzione applicata al livello sbagliato sembra giusta fino alla rete successiva. Quell'elenco dice anche al prossimo tecnico dove guardare senza ripetere tutta l'indagine.

Una sovrapposizione di indirizzi che sembra un guasto DNS

Una rete di accesso numerata dentro 10.0.0.0/8 può sovrapporsi al pool del tunnel, e il resolver di solito vive dentro quel pool. Quando un portatile riceve un indirizzo come 10.184.178.50 con maschera /8 su Wi-Fi, ogni destinazione 10.x è locale per definizione. I pacchetti per 10.4.0.1 vanno quindi alla LAN, il tunnel resta attivo e la risoluzione dei nomi fallisce.

ip addr espone la sovrapposizione a colpo d'occhio, e ip route get 10.4.0.1 mostra dove il pacchetto verrebbe davvero consegnato. Poiché il sintomo visibile è un guasto del resolver, questo spesso sopravvive a diversi giri di modifiche DNS.

Rinumera il pool o tieni quella rete di accesso fuori dall'ambito. Nessuna impostazione lato client recupera da una sovrapposizione.

Scegliere tra fallback TCP e correzione del percorso

Scegli il fallback TCP quando non controlli il percorso e gli utenti devono lavorare oggi, e accetta i suoi costi: TCP dentro TCP si comporta male su collegamenti con perdite, e il fallback richiede un listener che gestisci tu. Scegli la correzione del percorso quando il blocco sta su infrastruttura che possiedi, perché una regola del firewall costa meno di un secondo listener. In ogni caso, procedi per livelli in ordine: collegamento, trasporto esterno, negoziazione, routing interno. Lo stadio che è fallito su quella rete è l'unico fatto che conta.

Registra il risultato per rete, non per utente. La prossima segnalazione dello stesso guasto parte allora da uno stadio noto invece che da una teoria sui certificati. Quella registrazione è anche ciò che giustifica un secondo listener permanente, se mai ce ne fosse bisogno.