Quale modalità Sophos RED si adatta alla rete della tua filiale?

Sophos RED è un ruolo per una sede remota e non un protocollo VPN, per questo confrontarlo con IPsec o OpenVPN risponde alla domanda sbagliata. Il dispositivo estende il controllo di un firewall centrale verso una filiale, e la modalità che scegli decide chi fornisce il gateway della filiale, chi distribuisce gli indirizzi e quale traffico attraversa il tunnel. Quelle tre risposte contano più dei nomi delle modalità. Scriverle per prime trasforma una scelta di prodotto in una decisione di progettazione.

RED è un ruolo, non un protocollo

Un dispositivo RED collega una filiale a un Sophos Firewall centrale, e la configurazione del firewall definisce cosa diventa la filiale. Il tunnel è un dettaglio realizzativo di quel collegamento, non un endpoint VPN generalista da puntare verso qualsiasi peer.

Questa impostazione conta perché un RED non è intercambiabile con un peer IPsec qualsiasi. Si aspetta che il firewall centrale lo gestisca, e le modalità supportate descrivono quanto della filiale assume. Trattarlo come un normale endpoint di tunnel crea aspettative che il prodotto non ha mai promesso. Trattarlo come un ruolo produce le domande che decidono davvero la progettazione.

Le tre condizioni seguenti cambiano la risposta, e tutte riguardano la proprietà, non la cifratura.

Tre condizioni che scelgono la modalità

Chiedi chi possiede il gateway della filiale, chi gestisce DHCP e DNS per i client della filiale e se l'uscita internet locale deve sopravvivere a un guasto del tunnel.

Standard/Unified risponde a tutte e tre allo stesso modo: il firewall centrale possiede la LAN della filiale, compiti di gateway e DHCP inclusi, e il traffico attraversa il tunnel. Standard/Split mantiene la gestione centrale e invia nel tunnel solo le reti configurate. Transparent/Split lascia che la rete di filiale esistente gestisca il proprio gateway e i propri indirizzi, e reindirizza nel tunnel solo il traffico selezionato. Tre modalità, tre proprietari diversi.

Leggi prima la colonna centrale, perché decide quanta parte della filiale funziona ancora quando il tunnel non c'è.

Chi possiede il gateway della filiale e il DHCP

Nella disposizione unificata la filiale non ha un gateway indipendente, il che semplifica la configurazione e concentra il guasto. Quella concentrazione va bene quando la filiale è piccola e il firewall centrale è ad alta disponibilità.

In una distribuzione trasparente la filiale conserva il proprio router e il RED si mette in linea per reindirizzare il traffico selezionato. Questo preserva il controllo locale e aggiunge un dispositivo la cui posizione nel percorso ora conta per ogni flusso reindirizzato. Documenta dove si trova, perché una modifica successiva al router della filiale può aggirarlo in silenzio. Nessuna delle due disposizioni vince in generale; distribuiscono la responsabilità in modo diverso.

La proprietà degli indirizzi è la parte da scrivere, perché due server DHCP sullo stesso segmento producono guasti intermittenti che vengono segnalati come problemi VPN.

Cosa succede quando il tunnel cade

Il funzionamento in Split viene spesso letto come la promessa che internet locale continua a funzionare durante un guasto del tunnel, e quella lettura non è sicura. Il comportamento esatto dipende dalla modalità scelta, dal firmware e dal dispositivo, quindi appartiene ai criteri di accettazione e non a un'ipotesi.

Decidi cosa deve ancora fare la filiale senza tunnel: raggiungere stampanti locali, risolvere nomi, incassare pagamenti o niente affatto. Poi verifica quello stato di proposito bloccando il tunnel e osservando la filiale. Una filiale che perde DNS in silenzio è peggiore di una che fallisce rumorosamente, perché la chiamata all'assistenza arriva ore dopo. Scrivi il risultato osservato nel registro di progettazione.

La dipendenza centrale è la stessa in ogni modalità: qualcuno deve possedere il percorso di ripristino del dispositivo stesso.

Scrivi il contratto di filiale prima di distribuire

Un contratto di filiale sta in una pagina: proprietari, fonti degli indirizzi, prefissi in tunnel, politica di uscita e il comportamento in caso di guasto che hai accettato.

Poi verifica il risultato distribuito e non quello previsto. Controlla l'indirizzo del client della filiale, il suo gateway predefinito, quali prefissi si risolvono attraverso il tunnel e cosa risponde ancora quando il tunnel è bloccato. Compatibilità, raggiungibilità e licenze vanno tutte verificate con la documentazione attuale del fornitore per il modello esatto, perché un nome di prodotto non garantisce una modalità. Conserva quella pagina con la scheda del dispositivo, così il prossimo ingegnere eredita le decisioni e non lo schema.

ip -br addr
ip route
traceroute -n 10.80.4.10
dig +short intranet.corp.example

Ripeti quel blocco con il tunnel bloccato, e la differenza tra le due esecuzioni è il comportamento in caso di guasto che hai davvero acquistato.