Tre protezioni che impediscono a un gateway BGP per cliente di far trapelare route

Un gateway dedicato per cliente, che costruiamo e gestiamo noi, in peering interno con il nostro policy gateway su numeri AS privati, è il design giusto: isolamento, una policy che appartiene al cliente, e un routing che si adatta da solo. Il BGP è interno alla nostra piattaforma, non una sessione che gestisce il cliente. Significa anche che ora gestite molti piccoli speaker BGP, e una singola impostazione disattenta su uno qualsiasi di essi può annunciare route che non dovrebbe mai annunciare. Questo articolo spiega come succede e le tre protezioni che mettiamo su ogni gateway cliente perché non possa succedere.

Perché i gateway per cliente parlano BGP

Un concentratore VPN condiviso con route statiche sembra più semplice, finché non dovete aggiungere una subnet, spostare un cliente tra firewall o sopravvivere al guasto di un gateway. Con un gateway dedicato per cliente, ciascuno con un AS privato dentro la nostra piattaforma e in peering con un policy gateway centrale, aggiungere una rete è un annuncio, e perdere un percorso è un ritiro che converge da solo. La policy del cliente resta all'edge del cliente, e la policy di transito resta centrale.

Il prezzo è che ogni gateway ora è in grado di influenzare il routing per tutti. Quindi servono protezioni che non dipendano dall'attenzione di nessuno.

Come avvengono davvero le fughe

Nella maggior parte dei post-mortem pubblicati, la causa di un route leak da un dispositivo edge è raramente un bug BGP esotico. È la redistribution. Qualcuno abilita «redistribute connected» o «redistribute static» per risparmiare qualche tasto, e il gateway comincia ad annunciare il proprio link WAN, il pool del suo tunnel VPN, una subnet di gestione, o una route che ha imparato da qualche altra parte. Su un firewall open source con un demone di routing, quell'opzione è spesso a una casella di spunta di distanza.

Una volta che una route trapelata viene accettata a monte, il traffico per quel prefisso può essere attirato verso il gateway sbagliato, oppure la rete di un cliente può diventare raggiungibile da posti da cui non dovrebbe. Non si rompe nulla; il traffico va semplicemente da qualche parte di inatteso.

Protezione uno: annunciare con network statement espliciti

Un gateway dovrebbe annunciare esattamente i prefissi che appartengono al cliente, elencati uno per uno, e nient'altro. In FRR, che sta sotto molti plugin di routing dei firewall, si presenta così:

router bgp 64601
 bgp router-id 10.0.0.2
 neighbor 10.0.0.1 remote-as 64600
 address-family ipv4 unicast
  network 198.51.100.0/27
  neighbor 10.0.0.1 prefix-list CUSTOMER-OUT out
 exit-address-family

Il network statement annuncia solo un prefisso che è davvero presente nella tabella di routing, così un refuso non annuncia nulla invece di annunciare qualcosa di sbagliato.

Protezione due: una prefix list in uscita che corrisponde

Cintura e bretelle. Anche con network statement espliciti, una prefix list in uscita permette solo i prefissi del cliente e nega tutto il resto:

ip prefix-list CUSTOMER-OUT seq 10 permit 198.51.100.0/27
ip prefix-list CUSTOMER-OUT seq 100 deny any

Se qualcosa dovesse mai provare ad annunciare di più, questa lista lo scarta in uscita. Rispecchiatela anche sul lato ricevente: il gateway centrale accetta da ogni cliente solo i prefissi assegnati a quel cliente.

Protezione tre: nessuna redistribution, e la verifica che resti spenta

La redistribution è disabilitata, ed è parte della configurazione che verificate, non un'ipotesi. Su FRR potete controllare in una riga:

vtysh -c 'show running-config' | grep -i redistribute

Un risultato vuoto è l'unico risultato accettabile. Poiché alcune interfacce dei firewall espongono la redistribution come una comoda casella di spunta, questo controllo appartiene alla verifica della costruzione, non solo al design originale.

Confrontate con un gateway noto per funzionare prima della consegna

Tre protezioni prevengono le fughe. Non prevengono l'altro guasto comune dei gateway per cliente: un'impostazione che differisce dai gateway che funzionano, causando una VPN che «non si connette» o che si connette senza raggiungere nulla. Una regola pass mancante per la porta VPN sull'interfaccia WAN, il NAT in uscita lasciato in modalità automatica, una regola di interfaccia più restrittiva del previsto, un'opzione di autenticazione sottilmente diversa: ciascuna è facile da non vedere a occhio.

La cura è meccanica. Configurate ogni gateway attraverso la sua API, mai a mano, poi estraete le stesse impostazioni da un gateway di riferimento collaudato e da quello nuovo e confrontatele campo per campo:

• Impostazioni dell'istanza VPN: protocollo, porta, cifrari, modalità di autenticazione, route e DNS inviati.
• Regole firewall WAN per la porta VPN e la diagnostica.
• Regole sull'interfaccia VPN stessa.
• Modalità e regole del NAT in uscita.
• Configurazione BGP, campo redistribution compreso.

Qualsiasi differenza non esplicitamente attesa per questo cliente blocca la consegna. Nessuna credenziale lascia l'edificio finché il confronto non è pulito. Richiede secondi e sostituisce un pomeriggio di troubleshooting remoto con un utente che vuole solo lavorare.

Accesso per persona, fatto bene

Un certificato client per persona, firmato da un'autorità di certificazione che appartiene al cliente, più una credenziale, significa che un laptop perso è un certificato revocato e nessun altro ne risente. Un indirizzo di tunnel fisso per persona permette alla policy del firewall di seguire un individuo attraverso i dispositivi.

Checklist per i vostri gateway

• Ogni prefisso del cliente è annunciato da un network statement esplicito?
• C'è una prefix list in uscita su ogni sessione cliente, e una corrispondente in ingresso al centro?
• Un grep per redistribute torna vuoto su ogni gateway?
• I gateway sono configurati attraverso una API, con il risultato confrontato con un riferimento noto per funzionare prima della consegna?
• L'accesso remoto è per persona, con certificati revocabili individualmente?

Ogni gateway cliente che costruiamo ha queste protezioni, sul proprio segmento e con il proprio firewall. Se volete un accesso privato alla vostra piattaforma costruito così, saremo lieti di aiutarvi.

Parla con un ingegnere

Related (rows[1])

Correlati: Connettività privata: gateway VPN e linee dedicate · Firewall perimetrali gestiti · Backbone cifrato multi-sito: la mesh DMVPN