GCP-VM met meerdere NIC's: waarom antwoorden via de verkeerde interface vertrekken

Een tweede interface aan een Compute Engine-VM koppelen geeft die een extra netwerkaansluiting, geen symmetrische retourroute. De gast kiest nog steeds een interface en een bronadres uit zijn eigen routes en regels. Google Cloud past daarna VPC-routing en firewallbeleid toe rond de interface waar het pakket is vertrokken. Als die twee beslissingen niet overeenkomen, komen verzoeken binnen op de ene NIC en vertrekken antwoorden via de andere, en het filiaal ziet een halfopen gesprek.

Loop het pad in vijf stappen en de tegenstrijdigheid komt naar voren voordat u een beleidsregel schrijft.

Stap 1: koppel cloud-NIC's aan gastapparaten

De cloud noemt interfaces nic0, nic1 enzovoort, en de gast ziet apparaatnamen die niet hoeven te kloppen. Los de koppeling op uit de metadata van de instantie of uit het eigen adres van de interface voordat u iets anders doet. De gewone standaardroute van DHCP hoort bij nic0, waardoor het internetpad zo vaak per ongeluk wint. Beleid schrijven op een geraden apparaatnaam is hoe een correcte regel op de verkeerde interface belandt.

Noteer adressen, apparaatnamen en de VPC waartoe elk behoort. Die tabel met drie kolommen is de invoer voor elke volgende stap.

Stap 2: benoem de twee routingbeslissingen

De eerste beslissing hoort bij de gast: welke interface en welk bronadres voor dit pakket. De tweede hoort bij de cloud: wat de routes van de VPC en het firewallbeleid rond die interface toestaan.

Een route die zichtbaar is in de op VPN gerichte VPC wordt geen gastroute die die NIC kiest. De cloudroute beschrijft wat het netwerk kan leveren, terwijl de gastroute bepaalt wat het pakket doet.

Stap 3: kies een beleid voor de retourroute

Voor een kleine, stabiele set filiaalprefixen zijn expliciete gastbestemmingen de eenvoudigste uitdrukking: antwoorden op die prefixen vertrekken via de op VPN gerichte interface. Wanneer meerdere diensten bewust verschillende lokale bronadressen gebruiken, houden op de bron gebaseerde regels die per interface een tabel kiezen elk antwoord in de juiste context. De documentatie over meerdere interfaces beschrijft de NIC-naamgeving en het standaardroutegedrag waarop deze ontwerpen steunen.

Elke tabel heeft geldige verbonden routes en volgende hops nodig, plus de bestemmingen waarom gevraagd zal worden. Een regel die naar een onvolledige tabel wijst, is geen retourroute-ontwerp. Gebruik de gedocumenteerde gateway voor die NIC in plaats van een Ethernet-gateway te verzinnen op basis van het uiterlijk van het subnet.

Stap 4: controleer de eigen filters van de gast

Controleer waar de server luistert en welke lokale bron het antwoord draagt. Een luisteraar op alle adressen overrulet het routingbeleid niet, dus binden aan alle adressen verandert niets aan de interface waarlangs het antwoord vertrekt.

Op Linux bekijkt u de validatie van de omgekeerde route tegen het bedoelde ontwerp. Die globaal uitschakelen als eerste stap ruilt een routingfout in voor blootstelling aan spoofing, en verbergt de asymmetrie die u probeerde te vinden.

Stap 5: test één stroom per pad

Controleer een toegestaan filiaalverzoek en een ongerelateerd internetverzoek afzonderlijk, elk met hun echte bron en bestemming. Leg op beide interfaces vast wanneer u kunt, want het nuttige bewijs is welke interface het antwoord droeg. Bevestig daarna dat het beleid aan de cloudkant het pad heeft gerespecteerd dat u hebt ontworpen. Eén geslaagd verzoek bewijst één stroom, geen symmetrisch ontwerp.

Houd de twee tests gescheiden in uw notities, omdat ze verschillende routes en verschillende firewallregels gebruiken.

Wat een tweede NIC u niet geeft

Een tweede interface voegt een netwerkaansluiting en nog een adres toe. Het voegt geen automatische symmetrische routing toe en omzeilt geen firewallbeleid. Het als een routingoplossing behandelen is de reden dat multi-NIC-ontwerpen regels opstapelen die niemand later kan uitleggen.

Als de VM verkeer van andere machines moet doorsturen, plan die routerrol dan expliciet, inclusief de cloudinstelling die doorsturen toestaat en de gastfilters die daarbij horen.