Perché una VPN TAP condivisa ha ancora bisogno di HTTPS sul portale

Due dispositivi possiedono credenziali VPN valide e condividono un unico segmento Ethernet pontato. Solo uno di essi dovrebbe rispondere per il portale dell’ufficio, e l’altro può ancora rivendicare l’indirizzo del portale su quel segmento. Il tunnel ha fatto il suo lavoro: ha autenticato entrambi i pari e cifrato ogni percorso verso il server. Ciò che non ha fatto è certificare quale dei due possiede un nome di servizio, e proprio questa lacuna è il motivo per cui il portale ha ancora bisogno di un certificato valido.

Cosa autentica davvero la VPN

Una stretta di mano VPN risponde a una domanda: quale pari ha completato questo tunnel, e con quale materiale di chiave. Quella risposta vale per pari e per connessione, e non dice nulla sui servizi che quel pari espone in seguito. Su un segmento TAP il pari non è nemmeno un singolo indirizzo, perché può presentare qualsiasi MAC e qualsiasi IP che il ponte sia disposto a imparare. L’autenticazione si ferma all’estremità del tunnel, non all’applicazione.

Separa le tre domande invece di fonderle in una. Ognuna ha il proprio meccanismo e il proprio modo di fallire.

Un’installazione può avere un tunnel perfettamente autenticato e un servizio del tutto non autenticato dietro. Può anche avere un certificato convalidato su un host il cui indirizzo di secondo livello è rivendicato da un altro pari, ed è per questo che entrambi i controlli appartengono al progetto invece di sostituirsi a vicenda. La tabella è l’intero argomento in tre righe.

ARP su un segmento condiviso non è una rubrica

ARP associa un indirizzo IPv4 a un MAC sul collegamento locale e accetta risposte da chiunque su quel collegamento. Su un segmento pontato permissivo un pari può rivendicare un indirizzo che appartiene a un altro dispositivo, e il ponte inoltra i frame a chi ha risposto più di recente. Cifrare ogni percorso client verso il server non cambia questo, perché i frame vengono decifrati prima di raggiungere il ponte. Il confine di fiducia di ARP è il segmento, non il tunnel.

Guarda cosa ha effettivamente imparato l’host: ip neigh show elenca le associazioni correnti e il loro stato, e una voce che oscilla tra due indirizzi MAC durante il normale funzionamento è un sintomo che merita indagine invece di essere ignorato. Su un piccolo segmento sano quelle voci restano stabili a lungo.

L’isolamento dei pari e la politica del ponte esistono esattamente per questo caso. Un progetto instradato è di solito la risposta migliore quando il servizio è solo IP e i dispositivi non hanno alcun motivo di vedere i frame gli uni degli altri.

Mantieni la validazione del certificato dove si trova il servizio

Il TLS dell’applicazione risponde alla domanda che il tunnel non può: è questo il servizio che volevo raggiungere. Il browser controlla il nome host rispetto al certificato, e quel controllo è l’unica parte della catena che nomina il portale invece del pari.

Esamina ciò che presenta il server prima di decidere che l’avviso è cosmetico. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal stampa la catena e i nomi alternativi del soggetto. Se il nome digitato non è in quell’elenco, l’avviso è corretto e il certificato è ciò che va sistemato. Insegnare agli utenti a ignorarlo trasforma un controllo funzionante in decorazione.

La guida al bridging di OpenVPN descrive il modello Ethernet e le opzioni di policy che lo circondano, ed è il riferimento giusto per ciò che il segmento dovrebbe consentire. Leggila prima di allentare una regola di ponte, perché il modello che descrive è quello che ogni controllo sopra presuppone.

Decidi se quei pari dovrebbero condividere un segmento

La soluzione meno costosa è di solito smettere di condividere il secondo livello quando il requisito è solo la raggiungibilità IP. Una VPN instradata dà a ogni client il proprio indirizzo, elimina il dominio di broadcast condiviso e trasforma il traffico tra pari in una decisione di policy invece che in un valore predefinito. Il portale ha allora un solo indirizzo da proteggere e nessun vicino che possa rivendicarlo.

Se il segmento deve restare, controlla l’impostazione lato server che consente ai client di raggiungersi: grep -n client-to-client /etc/openvpn/server.conf. Quando è disattivata, il traffico dei client passa dal server e può essere filtrato lì. Quando è attiva, i pari scambiano frame direttamente attraverso il ponte e i tuoi punti di filtro sono il ponte e il firewall dell’host.

Annota su quali protezioni ogni host fa effettivamente affidamento: autenticazione del tunnel, isolamento del segmento o TLS dell’applicazione. Un host che dipende da tutte e tre va bene. Un host che dipende dalla prima e presume che le altre due siano arrivate con essa è quello che finisce per servire il contenuto sbagliato.