Gateway VPN combinato o separato: scegliere per dominio di guasto

Due apparati sembrano più resilienti di uno finché non notate che condividono la stessa ciabatta, lo stesso hypervisor e lo stesso collegamento a monte. Contare le scatole risponde a una domanda che nessuno ha posto; la domanda utile è cosa fallisce nello stesso momento. Scrivete prima il contratto di guasto, poi lasciate che scelga la topologia. Il runbook qui sotto produce quel registro.

Cosa si ferma durante un riavvio

Per un gateway combinato, elencate cosa scompare durante un riavvio, un aggiornamento fallito o un guasto hardware. Se l'accesso a internet e la connettività privata si fermano insieme, quell'interruzione condivisa fa ora parte del vostro requisito di disponibilità, che qualcuno l'abbia scritta o no. Lo stesso esercizio vale per un singolo apparato che termina diversi ruoli: l'elenco dei servizi che abbatte è la specifica reale.

Per gateway separati, elencate cosa resta condiviso: l'alimentazione, l'host di virtualizzazione, il collegamento a monte, il provider di identità, la rete di gestione. Due apparati dietro un solo switch guasto sono un solo dominio di guasto con due nomi host. Una separazione che ignora quelle dipendenze è uno schema, non un progetto.

Contate anche la proprietà della manutenzione. Un altro apparato porta configurazione, monitoraggio, backup e una seconda procedura di ripristino, e nulla di tutto ciò è gratuito.

Segnate dove viene applicata ogni regola

Seguite un pacchetto dal client a una risorsa privata e ritorno, e segnate ogni punto in cui viene applicata una politica. Un secondo router aggiunge un altro punto in cui la preferenza di rotta, la traduzione o lo stato della connessione possono discordare dal primo. La maggior parte dei guasti misteriosi in un progetto a due gateway vive su quella cucitura.

ip route get 10.20.30.40
traceroute -n 10.20.30.40
conntrack -L -p tcp --dport 443

Annotate dove finisce la protezione VPN e dove inizia la politica interna. Se il percorso tra i due apparati è permissivo, la seconda scatola non ha creato un confine; ha solo spostato il punto in cui un confine avrebbe potuto esserci. Su un'unica piattaforma, zone di politica distinte possono ancora essere efficaci, e la loro efficacia va valutata dalle regole invece che scartata perché l'hardware è condiviso.

Fermatevi se non sapete dire quale apparato applica la regola che conta. Quel vuoto è il risultato, non un dettaglio da risolvere dopo.

Il contenimento è un confine, non un telaio

Un apparato separato contiene una compromissione solo quando il percorso che lo attraversa è limitato a ciò che serve all'altro lato. Se entrambi gli apparati accettano qualsiasi traffico l'uno dall'altro, un attaccante che atterra su uno ha la stessa portata di prima. L'affermazione di contenimento appartiene all'insieme di regole, non all'inventario. Leggete le regole, dite quali flussi sono consentiti, poi decidete se la separazione ha comprato qualcosa.

La stessa logica vale per gli utenti. Un utente VPN di cui ci si fida per la rete da cui è arrivato si fida della posizione invece che dell'identità, e le linee guida NIST sullo zero trust descrivono l'alternativa: autenticare e autorizzare ogni richiesta rispetto alla risorsa. Quel principio vale qualunque telaio termini il tunnel.

Se la separazione esiste per soddisfare una linea di conformità invece che per cambiare un flusso, ditelo nel registro. Un controllo che nessuno sa spiegare è il primo a essere rimosso sotto pressione.

Recuperate ciò che potete davvero raggiungere

Chiedete quale percorso di ripristino sopravvive quando uno dei due ruoli muore. Quando l'unico modo di raggiungere un gateway VPN rotto passa da quel gateway, un apparato di riserva altrove non aiuta l'amministratore che deve ripararlo. Un percorso fuori banda, una console e un ritorno documentato sono le parti che rendono recuperabile il progetto.

systemctl status strongswan
nft list ruleset
ip -brief address

Dimensionate il progetto per il carico di lavoro completo supportato e non per un numero di cifratura isolato, perché il filtraggio e l'ispezione consumano lo stesso hardware. Usate la documentazione del fornitore e le vostre misurazioni invece di supporre che la separazione sia più veloce o più lenta. Poi scrivete il registro di decisione: quali flussi sono consentiti, quali dipendenze sono condivise, cosa abbatte una finestra di manutenzione, quali prove di capacità avete e chi possiede ogni passo di ripristino. Quel registro è abbastanza breve da rivedere e abbastanza specifico da tornarci.

Il runbook finisce quando il contratto di guasto è scritto, il percorso di inoltro ha un punto di applicazione nominato per regola, il contenimento è descritto con flussi e non con il numero di apparati, e il ripristino funziona dall'esterno del componente guasto. Scegliete la disposizione più semplice che soddisfa quei requisiti.