IP del client VPN in Kubernetes: conservarlo o fare SNAT?

Da qualche parte tra il tunnel e il backend, l'indirizzo di un client sopravvive o viene sostituito, ed entrambi gli esiti sono difendibili. La scelta spetta a chi possiede il servizio ricevente, non a chi ha installato il CNI. Quando contano l'autorizzazione per client, le quote o i registri di audit, l'indirizzo deve sopravvivere a ogni salto. Quando l'attribuzione condivisa è accettabile, il NAT di origine elimina un problema di routing che altrimenti manterresti per sempre.

Dove scompare davvero l'indirizzo del client

Il pacchetto di un client remoto arriva al pod VPN con un'origine interna nell'intervallo del tunnel, diciamo 10.90.0.42. Quando il pod inoltra quel pacchetto verso un ClusterIP o un IP di pod, tre meccanismi diversi possono riscrivere l'origine. La regola di masquerade del CNI sul nodo copre il traffico che il pod invia fuori dal CIDR del cluster. La voce conntrack di kube-proxy sul nodo di destinazione copre il salto verso il Service stesso. Un proxy che termina la connessione non inoltra affatto il pacchetto, quindi l'origine che alla fine vedi appartiene al proxy.

Ciascuno vive in uno strato diverso, ed è per questo che un singolo campo di Service quasi mai ripara l'intero percorso.

externalTrafficPolicy sul Service pubblico della VPN decide solo cosa succede alla connessione esterna: Local mantiene l'indirizzo remoto sul nodo che l'ha ricevuto, mentre Cluster lascia che kube-proxy consegni il pacchetto a un altro nodo e lo mascheri lì. Quell'impostazione governa il listener a cui si collegano i tuoi client. Non dice nulla sul pacchetto decifrato che il tuo processo VPN instrada poi nel cluster.

Tre condizioni che chiudono la discussione

Pongo le stesse tre domande nello stesso ordine ogni volta che la questione emerge, perché la prima di solito chiude la discussione. Rispondi per il carico di lavoro specifico e non per il cluster nel suo insieme. Due cluster dentro una stessa azienda possono arrivare a risposte diverse ed essere entrambi corretti.

Se il backend risponde sì alla prima domanda e no alla seconda, hai lavoro di rete da fare invece di un manifest da modificare. Se la terza riga dice proxy, l'indirizzo non sarebbe mai sopravvissuto, e fingere il contrario costa una settimana di catture di pacchetti.

Cosa richiede la modalità preserve alla rete

Conservare l'origine significa che il nodo di destinazione deve restituire il traffico a 10.90.0.42 attraverso un gateway VPN attivo. Il pool VPN non è un CIDR del cluster, quindi nessun CNI lo instrada per te per impostazione predefinita. Aggiungi la rotta da solo, poi ti assicuri che l'endpoint del gateway a cui punta sopravviva a una riprogrammazione.

ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2

Quel salto successivo è un indirizzo di pod, e gli indirizzi di pod si spostano. Punta la rotta a un VIP di Service o a un indirizzo di nodo che resta fermo, oppure accetta di inseguire il gateway dopo ogni espulsione. Il filtraggio del percorso inverso è l'altra trappola: la modalità strict scarta i pacchetti il cui percorso di ritorno non corrisponde all'interfaccia da cui sono arrivati, che è esattamente la forma di un flusso VPN conservato.

Una validazione lasca è spesso la differenza tra un percorso di ritorno funzionante e risposte che svaniscono dopo aver lasciato il backend. Anche le regole di masquerade sul nodo VPN devono escludere l'intervallo del tunnel, altrimenti il pacchetto inoltrato esce con l'indirizzo del pod, qualunque rotta tu abbia costruito. Preferisci esprimere tale esclusione nella configurazione del CNI stesso invece di modificare iptables a mano, perché l'agente riscrive le sue catene al riavvio e la tua regola scritta a mano sopravvive esattamente fino al prossimo aggiornamento.

NetworkPolicy è controllo degli accessi, non routing. Irrigidire una policy non ripristinerà mai un indirizzo che il masquerade ha già sostituito.

Quanto costa il SNAT, e come metterlo per iscritto

Il NAT di origine verso il cluster è il progetto più economico, e non è un errore. Il backend vede l'indirizzo del pod o del nodo VPN, i log concordano tra loro e non deve esistere alcuna rotta di ritorno. Quello che perdi è la capacità di distinguere due client a livello di rete, quindi quote, blocchi e tracce di audit devono venire da altrove.

Di solito quell'altrove è l'applicazione: un token di sessione, un'intestazione firmata o una riga del protocollo PROXY scritta da un proxy che controlli. Questi danno al destinatario un'identità di cui può fidarsi solo quando il proxy è sul percorso e l'intestazione non può essere impostata dal lato client. Sii esplicito nel runbook su quale si applica, perché il prossimo ingegnere assumerà che l'indirizzo nel log sia il client. Non lo è, e un solo incidente basta a rendere cara quell'assunzione.

Lo scambio resta onesto finché è messo per iscritto.

Controlli che separano un percorso funzionante da uno fortunato

Prova con una connessione nuova invece che in cache, e prova in entrambe le direzioni. Diversi guasti sembrano intermittenti solo perché i nuovi flussi prendono il percorso riscritto.

Cattura la tupla in tre punti durante una richiesta autorizzata: subito dopo la decapsulazione, sull'interfaccia di uscita del pod VPN e sul backend. Se l'origine cambia tra la seconda e la terza cattura, la causa è a valle del pod. Se cambia prima della seconda, il pod stesso sta traducendo.

Poi elimina il pod VPN e ripeti il test mentre viene riprogrammato. Un percorso conservato che si rompe all'espulsione è incompleto, e lo è anche una regola NAT fissata a un indirizzo che non esiste più. Infine, invia una richiesta da un'origine che ti aspetti venga negata e conferma che il rifiuto viene dalla policy e non da una rotta mancante.