Route statiche o un protocollo di routing su una VPN site-to-site?

Entrambe le opzioni trasportano pacchetti tra siti, quindi la decisione non riguarda quale protocollo è più recente, e nemmeno la dimensione del tunnel la risolve. La risolvono tre condizioni: quante rotte cambiano e con quale frequenza, se il progetto richiede un failover automatico tra percorsi, e quanta macchinerie del piano di controllo il team riesce a gestire alle tre del mattino. Rispondete con onestà e la scelta di solito si fa da sola. Il resto di questo articolo è quanto costa ogni risposta.

Tre condizioni la decidono

La prima condizione è la volatilità. Una manciata di sottoreti stabili con una proprietà chiara si può mantenere a mano per anni, e ogni route resta una riga che qualcuno può leggere e verificare. Decine di prefissi che si spostano con l'arrivo e la partenza dei progetti sono un altro problema, perché ogni spostamento deve raggiungere ogni dispositivo che ricorda ancora il vecchio percorso.

La seconda è il comportamento in caso di guasto. Quando un percorso di riserva deve diventare attivo senza che un umano se ne accorga, qualcosa deve rilevare il guasto e ritirare la route. Il routing statico può farlo solo tramite monitoraggio o installazione condizionale, e solo per i guasti che avete previsto.

La terza è l'appetito per un secondo piano di controllo. Un protocollo di routing aggiunge sessioni, autenticazione, filtri e politica di selezione, e ognuno di questi elementi richiede monitoraggio e un processo di cambiamento. È un costo operativo permanente, non un'attività di configurazione una tantum.

La tabella sotto il terzo paragrafo è la versione breve, e le tre sezioni che la seguono spiegano perché ogni riga sta dove sta. Leggete le righe rispetto al vostro numero di siti prima di scegliere, perché una decisione che ignora il costo operativo è solo mezza decisione.

Quanto costa davvero il routing statico

Una route statica deve essere corretta su entrambi i lati del tunnel. Aggiungere una sottorete significa modificare il gateway remoto, il gateway locale e di solito il percorso di ritorno, e dimenticare uno di questi produce un guasto unidirezionale che sembra un bug dell'applicazione. Il team applicativo vede timeout mentre il team di rete vede una route presente e apparentemente sana. Nessuno dei due team sbaglia, ed è per questo che questo guasto richiede tanto tempo per essere localizzato.

Una voce statica resta inoltre installata dopo che il percorso sottostante scompare. A meno che la piattaforma offra il monitoraggio, la route continua a puntare a un next hop che non inoltra più, e il traffico svanisce invece di commutare. Quel silenzio è la spesa che accettate scegliendo l'opzione semplice.

Scrivete il metodo di monitoraggio accanto a ogni route, annotate quali guasti copre e tenete l'elenco con la configurazione del tunnel. Altrimenti la prossima interruzione la scopre un utente invece della rete, che è sempre la scoperta più costosa.

Quanto costa davvero il routing dinamico

Un protocollo annuncia nuovi prefissi, ritira quelli irraggiungibili ed esprime preferenza tra percorsi. È davvero utile quando più siti o tunnel ridondanti altrimenti richiederebbero modifiche coordinate a ogni cambiamento. È anche il motivo per cui il protocollo può sorprendervi nel momento peggiore. Ognuna di queste azioni è un cambio di stato che non avete fatto personalmente.

Crea due stati che possono discordare. Il tunnel può essere attivo mentre la sessione di routing è inattiva, e la sessione può essere attiva mentre i suoi annunci omettono la sottorete di cui l'applicazione ha bisogno. Entrambi sembrano una rete che funziona a metà, e nessuno dei due è visibile da una pagina di stato del tunnel.

Filtri e politica diventano quindi parte del progetto invece di un ripensamento. Un protocollo che annuncia tutto prima o poi annuncerà qualcosa di sbagliato, e il prefisso sbagliato viaggia più veloce della persona che può correggerlo. Scrivete i filtri prima che la prima sessione sia abilitata, così il primo annuncio è già deliberato.

Controllate ciò che la sessione di routing può dire

Decidete l'elenco dei prefissi consentiti per peer e applicatelo in ingresso, perché un filtro in uscita non può impedire a un peer di inviarvi una route predefinita. Le route predefinite e gli aggregati sono gli errori costosi qui: possono sostituire in silenzio percorsi non correlati con una sola voce appresa che sembra legittima. Rifiutateli esplicitamente a meno che il progetto li voglia davvero.

Scrivete il sito proprietario accanto a ogni rete prima che la prima sessione salga, perché quella mappatura è la fonte dell'elenco dei filtri e non un ornamento della documentazione. Senza di essa, chi modifica un filtro deve indovinare quale sito dovrebbe annunciare il prefisso.

La ridistribuzione tra due protocolli è dove iniziano i loop e dove lo stesso prefisso arriva due volte con attributi che non si confrontano in modo pulito. Tenete la ridistribuzione fuori dal progetto finché un requisito specifico non la impone, e se deve esistere, marcatela e filtratela al confine.

Le interfacce tunnel basate su route rendono il routing dinamico più facile da rappresentare, perché il tunnel diventa un'interfaccia con route invece di una politica che abbina selettori. Questo non elimina la questione dell'ambito del peer: i selettori IPsec devono comunque consentire il traffico che intendete instradare.

Provate il percorso di guasto, non il percorso felice

Qualunque cosa scegliate, abbassate un uplink e confermate che il traffico si sposta, o che fallisce come avete documentato. Un progetto provato solo con entrambi i percorsi sani è un progetto che non è stato provato affatto. Misurate il tempo di rilevamento mentre siete lì, perché il numero che avete misurato è il numero che gli utenti vivranno.

Poi confermate il percorso di ritorno in modo indipendente, perché il routing asimmetrico su una VPN è comune e invisibile finché un dispositivo con stato non scarta le risposte. Un flusso che funziona in una direzione dimostra solo metà del percorso.

Ordine di lavoro: contate i prefissi, decidete come devono essere rilevati i guasti, verificate chi può gestire il protocollo, controllate cosa viene annunciato, poi provate un'interruzione da un capo all'altro. Ogni passo produce un fatto che il successivo richiede.