VPN kliento IP Kubernetes: išsaugoti ar atlikti SNAT?
Pasirinkite tarp tikrojo VPN kliento adreso išsaugojimo ir šaltinio NAT Kubernetes aplinkoje pagal tris sąlygas, tada patikrinkite grįžtamąjį kelią ir podų kaitą.
Kažkur tarp tunelio ir backend adresas arba išlieka, arba pakeičiamas, ir abu rezultatai yra apginami. Pasirinkimas priklauso priimančios paslaugos savininkui, o ne tam, kas įdiegė CNI. Kai svarbi autorizacija pagal klientą, kvotos ar audito įrašai, adresas turi išgyventi kiekvieną šuolį. Kai bendras priskyrimas priimtinas, šaltinio NAT pašalina maršrutizavimo problemą, kurią kitaip prižiūrėtumėte amžinai.
Kur kliento adresas iš tikrųjų dingsta
Nuotolinio kliento paketas atvyksta į VPN podą su vidiniu šaltiniu tunelio diapazone, tarkime 10.90.0.42. Kai podas persiunčia šį paketą link ClusterIP ar podo IP, šaltinį gali perrašyti trys skirtingi mechanizmai. Mazgo CNI masquerade taisyklė apima srautą, kurį podas siunčia už klasterio CIDR. kube-proxy conntrack įrašas paskirties mazge apima patį Service šuolį. Proxy, kuris užbaigia ryšį, paketo visai nepersiunčia, todėl galiausiai matomas šaltinis priklauso proxy.
Kiekvienas gyvena skirtingame sluoksnyje, todėl vienas Service laukas beveik niekada nesutaiso viso kelio.
externalTrafficPolicy viešajame VPN Service nusprendžia tik tai, kas nutinka išoriniam ryšiui: Local palieka nuotolinį adresą mazge, kuris jį priėmė, o Cluster leidžia kube-proxy perduoti paketą kitam mazgui ir ten jį maskuoti. Šis nustatymas valdo klausytoją, prie kurio jungiasi jūsų klientai. Jis nieko nesako apie iššifruotą paketą, kurį jūsų VPN procesas vėliau nukreipia į klasterį.
Trys sąlygos, kurios išsprendžia ginčą
Užduodu tuos pačius tris klausimus ta pačia tvarka kiekvieną kartą, kai tai iškyla, nes pirmasis paprastai užbaigia diskusiją. Atsakykite į juos konkrečiam darbo krūviui, o ne visam klasteriui. Du klasteriai vienoje įmonėje gali prieiti prie skirtingų atsakymų, ir abu gali būti teisingi.
| Question | Preserve | SNAT |
|---|---|---|
| Does the backend enforce policy per client? | Yes, the address is the identity | Only if a trusted proxy supplies identity |
| Can the cluster route 10.90.0.0/24 back to a stable gateway? | Required | Not needed |
| Is the workload a forwarder or a proxy? | Forwarder | Proxy is fine |
Jei backend į pirmą klausimą atsako taip, o į antrą – ne, jūsų laukia tinklo darbas, o ne manifestas, kurį reikia keisti. Jei trečia eilutė sako proxy, adresas niekada nebūtų išgyvenęs, o teigti priešingai kainuoja savaitę paketų fiksavimo.
Ko preserve režimas reikalauja iš tinklo
Išsaugoti šaltinį reiškia, kad paskirties mazgas turi grąžinti srautą į 10.90.0.42 per aktyvų VPN gateway. VPN baseinas nėra klasterio CIDR, todėl joks CNI jo už jus nenukreipia pagal nutylėjimą. Maršrutą pridedate patys, o tada pasirūpinate, kad gateway galinis taškas, į kurį jis rodo, išgyventų perkėlimą.
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2Kitas šuolis yra podo adresas, o podų adresai juda. Nukreipkite maršrutą į Service VIP arba į mazgo adresą, kuris lieka vietoje, arba priimkite, kad po kiekvieno iškeldinimo vysisite gateway. Atvirkštinio kelio filtravimas yra kita spąsta: griežtas režimas atmeta paketus, kurių grįžtamasis kelias neatitinka sąsajos, kuria jie atvyko, ir tai yra lygiai išsaugoto VPN srauto forma.
Laisvas tikrinimas dažnai yra skirtumas tarp veikiančio grįžtamojo kelio ir atsakymų, kurie dingsta palikus backend. VPN mazgo masquerade taisyklės taip pat turi neįtraukti tunelio diapazono, kitaip persiųstas paketas išeina su podo adresu, nesvarbu, kokį maršrutą sukūrėte. Verčiau išreikškite šį neįtraukimą pačios CNI konfigūracijoje, o ne redaguokite iptables rankiniu būdu, nes agentas paleidimo metu perrašo savo grandines, o jūsų ranka rašyta taisyklė išlieka lygiai iki kito atnaujinimo.
NetworkPolicy yra prieigos kontrolė, o ne maršrutizavimas. Politika griežtinant niekada neatkurs adreso, kurį masquerade jau pakeitė.
Kiek kainuoja SNAT ir kaip jį užrašyti
Šaltinio NAT link klasterio yra pigesnis sprendimas, ir tai ne klaida. Backend mato VPN podo ar mazgo adresą, žurnalai sutampa, ir grįžtamojo maršruto neturi būti. Prarandate galimybę atskirti du klientus tinklo lygmenyje, todėl kvotos, draudimai ir audito pėdsakai turi ateiti iš kitur.
Dažniausiai tas kitur yra programa: sesijos žetonas, pasirašyta antraštė ar PROXY protokolo eilutė, kurią rašo jūsų valdomas proxy. Jie suteikia gavėjui tapatybę, kuria jis gali pasitikėti tik tada, kai proxy yra kelyje ir antraštės negalima nustatyti iš kliento pusės. Runbooke aiškiai nurodykite, kuri galioja, nes kitas inžinierius manys, kad žurnale esantis adresas yra klientas. Taip nėra, ir vieno incidento pakanka, kad ši prielaida būtų brangi.
Mainai išlieka sąžiningi tol, kol yra užrašyti.
Patikros, skiriančios veikiantį kelią nuo sėkmingo
Bandykite su nauju ryšiu, o ne podėlyje laikomu, ir bandykite abiem kryptimis. Keli gedimai atrodo periodiški tik todėl, kad nauji srautai eina perrašytu keliu.
Užfiksuokite tuple trijuose taškuose per vieną leistą užklausą: iškart po dekapsuliavimo, VPN podo išėjimo sąsajoje ir backend. Jei šaltinis pasikeičia tarp antrojo ir trečiojo fiksavimo, priežastis yra žemiau podo. Jei pasikeičia prieš antrąjį, pats podas verčia.
Tada ištrinkite VPN podą ir pakartokite testą, kol jis perkeliamas. Išsaugotas kelias, kuris lūžta iškeldinant, yra nebaigtas, ir taip pat NAT taisyklė, pritvirtinta prie adreso, kurio nebėra. Galiausiai nusiųskite vieną užklausą iš šaltinio, kuriam tikitės atmetimo, ir patvirtinkite, kad atmetimas kyla iš politikos, o ne iš trūkstamo maršruto.