Porta VPN muta? Listener, indirizzo di bind o firewall dell'host

Il VPN non risponde nulla sulla sua porta, e le due cause possibili richiedono riparazioni opposte: o nessun processo ha aperto il socket, o il socket esiste e qualcosa tra le macchine ferma i pacchetti. Un solo comando risolve la prima metà di questa domanda, per questo viene prima di toccare qualsiasi regola del firewall. L'ordine qui sotto elimina una spiegazione per passo invece di aggiungere un'altra congettura. È il congetturare tra le due che trasforma una diagnosi di dieci minuti in un'intera serata.

Date per scontato di poter accedere al server e che il client sia un profilo vero e non uno scanner. Entrambe le ipotesi contano, perché una sonda generica non può rispondere a una domanda specifica del protocollo.

Il socket esiste davvero

Cominciate da ciò che il servizio dice di sé: se è partito e, più utile, quale è stato il suo primo errore di avvio. Un errore di parsing, una chiave mancante o un errore di bind impediscono al listener di esistere, e il processo può uscire così in silenzio che la riga di stato si legge in modo ambiguo. Un'unità che si dichiara attiva non è prova da sola, perché il processo principale può essere vivo mentre il componente che doveva collegare la porta ha già rinunciato.

systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp

L'elenco dei socket è il fatto su cui poggia il resto della diagnosi. Leggete la colonna dell'indirizzo locale e non solo la porta, perché è in quella colonna che compaiono i bind su loopback e i bind sull'interfaccia sbagliata. Un listener che esiste su 127.0.0.1 funziona perfettamente ed è comunque invisibile al vostro portatile.

Su quale indirizzo e famiglia risponde il socket

Due errori appaiono identici dal client e spiegano la maggior parte delle segnalazioni "non raggiungibile". Un server legato all'indirizzo di loopback non accetta mai traffico da un'altra macchina, e un server legato solo a un indirizzo IPv4 non risponde mai a un client che compone l'indirizzo IPv6 dello stesso host. Confrontate l'indirizzo della tabella dei socket con quello che il client compone davvero, carattere per carattere, prima di supporre qualcosa sulla politica.

Limitare l'elenco a una sola porta lo mantiene leggibile quando l'host esegue più servizi. Il filtro sport prende la porta insieme al trasporto che state provando:

ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'

La colonna del protocollo cambia tutta la risposta

La tabella dei socket indicizza sia il protocollo sia la porta, e sono due voci indipendenti. Un servizio che risponde in TCP sulla 1194 non dice nulla su cosa ascolta in UDP sulla 1194, e il client userà sempre solo una delle due. Confermate quale trasporto sceglie la configurazione del server e quale invia il profilo del client, poi cercate esattamente quella riga.

L'UDP ha una seconda piega: una sonda non autenticata non è un errore a cui il servizio debba rispondere. Una scansione che segnala la porta come muta ha misurato la discrezione del servizio, non la sua disponibilità, quindi provate con il client e il profilo veri.

Un tentativo, tre posti dove guardare

Da un client approvato fate esattamente un tentativo e annotate l'ora al secondo. Poi leggete tre fonti per quella finestra: la regola di rete o la console del provider, i contatori o il registro del firewall dell'host e il registro del servizio stesso. Farlo una volta è ciò che rende confrontabili i tre resoconti, e costa meno che ripetere un tentativo di cui nessuno ha registrato la marca temporale.

I due esiti puntano in direzioni opposte. Se nessun pacchetto ha raggiunto l'host, il percorso lo scarta e il listener è irrilevante. Se il pacchetto è arrivato al socket e il servizio lo ha rifiutato, il percorso è a posto e la risposta sta nel protocollo, nella crittografia o nelle credenziali. Aprire una porta per un servizio che ha già accettato una connessione rende la diagnosi successiva più difficile, non più facile.

Nominate la fase prima di cambiare una regola

Una negoziazione che inizia e un'autenticazione che fallisce sono un solo guasto, e un tunnel che si stabilisce mentre l'inoltro si blocca è un guasto del tutto diverso. Nominare la fase per prima mantiene la riparazione stretta: un problema di credenziali non si risolve con una regola del firewall, e un problema di percorso dati non si risolve con un riavvio.

Usate la diagnosi più stretta che risponde alla domanda. Un'osservazione temporanea dei pacchetti su una porta, sotto il controllo di un amministratore, è uno strumento ragionevole; disattivare tutto il firewall non lo è, perché il risultato diventa impossibile da attribuire. La documentazione di ss copre i filtri usati sopra, ed è un primo passo meno costoso di qualsiasi cattura. Annotate quale dei due rami avete dimostrato, e l'occorrenza successiva parte da una risposta nota.