GCP Cloud VPN: controllare gateway, tunnel e firewall nell'ordine giusto

La console mostra un tunnel verde, il monitoraggio on-premise continua a non raggiungere nemmeno un'istanza, e ricostruire il tunnel sembra la soluzione ovvia. Lo è raramente. Un tunnel stabilito dimostra solo che due gateway hanno completato lo scambio IKE. Non dice nulla sul fatto che un pacchetto sia mai stato ammesso nella vostra VPC.

Quattro decisioni separano quell'icona verde da una risposta, e falliscono in un ordine prevedibile. Affrontatele dalla più economica.

Tre oggetti, e solo uno di essi cifra

Un gateway VPN possiede l'indirizzo esterno verso cui cifra il vostro peer. Nella console non lo create mai a mano: scegliete o prenotate un indirizzo dentro il modulo di connessione e il gateway compare con esso. Un gateway HA occupa due indirizzi su due interfacce, cosa che conta al controllo delle quote più avanti.

Un tunnel è l'accoppiamento tra quel gateway e il peer. Trasporta il segreto condiviso e i selettori di traffico che promette di proteggere. È in quei selettori che iniziano la maggior parte dei guasti silenziosi. Un tunnel il cui selettore locale copre 10.0.0.0/24 non consegnerà 10.0.1.0/24, per quanto sano sembri lo stato.

L'estremità remota tiene la propria lista, di solito chiamata dominio di cifratura, e l'hardware di terminazione la confronta con la vostra. Nessun lato negozia un selettore che non gli è mai stato dato.

Il tipo di routing decide cosa raggiunge la tabella di routing

Cloud VPN offre tre forme di routing e non si mescolano in modo pulito. Il routing basato su policy conserva le coppie di selettori statici, il routing basato su route si aspetta che aggiungiate voi le route statiche, e il routing dinamico annuncia i prefissi tramite un Cloud Router su BGP. Sceglietene uno di proposito.

Un tunnel dinamico con route statiche scritte a mano accanto produce una tabella di routing che si svuota ogni volta che la sessione BGP oscilla.

Il dinamico è l'unica forma che consente ai prefissi protetti di cambiare senza ricostruire il tunnel, e trascina il Cloud Router nell'insieme degli oggetti che dovete verificare. I selettori statici restano praticabili quando il peer è un firewall hardware che non sa parlare BGP. Allora entrambe le estremità hanno bisogno degli stessi intervalli, e la voce più specifica deve vincere su entrambe. Una coppia che discorda di una sottorete si stabilisce e poi trasporta metà del vostro traffico.

Il rifiuto implicito sta dietro il tunnel

Il traffico in ingresso viene valutato contro un rifiuto implicito alla priorità più bassa, e quella regola non si cura del fatto che il pacchetto sia arrivato cifrato. Finché una regola del firewall non nomina l'intervallo on-premise e la porta in uso, il pacchetto viene decifrato, ispezionato e scartato. Il log VPN resta pulito per tutto il tempo, perché il tunnel ha fatto esattamente ciò che prometteva.

Leggete invece il log dei rifiuti del firewall quando il tunnel è attivo e la probe va in timeout, poi limitate una regola all'intervallo di origine e alle porte che vi servono:

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

Una sola direzione funzionante è un indizio del firewall

Il traffico in uscita si comporta diversamente, perché la regola di autorizzazione implicita lascia che le istanze inviino ovunque. Un data center che non raggiunge una VM spesso si trova dietro un percorso in uscita perfettamente funzionante nella direzione opposta. Questa asimmetria separa una dimenticanza del firewall da un guasto di routing, dato che un guasto di routing rompe entrambe le direzioni insieme. Provate la direzione inversa prima di modificare un'altra regola.

Anche la creazione di indirizzi è un'operazione a quote. Un progetto vicino al limite di indirizzi esterni in uso rifiuta la connessione con un errore che sembra un problema di permessi.

Selettori, quote, poi i quattro controlli

I tunnel creati nella console a volte restituiscono un selettore di traffico remoto vuoto da gcloud compute vpn-tunnels describe, mentre le route generate trasportano correttamente il traffico. Confrontate ciò che l'API registra con gli intervalli che proteggete davvero prima di decidere che il tunnel è sbagliato. Crearlo tramite API o SDK mantiene il selettore esplicito.

Le quote sono l'altra dimenticanza facile. Chiedete l'aumento prima della finestra di manutenzione e non durante, e controllate il numero di indirizzi nello stesso progetto del gateway.

Lavorate dall'esterno verso l'interno: stato del peer, entrambe le liste di selettori, una route per lato, una regola in ingresso per l'intervallo di origine e la porta, poi una cattura di pacchetti. Scrivete l'indirizzo del gateway, entrambe le liste di selettori e il tipo di routing nel ticket di modifica finché il tunnel è nuovo, perché il prossimo ingegnere che aggiungerà una sottorete avrà bisogno di tutte e tre.