IP del client VPN dins de Kubernetes: conservar-la o fer SNAT?

En algun punt entre el túnel i el backend, l'adreça d'un client sobreviu o se substitueix, i tots dos resultats són defensables. L'elecció pertany a qui posseeix el servei receptor, no a qui va instal·lar el CNI. Quan l'autorització per client, les quotes o els registres d'auditoria importen, l'adreça ha de sobreviure a cada salt. Quan l'atribució compartida és acceptable, el NAT d'origen elimina un problema d'encaminament que d'altra manera mantindries per sempre.

On desapareix realment l'adreça del client

El paquet d'un client remot arriba al pod VPN amb un origen intern dins del rang del túnel, posem per cas 10.90.0.42. Quan el pod reenvia aquest paquet cap a un ClusterIP o una IP de pod, tres mecanismes diferents poden reescriure l'origen. La regla de masquerade del CNI del node cobreix el trànsit que el pod envia fora del CIDR del clúster. L'entrada de conntrack de kube-proxy al node de destinació cobreix el mateix salt del Service. Un proxy que acaba la connexió no reenvia el paquet en absolut, així que l'origen que acabes veient pertany al proxy.

Cadascun viu en una capa diferent, i per això un sol camp de Service gairebé mai no arregla tota la ruta.

externalTrafficPolicy al Service públic de la VPN decideix només què passa amb la connexió externa: Local manté l'adreça remota al node que l'ha rebuda, mentre que Cluster deixa que kube-proxy passi el paquet a un altre node i hi faci masquerade. Aquest paràmetre governa l'oient al qual es connecten els teus clients. No di res sobre el paquet desxifrat que el teu procés VPN encamina cap al clúster després.

Tres condicions que resolen la discussió

Faig les mateixes tres preguntes en el mateix ordre cada vegada que això sorgeix, perquè la primera normalment tanca la discussió. Responeu-les per a la càrrega de treball concreta i no per al clúster sencer. Dos clústers dins d'una empresa poden arribar a respostes diferents i totes dues ser correctes.

Si el backend respon sí a la primera pregunta i no a la segona, tens feina de xarxa per fer en lloc d'un manifest per editar. Si la tercera fila diu proxy, l'adreça no havia de sobreviure mai, i fingir el contrari costa una setmana de captures de paquets.

Què exigeix el mode preserve a la xarxa

Conservar l'origen vol dir que el node de destinació ha de retornar el trànsit a 10.90.0.42 a través d'un gateway VPN actiu. El pool de la VPN no és un CIDR del clúster, així que cap CNI l'encamina per tu per defecte. Afegeixes la ruta tu mateix i després t'assegures que l'extrem del gateway al qual apunta sobreviu a una reprogramació.

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

Aquest salt següent és una adreça de pod, i les adreces de pod es mouen. Apunta la ruta a un VIP de Service o a una adreça de node que es quedi al lloc, o accepta que perseguiràs el gateway després de cada desallotjament. El filtratge de ruta inversa és l'altra trampa: el mode estricte descarta paquets la ruta de retorn dels quals no coincideix amb la interfície per la qual van arribar, que és exactament la forma d'un flux VPN conservat.

La validació laxa sovint és la diferència entre una ruta de retorn que funciona i respostes que desapareixen després de sortir del backend. Les regles de masquerade al node VPN també han d'excloure el rang del túnel, o el paquet reenviat surt amb l'adreça del pod, independentment de la ruta que hagis construït. Prefereix expressar aquesta exclusió a la configuració pròpia del CNI en lloc d'editar iptables a mà, perquè l'agent reescriu les seves cadenes en reiniciar-se i la teva regla escrita a mà sobreviu exactament fins a la propera actualització.

NetworkPolicy és control d'accés, no encaminament. Endurir una política no restaurarà mai una adreça que el masquerade ja ha substituït.

Quant costa el SNAT, i com deixar-ho escrit

El NAT d'origen cap al clúster és el disseny més barat, i no és cap error. El backend veu l'adreça del pod o del node VPN, els registres coincideixen entre si i no ha d'existir cap ruta de retorn. El que perds és la capacitat de distingir dos clients a la capa de xarxa, així que les quotes, els bloqueigs i les traces d'auditoria han de venir d'algun altre lloc.

Normalment aquest altre lloc és l'aplicació: un testimoni de sessió, una capçalera signada o una línia del protocol PROXY escrita per un proxy que controles. Aquestes donen al receptor una identitat en la qual només pot confiar quan el proxy és a la ruta i la capçalera no es pot definir des del costat del client. Sigues explícit al runbook sobre quina s'aplica, perquè el següent enginyer assumirà que l'adreça del registre és el client. No ho és, i un incident n'hi ha prou per fer cara aquesta suposició.

L'intercanvi continua sent honest mentre estigui escrit.

Comprovacions que separen una ruta funcional d'una d'afortunada

Prova amb una connexió nova en lloc d'una de la memòria cau, i prova en tots dos sentits. Diverses fallades semblen intermitents només perquè els fluxos nous prenen la ruta reescrita.

Captura la tupla en tres punts durant una sol·licitud autoritzada: just després de la desencapsulació, a la interfície de sortida del pod VPN i al backend. Si l'origen canvia entre la segona i la tercera captura, la causa és més avall del pod. Si canvia abans de la segona, el propi pod està traduint.

Després esborra el pod VPN i repeteix la prova mentre es reprograma. Una ruta conservada que es trenca en el desallotjament està inacabada, i també ho està una regla NAT fixada a una adreça que ja no existeix. Finalment, envia una sol·licitud des d'un origen que esperes que sigui denegat i confirma que la negativa ve de la política i no d'una ruta que falta.