GCP VM s više NIC-ova: zašto odgovori izlaze kroz pogrešno sučelje

Dodavanje drugog sučelja VM-u na Compute Engineu daje mu još jedan mrežni priključak, a ne simetričan povratni put. Gost i dalje bira sučelje i izvornu adresu iz vlastitih ruta i pravila. Google Cloud zatim primjenjuje usmjeravanje u VPC-u i politiku vatrozida oko onog sučelja kojim je paket izašao. Kad se te dvije odluke razilaze, zahtjevi dolaze na jedan NIC, a odgovori izlaze kroz drugi, pa podružnica vidi napola otvoren razgovor.

Prođite put u pet koraka i nesklad će se pokazati prije nego što napišete pravilo politike.

Korak 1: povežite oblake NIC-ove s uređajima u gostu

Oblak naziva sučelja nic0, nic1 i tako dalje, a gost vidi nazive uređaja koji se ne moraju podudarati. Razriješite mapiranje iz metapodataka instance ili iz vlastite adrese sučelja prije svega drugog. Uobičajena zadana ruta koju daje DHCP povezana je s nic0, zato internetski put tako često slučajno pobjeđuje. Pisanje politike prema pretpostavljenom nazivu uređaja način je na koji ispravno pravilo završi na pogrešnom sučelju.

Zabilježite adrese, nazive uređaja i VPC kojem svaki pripada. Ta tablica s tri stupca ulaz je za svaki kasniji korak.

Korak 2: imenujte dvije odluke o usmjeravanju

Prva odluka pripada gostu: koje sučelje i koja izvorna adresa za ovaj paket. Druga pripada oblaku: što rute VPC-a i politika vatrozida dopuštaju oko tog sučelja.

Ruta vidljiva u VPC-u okrenutom VPN-u ne postaje gostova ruta koja bira taj NIC. Oblak ruta opisuje što mreža može dostaviti, dok gostova ruta odlučuje što paket čini.

Korak 3: odaberite politiku povratnog puta

Za mali, stabilan skup prefiksa podružnice eksplicitne gostove rute prema odredištu najjednostavniji su izraz: odgovori na te prefikse izlaze kroz sučelje okrenuto VPN-u. Kad nekoliko servisa namjerno koristi različite lokalne izvorne adrese, pravila temeljena na izvoru koja biraju tablicu po sučelju drže svaki odgovor u ispravnom kontekstu. Dokumentacija o više sučelja opisuje imenovanje NIC-ova i ponašanje zadane rute na kojima se ti dizajni oslanjaju.

Svaka tablica treba valjane povezane rute i sljedeće skokove, plus odredišta za koja će se pitati. Pravilo koje pokazuje u nepotpunu tablicu nije dizajn povratnog puta. Upotrijebite dokumentirani pristupnik za taj NIC umjesto izmišljanja Ethernet pristupnika iz izgleda podmreže.

Korak 4: provjerite gostove vlastite filtre

Provjerite gdje poslužitelj sluša i koji lokalni izvor nosi odgovor. Slušatelj koji prima sve adrese ne poništava politiku usmjeravanja, pa vezanje na sve adrese ne mijenja ništa u vezi sučelja kroz koje odgovor izlazi.

Na Linuxu pregledajte obrnutu provjeru puta prema predviđenom dizajnu. Globalno ga isključivanje kao prvi potez mijenja grešku usmjeravanja za izloženost krivotvorenju adresa i skriva asimetriju koju ste pokušavali pronaći.

Korak 5: testirajte jedan tok po putu

Provjerite dopušteni zahtjev podružnice i nepovezani internetski zahtjev odvojeno, svaki s pravim izvorom i odredištem. Snimajte na oba sučelja kad možete, jer koristan dokaz je koje je sučelje prenijelo odgovor. Zatim potvrdite da je politika na strani oblaka poštovala put koji ste projektirali. Jedan uspješan zahtjev dokazuje jedan tok, a ne simetričan dizajn.

Držite dva testa odvojeno u svojim bilješkama, jer prolaze kroz različite rute i različita pravila vatrozida.

Što vam drugi NIC ne daje

Drugo sučelje dodaje mrežni priključak i još jednu adresu. Ono ne dodaje automatsko simetrično usmjeravanje i ne zaobilazi politiku vatrozida. Tretiranje toga kao popravka usmjeravanja razlog je zašto dizajni s više NIC-ova nakupljaju pravila koja kasnije nitko ne može objasniti.

Ako VM mora prosljeđivati promet drugih strojeva, planirajte tu usmjerivačku ulogu izričito, uključujući postavku u oblaku koja dopušta prosljeđivanje i gostove filtre koji idu s njom.