VPN-Client-IP in Kubernetes: bewahren oder per SNAT ersetzen?

Irgendwo zwischen Tunnel und Backend überlebt eine Client-Adresse oder wird ersetzt, und beide Ergebnisse sind vertretbar. Die Entscheidung gehört dem Eigentümer des empfangenden Dienstes, nicht dem, der das CNI installiert hat. Wenn Autorisierung pro Client, Kontingente oder Audit-Aufzeichnungen zählen, muss die Adresse jeden Hop überstehen. Wenn geteilte Zuordnung akzeptabel ist, entfernt Source-NAT ein Routingproblem, das Sie sonst für immer pflegen würden.

Wo die Client-Adresse tatsächlich verschwindet

Das Paket eines entfernten Clients erreicht den VPN-Pod mit einer inneren Quelle aus dem Tunnelbereich, etwa 10.90.0.42. Wenn der Pod dieses Paket in Richtung eines ClusterIP oder einer Pod-IP weiterleitet, können drei verschiedene Mechanismen die Quelle umschreiben. Die Masquerade-Regel des CNI auf dem Node deckt Traffic ab, den der Pod außerhalb des Cluster-CIDR sendet. Der conntrack-Eintrag von kube-proxy auf dem Ziel-Node deckt den Service-Hop selbst ab. Ein Proxy, der die Verbindung beendet, leitet das Paket gar nicht weiter, sodass die Quelle, die Sie am Ende sehen, dem Proxy gehört.

Jede lebt in einer anderen Schicht, weshalb ein einziges Service-Feld fast nie den ganzen Pfad repariert.

externalTrafficPolicy am öffentlichen Service des VPN entscheidet nur, was mit der äußeren Verbindung geschieht: Local behält die entfernte Adresse auf dem Node, der sie empfangen hat, während Cluster kube-proxy erlaubt, das Paket an einen anderen Node zu übergeben und es dort zu maskieren. Diese Einstellung regelt den Listener, den Ihre Clients ansprechen. Sie sagt nichts über das entschlüsselte Paket, das Ihr VPN-Prozess danach in den Cluster routet.

Drei Bedingungen, die die Debatte entscheiden

Ich stelle dieselben drei Fragen in derselben Reihenfolge, jedes Mal wenn das Thema aufkommt, weil die erste die Diskussion meist beendet. Beantworten Sie sie für die konkrete Workload und nicht für den Cluster als Ganzes. Zwei Cluster in einem Unternehmen können zu unterschiedlichen Antworten kommen, und beide können richtig sein.

Antwortet das Backend auf die erste Frage mit Ja und auf die zweite mit Nein, haben Sie Netzwerkarbeit zu erledigen statt ein Manifest zu bearbeiten. Sagt die dritte Zeile Proxy, hätte die Adresse nie überlebt, und das Gegenteil vorzugeben kostet eine Woche Paketmitschnitte.

Was der Preserve-Modus vom Netzwerk verlangt

Die Quelle zu bewahren bedeutet, dass der Ziel-Node den Traffic über ein aktives VPN-Gateway an 10.90.0.42 zurücksenden muss. Der VPN-Pool ist kein Cluster-CIDR, also routet ihn standardmäßig kein CNI für Sie. Sie fügen die Route selbst hinzu und stellen dann sicher, dass der Gateway-Endpunkt, auf den sie zeigt, eine Neuplanung übersteht.

ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2

Dieser nächste Hop ist eine Pod-Adresse, und Pod-Adressen wandern. Richten Sie die Route auf eine Service-VIP oder eine Node-Adresse, die fest bleibt, oder akzeptieren Sie, dass Sie nach jeder Eviction dem Gateway hinterherjagen. Reverse Path Filtering ist die andere Falle: Der strikte Modus verwirft Pakete, deren Rückweg nicht zur Schnittstelle passt, auf der sie ankamen, und das ist genau die Form eines bewahrten VPN-Flows.

Laxe Validierung ist oft der Unterschied zwischen einem funktionierenden Rückweg und Antworten, die nach dem Verlassen des Backends verschwinden. Masquerade-Regeln auf dem VPN-Node müssen außerdem den Tunnelbereich ausnehmen, sonst verlässt das weitergeleitete Paket den Pod mit dessen Adresse, egal welche Route Sie gebaut haben. Drücken Sie diese Ausnahme lieber in der Konfiguration des CNI selbst aus, statt iptables von Hand zu bearbeiten, denn der Agent schreibt seine Ketten beim Neustart neu, und Ihre handgeschriebene Regel überlebt genau bis zum nächsten Upgrade.

NetworkPolicy ist Zugriffskontrolle, nicht Routing. Eine Policy zu verschärfen wird nie eine Adresse wiederherstellen, die Masquerade bereits ersetzt hat.

Was SNAT kostet, und wie man es aufschreibt

Source-NAT zum Cluster ist das günstigere Design, und es ist kein Fehler. Das Backend sieht die Adresse des VPN-Pods oder Nodes, Logs stimmen überein, und es muss keine Rückroute existieren. Was Sie verlieren, ist die Fähigkeit, zwei Clients auf der Netzwerkschicht zu unterscheiden, also müssen Kontingente, Sperren und Audit-Spuren von woanders kommen.

Meist ist dieses Woanders die Anwendung: ein Session-Token, ein signierter Header oder eine PROXY-Protokollzeile, die ein Proxy schreibt, den Sie kontrollieren. Diese geben dem Empfänger eine Identität, der er nur vertrauen kann, wenn der Proxy im Pfad sitzt und der Header nicht von der Client-Seite gesetzt werden kann. Seien Sie im Runbook ausdrücklich, welche davon gilt, denn der nächste Ingenieur wird annehmen, die Adresse im Log sei der Client. Das ist sie nicht, und ein Vorfall genügt, um diese Annahme teuer zu machen.

Der Tausch bleibt ehrlich, solange er niedergeschrieben ist.

Prüfungen, die einen funktionierenden Pfad von einem glücklichen trennen

Testen Sie mit einer frischen Verbindung statt mit einer zwischengespeicherten, und testen Sie in beide Richtungen. Mehrere Fehler wirken nur sporadisch, weil neue Flows den umgeschriebenen Pfad nehmen.

Erfassen Sie das Tupel an drei Punkten während einer autorisierten Anfrage: direkt nach der Dekapsulierung, an der Egress-Schnittstelle des VPN-Pods und am Backend. Ändert sich die Quelle zwischen der zweiten und dritten Erfassung, sitzt die Ursache stromabwärts des Pods. Ändert sie sich vor der zweiten, übersetzt der Pod selbst.

Löschen Sie dann den VPN-Pod und wiederholen Sie den Test, während er neu geplant wird. Ein bewahrter Pfad, der bei einer Eviction bricht, ist unfertig, und ebenso eine NAT-Regel, die an eine nicht mehr existierende Adresse gebunden ist. Senden Sie schließlich eine Anfrage von einer Quelle, die Sie als abgelehnt erwarten, und bestätigen Sie, dass die Ablehnung von der Policy kommt und nicht von einer fehlenden Route.