Virtuálny stroj GCP s viacerými NIC: prečo odpovede odchádzajú nesprávnym rozhraním

Pripojenie druhého rozhrania k virtuálnemu stroju v Compute Engine mu dáva ďalšie sieťové pripojenie, nie symetrickú spiatočnú cestu. Host stále vyberá rozhranie a zdrojovú adresu zo svojich vlastných trás a pravidiel. Google Cloud potom uplatní smerovanie vo VPC a politiku firewallu okolo toho rozhrania, ktorým paket vyšiel. Keď sa tieto dve rozhodnutia rozchádzajú, požiadavky prichádzajú na jednu NIC a odpovede odchádzajú druhou, a pobočka vidí napoly otvorený rozhovor.

Prejdite cestu v piatich krokoch a nezrovnalosť sa ukáže skôr, než napíšete pravidlo politiky.

Krok 1: priraďte cloudové NIC zariadeniam hosta

Cloud pomenúva rozhrania nic0, nic1 a tak ďalej, zatiaľ čo host vidí názvy zariadení, ktoré sa nemusia zhodovať. Vyriešte mapovanie z metadát inštancie alebo z vlastnej adresy rozhrania skôr než čokoľvek iné. Bežná predvolená trasa poskytovaná DHCP je spojená s nic0, a preto cesta k internetu tak často vyhrá náhodou. Písanie politiky proti odhadnutému názvu zariadenia je spôsob, akým správne pravidlo skončí na nesprávnom rozhraní.

Zapíšte adresy, názvy zariadení a VPC, ku ktorej každé patrí. Táto trojstĺpcová mapa je vstupom pre každý ďalší krok.

Krok 2: pomenujte dve rozhodnutia o smerovaní

Prvé rozhodnutie patrí hostovi: ktoré rozhranie a ktorá zdrojová adresa pre tento paket. Druhé patrí cloudu: čo trasy VPC a politika firewallu okolo tohto rozhrania dovoľujú.

Trasa viditeľná vo VPC obrátenej k VPN sa nestane trasou hosta, ktorá by volila túto NIC. Cloudová trasa opisuje, čo sieť môže doručiť, zatiaľ čo trasa hosta rozhoduje, čo paket urobí.

Krok 3: vyberte politiku spiatočnej cesty

Pre malú a stabilnú množinu prefixov pobočky sú explicitné cieľové trasy v hostovi najjednoduchším vyjadrením: odpovede na tieto prefixy odchádzajú cez rozhranie obrátené k VPN. Keď niekoľko služieb zámerne používa rôzne lokálne zdrojové adresy, pravidlá založené na zdroji, ktoré volia tabuľku pre každé rozhranie, udržujú každú odpoveď v správnom kontexte. Dokumentácia k viacerým rozhraniam opisuje pomenovanie NIC a správanie predvolenej trasy, na ktorých tieto návrhy závisia.

Každá tabuľka potrebuje platné pripojené trasy a ďalšie skoky, plus ciele, na ktoré sa jej bude pýtať. Pravidlo ukazujúce do neúplnej tabuľky nie je návrhom spiatočnej cesty. Použite dokumentovanú bránu pre túto NIC namiesto vymýšľania Ethernetovej brány podľa vzhľadu podsiete.

Krok 4: skontrolujte vlastné filtre hosta

Skontrolujte, kde server načúva a ktorý lokálny zdroj nesie odpoveď. Načúvač na všetkých adresách neprepisuje smerovaciu politiku, takže viazanie na všetky adresy nič nemení na rozhraní, ktorým odpoveď odchádza.

V Linuxe prejdite validáciu spätnej cesty voči zamýšľanému návrhu. Vypnutie globálne ako prvý krok vymení chybu smerovania za vystavenie podvrhnutiu adresy a skryje asymetriu, ktorú ste sa snažili nájsť.

Krok 5: otestujte jeden tok na cestu

Overte povolenú požiadavku pobočky a nesúvisiacu internetovú požiadavku oddelene, každú s jej skutočným zdrojom a cieľom. Zachytávajte na oboch rozhraniach, keď môžete, pretože užitočným dôkazom je, ktoré rozhranie nieslo odpoveď. Potom potvrďte, že politika na strane cloudu rešpektovala cestu, ktorú ste navrhli. Jedna úspešná požiadavka dokazuje jeden tok, nie symetrický návrh.

Držte dva testy v poznámkach oddelene, pretože používajú rôzne trasy a rôzne pravidlá firewallu.

Čo vám druhá NIC nedá

Druhé rozhranie pridáva sieťové pripojenie a ďalšiu adresu. Nepridáva automatické symetrické smerovanie a neobchádza politiku firewallu. Považovať ho za opravu smerovania je dôvod, prečo návrhy s viacerými NIC hromadia pravidlá, ktoré potom nikto nedokáže vysvetliť.

Ak virtuálny stroj musí preposielať prevádzku iných strojov, naplánujte túto úlohu smerovača výslovne, vrátane cloudového nastavenia, ktoré preposielanie povoľuje, a príslušných filtrov hosta.