Kial GKE-podoj ne atingas surlokajn gastigantojn tra VPN

Ping funkcias de la nodo kaj malsukcesas de la podo, kaj nenio alvenas surloke. La tunelo kaj la itinero estas bonaj; la fonta adreso sur la drato ne. Kio diferencas inter tiuj du kazoj estas, kion la paketo asertas esti kiam ĝi forlasas la klastron, kaj GKE havas opinion pri tio. La mekanismo estas masquerade-esceptolisto, kaj legi ĝin postulas unu komandon.

Legu la validan liston antaŭ ol ŝanĝi ion

GKE liveras agenton, kiu por ĉiu cela intervalo decidas, ĉu poda trafiko estas reskribata al la noda adreso dum la eliro. Ĝia liverita agordo nomas la tri RFC1918-blokojn, 10.0.0.0/8, 172.16.0.0/12 kaj 192.168.0.0/16, kiel esceptitaj celoj. Ĉio, kion vi sendas de podo al surloka 10.x-gastiganto, do forlasas la nodon kun la propra adreso de la podo ankoraŭ alkroĉita. La trafiko de la nodo mem ne estas reskribata, kaj ĝuste tial ĝia ping funkcias.

Legu la celitan agordon kaj la instalitajn regulojn, ĉar ili povas malkonsenti. kubectl -n kube-system get configmap ip-masq-agent -o yaml montras, kion oni diris al la agento, kaj kubectl -n kube-system get pods -l k8s-app=ip-masq-agent montras, ĉu io ruliĝas por apliki ĝin. Sur nodo, iptables-save | grep -i masq montras la regulojn, kiuj efektive ekzistas en la kerno. Kiam la ConfigMap diras unu aferon kaj la reguloj alian, la agento estas la suspektato, ne la reto.

Konfirmu la fontan adreson per kapto

Faru kapton antaŭ ol ŝanĝi liston. Filtrilo sur la unu celo tenas la eligon legebla: tcpdump -ni any host 10.20.30.40.

Komparu tion kun tio, kion raportas la alia flanko. Kapto surloke, kiu montras la podan adreson kaj neniun respondon, fermas la ciklon: la esceptolisto klarigas la malsimetrion sen ia tunela difekto. Du observoj de unu fonta adreso sufiĉas por ĉesi konjekti pri la CNI.

Mallarĝigu la escepton al la poda CIDR

La subtenata riparo mallarĝigas la escepton anstataŭ forigi ĝin: tenu la podan CIDR esceptita kaj forlasu la reston de la 10.x-spaco. Tiu listo loĝas en la ConfigMap de la agento sub nonMasqueradeCIDRs, kaj ŝanĝi ĝin estas redakto sekvata de dislokigo. Anstataŭigu la larĝan rikordon per la reala poda intervalo de la klastro, tenu la aliajn privatajn blokojn se trafiko ene de la klastro ankoraŭ bezonas ilin, kaj lasu resyncInterval trankvila krom se vi havas kialon. Apliku ĝin, konfirmu ke la agentaj podoj restartis, kaj konfirmu ke la kernaj reguloj ŝanĝiĝis.

Ĉi tio estas ŝanĝo tra la tuta klastro kun reala efika radiuso. Post kiam ĝi efektiviĝas, trafiko, kiu antaŭe konservis sian podan fonton, nun alvenas reskribita al la nodo, do ĉio, kio estis ŝlosita al tiuj podaj adresoj, vidas alian sendanton. La viktimoj estas protokoloj, permeslistoj kaj surlokaj fajroŝirmilaj reguloj, kiuj nomas podajn adresojn, kaj ili malsukcesas silente. Anoncu la ŝanĝon kiel kondutan ŝanĝon, ne kiel riparon.

En klastro kun pluraj nodaj grupoj, kontrolu, ĉu la agento estas planita sur la nodoj, kie la tuŝitaj podoj efektive ruliĝas. Grupo sen la DaemonSet tenas siajn malnovajn regulojn, kaj nenio en la ConfigMap montros tion.

La alternativo kaj ĝia kosto

La alia opcio konservas la podajn adresojn sendifektaj kaj instruas la vojon pri ili. La poda CIDR iras en la trafikajn selektilojn de Cloud VPN, kaj la surloka flanko bezonas revenan itineron por ĝi, por ke respondoj sciu kien iri. Tio konservas la podan identecon, kiun iuj sekurecaj modeloj volas, kaj ĝi larĝigas kaj la itineran kaj la fajroŝirmilan amplekson, kiun la alia flanko devas akcepti.

La interŝanĝo estas legebleco kontraŭ amplekso. Traduko igas la surlokan flankon vidi unu adreson por nodo, kio estas facila por permeslisto kaj kaŝas, kiu podo sendis kion. Neniu traduko tenas la podan adreson de fino al fino, kio estas pli bona por atribuo kaj pli malbona por ĉiu aparato en la vojo, kiu devas lerni novan intervalon. Neniu opcio estas difekto de Docker aŭ de la CNI; ambaŭ estas itineraj decidoj kun operacia fakturo. Elektu tiun, kies fakturon via teamo povas pagi, kaj skribu kial.

Kontrolu kaj restarigu

Rulu la saman kapton denove. Kapto je noda nivelo, kiu ankoraŭ presas la podan adreson post via redakto, signifas, ke la reguloj neniam ŝanĝiĝis, kion ajn diras la ConfigMap. La drato estas la fakto; ĉio alia estas konkludo.

Poste kontrolu la inversan direkton, ĉar duono de ĉi tiuj ŝanĝoj estas kontrolata nur elire. Konfirmu, ke la respondo atingas la nodon aŭ podon, kiu sendis la peton, kaj konfirmu, ke la aplikaĵo finiĝis anstataŭ nur ricevi SYN. Kapto montranta peton sen respondo estas itinera problemo sur la alia flanko, ne masquerade-problemo sur ĉi tiu.

Restarigo estas la antaŭa ConfigMap, aplikita same, kun la sama konfirmo, ke la agento restartis kaj la reguloj ŝanĝiĝis. Konservu la fontan adreson antaŭ kaj post por unu konata peto en la ŝanĝprotokolo, ĉar ĝuste tiu unu linio pruvas, ke la ŝanĝo faris tion, kion vi diris. La gvidilo de GKE pri la IP-masquerade-agento dokumentas la defaŭltojn kaj la ConfigMap-kampojn. Se la fonta adreso restas senŝanĝa post la dislokigo, la agento ne ruliĝas sur tiu nodo kaj neniu kvanto da YAML-redaktado riparos ĝin.