Eseguire una VPN e un sito web su un solo host senza collisioni

Se condividete un host tra un sito pubblico e una VPN, ereditate due domande, non una: cosa ascolta dove e chi autentica chi. Rispondete a entrambe prima di toccare un file di configurazione, perché i valori predefiniti sono sbagliati in modi che si vedono solo sotto carico. Una pagina che si carica via HTTPS dimostra che l’ascoltatore web risponde e nulla sull’ascoltatore dei peer. Quello che segue è un ordine di decisioni che impedisce ai due di divorarsi.

Decidete cosa ascolta su quale indirizzo e trasporto

Scrivete una tabella con tre colonne, indirizzo, trasporto e porta, e una riga per servizio, inclusa l’interfaccia amministrativa. TCP 443 per il sito e UDP 443 per la VPN non sono un conflitto anche quando i numeri coincidono, perché il trasporto è diverso. Due servizi sullo stesso indirizzo, trasporto e porta hanno bisogno di un accordo che l’implementazione documenta, non di uno che inventate durante un guasto. Quella tabella è anche l’artefatto che rende verificabile la modifica successiva.

Indirizzi separati o una seconda porta rendono la proprietà visibile in una cattura di pacchetti, e questo vale più dell’eleganza. Alcune implementazioni VPN supportano la condivisione di una porta con un server web, ma il meccanismo è specifico: il demone ispeziona i primi byte e inoltra il traffico che non è il suo protocollo. Un proxy inverso HTTP generico non lo fa, e riscrivere le intestazioni non gli farà capire una stretta di mano di un tunnel cifrato. Leggete le note di distribuzione del protocollo, come la documentazione dell’ascoltatore OpenVPN, e seguite l’accordo che descrive.

Decidete quale identità appartiene a quale servizio

Un certificato del browser e una credenziale di peer VPN sono oggetti diversi con modelli di fiducia diversi. Il certificato web è convalidato da un’autorità pubblica e nomina un nome host, mentre la credenziale di peer autentica un dispositivo o un utente verso il concentratore e può essere autofirmata o emessa internamente. Riusare l’uno come l’altro funziona in casi ristretti e raramente vale l’accoppiamento. Disattivare la verifica perché un certificato condiviso si adatti non è un piano di separazione; rimuove il controllo che dava senso alla credenziale.

Tenete i due archivi indipendenti e annotate quale autorità emette ciascuno. Quando uno viene ruotato, l’altro non dovrebbe aver bisogno di cambiare, e se ne ha bisogno, l’accoppiamento è ciò che va corretto.

Decidete dove vive l’amministrazione

L’interfaccia amministrativa della VPN appartiene a un percorso di gestione, mai all’ascoltatore pubblico, anche quando l’host serve già internet. Un server web sulla 443 non implica che la console dei peer debba essere raggiungibile da ovunque, e la console è di solito l’obiettivo di valore maggiore. Legatela a un indirizzo di loopback o di gestione, limitatela per origine e mantenete un percorso di ripristino che non dipenda dal fatto che il tunnel sia attivo. Il percorso di ripristino conta perché il guasto comune è chiudersi fuori mentre si ripara il blocco.

Scrivete regole del firewall strette, una per ascoltatore, nominando l’interfaccia o l’account di servizio dove la piattaforma lo consente. Le regole ampie che aprono l’host perché il sito ha bisogno della 443 sono il modo in cui le interfacce amministrative finiscono negli indici degli scanner.

Rivedete queste regole rispetto alla tabella degli ascoltatori ogni volta che viene aggiunto un servizio. La revisione costa poco e intercetta la regola che qualcuno ha aggiunto alle due di notte.

Decidete cosa fare quando i due si contendono

Condividere un host significa condividere CPU, memoria, descrittori di file e larghezza di banda, e la risorsa contesa non è sempre quella ovvia. Un sito occupato può riempire la tabella delle connessioni, esaurire gli slot di lavoro o spingere la coda del disco abbastanza da bloccare la registrazione della VPN. Guardate l’uso per servizio invece dei totali dell’host, perché una media nasconde quale processo soffre la fame. Se un carico di lavoro disturba ripetutamente l’altro, isolateli invece di regolare intorno al sintomo.

L’isolamento può essere un container, un limite cgroup, una coda separata o un secondo host, e la scelta giusta dipende da quale risorsa è contesa. Un cambio di porta non risolve nulla qui, e un’istanza più grande non risolve nulla se il limite è una coda satura. Decidete con una misura: nominate la risorsa, caricatela, poi scegliete l’isolamento più piccolo che elimina la contesa.

Verificate dall’esterno, poi di nuovo dopo un riavvio

Provate da un dispositivo che non è sulla rete dell’host stesso: caricate il sito, alzate il tunnel e raggiungete una risorsa che lo richiede. Poi riavviate ciascun servizio per conto suo e ripetete l’altra prova, perché un riavvio è il momento in cui un accordo di ascoltatore condiviso perde il suo ordine. Se la VPN parte prima del server web che possiede la porta condivisa, il meccanismo di condivisione potrebbe non agganciarsi mai, e il sintomo è un tunnel che ieri funzionava. Rendete esplicita la dipendenza nell’ordine delle unità.

Poi confermate i confini: il sito risponde sulla sua porta, la VPN risponde sulla propria, e l’interfaccia amministrativa risponde solo dal percorso di gestione. Annotate il risultato accanto alla tabella degli ascoltatori con la data. Un host che supera tutti e tre i controlli dopo un riavvio è un host che potete consegnare a qualcun altro senza un briefing.