Virtuální stroj GCP s více NIC: proč odpovědi odcházejí špatným rozhraním

Připojení druhého rozhraní k virtuálnímu stroji v Compute Engine mu dává další síťové připojení, nikoli symetrickou zpáteční cestu. Host stále volí rozhraní a zdrojovou adresu ze svých vlastních tras a pravidel. Google Cloud poté uplatní směrování ve VPC a politiku firewallu kolem toho rozhraní, kterým paket vyšel. Když se tato dvě rozhodnutí rozcházejí, požadavky přicházejí na jednu NIC a odpovědi odcházejí druhou, a pobočka vidí napůl otevřenou konverzaci.

Projděte cestu v pěti krocích a nesoulad se ukáže dřív, než napíšete pravidlo zásad.

Krok 1: přiřaďte cloudové NIC zařízením hosta

Cloud pojmenovává rozhraní nic0, nic1 a tak dále, zatímco host vidí názvy zařízení, které se nemusí shodovat. Vyřešte mapování z metadat instance nebo z vlastní adresy rozhraní dřív než cokoli jiného. Běžná výchozí trasa poskytovaná DHCP je spojena s nic0, a proto cesta k internetu tak často vyhraje náhodou. Psaní zásad proti odhadnutému názvu zařízení je způsob, jak správné pravidlo skončí na špatném rozhraní.

Zapište adresy, názvy zařízení a VPC, ke které každé patří. Tato třísloupcová mapa je vstupem pro každý další krok.

Krok 2: pojmenujte dvě rozhodnutí o směrování

První rozhodnutí patří hostu: které rozhraní a která zdrojová adresa pro tento paket. Druhé patří cloudu: co trasy VPC a politika firewallu kolem tohoto rozhraní dovolují.

Trasa viditelná ve VPC obrácené k VPN se nestane trasou hosta, která by volila tuto NIC. Cloudová trasa popisuje, co síť může doručit, zatímco trasa hosta rozhoduje, co paket udělá.

Krok 3: zvolte politiku zpáteční cesty

Pro malou a stabilní množinu prefixů pobočky jsou explicitní cílové trasy v hostu nejjednodušším vyjádřením: odpovědi na tyto prefixy odcházejí přes rozhraní obrácené k VPN. Když několik služeb záměrně používá různé místní zdrojové adresy, pravidla založená na zdroji, která volí tabulku pro každé rozhraní, udržují každou odpověď ve správném kontextu. Dokumentace k více rozhraním popisuje pojmenování NIC a chování výchozí trasy, na kterých tyto návrhy závisí.

Každá tabulka potřebuje platné připojené trasy a další skoky, plus cíle, na které se jí bude ptát. Pravidlo ukazující do neúplné tabulky není návrhem zpáteční cesty. Použijte dokumentovanou bránu pro tuto NIC místo vymýšlení Ethernetové brány podle vzhledu podsítě.

Krok 4: zkontrolujte vlastní filtry hosta

Zkontrolujte, kde server naslouchá a který místní zdroj nese odpověď. Naslouchač na všech adresách nepřepisuje směrovací politiku, takže vázání na všechny adresy nic nemění na rozhraní, kterým odpověď odchází.

V Linuxu projděte validaci zpětné cesty proti zamýšlenému návrhu. Vypnutí globálně jako první krok vymění chybu směrování za vystavení podvržení adres a skryje asymetrii, kterou jste se snažili najít.

Krok 5: otestujte jeden tok na cestu

Ověřte povolený požadavek pobočky a nesouvisející internetový požadavek odděleně, každý s jeho skutečným zdrojem a cílem. Zachyťte provoz na obou rozhraních, když můžete, protože užitečným důkazem je, které rozhraní odpověď přeneslo. Poté potvrďte, že politika na straně cloudu ctila cestu, kterou jste navrhli. Jeden úspěšný požadavek dokazuje jeden tok, ne symetrický návrh.

Držte oba testy v poznámkách odděleně, protože procházejí různými trasami a různými pravidly firewallu.

Co vám druhá NIC nedá

Druhé rozhraní přidává síťové připojení a další adresu. Nepřidává automatické symetrické směrování a neobchází politiku firewallu. Považovat ho za opravu směrování je důvod, proč návrhy s více NIC hromadí pravidla, která pak nikdo nedokáže vysvětlit.

Pokud musí virtuální stroj přeposílat provoz jiných strojů, naplánujte tuto roli routeru výslovně, včetně cloudového nastavení, které přeposílání povoluje, a odpovídajících filtrů hosta.