OpenVPN dietro stunnel: inoltra il wrapper, non la porta 1194

Metti un wrapper TLS davanti a OpenVPN e la distribuzione guadagna un secondo listener, di cui solo uno dovrebbe mai affacciarsi su internet. Quando il tunnel funziona dalla stessa macchina e fallisce dall'esterno, l'inoltro è di solito puntato su quello sbagliato dei due. Ciò che deve allinearsi è una catena: la regola pubblica raggiunge il wrapper, e la connessione backend del wrapper stesso raggiunge la vera socket VPN. Quattro salti portano questa catena, e ciascuno può chiudere l'indagine in anticipo.

Due socket, due proprietari, uno pubblico

Il wrapper termina TLS per la connessione esterna e passa il flusso di byte decifrato a un listener OpenVPN TCP semplice. Sono socket separate con file di configurazione separati, quindi modificarne una lascia l'altra intatta e ancora apparentemente sana. Significa anche che le due possono allontanarsi ogni volta che una cambia senza l'altra.

Lavorare dalla macchina stessa, quindi, dimostra molto poco sul percorso pubblico. Una connessione diretta alla porta nativa salta il wrapper, una connessione al wrapper sul suo indirizzo LAN salta la traduzione, e solo la disposizione completa lato client esercita ciò che fa un utente esterno. Anche i nomi vanno letti con cura, perché localhost indica l'host che esegue quel preciso componente e non l'host su cui stai digitando per caso. Tieni questa distinzione nelle tue note, perché un test registrato senza il salto che copriva invita a confrontare due cose diverse.

Dove atterra davvero l'inoltro

La catena è più facile da tenere come quattro salti che come tre numeri di porta, perché lo stesso numero può significare cose diverse a ciascun estremo. Leggi la tabella riga per riga: ogni riga è una socket che deve accettare una connessione e poi aprire la successiva. Quando una riga punta al partner sbagliato, il sintomo dell'ultima colonna è quello che l'utente segnala.

Una regola che punta alla porta VPN nativa invece che al wrapper salta del tutto la terminazione TLS, che è la versione più comune di questo errore: il client apre un handshake con un listener che si aspetta l'incorniciatura OpenVPN, quindi la connessione può aprirsi e poi bloccarsi. Conferma la porta tradotta sul file di configurazione del wrapper e non sulla memoria, perché la prossima persona che modificherà quel file potrebbe aver scelto un altro numero. I due comandi qui sotto mostrano entrambi i lati di quella domanda insieme.

grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'

L'indirizzo di binding che ti rifiuta

Una riga accept legata a 127.0.0.1 risponde solo all'host stesso, quindi un inoltro che arriva sull'indirizzo LAN non può connettersi e il client vede un rifiuto che suona come un problema di filtro pacchetti. Guarda la socket prima di toccare il firewall, perché la socket è la risposta più economica. O leghi il wrapper all'interfaccia a cui punta l'inoltro, oppure lo tieni su loopback e fai in modo che l'inoltro raggiunga loopback attraverso qualcosa che funziona davvero. Sono due progetti, e ciascuno ha bisogno della propria regola.

Mescolarli è il modo in cui un wrapper funzionante finisce irraggiungibile dall'esterno mentre ogni file sembra corretto. Il controllo qui sotto è un solo comando, e risponde a una domanda a cui una revisione delle regole del firewall non può. Se l'output mostra un indirizzo loopback mentre l'inoltro punta all'indirizzo LAN, la correzione appartiene alla riga accept e non al filtro pacchetti.

ss -lntp '( sport = :8443 )'

Cosa ha davvero dimostrato il test locale

Un successo registrato senza il salto che copriva non è una prova sugli altri salti. Annota quale indirizzo ha usato il test e quale processo ha risposto. Poi ripeti da fuori della rete invece che da un telefono sulla stessa Wi-Fi, perché il comportamento a forcella varia tra i router e una connessione che non ha mai lasciato la LAN può soddisfare un client senza che l'inoltro sia minimamente coinvolto. Solo quel secondo tentativo esercita il percorso che fa uno sconosciuto.

Quando il tentativo fallisce, segui una sola connessione in entrambi i log: le righe di accettazione e connessione del wrapper, poi il log di sessione del demone VPN. Il primo confine che non registra nulla è dove appartiene la modifica successiva. Una volta che OpenVPN confronta le opzioni del peer, giudica quei messaggi secondo le regole di quell'implementazione. Un avviso di incoerenza di link-mtu non è automaticamente fatale, fissare link-mtu a 1500 non dimostra che la frammentazione sia cessata, e la negoziazione del cifrario appartiene alla configurazione interna di OpenVPN e non all'inoltro del router.

nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pager

Quelle sonde coprono la socket backend e il log del wrapper, il che separa un backend rifiutato da un handshake rifiutato. Eseguile mentre un singolo tentativo è in corso e non dopo. Le marche temporali di un solo tentativo sono ciò che rende affidabile il confronto.

Due identità, due ordini di guasto

Il certificato esterno appartiene al wrapper e l'identità interna appartiene a OpenVPN, e possono venire da autorità diverse. Disattivare l'una o l'altra verifica per far sembrare sano un percorso scambia una protezione reale con un risultato cosmetico. Mantieni entrambe le verifiche e diagnosticarle in ordine, perché la sequenza dei messaggi nomina il livello: un problema del certificato del wrapper appare prima che qualsiasi opzione VPN venga negoziata, mentre un guasto dell'identità interna appare solo una volta stabilito il flusso.

Il manuale di stunnel definisce con precisione accept, connect e la modalità client, e quelle sezioni rispondono alla domanda sulla socket più in fretta che indovinare. Quando non riesci ancora a dire quale livello ha risposto, leggi il certificato che la porta pubblica presenta con il comando qui sotto. Un certificato del wrapper nell'output significa che l'inoltro ha raggiunto il wrapper, e il silenzio o un errore di protocollo significa che non lo ha fatto. Quella sola distinzione fa risparmiare più tempo di qualsiasi altro controllo qui.

openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer