Maszyna GCP z wieloma NIC: dlaczego odpowiedzi wychodzą niewłaściwym interfejsem

Podłączenie drugiego interfejsu do maszyny Compute Engine daje jej kolejne połączenie sieciowe, a nie symetryczną drogę powrotną. Gość nadal wybiera interfejs i adres źródłowy ze swoich własnych tras i reguł. Google Cloud stosuje następnie routing VPC i politykę firewalla wokół tego interfejsu, którym pakiet opuścił sieć. Gdy te dwie decyzje się nie zgadzają, żądania przychodzą jednym NIC, a odpowiedzi wychodzą drugim, i oddział widzi na wpół otwartą rozmowę.

Przejdź ścieżkę w pięciu krokach, a niezgodność ujawni się, zanim napiszesz regułę polityki.

Krok 1: przypisz NIC-e chmury do urządzeń gościa

Chmura nazywa interfejsy nic0, nic1 i tak dalej, a gość widzi nazwy urządzeń, które nie muszą się zgadzać. Ustal mapowanie z metadanych instancji lub z adresu samego interfejsu, zanim zrobisz cokolwiek innego. Zwykła trasa domyślna dostarczana przez DHCP jest powiązana z nic0, dlatego droga do internetu tak często wygrywa przypadkiem. Pisanie polityki pod zgadywaną nazwę urządzenia to sposób, w jaki poprawna reguła trafia na niewłaściwy interfejs.

Zapisz adresy, nazwy urządzeń i VPC, do której należy każdy z nich. Ta trójkolumnowa mapa jest wejściem każdego kolejnego kroku.

Krok 2: nazwij dwie decyzje routingu

Pierwsza decyzja należy do gościa: który interfejs i który adres źródłowy dla tego pakietu. Druga należy do chmury: co dopuszczają trasy VPC i polityka firewalla wokół tego interfejsu.

Trasa widoczna w VPC zwróconej do VPN nie staje się trasą gościa wybierającą ten NIC. Trasa chmury opisuje, co sieć może dostarczyć, natomiast trasa gościa decyduje, co robi pakiet.

Krok 3: wybierz politykę drogi powrotnej

Dla małego, stabilnego zbioru prefiksów oddziału jawne trasy docelowe w gościu są najprostszym wyrazem: odpowiedzi do tych prefiksów wychodzą interfejsem zwróconym do VPN. Gdy kilka usług świadomie używa różnych lokalnych adresów źródłowych, reguły oparte na źródle, wybierające tabelę dla każdego interfejsu, utrzymują każdą odpowiedź we właściwym kontekście. Dokumentacja wielu interfejsów opisuje nazewnictwo NIC i zachowanie trasy domyślnej, na których opierają się te projekty.

Każda tabela potrzebuje prawidłowych tras połączonych i następnych skoków oraz miejsc docelowych, o które będzie pytana. Reguła wskazująca niepełną tabelę nie jest projektem drogi powrotnej. Użyj udokumentowanej bramy dla tego NIC zamiast wymyślać bramę Ethernet z wyglądu podsieci.

Krok 4: sprawdź własne filtry gościa

Sprawdź, gdzie nasłuchuje serwer i jaki lokalny adres źródłowy niesie odpowiedź. Nasłuchiwacz na wszystkich adresach nie unieważnia polityki routingu, więc przypisanie do wszystkich adresów niczego nie zmienia w kwestii interfejsu, którym wychodzi odpowiedź.

W Linuksie przejrzyj walidację odwrotnej ścieżki wobec zamierzonego projektu. Wyłączenie jej globalnie jako pierwszy krok zamienia błąd routingu na ekspozycję na podszywanie się i ukrywa asymetrię, której próbowałeś szukać.

Krok 5: testuj jeden przepływ na ścieżkę

Zweryfikuj osobno dozwolone żądanie oddziału i niepowiązane żądanie internetowe, każde z jego rzeczywistym źródłem i celem. Przechwytuj na obu interfejsach, gdy możesz, ponieważ użytecznym dowodem jest to, który interfejs niósł odpowiedź. Następnie potwierdź, że polityka po stronie chmury uszanowała zaprojektowaną ścieżkę. Jedno udane żądanie dowodzi jednego przepływu, a nie symetrycznego projektu.

Trzymaj oba testy osobno w notatkach, ponieważ korzystają z różnych tras i różnych reguł firewalla.

Czego drugi NIC ci nie daje

Drugi interfejs dodaje połączenie sieciowe i jeszcze jeden adres. Nie dodaje automatycznego symetrycznego routingu i nie omija polityki firewalla. Traktowanie go jako poprawki routingu jest powodem, dla którego projekty z wieloma NIC gromadzą reguły, których później nikt nie potrafi wyjaśnić.

Jeśli maszyna ma przekazywać ruch innych maszyn, zaplanuj tę rolę routera wyraźnie, wraz z ustawieniem chmury, które zezwala na przekazywanie, i towarzyszącymi mu filtrami gościa.