IP-ul clientului VPN în Kubernetes: îl păstrăm sau facem SNAT?

Undeva între tunel și backend, adresa unui client fie supraviețuiește, fie este înlocuită, iar ambele rezultate sunt de apărat. Alegerea aparține celui care deține serviciul receptor, nu celui care a instalat CNI-ul. Când autorizarea pe client, cotele sau înregistrările de audit contează, adresa trebuie să supraviețuiască fiecărui hop. Când atribuirea partajată este acceptabilă, NAT-ul de sursă elimină o problemă de rutare pe care altfel ai întreține-o pentru totdeauna.

Unde dispare de fapt adresa clientului

Pachetul unui client la distanță ajunge la pod-ul VPN cu o sursă internă în intervalul tunelului, să spunem 10.90.0.42. Când pod-ul redirecționează pachetul către un ClusterIP sau un IP de pod, trei mecanisme diferite pot rescrie sursa. Regula de masquerade a CNI-ului nodului acoperă traficul pe care pod-ul îl trimite în afara CIDR-ului clusterului. Intrarea conntrack a kube-proxy pe nodul destinație acoperă hopul Service în sine. Un proxy care termină conexiunea nu redirecționează deloc pachetul, așa că sursa pe care o vezi până la urmă aparține proxy-ului.

Fiecare trăiește într-un strat diferit, de aceea un singur câmp Service aproape niciodată nu repară întreaga cale.

externalTrafficPolicy pe Service-ul public al VPN-ului decide doar ce se întâmplă cu conexiunea exterioară: Local păstrează adresa la distanță pe nodul care a primit-o, în timp ce Cluster lasă kube-proxy să predea pachetul altui nod și să îl mascheze acolo. Această setare guvernează listenerul la care se conectează clienții tăi. Nu spune nimic despre pachetul decriptat pe care procesul tău VPN îl rutează apoi în cluster.

Trei condiții care încheie dezbaterea

Pun aceleași trei întrebări în aceeași ordine de fiecare dată când apare subiectul, pentru că prima încheie de obicei discuția. Răspunde la ele pentru sarcina de lucru concretă și nu pentru cluster în ansamblu. Două clustere din aceeași companie pot ajunge la răspunsuri diferite și ambele pot fi corecte.

Dacă backend-ul răspunde da la prima întrebare și nu la a doua, ai de făcut muncă de rețea, nu un manifest de editat. Dacă al treilea rând spune proxy, adresa nu avea cum să supraviețuiască, iar a pretinde altfel costă o săptămână de capturi de pachete.

Ce cere modul preserve de la rețea

Păstrarea sursei înseamnă că nodul destinație trebuie să returneze traficul către 10.90.0.42 printr-un gateway VPN activ. Pool-ul VPN nu este un CIDR al clusterului, așa că niciun CNI nu îl rutează pentru tine implicit. Adaugi ruta singur, apoi te asiguri că endpointul gateway-ului către care indică supraviețuiește unei reprogramări.

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

Următorul hop este o adresă de pod, iar adresele de pod se mută. Îndreaptă ruta către un VIP de Service sau o adresă de nod care rămâne pe loc, sau acceptă că vei alerga după gateway după fiecare evacuare. Filtrarea căii inverse este cealaltă capcană: modul strict elimină pachetele a căror cale de retur nu corespunde interfeței pe care au sosit, ceea ce este exact forma unui flux VPN păstrat.

Validarea laxă este adesea diferența dintre o cale de retur funcțională și răspunsuri care dispar după ce părăsesc backend-ul. Regulile de masquerade de pe nodul VPN trebuie și ele să excludă intervalul tunelului, altfel pachetul redirecționat pleacă cu adresa pod-ului, indiferent de ruta pe care ai construit-o. Preferă să exprimi această excludere în configurația proprie a CNI-ului în loc să editezi iptables manual, pentru că agentul își rescrie lanțurile la repornire, iar regula ta scrisă de mână supraviețuiește exact până la următorul upgrade.

NetworkPolicy este control de acces, nu rutare. Înăsprirea unei politici nu va restaura niciodată o adresă pe care masquerade a înlocuit-o deja.

Cât costă SNAT-ul și cum îl notezi

NAT-ul de sursă către cluster este proiectul mai ieftin și nu este o greșeală. Backend-ul vede adresa pod-ului sau a nodului VPN, jurnalele concordă între ele și nu trebuie să existe nicio rută de retur. Ce pierzi este capacitatea de a distinge doi clienți la nivel de rețea, așa că cotele, interdicțiile și urmele de audit trebuie să vină de altundeva.

De obicei acel altundeva este aplicația: un token de sesiune, un antet semnat sau o linie a protocolului PROXY scrisă de un proxy pe care îl controlezi. Acestea îi dau receptorului o identitate în care poate avea încredere doar când proxy-ul se află pe cale și antetul nu poate fi setat din partea clientului. Fii explicit în runbook despre care se aplică, pentru că următorul inginer va presupune că adresa din jurnal este clientul. Nu este, și un singur incident este suficient pentru a face această presupunere costisitoare.

Schimbul rămâne onest atât timp cât este notat.

Verificări care separă o cale funcțională de una norocoasă

Testează cu o conexiune nouă, nu cu una din cache, și testează în ambele direcții. Mai multe eșecuri par intermitente doar pentru că fluxurile noi iau calea rescrisă.

Captează tuplul în trei puncte în timpul unei cereri autorizate: imediat după decapsulare, pe interfața de ieșire a pod-ului VPN și pe backend. Dacă sursa se schimbă între a doua și a treia captură, cauza se află în aval de pod. Dacă se schimbă înainte de a doua, pod-ul însuși traduce.

Apoi șterge pod-ul VPN și repetă testul în timp ce este reprogramat. O cale păstrată care se rupe la evacuare este neterminată, la fel și o regulă NAT fixată pe o adresă care nu mai există. În final, trimite o cerere dintr-o sursă despre care te aștepți să fie refuzată și confirmă că refuzul vine din politică, nu dintr-o rută lipsă.