VM GCP z več NIC: zakaj odgovori odhajajo skozi napačen vmesnik

Pripajanje drugega vmesnika na VM v Compute Engine mu daje še eno omrežno povezavo, ne simetrične povratne poti. Gost še vedno izbira vmesnik in izvorni naslov iz svojih lastnih poti in pravil. Google Cloud nato uporabi usmerjanje v VPC in politiko požarnega zidu okoli vmesnika, skozi katerega je paket odšel. Ko se ti dve odločitvi ne ujemata, zahteve prihajajo na en NIC, odgovori pa odhajajo skozi drugega, in podružnica vidi napol odprt pogovor.

Prehodite pot v petih korakih in neskladje se bo pokazalo, preden napišete pravilo politike.

Korak 1: povežite NIC v oblaku z napravami gosta

Oblak poimenuje vmesnike nic0, nic1 in tako naprej, gost pa vidi imena naprav, ki se jim ni treba ujemati. Razrešite preslikavo iz metapodatkov instance ali iz lastnega naslova vmesnika pred vsem drugim. Običajna privzeta pot, ki jo zagotavlja DHCP, je povezana z nic0, zato pot proti internetu tako pogosto zmaga po naključju. Pisanje politike glede na ugibano ime naprave je način, kako pravilno pravilo pristane na napačnem vmesniku.

Zapišite naslove, imena naprav in VPC, ki ji vsak pripada. Ta tabela s tremi stolpci je vhod za vsak naslednji korak.

Korak 2: poimenujte dve odločitvi usmerjanja

Prva odločitev pripada gostu: kateri vmesnik in kateri izvorni naslov za ta paket. Druga pripada oblaku: kaj dovoljujejo poti v VPC in politika požarnega zidu okoli tega vmesnika.

Pot, vidna v VPC, obrnjeni proti VPN, ne postane gostova pot, ki bi izbrala ta NIC. Pot v oblaku opisuje, kaj lahko omrežje dostavi, medtem ko gostova pot odloča, kaj paket naredi.

Korak 3: izberite politiko povratne poti

Za majhen, stabilen nabor prefiksov podružnice so izrecne ciljne poti v gostu najpreprostejši izraz: odgovori na te prefikse odhajajo skozi vmesnik, obrnjen proti VPN. Ko več storitev namerno uporablja različne lokalne izvorne naslove, pravila na podlagi vira, ki izbirajo tabelo za vsak vmesnik, ohranijo vsak odgovor v pravem kontekstu. Dokumentacija o več vmesnikih opisuje poimenovanje NIC in vedenje privzete poti, na katerih temeljijo te zasnove.

Vsaka tabela potrebuje veljavne povezane poti in naslednje skoke ter cilje, po katerih bo vprašana. Pravilo, ki kaže v nepopolno tabelo, ni zasnova povratne poti. Uporabite dokumentirana vrata za ta NIC, namesto da bi iz videza podomrežja izmislili Ethernet vrata.

Korak 4: preverite gostove lastne filtre

Preverite, kje strežnik posluša in kateri lokalni vir nosi odgovor. Poslušalec na vseh naslovih ne razveljavi usmerjevalne politike, zato vezava na vse naslove ne spremeni ničesar glede vmesnika, skozi katerega odhaja odgovor.

V Linuxu preglejte validacijo obrnjene poti glede na predvideno zasnovo. Če jo kot prvi korak globalno izklopite, zamenjate napako usmerjanja za izpostavljenost ponarejanju in skrijete asimetrijo, ki ste jo poskušali najti.

Korak 5: preizkusite en tok na pot

Ločeno preverite dovoljeno zahtevo podružnice in nepovezano internetno zahtevo, vsako z njenim resničnim virom in ciljem. Zajemite na obeh vmesnikih, ko lahko, ker je koristen dokaz, kateri vmesnik je nosil odgovor. Nato potrdite, da je politika na strani oblaka spoštovala pot, ki ste jo zasnovali. Ena uspešna zahteva dokazuje en tok, ne simetrične zasnove.

Oba preizkusa hranite ločeno v svojih zapiskih, saj uporabljata različne poti in različna pravila požarnega zidu.

Česa vam drugi NIC ne da

Drugi vmesnik doda omrežno povezavo in še en naslov. Ne doda samodejnega simetričnega usmerjanja in ne obide politike požarnega zidu. Obravnavanje kot popravka usmerjanja je razlog, da zasnove z več NIC kopičijo pravila, ki jih pozneje nihče ne zna razložiti.

Če mora VM posredovati promet drugih strojev, to vlogo usmerjevalnika načrtujte izrecno, vključno z nastavitvijo v oblaku, ki dovoljuje posredovanje, in pripadajočimi filtri gosta.