VPN klienta IP Kubernetes vidē: saglabāt vai veikt SNAT?
Izvēlieties starp īstās VPN klienta adreses saglabāšanu un avota NAT Kubernetes vidē, pamatojoties uz trim nosacījumiem, pēc tam pārbaudiet atgriešanās ceļu un podu maiņu.
Kaut kur starp tuneli un backendu klienta adrese vai nu izdzīvo, vai tiek aizstāta, un abi iznākumi ir aizstāvami. Izvēle pieder saņēmējpakalpojuma īpašniekam, nevis tam, kurš instalēja CNI. Ja svarīga ir autorizācija katram klientam, kvotas vai audita ieraksti, adresei jāiztur katrs lēciens. Ja kopīga attiecināšana ir pieņemama, avota NAT novērš maršrutēšanas problēmu, kuru citādi uzturētu mūžīgi.
Kur klienta adrese patiesībā pazūd
Attālināta klienta pakete nonāk VPN podā ar iekšēju avotu tuneļa diapazonā, teiksim 10.90.0.42. Kad pods pārsūta šo paketi uz ClusterIP vai poda IP, avotu var pārrakstīt trīs dažādi mehānismi. Mezglu CNI masquerade noteikums aptver trafiku, ko pods sūta ārpus klastera CIDR. kube-proxy conntrack ieraksts mērķa mezglā aptver pašu Service lēcienu. Proxy, kas izbeidz savienojumu, paketi nemaz nepārsūta, tāpēc avots, ko beigu beigās redzat, pieder proxy.
Katrs dzīvo citā slānī, tāpēc viens Service lauks gandrīz nekad nesalabo visu ceļu.
externalTrafficPolicy VPN publiskajā Service izlemj tikai to, kas notiek ar ārējo savienojumu: Local patur attālo adresi mezglā, kas to saņēma, savukārt Cluster ļauj kube-proxy nodot paketi citam mezglam un maskēt to tur. Šis iestatījums pārvalda klausītāju, uz kuru savienojas jūsu klienti. Tas neko nepasaka par atšifrēto paketi, ko jūsu VPN process pēc tam maršrutē klasterī.
Trīs nosacījumi, kas izšķir strīdu
Es uzdodu tos pašus trīs jautājumus tajā pašā secībā katru reizi, kad šis jautājums rodas, jo pirmais parasti izbeidz diskusiju. Atbildiet uz tiem konkrētajai darba slodzei, nevis visam klasterim. Divi klasteri vienā uzņēmumā var nonākt pie atšķirīgām atbildēm, un abas var būt pareizas.
| 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 |
Ja backend uz pirmo jautājumu atbild jā un uz otro nē, jums ir tīkla darbs, nevis manifests, kas jālabo. Ja trešā rinda saka proxy, adrese nekad nebūtu izdzīvojusi, un pretējā apgalvošana maksā nedēļu paketes uztveršanas.
Ko preserve režīms prasa no tīkla
Avota saglabāšana nozīmē, ka mērķa mezglam ir jāatgriež trafiks uz 10.90.0.42 caur aktīvu VPN gateway. VPN baseins nav klastera CIDR, tāpēc neviens CNI to jūsu vietā nemaršrutē pēc noklusējuma. Jūs pats pievienojat maršrutu un pēc tam pārliecināties, ka gateway galapunkts, uz kuru tas norāda, iztur pārplānošanu.
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2Nākamais lēciens ir poda adrese, un podu adreses pārvietojas. Novirziet maršrutu uz Service VIP vai mezgla adresi, kas paliek uz vietas, vai pieņemiet, ka pēc katras izdzīšanas dzīsieties pakaļ gateway. Apgrieztā ceļa filtrēšana ir otra lamatas: stingrais režīms atmet paketes, kuru atgriešanās ceļš neatbilst saskarnei, pa kuru tās ieradās, un tā ir tieši saglabātas VPN plūsmas forma.
Vaļīga validācija bieži ir atšķirība starp strādājošu atgriešanās ceļu un atbildēm, kas pazūd pēc backend atstāšanas. Masquerade noteikumiem VPN mezglā arī jāizslēdz tuneļa diapazons, citādi pārsūtītā pakete iziet ar poda adresi neatkarīgi no tā, kādu maršrutu esat izveidojis. Labāk izsakiet šo izslēgšanu paša CNI konfigurācijā, nevis rediģējiet iptables ar roku, jo aģents pārstartēšanas laikā pārraksta savas ķēdes, un jūsu ar roku rakstītais noteikums iztur tieši līdz nākamajam atjauninājumam.
NetworkPolicy ir piekļuves kontrole, nevis maršrutēšana. Politikas stingrāka noteikšana nekad neatjaunos adresi, ko masquerade jau ir aizstājis.
Cik maksā SNAT un kā to pierakstīt
Avota NAT uz klasteri ir lētāks dizains, un tā nav kļūda. Backend redz VPN poda vai mezgla adresi, žurnāli saskan, un atgriešanās maršrutam nav jāpastāv. Jūs zaudējat spēju atšķirt divus klientus tīkla līmenī, tāpēc kvotām, aizliegumiem un audita pēdām jānāk no citurienes.
Parasti šī cituriene ir lietojumprogramma: sesijas marķieris, parakstīta galvene vai PROXY protokola rinda, ko raksta jūsu kontrolēts proxy. Tie piešķir saņēmējam identitāti, kurai tas var uzticēties tikai tad, kad proxy atrodas ceļā un galveni nevar iestatīt no klienta puses. Runbookā skaidri norādiet, kura attiecas, jo nākamais inženieris pieņems, ka žurnālā esošā adrese ir klients. Tā nav, un viens incidents ir pietiekams, lai šo pieņēmumu padarītu dārgu.
Apmaiņa paliek godīga, kamēr tā ir pierakstīta.
Pārbaudes, kas atdala strādājošu ceļu no laimīga
Pārbaudiet ar svaigu savienojumu, nevis kešatmiņā saglabātu, un pārbaudiet abos virzienos. Vairākas kļūdas šķiet periodiskas tikai tāpēc, ka jaunas plūsmas iet pa pārrakstīto ceļu.
Uztveriet tuple trīs punktos viena autorizēta pieprasījuma laikā: tūlīt pēc dekapsulācijas, VPN poda izejas saskarnē un backend. Ja avots mainās starp otro un trešo uztveršanu, cēlonis ir lejpus poda. Ja tas mainās pirms otrās, pats pods tulko.
Pēc tam izdzēsiet VPN podu un atkārtojiet testu, kamēr tas tiek pārplānots. Saglabāts ceļš, kas salūzt izdzīšanas laikā, ir nepabeigts, un tāds pats ir NAT noteikums, kas piesaistīts adresei, kura vairs neeksistē. Visbeidzot nosūtiet vienu pieprasījumu no avota, kuram sagaidāt atteikumu, un apstipriniet, ka atteikums nāk no politikas, nevis no trūkstoša maršruta.