GKE-Pods verloren nach 1.14 den VPN-Zugriff: zwei Wege, die Quelle zu reparieren

Nach 1.14 erreichen Pods die VPN mit ihren eigenen Adressen, deshalb verwerfen Peers Antworten. Wählen Sie den Quellvertrag und stellen Sie nonMasqueradeCIDRs passend ein.

Ein Upgrade wird eingespielt, und Systeme auf der anderen Seite des Tunnels beginnen, Pod-Traffic abzulehnen, der in der Vorwoche noch funktionierte. Der Tunnel steht, die Firewall-Regeln sind unangetastet, und niemand hat die Peer-Policy bearbeitet. Was sich geändert hat, ist in den Cluster-Logs unsichtbar: die Quelladresse, die diese Systeme jetzt sehen. Diese Lücke erklärt einen Fehler, der wie ein Netzausfall aussieht und sich wie ein Berechtigungsproblem verhält.

Es gibt zwei gültige Antworten, und sie führen an verschiedene Orte. Wählen Sie den Quellvertrag, bevor Sie eine ConfigMap bearbeiten.

Die Standardregel, die nicht mehr installiert wird

Frühere GKE-Versionen installierten eine Masquerade-Regel, die Pod-Quellen durch die Knotenadresse ersetzte, sobald das Ziel außerhalb von 10.0.0.0/8 lag. Ein VPN-Gateway innerhalb dieses Bereichs sah die Pod-Adresse, während alles weiter Entfernte aussah, als käme es vom Knoten. Peers bauten Allowlists und Rückrouten um Knotenadressen herum, weil sie genau das beobachteten.

Spätere Versionen installierten diese Standardregel nicht mehr. Pod-Traffic erreicht das Gateway nun mit Pod-Adressen, ganz gleich, wie das Ziel lautet. Ein Peer, der nur Knotenadressen routet, verwirft die Antworten, und keine Seite schreibt einen brauchbaren Logeintrag. Die Anfrage kann am fernen Ende sogar erfolgreich sein, und genau das macht den Fehler schwer zu verfolgen.

Nichts ist kaputt im Sinne einer toten Komponente. Die beiden Seiten sind sich schlicht uneinig darüber, welche Quelle legitim ist.

Wählen Sie die Quelle, die der Peer sehen soll

Pod-Adressen zu behalten ist der genauere Vertrag. Die Gegenseite sieht die Arbeitslast, die den Traffic erzeugt hat, die Protokollierung bleibt ehrlich, und Richtlinien pro Pod werden möglich. Der Preis ist, dass der Peer das Pod-Präfix mitführen muss.

Knotenadressen zu behalten ist der günstigere Vertrag. Schalten Sie die Maskierung für dieses Ziel wieder ein, und der Peer sieht weiterhin eine Adresse, der er bereits vertraut.

Eine Frage entscheidet zwischen beiden: Was macht der Peer mit der Quelle? Wenn er protokolliert, Richtlinien pro Quelle anwendet oder enges Rück-Routing erzwingt, rechtfertigen Pod-Adressen die zusätzliche Konfiguration. Wenn er nur Antworten senden muss, kostet Maskierung weniger und verlangt der Gegenseite nichts ab. Beide Entscheidungen sind vertretbar, solange beide Teams sie schriftlich festhalten.

Eine dritte Option ist meist ein Fehler: alles maskieren und die Fähigkeit verlieren, Traffic zuzuordnen. Vermeiden Sie sie, es sei denn, ein Peer kann wirklich nichts außer Knotenadressen routen.

Richten Sie nonMasqueradeCIDRs auf die echten Bereiche

GKE betreibt den ip-masq-agent in kube-system, und dessen ConfigMap listet die Ziele, die die Maskierung überspringen. Um Pod-Quellen in Richtung Tunnel zu bewahren, gehören der Pod-Bereich, das Knoten-Subnetz und das lokale Präfix alle in diese Liste.

Ersetzen Sie die Beispielwerte durch Bereiche aus Ihrem eigenen Cluster. Halten Sie die Liste nicht breiter, als die Anforderung es verlangt, denn jeder zusätzliche Eintrag ändert, was ein anderes Ziel sieht. Die drei Einträge unten stehen für das Pod-Netz, das Knoten-Subnetz und das Präfix hinter dem Tunnel:

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

Ein Eintrag 0.0.0.0/0 deaktiviert die Maskierung für alle Ziele, was verändert, wie unabhängige Arbeitslasten für externe Dienste erscheinen, und ist selten beabsichtigt. Der Agent liest seine Konfiguration bei resyncInterval neu ein, ein Neustart ist also meist unnötig. Prüfen Sie, ob der Agent-Pod läuft, und öffnen Sie dann die eingebundene Datei darin. Erst das Lesen dieser Datei beweist, dass die Änderung angekommen ist.

Der Rückweg ist die andere Hälfte

Die Maskierung ändert die Quelle der Anfrage und sonst nichts. Welche Quelle der Peer auch empfängt, er braucht weiterhin eine Route dorthin zurück, und das Cluster braucht weiterhin eine Route zum Peer.

Ein Mitschnitt am VPN-Gateway trennt die beiden Fehler schnell. Pakete, die mit Pod-Adressen ankommen und nie eine Antwort erhalten, bedeuten, dass dem Peer eine Route für das Pod-Präfix fehlt. Eine Antwort, die am Gateway erscheint, aber nie das Cluster erreicht, bedeutet, dass die lokale Route fehlt. Schreiben Sie den Vertrag so oder so ins Ticket: welche Quelle der Peer sieht und welches Präfix er zurückschickt.

Prüfen Sie nach jedem Upgrade erneut

Das Standardverhalten der Maskierung hat sich bereits einmal geändert, und der Austausch eines Knotenpools kann das Clusternetzwerk zurücksetzen. Behandeln Sie den Quellvertrag als etwas, das zu prüfen ist, nicht als etwas, das man annimmt.

Senden Sie nach einem Upgrade eine Anfrage von einem Pod an einen lokalen Dienst und lesen Sie die Quelle, die der Peer protokolliert. Diese eine Beobachtung fängt eine Regression, die eine Tunnel-Statusseite fröhlich als gesund melden würde. Die Wiederholung kostet eine Minute und erspart der nächsten Person einen Abend.

Ähnliche Artikel