Su quali porte ascolta davvero OpenVPN Access Server?

Esegui ss -lntup su un host Access Server e ottieni un elenco lungo il doppio del previsto. Metà delle voci sono porte a forma di demone che nessuno ha menzionato durante l’installazione. Il riflesso è chiudere tutto ciò che non è 443 o 1194, ed è così che le persone rompono il proprio portale clienti.

Access Server non è un solo ascoltatore. È un servizio VPN, un servizio web e un partecipante al cluster, e può generare porte aggiuntive specifiche dei demoni e reindirizzamenti del firewall a seconda di quanti demoni TCP hai configurato.

Percorri l’inventario in ordine: leggi i socket, mappa quelli familiari, classifica il resto per proprietario e binding, poi controlla cosa li pubblica davvero.

Inizia con un solo comando di sola lettura

sudo ss -lntup ti dà trasporto, indirizzo locale, porta e processo proprietario per ogni socket in ascolto. I flag contano: -l in ascolto, -n numerico, -t TCP, -u UDP, -p processo. Senza root ottieni i socket ma non i nomi dei processi, ed è esattamente la colonna che ti serve per classificare.

Annota quattro campi per riga prima di formarti un’opinione: protocollo, indirizzo di binding, porta e comando. Tieni la versione di Access Server e il numero di demoni configurato accanto a quell’elenco, perché entrambi cambiano ciò che ci si aspetta.

Due righe che sembrano identiche non lo sono. TCP e UDP sullo stesso numero sono socket separati con esposizione separata, e 0.0.0.0 e :: sono binding separati per famiglie di indirizzi separate. Un servizio associato solo a 127.0.0.1 non è raggiungibile direttamente da un altro host, anche se un reindirizzamento locale può ancora pubblicarlo.

Gli ascoltatori che dovresti riconoscere

Questi valori predefiniti coprono la maggior parte delle distribuzioni e ti danno una base di confronto. Sono valori predefiniti, non un elenco completo di autorizzazioni.

Tutto ciò che va oltre richiede una spiegazione, non un’ipotesi. Spesso vedrai ascoltatori solo locali appartenenti a componenti che il prodotto installa per sé. Confermali tramite PID e configurazione del servizio invece che con un numero di porta ricordato, e non trattare una porta sconosciuta come ostile solo perché è sconosciuta.

Un socket fuori dalla coppia nota non è nemmeno automaticamente un residuo. Quando sono configurati più demoni TCP, Access Server crea ascoltatori per demone e vi reindirizza il traffico, quindi il loro numero e i valori di porta seguono quella configurazione.

Classifica prima di chiudere qualcosa

Per ogni riga incerta, rispondi a tre domande in questo ordine.

1. Proprietario e scopo. Abbina il PID a un’unità o a un processo e leggi la configurazione di quel servizio. Se non riesci a nominare il proprietario, non sei pronto a decidere nulla sul socket.
2. Ambito del binding. Loopback è locale allo spazio dei nomi. Un binding wildcard è raggiungibile solo se il routing, il filtraggio dell’host e qualsiasi regola a livello di cloud lo consentono, quindi l’indirizzo di binding è necessario ma non sufficiente. Controlla IPv4 e IPv6 come decisioni separate.
3. Percorso pubblicato. Cerca l’inoltro del servizio, i reindirizzamenti specifici dei demoni, un proxy esterno e la politica firewall effettiva. Questo è il passo che le persone saltano, ed è quello che trasforma una porta backend apparentemente innocua in un percorso amministrativo raggiungibile.

La stessa domanda si legge diversamente dall’esterno dell’host. Una porta senza regola firewall dell’host può comunque essere chiusa da un gruppo di sicurezza cloud, e una porta con una regola host permissiva può essere irraggiungibile perché nulla vi instrada. Guarda entrambe le estremità prima di scrivere la conclusione dell’inventario.

Dove il percorso pubblicato differisce dall’elenco dei socket

La documentazione di Access Server stesso copre il caso che crea più confusione: quando sono in esecuzione più demoni TCP, la porta frontale inoltra verso porte specifiche dei demoni, e la disposizione visibile smette di corrispondere all’elenco dei socket. Il tutorial sul filtraggio dell’interfaccia web descrive quelle regole e perché un filtro scritto solo per la porta ovvia può mancare del tutto il percorso reindirizzato.

Il controllo del cluster è il secondo punto in cui la versione conta. Dalla 3.0 in poi condivide la 943; le configurazioni cluster più vecchie usavano la 945. Aprire o bloccare una delle due senza controllare la versione produce un inventario che sembra ordinato ed è sbagliato.

Quindi la superficie visibile dall’esterno è l’unione di tre cose: socket in ascolto, regole di inoltro che li ripubblicano e i controlli di rete davanti all’host. Qualsiasi inventario che registri solo la prima è incompleto, e qualsiasi modifica che consideri solo la prima lascerà un percorso aperto o taglierà un servizio.

Verifica dopo ogni modifica

Modifica le impostazioni degli ascoltatori tramite il proprietario di configurazione supportato e tieni aperta una console di ripristino mentre lo fai. Perdere l’accesso amministrativo a un’interfaccia web su un host remoto non è recuperabile tramite la VPN che hai appena disattivato.

Poi convalida le quattro cose di cui una distribuzione ha di solito bisogno: un client VPN si connette, il portale clienti si carica, l’accesso amministrativo funziona e la comunicazione del cluster funziona ancora se gestisci più di un nodo. Un test solo VPN passa comodamente mentre il portale è rotto.

Termina annotando il percorso consentito per ogni servizio: quale socket, quale binding, quale regola di inoltro, quale controllo di rete. Quel documento è il risultato di sicurezza utile. Un numero minimo di socket non lo è, e nemmeno un reset di massa che chiude ascoltatori che nessuno ha finito di identificare.