Come costruire una policy di failover VPN sul router senza fughe

Il failover funzionava esattamente come configurato, e questo era il problema. Quando il tunnel principale è caduto, il router ha spostato la route predefinita sul modem via cavo, i portatili hanno continuato a navigare e nessuno ha chiamato. Due giorni dopo qualcuno ha notato che la cartella condivisa della finanza era stata raggiungibile sulla via internet aperta per sei ore. Una policy di failover VPN sul router non è un trucco di routing; è una decisione su cosa deve fare il traffico quando il percorso preferito non c'è più, e quella decisione deve esistere prima che il percorso sparisca.

Decidi l'esito prima di scegliere il rilevatore

Di solito ci sono tre esiti sul tavolo: mandare i client colpiti attraverso un tunnel di riserva, lasciarli usare la WAN normale o bloccarli del tutto. Annota quale vale per quale VLAN, SSID o classe di dispositivo. Una singola regola piatta “passa alla WAN” è il motivo per cui la cartella della finanza qui sopra è finita su un percorso pubblico.

I tre non sono intercambiabili. Il fallback sulla WAN tiene il supporto a rispondere al telefono mentre espone i nomi interni al resolver locale. Un tunnel di riserva conserva la policy ma può atterrare su un indirizzo di uscita che l'altro lato non accetta. Il blocco è corretto per una VLAN stipendi e sbagliato per una rete ospiti che non ha mai usato il tunnel.

Adatta il rilevatore al guasto che temi davvero

Lo stato dell'handshake, lo stato dell'interfaccia e l'inoltro utilizzabile sono tre segnali diversi, e all'utente interessa solo l'ultimo. Un peer WireGuard può mostrare un handshake recente mentre l'upstream del provider getta i pacchetti in un buco nero. OpenVPN il client può restare su “connesso” dopo che la route che ha spinto ha smesso di risolversi.

Su pfSense la disposizione pratica è un gruppo di gateway alimentato da dpinger, che sonda un indirizzo di monitoraggio e segna un gateway come abbattuto quando perdita o latenza superano le sue soglie. Punta quel monitoraggio a qualcosa oltre il tunnel, come un host sulla LAN remota o un indirizzo pubblico che raggiungi attraverso di esso. Puntarlo all'indirizzo di peer del tunnel stesso misura la parte che sai già essere viva.

Costruisci il gruppo in modo che la riserva resti l'ultima risorsa

Usa livelli invece di un elenco piatto di membri. Primario nel livello 1, tunnel di riserva nel livello 2, WAN nel livello 3 solo per le VLAN la cui policy lo consente. Su pfSense questo sta sotto System > Routing > Gateway Groups: aggiungi entrambi i gateway, assegna livelli diversi, imposta Trigger Level su member down plus packet loss, salva, poi applica il gruppo come predefinito dell'interfaccia o nel campo Gateway delle regole del firewall che ne hanno bisogno.

Per un'istanza client OpenVPN su pfSense 2.5 e successivi, l'impostazione Default Gateway dell'istanza decide se il tunnel sostituisce del tutto la route predefinita di sistema. Il policy routing per regola si comporta come ti aspetti solo quando la route che dai per scontata è davvero installata. Controlla Status > Gateways dopo la modifica invece di fidarti dell'icona di stato del tunnel.

Due impostazioni causano la maggior parte dello sfarfallio. Una è un intervallo di sonda più breve della riconvergenza del provider stesso. L'altra è un gruppo in cui primario e riserva condividono il livello, così entrambi restano idonei in ogni momento. Aggiungi isteresi tramite soglie di perdita e latenza prima che i tuoi utenti sentano le transizioni al posto tuo.

Chiudi i percorsi che il tunnel non ha mai posseduto

Prima le fughe DNS. Il resolver continua a rispondere sulla WAN e a inoltrare da lì, quindi i nomi continuano a risolversi tramite l'ISP mentre il traffico è bloccato sul tunnel. Limita le interfacce in uscita del resolver, spingi il resolver interno ai client e blocca la porta 53 per tutto il resto sulle VLAN solo-VPN.

IPv6 ha bisogno della sua decisione. Una LAN dual-stack può perdere il tunnel e mantenere una route predefinita globale IPv6 funzionante, così i browser preferiscono IPv6 ed escono dalla WAN mentre IPv4 sembra perfettamente contenuto. O instradi IPv6 nel tunnel o smetti di annunciare un prefisso globale mentre il tunnel è giù. Mezza policy è peggio di nessuna, perché sembra funzionare.

Poi il percorso di ritorno. Se l'uscita di riserva usa un indirizzo sorgente diverso, l'altro lato deve sapere come rimandare il traffico, e ogni stato legato al vecchio indirizzo è già morto. Le sessioni aperte quando il primario è caduto non migrano; restano ferme finché non scadono e l'applicazione decide cosa fare.

Prova la caduta, lo sfarfallio e la via di rientro

Stacca il primario con traffico innocuo in corso, poi leggi quattro cose: Status > Gateways per gli stati dei membri del gruppo, pfctl -ss per gli stati ancora bloccati sul vecchio gateway, un traceroute da un client per il percorso di uscita e una query al resolver per vedere quale server ha risposto.

Ora fallo sfarfallare. Alza il primario per trenta secondi, abbassalo per trenta, due volte. Se il traffico insegue ogni transizione, le soglie sono troppo strette o i livelli sono sbagliati. Sistema questo secondo il tuo calendario, perché altrimenti un provider lo farà secondo il suo.

Infine, conferma di poter ancora amministrare il router. Tieni un percorso fuori banda come un cavo console, una VLAN di gestione o un modem cellulare. Un test di failover che ti chiude fuori è un test che non puoi finire, e un router irraggiungibile non può tornare indietro da solo.

Prima di dichiarare la policy finita, dovresti poter rispondere a quattro domande senza aprire un terminale: quali VLAN possono usare la WAN mentre il tunnel è giù, cosa sorveglia il rilevatore e quanto aspetta, quali server di nomi e route IPv6 si muovono con il percorso e come rientri se anche la riserva fallisce. Se una risposta è “qualunque fosse il valore predefinito”, la policy appartiene ancora al router e non a te.