GCP-VM med flere NIC'er: hvorfor svar går ud ad den forkerte grænseflade

At vedhæfte en anden grænseflade til en Compute Engine-VM giver den en ekstra netværkstilknytning, ikke en symmetrisk returvej. Gæsten vælger stadig en grænseflade og en kildeadresse ud fra sine egne ruter og regler. Google Cloud anvender derefter VPC-routing og firewallpolitik omkring den grænseflade, pakken forlod via. Når de to beslutninger er uenige, ankommer anmodninger på den ene NIC, og svar går ud ad den anden, og branchen ser en halvåben samtale.

Gå vejen i fem trin, og uenigheden viser sig, før du skriver en politikregel.

Trin 1: knyt skyens NIC'er til gæstens enheder

Skyen navngiver grænseflader nic0, nic1 og så videre, og gæsten ser enhedsnavne, som ikke behøver at passe. Afklar koblingen fra instansens metadata eller fra grænsefladens egen adresse før alt andet. Den almindelige standardrute fra DHCP er knyttet til nic0, og derfor vinder den internetvendte vej så ofte ved et uheld. At skrive politik ud fra et gættet enhedsnavn er måden, hvorpå en korrekt regel ender på den forkerte grænseflade.

Notér adresser, enhedsnavne og den VPC, som hver enkelt hører til. Det kort med tre kolonner er input til hvert senere trin.

Trin 2: navngiv de to rutningsbeslutninger

Den første beslutning tilhører gæsten: hvilken grænseflade og hvilken kildeadresse til denne pakke. Den anden tilhører skyen: hvad VPC'ens ruter og firewallpolitik tillader omkring den grænseflade.

En rute, der er synlig i den VPN-vendte VPC, bliver ikke en gæsterute, som vælger den NIC. Skyruten beskriver, hvad netværket kan levere, mens gæsteruten afgør, hvad pakken gør.

Trin 3: vælg en politik for returvejen

For et lille, stabilt sæt branch-præfikser er eksplicitte gæstedestinationer den enkleste udtryksform: svar til disse præfikser går ud ad den VPN-vendte grænseflade. Når flere tjenester bevidst bruger forskellige lokale kildeadresser, holder kildedrevne regler, som vælger en tabel per grænseflade, hvert svar i den rigtige sammenhæng. Dokumentationen om flere grænseflader beskriver den NIC-navngivning og standardruteadfærd, som disse design bygger på.

Hver tabel kræver gyldige forbundne ruter og næste hop samt de destinationer, der vil blive spurgt efter. En regel, der peger ind i en ufuldstændig tabel, er ikke et returvejsdesign. Brug den dokumenterede gateway til den NIC i stedet for at opfinde en Ethernet-gateway ud fra undernetets udseende.

Trin 4: kontrollér gæstens egne filtre

Kontrollér, hvor serveren lytter, og hvilken lokal kilde svaret bærer. En lytter, der accepterer alle adresser, tilsidesætter ikke rutningspolitikken, så binding til alle adresser ændrer intet ved den grænseflade, svaret går ud ad.

På Linux skal du gennemgå validering af omvendt vej mod det tilsigtede design. At slå den fra globalt som første skridt bytter en rutningsfejl for en spoofing-eksponering og skjuler den asymmetri, du forsøgte at finde.

Trin 5: test én strøm per vej

Bekræft en tilladt branch-anmodning og en urelateret internetanmodning hver for sig, hver med sin rigtige kilde og destination. Fang på begge grænseflader, når du kan, fordi det nyttige bevis er, hvilken grænseflade der bar svaret. Bekræft derefter, at politikken på cloud-siden respekterede den vej, du designede. Én vellykket anmodning beviser én strøm, ikke et symmetrisk design.

Hold de to tests adskilt i dine noter, da de bruger forskellige ruter og forskellige firewallregler.

Hvad en ekstra NIC ikke giver dig

En anden grænseflade tilføjer en netværkstilknytning og endnu en adresse. Den tilføjer ikke automatisk symmetrisk routing og omgår ikke firewallpolitik. At behandle den som en rutningsrettelse er grunden til, at multi-NIC-design ophober regler, som ingen senere kan forklare.

Hvis VM'en skal videresende andre maskiners trafik, skal du planlægge den routerrolle eksplicit, inklusive den cloudindstilling, der tillader videresendelse, og de gæstefiltre, der hører til.