Un servizio VPN è raggiungibile da dove il suo socket è associato e il suo firewall lo consente. Sono due decisioni separate, e di solito le persone ne prendono solo una. Leggere il listener reale richiede dieci secondi e risolve una questione che le congetture non possono. Parti da lì, poi cambia un controllo alla volta.

Tutto quanto segue presuppone che tu possa eseguire comandi sull'host con root o sudo.

Leggi i socket prima di cambiare qualcosa

Su Linux, ss -lunp elenca i listener UDP con il loro indirizzo locale, la porta e il processo, e ss -ltnp fa lo stesso per TCP. Cerca la porta della VPN e leggi con attenzione la colonna dell'indirizzo. 0.0.0.0:51820 e [::]:51820 significano tutte le interfacce, mentre 10.0.0.5:51820 significa un indirizzo su un'interfaccia. Il manuale di ss documenta le colonne se l'output non ti è familiare. Se manca il nome del processo, esegui lo stesso comando con sudo, perché la colonna del proprietario richiede privilegi.

Annota l'indirizzo. È il fatto da cui dipende il resto di questa guida.

Associa a un indirizzo, non a un desiderio

OpenVPN associa il listener a un indirizzo specifico con la sua direttiva local, ed è il modo supportato per limitarlo a livello di processo. Non ogni implementazione offre un equivalente, e un protocollo senza opzione di associazione non può essere ristretto in questo modo. Se il tuo non ne ha nessuna, il firewall è il tuo unico controllo, e le note di distribuzione dovrebbero dirlo chiaramente. Su un host con più indirizzi, associa a quello rivolto verso il tunnel; associare a un indirizzo flottante è di solito un errore.

Un servizio che deve sopravvivere a un cambio di indirizzo ha bisogno di un piano per l'associazione obsoleta, non solo di una riga di configurazione.

Controlla la famiglia di indirizzi separatamente

IPv4 e IPv6 sono socket separati. Un processo associato a 0.0.0.0 può ancora accettare IPv6 tramite un socket dual-stack, oppure no, a seconda dell'opzione del socket e del valore predefinito della piattaforma. Leggere solo la riga IPv4 ha ingannato più di una revisione di distribuzione. Elenca entrambe le famiglie prima di concludere che il listener è ristretto.

Se IPv6 non fa parte del progetto, disattivarlo a livello di socket è più pulito che sperare che il firewall lo copra. È una decisione politica, quindi registrala insieme al resto delle scelte di interfaccia.

Sovrapponi il firewall all'associazione

Un'associazione ristretta non sostituisce una regola del firewall, e una regola del firewall non restringe un'associazione wildcard. Usa entrambi: associa dove l'implementazione lo supporta, poi consenti la porta solo dalle sorgenti che dovrebbero raggiungerla. I gruppi di sicurezza cloud stanno davanti al firewall dell'host, quindi controlla entrambi quando il percorso attraversa un confine VPC. La regola effettiva è l'intersezione delle due, e ogni livello può solo togliere raggiungibilità.

Prova da una sorgente consentita e da una deliberatamente esclusa. Una connessione da localhost non dimostra nulla sul confine pubblico.

Registra ciò che hai scelto

Annota l'indirizzo associato, l'interfaccia che lo possiede, la regola del firewall e il suo scopo. Una NIC sostitutiva o un indirizzo cloud riassegnato possono cambiare l'esposizione senza che nessuno modifichi il profilo. Data la nota, perché gli indirizzi cloud si spostano tra le revisioni più spesso di quanto la gente si aspetti.

È quella nota che rende la prossima revisione un confronto invece di un progetto di archeologia.

Articoli correlati