GCP-VM mit mehreren NICs: Warum Antworten über die falsche Schnittstelle verlassen

Das Anhängen einer zweiten Schnittstelle an eine Compute Engine-VM gibt ihr eine weitere Netzwerkanbindung, keinen symmetrischen Rückweg. Der Gast wählt weiterhin eine Schnittstelle und eine Quelladresse aus seinen eigenen Routen und Regeln. Google Cloud wendet dann VPC-Routing und Firewall-Richtlinie um diejenige Schnittstelle an, über die das Paket das Netz verlassen hat. Wenn diese beiden Entscheidungen nicht übereinstimmen, kommen Anfragen auf der einen NIC an und Antworten verlassen die andere, und die Filiale sieht eine halb offene Verbindung.

Gehen Sie den Weg in fünf Schritten, und die Unstimmigkeit zeigt sich, bevor Sie eine Richtlinienregel schreiben.

Schritt 1: Cloud-NICs den Geräten im Gast zuordnen

Die Cloud benennt Schnittstellen nic0, nic1 und so weiter, und der Gast sieht Gerätenamen, die nicht übereinstimmen müssen. Klären Sie die Zuordnung aus den Instanzmetadaten oder aus der eigenen Adresse der Schnittstelle, bevor Sie etwas anderes tun. Die gewöhnliche Standardroute von DHCP ist nic0 zugeordnet, weshalb der internetseitige Weg so oft versehentlich gewinnt. Eine Richtlinie gegen einen geratenen Gerätenamen zu schreiben, ist der Weg, auf dem eine korrekte Regel auf der falschen Schnittstelle landet.

Notieren Sie Adressen, Gerätenamen und die VPC, zu der jedes gehört. Diese Tabelle mit drei Spalten ist die Eingabe für jeden weiteren Schritt.

Schritt 2: die beiden Routing-Entscheidungen benennen

Die erste Entscheidung gehört dem Gast: welche Schnittstelle und welche Quelladresse für dieses Paket. Die zweite gehört der Cloud: was die Routen der VPC und die Firewall-Richtlinie um diese Schnittstelle herum zulassen.

Eine in der VPN-zugewandten VPC sichtbare Route wird keine Gastroute, die diese NIC auswählt. Die Cloud-Route beschreibt, was das Netz liefern kann, während die Gastroute entscheidet, was das Paket tut.

Schritt 3: eine Rückweg-Richtlinie wählen

Für einen kleinen, stabilen Satz von Standort-Präfixen sind ausdrückliche Zielrouten im Gast der einfachste Ausdruck: Antworten an diese Präfixe verlassen die VPN-zugewandte Schnittstelle. Wenn mehrere Dienste absichtlich unterschiedliche lokale Quelladressen verwenden, halten quellenbasierte Regeln, die pro Schnittstelle eine Tabelle auswählen, jede Antwort im richtigen Kontext. Die Dokumentation zu mehreren Schnittstellen beschreibt die NIC-Benennung und das Standardroutenverhalten, auf das sich diese Entwürfe stützen.

Jede Tabelle braucht gültige verbundene Routen und nächste Hops sowie die Ziele, nach denen sie gefragt wird. Eine Regel, die in eine unvollständige Tabelle zeigt, ist kein Rückweg-Entwurf. Verwenden Sie das dokumentierte Gateway für diese NIC, statt aus dem Aussehen des Subnetzes ein Ethernet-Gateway zu erfinden.

Schritt 4: die eigenen Filter des Gastes prüfen

Prüfen Sie, wo der Server lauscht und welche lokale Quelle die Antwort trägt. Ein Listener auf allen Adressen setzt die Routing-Richtlinie nicht außer Kraft, daher ändert das Binden an alle Adressen nichts an der Schnittstelle, über die die Antwort hinausgeht.

Prüfen Sie unter Linux die Rückwegvalidierung gegen den beabsichtigten Entwurf. Sie global als ersten Schritt abzuschalten tauscht einen Routingfehler gegen eine Spoofing-Angriffsfläche und verdeckt die Asymmetrie, die Sie suchten.

Schritt 5: einen Fluss pro Weg testen

Prüfen Sie eine erlaubte Standortanfrage und eine unabhängige Internetanfrage getrennt, jede mit ihrer echten Quelle und ihrem Ziel. Zeichnen Sie auf beiden Schnittstellen auf, wenn Sie können, denn der nützliche Beweis ist, welche Schnittstelle die Antwort trug. Bestätigen Sie dann, dass die Richtlinie auf Cloud-Seite den von Ihnen entworfenen Weg eingehalten hat. Eine erfolgreiche Anfrage beweist einen Fluss, nicht einen symmetrischen Entwurf.

Halten Sie die beiden Tests in Ihren Notizen getrennt, da sie unterschiedliche Routen und unterschiedliche Firewall-Regeln nutzen.

Was eine zweite NIC Ihnen nicht gibt

Eine zweite Schnittstelle fügt eine Netzwerkanbindung und eine weitere Adresse hinzu. Sie fügt kein automatisches symmetrisches Routing hinzu und umgeht keine Firewall-Richtlinie. Sie als Routing-Korrektur zu behandeln ist der Grund, warum Multi-NIC-Entwürfe Regeln anhäufen, die später niemand erklären kann.

Wenn die VM den Verkehr anderer Maschinen weiterleiten muss, planen Sie diese Routerrolle ausdrücklich ein, einschließlich der Cloud-Einstellung, die Weiterleitung erlaubt, und der zugehörigen Gastfilter.