I pod GKE hanno perso l'accesso alla VPN dopo la 1.14: due modi per correggere l'origine

Arriva un aggiornamento e i sistemi dall'altra parte del tunnel iniziano a rifiutare il traffico dei pod che funzionava la settimana prima. Il tunnel è attivo, le regole del firewall sono intatte e nessuno ha modificato la politica del peer. Ciò che è cambiato è invisibile nei log del cluster: l'indirizzo di origine che quei sistemi vedono ora. Questo scarto spiega un guasto che sembra un'interruzione di rete e si comporta come un problema di permessi.

Esistono due risposte valide e portano in luoghi diversi. Scegliete il contratto di origine prima di modificare una ConfigMap.

La regola predefinita che non viene più installata

Le versioni precedenti di GKE installavano una regola di masquerade che sostituiva le origini dei pod con l'indirizzo del nodo ogni volta che la destinazione era fuori da 10.0.0.0/8. Un gateway VPN dentro quell'intervallo vedeva l'indirizzo del pod, mentre tutto ciò che era più lontano sembrava provenire dal nodo. I peer hanno costruito elenchi di autorizzati e rotte di ritorno intorno agli indirizzi dei nodi perché è ciò che osservavano.

Le versioni successive hanno smesso di installare quella regola predefinita. Il traffico dei pod ora arriva al gateway con gli indirizzi dei pod, qualunque sia la destinazione. Un peer che instrada solo gli indirizzi dei nodi scarta le risposte e nessuno dei due lati scrive una voce di log utile. La richiesta può persino riuscire all'estremità remota, ed è questo che rende il guasto difficile da inseguire.

Niente è rotto nel senso di un componente morto. I due lati semplicemente non concordano su quale origine sia legittima.

Scegliete l'origine che il peer dovrebbe vedere

Mantenere gli indirizzi dei pod è il contratto più preciso. Il lato remoto vede il carico di lavoro che ha prodotto il traffico, i log restano onesti e la politica per pod diventa possibile. Il prezzo è che il peer deve portare il prefisso dei pod.

Mantenere gli indirizzi dei nodi è il contratto più economico. Riattivate il masquerade per quella destinazione e il peer continua a vedere un indirizzo di cui si fida già.

Una domanda decide fra i due: che cosa fa il peer con l'origine? Se registra, applica una politica per origine o impone un instradamento di ritorno stretto, gli indirizzi dei pod giustificano la configurazione extra. Se deve solo inviare risposte, il masquerade costa meno e non chiede nulla all'altro lato. Ogni scelta è difendibile finché entrambi i team la mettono per iscritto.

Una terza opzione di solito è un errore: mascherare tutto e perdere la capacità di attribuire il traffico. Evitatela a meno che un peer non possa davvero instradare altro che indirizzi dei nodi.

Puntate nonMasqueradeCIDRs ai veri intervalli

GKE esegue l'ip-masq-agent in kube-system e la sua ConfigMap elenca le destinazioni che saltano il masquerade. Per preservare le origini dei pod verso il tunnel, l'intervallo dei pod, la sottorete dei nodi e il prefisso locale appartengono tutti a quell'elenco.

Sostituite i valori di esempio con intervalli del vostro cluster. Non allargate l'elenco più di quanto richieda il requisito, perché ogni voce in più cambia ciò che vede un'altra destinazione. Le tre voci qui sotto rappresentano la rete dei pod, la sottorete dei nodi e il prefisso dietro il tunnel:

nonMasqueradeCIDRs:
  - 10.12.0.0/14
  - 10.100.0.0/16
  - 172.16.0.0/12
masqLinkLocal: false
resyncInterval: 60s

Una voce 0.0.0.0/0 disattiva il masquerade per tutte le destinazioni, il che altera il modo in cui carichi di lavoro non correlati appaiono ai servizi esterni ed è raramente voluto. L'agente rilegge la propria configurazione a resyncInterval, quindi di solito un riavvio non serve. Verificate che il pod dell'agente sia in esecuzione, poi aprite il file montato al suo interno. È la lettura di quel file che dimostra che la modifica è arrivata.

Il percorso di ritorno è l'altra metà

Il masquerade modifica l'origine della richiesta e nient'altro. Qualunque origine riceva il peer, gli serve ancora una rotta verso di essa, e al cluster serve ancora una rotta verso il peer.

Una cattura sul gateway VPN separa rapidamente i due guasti. I pacchetti che arrivano con indirizzi dei pod e non ricevono mai risposta significano che al peer manca una rotta per il prefisso dei pod. Una risposta che appare sul gateway ma non raggiunge mai il cluster significa che manca la rotta locale. Scrivete il contratto nel ticket in ogni caso: quale origine vede il peer e verso quale prefisso instrada la risposta.

Ricontrollate dopo ogni aggiornamento

Il comportamento predefinito del masquerade è già cambiato una volta, e la sostituzione di un pool di nodi può azzerare la rete del cluster. Trattate il contratto di origine come qualcosa da verificare e non da dare per scontato.

Dopo un aggiornamento, inviate una richiesta da un pod a un servizio locale e leggete l'origine che il peer registra. Quella singola osservazione intercetta una regressione che una pagina di stato del tunnel segnalerebbe volentieri come sana. Ripeterla costa un minuto e risparmia una serata alla persona successiva.