OpenVPN e HTTPS sulla porta 443: di chi è il listener?
TCP e UDP 443 sono socket distinti. Condividere un solo listener TCP richiede un proprietario, e la condivisione della porta di OpenVPN è un accordo ristretto, non un trucco da proxy.
Due servizi possono entrambi rispondere sulla porta 443 senza mai competere, perché un listener è determinato da trasporto, indirizzo e porta insieme, non dal solo numero. Metti un server web e OpenVPN sulla stessa macchina, e l’unica domanda che merita una risposta per prima è quale socket ogni processo chiede al kernel. Scrivi quell’elenco prima di modificare una configurazione, e la maggior parte degli errori «indirizzo già in uso» si spiega da sola. Tutto ciò che segue l’elenco è una scelta tra un listener UDP, un socket TCP condiviso o un frontend che instrada per protocollo.
Parti dal socket che chiede ogni processo
Un bind riesce o fallisce su quella terna, quindi due demoni si scontrano solo quando tutte e tre le parti coincidono. Per questo un sito web su TCP 443 convive indefinitamente con un listener OpenVPN su UDP 443, e per questo spostare uno dei due su un secondo indirizzo locale sullo stesso host chiude comunque la discussione. Leggi i listener vivi invece dei file che avrebbero dovuto crearli, perché un include obsoleto o un file unit dimenticato sopravvive alla modifica che ricordi di aver fatto.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
Esegui ss -lntup come root e leggi ogni riga che menziona 443, comprese le voci IPv6. Un listener v6 jolly di solito accetta anche il traffico v4, ed è così che un listener dimenticato tiene la porta occupata dopo che hai cambiato il file che credevi responsabile. Se un nome di processo ti sorprende, restringi l’output con ss -lntup 'sport = :443' prima di toccare qualcosa.
Passa il tunnel a UDP quando la rete lo consente
Un listener UDP aggira del tutto la collisione ed è di solito la riparazione più breve, dato che nessun socket viene condiviso e nessun prodotto extra entra nel percorso. Non è gratis. Alcune reti dei clienti scartano UDP 443 senza inviare un reset, così il tunnel smette di stabilirsi invece di fallire al bind, e l’utente segnala la VPN come inattiva senza alcun errore da leggere. Un listener UDP sopravvive anche a un riavvio del livello web, cosa che conta su una macchina il cui sito viene ridistribuito spesso. Prova dalla rete in cui si trovano gli utenti, perché una shell sul server dimostra solo che il server raggiunge se stesso.
Cambia il trasporto nella configurazione del server e nel profilo del client insieme. Un profilo che chiede ancora TCP entrerà in un ciclo di riconnessioni contro un listener solo UDP, e questo sembra un guasto di rete finché non confronti i due file.
Lascia che il processo VPN possieda TCP 443 e inoltra il resto
Community OpenVPN in modalità server TCP legge i primi byte di una connessione in arrivo e inoltra tutto ciò che non è il suo protocollo a un backend HTTPS, ed è a questo che serve la direttiva port-share. Il backend è un normale server web con TLS abilitato, nominato per host e porta in quella direttiva anziché tramite un URL.
port-share 10.0.0.5 8080
Su una macchina in cui il sito detiene un secondo indirizzo privato, quella riga invia il traffico non VPN a 10.0.0.5:8080, quindi l’host virtuale HTTPS deve essere associato lì e il firewall deve consentire il salto locale. Il server web deve terminare TLS da solo, perché i byte in arrivo sono l’handshake originale del browser e nulla nel mezzo li ha decifrati. Punta la direttiva a un listener HTTP semplice e il browser riceve un errore di metodo non valido, che si legge come un sito rotto anziché come un backend mal posizionato. La direttiva esiste solo in modalità server TCP, e un listener UDP non ha alcun flusso da ispezionare.
Poiché il processo VPN accetta ogni connessione, l’applicazione web vede la richiesta inoltrata arrivare da uno degli indirizzi dell’host stesso invece che dal visitatore. Tutto ciò che ha bisogno del vero indirizzo del client dipende dal supporto del protocollo PROXY nel backend o da un frontend che lo aggiunga. Spostare il backend su un altro indirizzo locale non riporta l’indirizzo del visitatore; cambia solo quale degli indirizzi dell’host il sito registra. Annota questo limite nelle note di distribuzione prima che un report di analisi sollevi la questione.
Un proxy inverso è lo strumento sbagliato; un router di livello quattro no
Un proxy inverso HTTP termina TLS per poter leggere le richieste, il che significa che non può far passare un flusso OpenVPN intatto. Un router di livello quattro che inoltra in base all’SNI o all’ispezione del primo pacchetto può stare davanti a entrambi, purché non termini la sessione da cui dipende la VPN. I due dispositivi si somigliano in un diagramma e si comportano in modo del tutto diverso al socket.
L’Access Server commerciale porta le proprie impostazioni di condivisione della porta, e queste non corrispondono uno a uno alla direttiva della community. Identifica prodotto e versione prima di adattare una guida scritta per l’altro. Un’impostazione copiata e silenziosamente ignorata è peggio di nessuna impostazione, perché l’elenco dei listener dopo sembra ancora plausibile.
Prova il sito web e il tunnel come due percorsi separati
Carica il sito e collega il tunnel, poi rileggi l’elenco dei listener per vedere quale processo possiede 443 adesso. Una pagina che si carica non dimostra nulla sulla VPN, e un tunnel che si collega non dimostra nulla sul sito, anche se entrambi usano lo stesso numero. I tre comandi qui sotto controllano il socket condiviso, il percorso web e il servizio VPN in quest’ordine.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Confronta l’indirizzo del client nel log di accesso del backend con quello nel log della VPN nello stesso istante. Se il sito registra ogni visitatore come l’host stesso, l’inoltro funziona e la gestione dell’indirizzo no. Se entrambi i log restano muti, il frontend non ha mai consegnato la connessione. In ogni caso l’elenco dei listener stabilisce chi accetta il socket, e questo è il fatto da confermare prima di cambiare un altro file.
Lascia quella mappa dei listener accanto alla configurazione, così la prossima persona che tocca 443 sa quale processo accetta e dove è finito l’altro protocollo. Conferma la proprietà dopo la modifica invece di fidarti di ciò che la modifica doveva fare.