IP do cliente VPN dentro de Kubernetes: conservala ou facer SNAT?

Nalgures entre o túnel e o backend, o enderezo dun cliente sobrevive ou é substituído, e ambos os resultados son defendibles. A elección pertence a quen posúe o servizo receptor, non a quen instalou o CNI. Cando a autorización por cliente, as cotas ou os rexistros de auditoría importan, o enderezo ten que sobrevivir a cada salto. Cando a atribución compartida é aceptable, o NAT de orixe elimina un problema de routing que doutro xeito manterías para sempre.

Onde desaparece realmente o enderezo do cliente

O paquete dun cliente remoto chega ao pod VPN cunha orixe interna dentro do rango do túnel, digamos 10.90.0.42. Cando o pod reenvía ese paquete cara a un ClusterIP ou un IP de pod, tres mecanismos distintos poden reescribir a orixe. A regra de masquerade do CNI do nodo cobre o tráfico que o pod envía fóra do CIDR do clúster. A entrada de conntrack de kube-proxy no nodo de destino cobre o propio salto do Service. Un proxy que termina a conexión non reenvía o paquete en absoluto, así que a orixe que acabas vendo pertence ao proxy.

Cada un vive nunha capa distinta, e por iso un só campo de Service case nunca repara toda a ruta.

externalTrafficPolicy no Service público da VPN decide só que acontece coa conexión externa: Local mantén o enderezo remoto no nodo que o recibiu, mentres que Cluster deixa que kube-proxy pase o paquete a outro nodo e lle faga masquerade alí. Ese axuste goberna o listener ao que se conectan os teus clientes. Non di nada sobre o paquete descifrado que o teu proceso VPN encamiña cara ao clúster despois.

Tres condicións que resolven a discusión

Fago as mesmas tres preguntas na mesma orde cada vez que isto xorde, porque a primeira adoita pechar a discusión. Respondeas para a carga de traballo concreta e non para o clúster enteiro. Dous clústeres dentro dunha empresa poden chegar a respostas distintas e ambas ser correctas.

Se o backend responde si á primeira pregunta e non á segunda, tes traballo de rede que facer en lugar dun manifest que editar. Se a terceira fila di proxy, o enderezo nunca ía sobrevivir, e finxir o contrario custa unha semana de capturas de paquetes.

O que esixe o modo preserve da rede

Conservar a orixe significa que o nodo de destino debe devolver o tráfico a 10.90.0.42 a través dun gateway VPN activo. O pool da VPN non é un CIDR do clúster, así que ningún CNI o encamiña por ti de forma predeterminada. Engades a ruta ti mesmo e despois asegúrate de que o endpoint do gateway ao que apunta sobrevive a unha reprogramación.

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

Ese seguinte salto é un enderezo de pod, e os enderezos de pod móvense. Apunta a ruta a un VIP de Service ou a un enderezo de nodo que quede fixo, ou acepta que irás detrás do gateway despois de cada desaloxo. O filtrado de ruta inversa é a outra trampa: o modo estrito descarta paquetes cuxa ruta de retorno non coincide coa interface pola que chegaron, que é exactamente a forma dun fluxo VPN conservado.

A validación laxa adoita ser a diferenza entre unha ruta de retorno funcional e respostas que desaparecen despois de saír do backend. As regras de masquerade no nodo VPN tamén teñen que excluír o rango do túnel, ou o paquete reenviado sae co enderezo do pod, independentemente da ruta que construíse. Prefire expresar esa exclusión na configuración propia do CNI en vez de editar iptables á man, porque o axente reescribe as súas cadeas ao reiniciar e a túa regra escrita á man sobrevive exactamente ata a seguinte actualización.

NetworkPolicy é control de acceso, non routing. Endurecer unha política nunca restaurará un enderezo que o masquerade xa substituíu.

O que custa o SNAT, e como documentalo

O NAT de orixe cara ao clúster é o deseño máis barato, e non é un erro. O backend ve o enderezo do pod ou do nodo VPN, os rexistros concordan entre si, e non ten que existir ningunha ruta de retorno. O que perdes é a capacidade de distinguir dous clientes na capa de rede, así que as cotas, os bloqueos e as pistas de auditoría teñen que vir doutro sitio.

Normalmente ese outro sitio é a aplicación: un token de sesión, unha cabeceira asinada ou unha liña do protocolo PROXY escrita por un proxy que controlas. Estas danlle ao receptor unha identidade na que só pode confiar cando o proxy está na ruta e a cabeceira non se pode definir desde o lado do cliente. Sé explícito no runbook sobre cal se aplica, porque o seguinte enxeñeiro asumirá que o enderezo do rexistro é o cliente. Non o é, e un incidente abonda para facer cara esa suposición.

O intercambio segue sendo honesto mentres estea escrito.

Comprobacións que separan unha ruta funcional dunha afortunada

Proba cunha conexión nova en vez dunha en caché, e proba en ambos os sentidos. Varios fallos parecen intermitentes só porque os fluxos novos collen a ruta reescrita.

Captura a tupla en tres puntos durante unha solicitude autorizada: xusto despois da desencapsulación, na interface de saída do pod VPN e no backend. Se a orixe cambia entre a segunda e a terceira captura, a causa está augas abaixo do pod. Se cambia antes da segunda, o propio pod está traducindo.

Despois borra o pod VPN e repite a proba mentres se reprograma. Unha ruta conservada que se rompe no desaloxo está inacabada, e tamén o está unha regra NAT fixada a un enderezo que xa non existe. Por último, envía unha solicitude desde unha orixe que esperas que sexa denegada e confirma que a negativa vén da política e non dunha ruta que falta.