Kodėl GKE podai nepasiekia vietinių serverių per VPN

Ping veikia iš mazgo ir nepavyksta iš podo, o į vietinį tinklą niekas neateina. Tunelis ir maršrutas tvarkingi; šaltinio adresas laide ne. Šiuos du atvejus skiria tai, kuo paketas teigia esąs išėjęs iš klasterio, ir GKE šiuo klausimu turi nuomonę. Mechanizmas yra masquerade išimčių sąrašas, o jam perskaityti pakanka vienos komandos.

Perskaitykite galiojantį sąrašą prieš ką nors keisdami

GKE tiekia agentą, kuris pagal paskirties diapazoną nusprendžia, ar podų srautas išeinant bus perrašytas mazgo adresu. Jo pateikta konfigūracija nurodo tris RFC1918 blokus, 10.0.0.0/8, 172.16.0.0/12 ir 192.168.0.0/16, kaip išimtus paskirties taškus. Todėl viskas, ką siunčiate iš podo į vietinį 10.x serverį, palieka mazgą su paties podo adresu. Paties mazgo srautas neperrašomas, ir būtent todėl jo ping veikia.

Perskaitykite numatytą konfigūraciją ir įdiegtas taisykles, nes jos gali nesutapti. kubectl -n kube-system get configmap ip-masq-agent -o yaml rodo, kas buvo pasakyta agentui, o kubectl -n kube-system get pods -l k8s-app=ip-masq-agent rodo, ar kas nors veikia, kad tai pritaikytų. Mazge iptables-save | grep -i masq rodo taisykles, kurios iš tikrųjų egzistuoja branduolyje. Kai ConfigMap sako viena, o taisyklės kita, įtariamasis yra agentas, o ne tinklas.

Patvirtinkite šaltinio adresą įrašu

Padarykite įrašą prieš keisdami sąrašą. Filtras vienam paskirties taškui palieka išvestį įskaitomą: tcpdump -ni any host 10.20.30.40.

Palyginkite tai su tuo, ką praneša kita pusė. Įrašas vietiniame tinkle, rodantis podo adresą ir jokio atsakymo, uždaro ratą: išimčių sąrašas paaiškina asimetriją be jokios tunelio klaidos. Dviejų vieno šaltinio adreso stebėjimų pakanka, kad nustotumėte spėlioti apie CNI.

Susiaurinkite išimtį iki podų CIDR

Palaikomas taisymas susiaurina išimtį, o ne ją pašalina: palikite podų CIDR išimtą ir atmeskite likusią 10.x erdvę. Tas sąrašas yra agento ConfigMap faile po nonMasqueradeCIDRs, o jo keitimas yra redagavimas ir po jo diegimas. Pakeiskite platų įrašą tikruoju klasterio podų diapazonu, palikite kitus privačius blokus, jei srautas klasterio viduje jų dar reikia, ir palikite resyncInterval ramybėje, jei neturite priežasties. Pritaikykite, patvirtinkite, kad agento podai persikrovė, ir patvirtinkite, kad branduolio taisyklės pasikeitė.

Tai viso klasterio pakeitimas su realiu poveikio spinduliu. Jam įsigaliojus, srautas, kuris anksčiau išlaikydavo savo podo šaltinį, dabar atvyksta perrašytas mazgu, todėl viskas, kas buvo susieta su tais podų adresais, mato kitą siuntėją. Aukos yra žurnalai, leidimų sąrašai ir vietinės ugniasienės taisyklės, kuriose nurodomi podų adresai, ir jos tyliai sugenda. Skelbkite pakeitimą kaip elgsenos pakeitimą, o ne kaip taisymą.

Klasteryje su keliais mazgų telkiniais patikrinkite, ar agentas suplanuotas tuose mazguose, kuriuose paveikti podai iš tikrųjų veikia. Telkinys be DaemonSet išlaiko savo senas taisykles, ir niekas ConfigMap faile to neparodys.

Alternatyva ir jos kaina

Kitas variantas palieka podų adresus nepažeistus ir moko kelią apie juos. Podų CIDR patenka į Cloud VPN srauto selektorius, o vietinei pusei reikia grįžimo maršruto, kad atsakymai žinotų, kur eiti. Tai išsaugo podo tapatybę, kurios nori kai kurie saugumo modeliai, ir išplečia tiek maršrutizavimo, tiek ugniasienės apimtį, kurią turi priimti kita pusė.

Mainai yra įskaitomumas prieš apimtį. Vertimas leidžia vietinei pusei matyti vieną adresą vienam mazgui, ką lengva įtraukti į leidimų sąrašą ir kas paslepia, kuris podas ką išsiuntė. Be vertimo podo adresas išlieka nuo galo iki galo, kas geriau priskyrimui ir blogiau kiekvienam kelyje esančiam įrenginiui, kuris turi išmokti naują diapazoną. Nė vienas variantas nėra Docker ar CNI defektas; abu yra maršrutizavimo sprendimai su operacine sąskaita. Pasirinkite tą, kurio sąskaitą jūsų komanda gali apmokėti, ir užrašykite kodėl.

Patikrinkite ir grąžinkite

Paleiskite tą patį įrašą dar kartą. Mazgo lygio įrašas, kuris po jūsų redagavimo vis dar spausdina podo adresą, reiškia, kad taisyklės niekada nepasikeitė, ką bebūtų sakoma ConfigMap faile. Laidas yra faktas; visa kita yra išvada.

Tada patikrinkite priešingą kryptį, nes pusė šių pakeitimų tikrinama tik išeinančia kryptimi. Patvirtinkite, kad atsakymas pasiekia mazgą ar podą, kuris išsiuntė užklausą, ir patvirtinkite, kad programa baigė, o ne tik gavo SYN. Įrašas, rodantis užklausą be atsakymo, yra maršrutizavimo problema kitoje pusėje, o ne masquerade problema šioje.

Grąžinimas yra ankstesnis ConfigMap, pritaikytas taip pat, su tuo pačiu patvirtinimu, kad agentas persikrovė ir taisyklės pasikeitė. Pakeitimų žurnale išsaugokite vienos žinomos užklausos šaltinio adresą prieš ir po, nes būtent ta viena eilutė įrodo, kad pakeitimas padarė tai, ką sakėte. GKE IP masquerade agento vadovas dokumentuoja numatytąsias reikšmes ir ConfigMap laukus. Jei po diegimo šaltinio adresas nepakito, agentas tame mazge neveikia ir joks YAML redagavimas to neištaisys.