Pody GKE straciły dostęp do VPN po 1.14: dwa sposoby naprawy źródła

Po 1.14 pody docierają do VPN z własnymi adresami, więc peery odrzucają odpowiedzi. Wybierz kontrakt źródła, a następnie ustaw nonMasqueradeCIDRs zgodnie z nim.

Przychodzi aktualizacja i systemy po drugiej stronie tunelu zaczynają odrzucać ruch podów, który działał tydzień wcześniej. Tunel jest podniesiony, reguły zapory są nietknięte i nikt nie edytował polityki peera. To, co się zmieniło, jest niewidoczne w logach klastra: adres źródłowy, który te systemy teraz widzą. Ta luka wyjaśnia awarię, która wygląda jak awaria sieci, a zachowuje się jak problem z uprawnieniami.

Istnieją dwie poprawne odpowiedzi i prowadzą w różne miejsca. Wybierz kontrakt źródła, zanim edytujesz ConfigMap.

Domyślna reguła, której przestano instalować

Starsze wydania GKE instalowały regułę masquerade, która zastępowała źródła podów adresem węzła, ilekroć cel znajdował się poza 10.0.0.0/8. Brama VPN w tym zakresie widziała adres poda, a wszystko dalej wyglądało, jakby pochodziło z węzła. Peery budowały listy dozwolonych i trasy powrotne wokół adresów węzłów, bo to właśnie obserwowały.

Późniejsze wydania przestały instalować tę domyślną regułę. Ruch podów dociera teraz do bramy z adresami podów, niezależnie od celu. Peer, który trasuje tylko adresy węzłów, odrzuca odpowiedzi i żadna strona nie zapisuje użytecznego wpisu w logu. Żądanie może nawet się powieść na dalekim końcu, i to właśnie sprawia, że awaria jest trudna do prześledzenia.

Nic nie jest zepsute w sensie martwego komponentu. Obie strony po prostu nie zgadzają się, które źródło jest legalne.

Wybierz źródło, które peer powinien widzieć

Zachowanie adresów podów to dokładniejszy kontrakt. Druga strona widzi obciążenie, które wytworzyło ruch, logi pozostają uczciwe, a polityka dla każdego poda staje się możliwa. Ceną jest to, że peer musi nieść prefiks podów.

Zachowanie adresów węzłów to tańszy kontrakt. Włącz masquerade ponownie dla tego celu, a peer nadal widzi adres, któremu już ufa.

Jedno pytanie rozstrzyga między nimi: co peer robi ze źródłem? Jeśli loguje, stosuje politykę na źródło lub wymusza wąskie trasowanie powrotne, adresy podów uzasadniają dodatkową konfigurację. Jeśli musi tylko wysyłać odpowiedzi, masquerade kosztuje mniej i niczego nie wymaga od drugiej strony. Każdy wybór jest do obrony, dopóki oba zespoły go zapiszą.

Trzecia opcja jest zwykle błędem: maskować wszystko i stracić możliwość przypisania ruchu. Unikaj jej, chyba że peer naprawdę nie potrafi trasować niczego poza adresami węzłów.

Skieruj nonMasqueradeCIDRs na rzeczywiste zakresy

GKE uruchamia ip-masq-agent w kube-system, a jego ConfigMap wymienia cele, które pomijają masquerade. Aby zachować źródła podów w stronę tunelu, zakres podów, podsieć węzłów i prefiks lokalny wszystkie należą do tej listy.

Zastąp przykładowe wartości zakresami z własnego klastra. Nie rób listy szerszej, niż wymaga potrzeba, bo każdy dodatkowy wpis zmienia to, co widzi inny cel. Trzy wpisy poniżej oznaczają sieć podów, podsieć węzłów i prefiks za tunelem:

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

Wpis 0.0.0.0/0 wyłącza masquerade dla wszystkich celów, co zmienia sposób, w jaki niepowiązane obciążenia wyglądają dla usług zewnętrznych, i rzadko jest zamierzone. Agent ponownie odczytuje konfigurację przy resyncInterval, więc restart zwykle nie jest potrzebny. Sprawdź, czy pod agenta działa, a następnie otwórz zamontowany w nim plik. To odczytanie tego pliku dowodzi, że zmiana dotarła.

Ścieżka powrotna to druga połowa

Masquerade zmienia źródło żądania i nic więcej. Jakiekolwiek źródło otrzyma peer, nadal potrzebuje trasy z powrotem do niego, a klaster nadal potrzebuje trasy w stronę peera.

Przechwycenie na bramie VPN szybko rozdziela obie awarie. Pakiety, które przychodzą z adresami podów i nigdy nie dostają odpowiedzi, oznaczają, że peerowi brakuje trasy dla prefiksu podów. Odpowiedź, która pojawia się na bramie, ale nigdy nie dociera do klastra, oznacza, że brakuje trasy lokalnej. W obu przypadkach zapisz kontrakt w zgłoszeniu: jakie źródło widzi peer i na jaki prefiks trasuje odpowiedź.

Sprawdzaj ponownie po każdej aktualizacji

Domyślne zachowanie masquerade zmieniło się już raz, a wymiana puli węzłów może zresetować sieć klastra. Traktuj kontrakt źródła jako coś do zweryfikowania, a nie do założenia.

Po aktualizacji wyślij jedno żądanie z poda do usługi lokalnej i odczytaj źródło, które loguje peer. Ta jedna obserwacja łapie regresję, którą strona statusu tunelu chętnie zgłosi jako zdrową. Powtórzenie kosztuje minutę i oszczędza następnej osobie wieczór.

Powiązane artykuły