Podurile GKE au pierdut accesul la VPN după 1.14: două moduri de a repara sursa

După 1.14 podurile ajung la VPN cu propriile adrese, așa că partenerii aruncă răspunsurile. Alegeți contractul de sursă, apoi setați nonMasqueradeCIDRs în consecință.

Sosește o actualizare, iar sistemele de cealaltă parte a tunelului încep să respingă traficul podurilor care funcționa săptămâna precedentă. Tunelul este activ, regulile firewall-ului sunt neatinse și nimeni nu a editat politica partenerului. Ce s-a schimbat este invizibil în jurnalele clusterului: adresa de sursă pe care aceste sisteme o văd acum. Acest decalaj explică o defecțiune care arată ca o cădere de rețea și se comportă ca o problemă de permisiuni.

Există două răspunsuri valabile și ele duc în locuri diferite. Alegeți contractul de sursă înainte de a edita un ConfigMap.

Regula implicită care nu mai este instalată

Versiunile anterioare de GKE instalau o regulă de masquerade care înlocuia sursele podurilor cu adresa nodului ori de câte ori destinația se afla în afara 10.0.0.0/8. O poartă VPN din acel interval vedea adresa podului, în timp ce orice se afla mai departe părea să vină de la nod. Partenerii au construit liste de permisiuni și rute de retur în jurul adreselor nodurilor pentru că asta observau.

Versiunile ulterioare au încetat să instaleze acea regulă implicită. Traficul podurilor ajunge acum la poartă cu adrese de pod, indiferent de destinație. Un partener care rutează doar adrese de nod aruncă răspunsurile, iar niciuna dintre părți nu scrie o intrare de jurnal utilă. Cererea poate chiar reuși la capătul îndepărtat, și exact asta face defecțiunea greu de urmărit.

Nimic nu este stricat în sensul unei componente moarte. Cele două părți pur și simplu nu sunt de acord care sursă este legitimă.

Alegeți sursa pe care partenerul ar trebui să o vadă

Păstrarea adreselor de pod este contractul mai precis. Partea îndepărtată vede încărcarea de lucru care a produs traficul, jurnalele rămân oneste, iar politica per pod devine posibilă. Prețul este că partenerul trebuie să poarte prefixul podurilor.

Păstrarea adreselor de nod este contractul mai ieftin. Reactivați masquerade pentru acea destinație și partenerul continuă să vadă o adresă în care are deja încredere.

O singură întrebare decide între ele: ce face partenerul cu sursa? Dacă înregistrează, aplică politică per sursă sau impune rutare de retur îngustă, adresele de pod justifică configurația suplimentară. Dacă trebuie doar să trimită răspunsuri, masquerade costă mai puțin și nu cere nimic celeilalte părți. Ambele alegeri sunt apărabile atâta timp cât ambele echipe le notează.

O a treia opțiune este de obicei o greșeală: masquerade la tot și pierderea capacității de a atribui traficul. Evitați-o, dacă un partener chiar nu poate ruta altceva decât adrese de nod.

Îndreptați nonMasqueradeCIDRs către intervalele reale

GKE rulează ip-masq-agent în kube-system, iar ConfigMap-ul său listează destinațiile care ocolesc masquerade. Pentru a păstra sursele podurilor spre tunel, intervalul podurilor, subrețeaua nodului și prefixul local fac toate parte din acea listă.

Înlocuiți valorile de exemplu cu intervale din propriul cluster. Nu faceți lista mai largă decât cere cerința, pentru că fiecare intrare suplimentară schimbă ce vede o altă destinație. Cele trei intrări de mai jos reprezintă rețeaua podurilor, subrețeaua nodului și prefixul din spatele tunelului:

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

O intrare 0.0.0.0/0 dezactivează masquerade pentru toate destinațiile, ceea ce schimbă felul în care încărcările de lucru nelegate apar serviciilor externe și rareori este intenționat. Agentul recitește configurația la resyncInterval, așa că o repornire nu este de obicei necesară. Verificați dacă podul agentului rulează, apoi deschideți fișierul montat în el. Citirea acelui fișier este ce dovedește că modificarea a ajuns.

Calea de retur este cealaltă jumătate

Masquerade schimbă sursa cererii și nimic altceva. Orice sursă ar primi partenerul, tot are nevoie de o rută înapoi la ea, iar clusterul tot are nevoie de o rută către partener.

O captură pe poarta VPN separă rapid cele două defecțiuni. Pachetele care sosesc cu adrese de pod și nu primesc niciodată răspuns înseamnă că partenerului îi lipsește o rută pentru prefixul podurilor. Un răspuns care apare pe poartă dar nu ajunge niciodată la cluster înseamnă că lipsește ruta locală. Scrieți contractul în tichet în orice caz: ce sursă vede partenerul și către ce prefix rutează răspunsul.

Verificați din nou după fiecare actualizare

Comportamentul implicit al masquerade s-a schimbat deja o dată, iar înlocuirea unui pool de noduri poate reseta rețeaua clusterului. Tratați contractul de sursă ca ceva de verificat, nu de presupus.

După o actualizare, trimiteți o cerere dintr-un pod către un serviciu local și citiți sursa pe care o înregistrează partenerul. Acea singură observație prinde o regresie pe care o pagină de stare a tunelului ar raporta bucuroasă ca fiind sănătoasă. Repetarea costă un minut și economisește o seară pentru următoarea persoană.

Articole similare