Dlaczego Twoja publiczna usługa Linux odpowiada przez VPN

Nic w gnieździe nie pamięta, która karta przeniosła żądanie, więc domyślna trasa VPN z pełnym tunelem może przechwycić odpowiedź, która należy do WAN. Usługa nie ignoruje karty wejściowej; Linux trasuje odpowiedź wygenerowaną lokalnie według celu i polityki źródła. Reguła oparta na źródle może zamiast tego wysyłać tylko odpowiedzi usługi przez pełną tablicę WAN, pozostawiając zwykłe wyjście w tunelu. Port pozostaje otwarty, gdy odpowiedź wychodzi złą ścieżką, i dlatego objaw wygląda jednostronnie.

Błędne przekonanie: odpowiedzi podążają za interfejsem, na którym przyszły

Wydaje się logiczne, że pakiet przychodzący na eth0 powinien wyjść przez eth0. Bezstanowe filtry pakietów można tak napisać, a tcpdump po stronie wejściowej pokazuje żądanie dokładnie tam, gdzie się go oczekuje. Routing tak nie działa w przypadku ruchu, który sam host tworzy.

Gdy usługa przyjmie połączenie, jej odpowiedź jest nowym, lokalnie wygenerowanym pakietem. Jądro sprawdza reguły routingu dla celu i źródła odpowiedzi, a domyślna trasa VPN jest całkowicie poprawną odpowiedzią. Nic w gnieździe nie pamięta, która karta przeniosła żądanie.

Dlatego objaw wygląda jednostronnie: żądania przychodzą, odpowiedzi znikają. Dlatego też dodanie reguły zapory dla portu wejściowego niczego nie zmienia. Pakiet nie jest blokowany na drodze do środka; jest trasowany gdzie indziej na drodze na zewnątrz. Prześledź odpowiedź wyszukiwaniem kwalifikowanym źródłem, a objazd stanie się widoczny.

Co jądro faktycznie trasuje: adres źródłowy

Potrzebnym uchwytem jest adres lokalny, którego usługa używa do odpowiedzi. Na hoście z przykładowym adresem eth0 192.0.2.10/24 i bramą 192.0.2.1 ten adres jest obecny na interfejsie. W maszynie w chmurze adres publiczny może być przetłumaczony wyżej i nieobecny w gościu, więc używaj adresu, który host naprawdę ma.

Sprawdź bieżący stan przed zarezerwowaniem numeru tablicy lub priorytetu reguły. Istniejące reguły polityki mogą przesłonić nową, a stara tablica o tym samym numerze może już zawierać niepowiązane trasy:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

Następnie wybierz tablicę według źródła. Reguła pasuje do odpowiedzi, które już niosą 192.0.2.10, czyli dokładnie do ruchu zakończonego lokalnie, który chcesz wyłączyć. Ruch przekazywany i pakiety z innych adresów lokalnych nie pasują.

Zbuduj pełną tablicę powrotną, a nie połowę domyślnej trasy

Tablica z samą trasą domyślną nie wystarczy. Jądro nadal musi rozwiązać bramę, a to rozwiązanie wymaga podłączonego prefiksu w tej samej tablicy. Tablica, której brakuje tego prefiksu, zawodzi przy rozwiązywaniu bramy, nawet gdy jej trasa domyślna wygląda poprawnie. Dodaj oba, a następnie skieruj regułę źródłową na tablicę:

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Użyj prawdziwego prefiksu i bramy, zamiast kopiować przykład. Interfejs w chmurze skonfigurowany jako /32 z bramą on-link wymaga innej trasy podłączonej, a tablica zbudowana z niewłaściwego prefiksu zawodzi na pierwszym skoku. Atrybut src wskazuje preferowane źródło dla tej trasy; nie zastępuje reguły źródłowej.

Kolejność też ma znaczenie. Szeroka reguła o niższym numerze priorytetu jest oceniana najpierw, więc do reguły źródłowej trzeba dotrzeć przed każdą regułą, która odesłałaby ten ruch do tablicy głównej. Sprawdź priorytety za pomocą ip rule show po dodaniu, nie tylko przy starcie.

Zweryfikuj wyszukiwaniem kwalifikowanym źródłem

Poproś jądro o trasowanie celu testowego z adresu usługi. Odpowiedź powinna wskazać eth0 i bramę WAN, a nie tunel:

ip -4 route get 198.51.100.25 from 192.0.2.10

Następnie ustanów nowe autoryzowane połączenie i obserwuj oba kierunki. Wyszukiwanie, które wybiera właściwą tablicę, gdy żywe połączenie nadal zawodzi, wskazuje na filtrowanie odwrotnej ścieżki lub regułę zapory, a nie na tablicę. Sprawdź te mechanizmy, zanim cokolwiek wyłączysz globalnie.

Umieść końcowe trasy i regułę pod menedżerem sieci, do którego należy interfejs. Zmiany adresu, odnowienie DHCP i ponowne połączenia VPN przepisują stan jądra, a reguła dodana ręcznie znika lub wskazuje nieaktualną bramę po następnym zdarzeniu.

Gdzie kończy się ten wyjątek

Reguła zwalnia ruch zakończony lokalnie z jednego adresu źródłowego. Nie obejmuje portów publikowanych przez Docker, DNAT ani usług przekazywanych przez host, ponieważ te pakiety są trasowane jako ruch przekazywany i nigdy nie niosą lokalnego źródła hosta w ten sam sposób. Takie rozwiązania zwykle wymagają znacznika ustawionego na wejściu i reguły pasującej do znacznika.

Nie powoduje też, że publiczny adres hosta pojawia się na interfejsie. Gdy nadrzędny NAT posiada ten adres, odpowiedź nadal musi wyjść ścieżką, której ten NAT oczekuje, dlatego tablica WAN musi odzwierciedlać pierwotną bramę i prefiks, a nie zgadywany zakres publiczny.

Utrzymuj wyjątek udokumentowany wraz z numerem tablicy, priorytetem reguły i dokładnym adresem źródłowym. Następna zmiana w VPN lub interfejsie może go po cichu zepsuć, a notatka wymieniająca trzy wartości jest szybsza do sprawdzenia niż ponowne odkrywanie objawu z raportu klienta.

Jeśli usługa nadal odpowiada złą ścieżką po udanym wyszukiwaniu kwalifikowanym źródłem, porównaj adres źródłowy żywego gniazda z tym w regule. Usługa powiązana z adresem wieloznacznym może wybrać inne źródło niż testowany adres, i ta rozbieżność jest pozostałą luką.