GCP-VM med flere NIC-er: hvorfor svar går ut gjennom feil grensesnitt

Å koble et andre grensesnitt til en Compute Engine-VM gir den en annen nettverkstilkobling, ikke en symmetrisk returvei. Gjesten velger fortsatt et grensesnitt og en kildeadresse fra sine egne ruter og regler. Google Cloud bruker deretter VPC-ruting og brannmurpolicy rundt grensesnittet pakken forlot gjennom. Når disse to beslutningene er uenige, ankommer forespørsler på én NIC og svar går ut gjennom den andre, og filialen ser en halvåpen samtale.

Gå veien i fem trinn, og uenigheten viser seg før du skriver en policyregel.

Trinn 1: kartlegg skyens NIC-er til gjestens enheter

Skyen navngir grensesnittene nic0, nic1 og så videre, og gjesten ser enhetsnavn som ikke trenger å stemme. Løs opp kartleggingen fra instansens metadata eller fra grensesnittets egen adresse før noe annet. Den vanlige standardruten fra DHCP er knyttet til nic0, og derfor vinner den internettvendte veien så ofte ved uhell. Å skrive policy mot et gjettet enhetsnavn er hvordan en korrekt regel havner på feil grensesnitt.

Noter adresser, enhetsnavn og VPC-en hver enkelt tilhører. Det trekolonners kartet er inndata for hvert senere trinn.

Trinn 2: navngi de to rutingsbeslutningene

Den første beslutningen tilhører gjesten: hvilket grensesnitt og hvilken kildeadresse for denne pakken. Den andre tilhører skyen: hva VPC-ens ruter og brannmurpolicy tillater rundt det grensesnittet.

En rute som er synlig i VPC-en som vender mot VPN, blir ikke en gjesterute som velger den NIC-en. Skyruten beskriver hva nettverket kan levere, mens gjesteruten avgjør hva pakken gjør.

Trinn 3: velg en policy for returveien

For et lite, stabilt sett filialprefikser er eksplisitte gjestedestinasjoner den enkleste uttrykksformen: svar til disse prefiksene går ut gjennom grensesnittet som vender mot VPN. Når flere tjenester bevisst bruker forskjellige lokale kildeadresser, holder kildebaserte regler som velger en tabell per grensesnitt, hvert svar i riktig kontekst. Dokumentasjonen om flere grensesnitt beskriver NIC-navngivingen og standardruteadferden som disse designene bygger på.

Hver tabell trenger gyldige tilkoblede ruter og neste hopp, samt destinasjonene den vil bli spurt om. En regel som peker inn i en ufullstendig tabell, er ikke et returveidesign. Bruk den dokumenterte gatewayen for den NIC-en i stedet for å finne opp en Ethernet-gateway ut fra subnettets utseende.

Trinn 4: kontroller gjestens egne filtre

Kontroller hvor serveren lytter, og hvilken lokal kilde svaret bærer. En lytter på alle adresser overstyrer ikke rutingspolicyen, så binding til alle adresser endrer ingenting ved grensesnittet svaret går ut gjennom.

På Linux bør du gjennomgå validering av omvendt vei mot det tiltenkte designet. Å slå den av globalt som første trekk bytter en rutingsfeil mot en spoofing-eksponering, og skjuler asymmetrien du prøvde å finne.

Trinn 5: test én strøm per vei

Bekreft en tillatt filialforespørsel og en urelatert internettforespørsel hver for seg, hver med sin virkelige kilde og destinasjon. Fang på begge grensesnittene når du kan, fordi det nyttige beviset er hvilket grensesnitt som bar svaret. Bekreft deretter at policyen på skysiden respekterte veien du designet. Én vellykket forespørsel beviser én strøm, ikke et symmetrisk design.

Hold de to testene atskilt i notatene dine, siden de bruker forskjellige ruter og forskjellige brannmurregler.

Hva en ekstra NIC ikke gir deg

Et andre grensesnitt legger til en nettverkstilkobling og enda en adresse. Det legger ikke til automatisk symmetrisk ruting og omgår ikke brannmurpolicy. Å behandle det som en rutingsreparasjon er grunnen til at multi-NIC-design samler regler som ingen senere kan forklare.

Hvis VM-en må videresende trafikk fra andre maskiner, planlegg den ruteren rolle eksplisitt, inkludert skyinnstillingen som tillater videresending, og gjestefiltrene som følger med.