GCP-VM med flera NIC: varför svar går ut genom fel gränssnitt

Att koppla ett andra gränssnitt till en Compute Engine-VM ger den en annan nätverksanslutning, inte en symmetrisk returväg. Gästen väljer fortfarande ett gränssnitt och en källadress från sina egna rutter och regler. Google Cloud tillämpar sedan VPC-routing och brandmurspolicy runt det gränssnitt paketet lämnade genom. När dessa två beslut inte stämmer överens anländer förfrågningar på en NIC och svar går ut genom den andra, och filialen ser ett halvöppet samtal.

Gå vägen i fem steg och oöverensstämmelsen visar sig innan du skriver en policyregel.

Steg 1: mappa molnets NIC:ar till gästens enheter

Molnet namnger gränssnitten nic0, nic1 och så vidare, och gästen ser enhetsnamn som inte behöver stämma. Lös upp mappningen från instansens metadata eller från gränssnittets egen adress innan något annat. Den vanliga standardrutten från DHCP är kopplad till nic0, och därför vinner den internetvända vägen så ofta av misstag. Att skriva policy mot ett gissat enhetsnamn är hur en korrekt regel hamnar på fel gränssnitt.

Notera adresser, enhetsnamn och den VPC som var och en tillhör. Den trekolumnskartan är indata för varje senare steg.

Steg 2: namnge de två routingbesluten

Det första beslutet tillhör gästen: vilket gränssnitt och vilken källadress för detta paket. Det andra tillhör molnet: vad VPC:ns rutter och brandmurspolicy tillåter runt det gränssnittet.

En rutt som syns i VPC:n som är vänd mot VPN blir inte en gästrutt som väljer den NIC:en. Molnrutten beskriver vad nätverket kan leverera, medan gästrutten avgör vad paketet gör.

Steg 3: välj en policy för returvägen

För en liten, stabil uppsättning filialprefix är explicita gästdestinationer det enklaste uttrycket: svar till dessa prefix går ut genom gränssnittet som är vänt mot VPN. När flera tjänster medvetet använder olika lokala källadresser håller källbaserade regler som väljer en tabell per gränssnitt varje svar i rätt sammanhang. Dokumentationen om flera gränssnitt beskriver NIC-namngivningen och standardruttens beteende som dessa konstruktioner bygger på.

Varje tabell behöver giltiga anslutna rutter och nästa hopp, plus de destinationer den kommer att tillfrågas om. En regel som pekar in i en ofullständig tabell är inte en returvägskonstruktion. Använd den dokumenterade gatewayen för den NIC:en i stället för att hitta på en Ethernet-gateway utifrån subnätets utseende.

Steg 4: kontrollera gästens egna filter

Kontrollera var servern lyssnar och vilken lokal källa svaret bär. En lyssnare på alla adresser åsidosätter inte routingpolicyn, så bindning till alla adresser ändrar ingenting vad gäller gränssnittet svaret går ut genom.

På Linux, granska valideringen av omvänd väg mot den avsedda konstruktionen. Att stänga av den globalt som första steg byter ett routingfel mot en spoofing-exponering och döljer den asymmetri du försökte hitta.

Steg 5: testa ett flöde per väg

Verifiera en tillåten filialförfrågan och en orelaterad internetförfrågan separat, var och en med sin riktiga källa och destination. Fånga på båda gränssnitten när du kan, eftersom det användbara beviset är vilket gränssnitt som bar svaret. Bekräfta sedan att policyn på molnsidan respekterade den väg du designade. En lyckad förfrågan bevisar ett flöde, inte en symmetrisk konstruktion.

Håll de två testerna åtskilda i dina anteckningar, eftersom de använder olika rutter och olika brandmursregler.

Vad en extra NIC inte ger dig

Ett andra gränssnitt lägger till en nätverksanslutning och ännu en adress. Det lägger inte till automatisk symmetrisk routing och kringgår inte brandmurspolicy. Att behandla det som en routingreparation är anledningen till att multi-NIC-konstruktioner samlar regler som ingen senare kan förklara.

Om VM:n måste vidarebefordra trafik från andra maskiner, planera den routerrollen uttryckligen, inklusive molninställningen som tillåter vidarebefordran och gästfiltren som hör till.