A GKE podok elvesztették a VPN-hozzáférést az 1.14 után: két mód a forrás javítására

Az 1.14 után a podok saját címeikkel érik el a VPN-t, ezért a partnerek eldobják a válaszokat. Válassza ki a forrásszerződést, majd állítsa be hozzá a nonMasqueradeCIDRs-t.

Megérkezik egy frissítés, és a tunel túloldalán lévő rendszerek elkezdik elutasítani azt a pod-forgalmat, amely az előző héten még működött. A tunel áll, a tűzfal szabályai érintetlenek, és senki nem szerkesztette a partner házirendjét. Ami megváltozott, az láthatatlan a fürt naplóiban: az a forráscím, amelyet ezek a rendszerek most látnak. Ez a rés magyarázza azt a hibát, amely hálózatkiesésnek látszik és engedélyproblémaként viselkedik.

Két érvényes válasz létezik, és különböző helyekre vezetnek. A ConfigMap szerkesztése előtt válassza ki a forrásszerződést.

Az az alapértelmezett szabály, amelyet már nem telepítenek

A korábbi GKE-kiadások telepítettek egy masquerade-szabályt, amely a pod-forrásokat a csomópont címére cserélte, valahányszor a cél a 10.0.0.0/8 tartományon kívül esett. Az ezen a tartományon belüli VPN-átjáró a pod címét látta, míg a távolabbi dolgok úgy tűntek, mintha a csomóponttól jönnének. A partnerek engedélylistákat és visszatérési útvonalakat építettek a csomópontcímek köré, mert ezt figyelték meg.

A későbbi kiadások felhagytak ennek az alapértelmezett szabálynak a telepítésével. A pod-forgalom most pod-címekkel érkezik az átjáróhoz, bármi is a cél. Az a partner, amely csak csomópontcímeket irányít, eldobja a válaszokat, és egyik oldal sem ír hasznos naplóbejegyzést. A kérés akár a távoli oldalon is sikerülhet, és ez teszi a hibát nehezen követhetővé.

Semmi sem hibás egy halott komponens értelmében. A két oldal egyszerűen nem ért egyet abban, melyik forrás jogos.

Válassza ki azt a forrást, amelyet a partnernek látnia kell

A pod-címek megtartása a pontosabb szerződés. A távoli oldal látja a forgalmat előállító munkaterhelést, a naplózás őszinte marad, és a podonkénti házirend lehetővé válik. Az ár az, hogy a partnernek hordoznia kell a pod-előtagot.

A csomópontcímek megtartása az olcsóbb szerződés. Kapcsolja vissza a masquerade-et arra a célra, és a partner továbbra is egy általa már megbízott címet lát.

Egy kérdés dönt közöttük: mit tesz a partner a forrással? Ha naplóz, forrásonkénti házirendet alkalmaz vagy szűk visszatérési útvonalat kényszerít ki, a pod-címek indokolják a plusz konfigurációt. Ha csak válaszokat kell küldenie, a masquerade kevesebbe kerül, és semmit sem kér a másik oldaltól. Bármelyik választás védhető, amíg mindkét csapat leírja.

A harmadik lehetőség általában hiba: mindent masquerade-elni és elveszíteni a forgalom hozzárendelésének képességét. Kerülje el, hacsak a partner valóban nem tud mást irányítani, csak csomópontcímeket.

Irányítsa a nonMasqueradeCIDRs-t a valódi tartományokra

A GKE az ip-masq-agentet futtatja a kube-systemben, és annak ConfigMapje listázza azokat a célokat, amelyek kihagyják a masquerade-et. Ahhoz, hogy a pod-források a tunel felé megmaradjanak, a pod-tartomány, a csomópont alhálózata és a helyi előtag mind ebbe a listába tartozik.

Cserélje ki a mintaértékeket a saját fürtje tartományaival. Ne tegye a listát szélesebbé a követelménynél, mert minden további bejegyzés megváltoztatja, hogy egy másik cél mit lát. Az alábbi három bejegyzés a pod-hálózatot, a csomópont alhálózatát és a tunel mögötti előtagot képviseli:

nonMasqueradeCIDRs:
  - 10.12.0.0/14
  - 10.100.0.0/16
  - 172.16.0.0/12
masqLinkLocal: false
resyncInterval: 60s

A 0.0.0.0/0 bejegyzés kikapcsolja a masquerade-et minden célra, ami megváltoztatja, hogyan jelennek meg a nem kapcsolódó munkaterhelések a külső szolgáltatások előtt, és ritkán szándékos. Az ügynök a resyncInterval során újraolvassa a konfigurációját, így újraindításra általában nincs szükség. Ellenőrizze, hogy az ügynök podja fut-e, majd nyissa meg a benne csatolt fájlt. Éppen a fájl elolvasása bizonyítja, hogy a változás megérkezett.

A válaszútvonal a másik fél

A masquerade megváltoztatja a kérés forrását és semmi mást. Bármilyen forrást is kap a partner, még mindig kell egy útvonal visszafelé hozzá, és a fürtnek még mindig kell egy útvonal a partner felé.

Egy rögzítés a VPN-átjárón gyorsan elválasztja a két hibát. A pod-címekkel érkező és soha nem válaszolt csomagok azt jelentik, hogy a partnernek nincs útvonala a pod-előtaghoz. Az átjárón megjelenő, de a fürtöt soha el nem érő válasz azt jelenti, hogy a helyi útvonal hiányzik. Írja be a szerződést a jegybe mindenképp: melyik forrást látja a partner, és melyik előtag felé irányítja vissza.

Minden frissítés után ellenőrizze újra

A masquerade alapértelmezett viselkedése már egyszer megváltozott, és a csomópontkészlet cseréje visszaállíthatja a fürt hálózatát. Kezelje a forrásszerződést ellenőrizendő dologként, nem feltételezendőként.

Frissítés után küldjön egy kérést egy podból egy helyi szolgáltatásnak, és olvassa el a forrást, amelyet a partner naplóz. Ez az egyetlen megfigyelés elkap egy regressziót, amelyet egy tunel-státuszoldal szívesen jelentene egészségesnek. Megismétlése egy percbe kerül, és megspórol a következő embernek egy estét.

Kapcsolódó cikkek