GCP-VM med fleire NIC-ar: kvifor svar går ut gjennom feil grensesnitt

Å kople eit andre grensesnitt til ein Compute Engine-VM gir han ei anna nettverkstilkopling, ikkje ein symmetrisk returveg. Gjesten vel framleis eit grensesnitt og ei kjeldeadresse frå sine eigne ruter og reglar. Google Cloud nyttar deretter VPC-ruting og brannmurpolicy rundt grensesnittet pakken forlét gjennom. Når desse to avgjerdene er usamde, kjem førespurnader inn på éin NIC og svar går ut gjennom den andre, og filialen ser ein halvopen samtale.

Gå vegen i fem trinn, og usemja viser seg før du skriv ein policyregel.

Trinn 1: kartlegg NIC-ane i skya til einingane i gjesten

Skya namngir grensesnitta nic0, nic1 og så vidare, og gjesten ser einingnamn som ikkje treng å stemme. Løys opp kartlegginga frå metadataa til instansen eller frå den eigne adressa til grensesnittet før noko anna. Den vanlege standardruta frå DHCP er knytt til nic0, og difor vinn den internettvende vegen så ofte ved eit uhell. Å skrive policy mot eit gjette einingnamn er korleis ein korrekt regel hamnar på feil grensesnitt.

Noter adresser, einingnamn og VPC-en kvar einskild høyrer til. Det trekolonnekartet er inndata for kvart seinare trinn.

Trinn 2: namngi dei to rutingsavgjerdene

Den første avgjerda høyrer til gjesten: kva grensesnitt og kva kjeldeadresse for denne pakken. Den andre høyrer til skya: kva rutene i VPC-en og brannmurpolicyen tillèt rundt det grensesnittet.

Ei rute som er synleg i VPC-en som vender mot VPN, vert ikkje ei gjesterute som vel den NIC-en. Skyruta skildrar kva nettverket kan levere, medan gjesteruta avgjer kva pakken gjer.

Trinn 3: vel ein policy for returvegen

For eit lite, stabilt sett filialprefiks er eksplisitte gjestedestinasjonar den enklaste uttrykksforma: svar til desse prefiksa går ut gjennom grensesnittet som vender mot VPN. Når fleire tenester med vilje nyttar ulike lokale kjeldeadresser, held kjeldebaserte reglar som vel ein tabell per grensesnitt, kvart svar i rett samanheng. Dokumentasjonen om fleire grensesnitt skildrar NIC-namngjevinga og standardruteåferda som desse designa byggjer på.

Kvar tabell treng gyldige tilkopla ruter og neste hopp, samt destinasjonane han vil verte spurd om. Ein regel som peikar inn i ein ufullstendig tabell, er ikkje eit returvegdesign. Bruk den dokumenterte gatewayen for den NIC-en i staden for å finne opp ein Ethernet-gateway ut frå utsjånaden til subnettet.

Trinn 4: kontroller dei eigne filtera til gjesten

Kontroller kvar tenaren lyttar, og kva lokal kjelde svaret ber. Ein lyttar på alle adresser overstyrer ikkje rutingspolicyen, så binding til alle adresser endrar ingenting ved grensesnittet svaret går ut gjennom.

På Linux bør du gå gjennom validering av omvendt veg mot det tiltenkte designet. Å slå han av globalt som første trekk byter ein rutingsfeil mot ei spoofing-eksponering, og skjuler asymmetrien du prøvde å finne.

Trinn 5: test éin straum per veg

Stadfest ein tillaten filialførespurnad og ein urelatert internettførespurnad kvar for seg, kvar med sin verkelege kjelde og destinasjon. Fang på begge grensesnitta når du kan, fordi det nyttige beviset er kva grensesnitt som bar svaret. Stadfest deretter at policyen på skysida respekterte vegen du designa. Éin vellukka førespurnad beviser éin straum, ikkje eit symmetrisk design.

Hald dei to testane åtskilde i notata dine, sidan dei brukar ulike ruter og ulike brannmurreglar.

Kva ein ekstra NIC ikkje gir deg

Eit andre grensesnitt legg til ei nettverkstilkopling og endå ei adresse. Det legg ikkje til automatisk symmetrisk ruting og omgår ikkje brannmurpolicy. Å handsame det som ein rutingsreparasjon er grunnen til at multi-NIC-design samlar reglar som ingen seinare kan forklare.

Viss VM-en må videresende trafikk frå andre maskiner, planlegg den rutaren rolla eksplisitt, inkludert skyinnstillinga som tillèt videresending, og gjestefiltra som følgjer med.