Ruch jednokierunkowy po wyłączeniu SNAT podsieci Tailscale

Wyłącz źródłowy NAT na routerze podsieci Tailscale, a tunel nadal działa, podczas gdy połączenia przez niego ustają. Żądania docierają do celu z własnym adresem overlay zdalnego klienta, co jest właśnie sensem zmiany, i odpowiedzi potrzebują teraz ścieżki, której sieć LAN nigdy nie musiała znać. Bez tej ścieżki pakiety lądują, odpowiedzi wychodzą przez zwykłą bramę, a usterka wygląda jak problem zapory, którego nie wyjaśnia żadna reguła zapory. Tunel jest zdrowy; brakuje odcinka powrotnego.

Co ukrywał SNAT

Przy włączonym SNAT router przepisuje adres źródłowy na własny adres LAN przed przekazaniem do podsieci, więc cel odpowiada hostowi, do którego już wie, jak dotrzeć, i nic więcej nie trzeba konfigurować. Wyłączenie zachowuje pierwotne źródło, a cel widzi wtedy adres w zakresie overlay, a nie sąsiada na własnym kablu. Ten adres jest prawdziwy i trasowalny w całym tailnecie, ale jest nieosiągalny z sieci LAN przez bramę domyślną. Udokumentowanym przełącznikiem jest --snat-subnet-routes=false, stosowany do samego routera podsieci Linux.

To ustawienie stałe, a nie przełącznik dla każdego pakietu, więc trasa powrotna musi istnieć dla każdej sieci docelowej obsługiwanej przez ten router. To właśnie czyni zmianę decyzją wdrożeniową, a nie polem wyboru. Wszystko obsługiwane przez ten router dziedziczy wymóg w tej samej chwili.

Gdzie może znajdować się trasa powrotna

Trzy lokalizacje są typowe i różnią się zasięgiem, a nie poprawnością. Trasa statyczna na hoście docelowym jest najbardziej bezpośrednia i najmniej skalowalna, ponieważ każde urządzenie potrzebuje własnej kopii. Tabela tras w VPC lub w routerze oddziału obejmuje całą sieć naraz, a opcja DHCP przenosząca bezklasowe trasy statyczne dociera do klientów automatycznie, ale po cichu zawodzi na urządzeniach, które ją ignorują.

ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5

Niezależnie od wybranej lokalizacji następnym skokiem jest adres LAN routera, a nigdy jego adres tailnet. Host w sieci LAN nie może dotrzeć do overlay, dopóki nie ma tej trasy, więc następny skok wewnątrz overlay jest cykliczny i nie wysyła pakietu nigdzie. Ten jeden błąd wyjaśnia większość konfiguracji, które wyglądają poprawnie i mimo to zawodzą, i przeżywa każde sprawdzenie czytające tylko własną tabelę routera. Zapisz, której lokalizacji użyto, bo inaczej następna osoba sprawdzi niewłaściwą.

Czytanie usterki jako ruchu jednokierunkowego

Objaw łatwiej rozpoznać niż przyczynę: usługa odpowiada na samym routerze i milczy wobec zdalnego klienta. Przechwycenie na celu pokazuje przychodzące żądania i wychodzące odpowiedzi, co wygląda na sukces, dopóki nie zauważysz, dokąd zmierzają te odpowiedzi. Zmierzają do bramy domyślnej, co oznacza, że odcinek wejściowy działał, a powrotny nie.

Przechwytuj raczej na routerze, bo widzi oba kierunki jednej wymiany i pokazuje, czy odpowiedź kiedykolwiek dotarła. Jeśli odpowiedź pojawia się na celu, ale nigdy na routerze, trasy brakuje lub jest błędna po stronie celu. Jeśli pojawia się na routerze i tam się zatrzymuje, problem leży dalej i należy do innego dochodzenia.

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

Czy prawdziwy adres jest wart trasy

Zachowanie SNAT pozostaje prostszą odpowiedzią, gdy sieci docelowej nie da się przekonfigurować, a kosztem jest to, że każdy klient wygląda jak router w logach i polityce celu. Wyłączenie jest uzasadnione, gdy aplikacja potrzebuje prawdziwego adresu źródłowego albo gdy polityka sieci musi odróżniać klientów współdzielących router. Oba powody są uzasadnione i żaden nie jest darmowy. Korzyść musi być warta utrzymywania trasy w każdej sieci docelowej oraz opisany poniżej przegląd zapory.

Dla jednej małej sieci LAN wymiana zwykle się opłaca, a dla mnóstwa urządzeń, które nie mogą przyjąć trasy statycznej, zwykle nie. Zapisz decyzję i powód obok konfiguracji routera, aby następny administrator wiedział, które zachowanie jest zamierzone. Wartość domyślna, której nikt nie zapisał, jest nie do odróżnienia od przeoczenia.

Zapora, logowanie i podwójna rola

Każda reguła pasująca do adresu LAN routera pasuje teraz do innego źródła, w tym reguły zezwalające i każde pole logu, które zapisywało router jako klienta. Przeczytaj te reguły przed pierwszym testem, a nie po pierwszej porażce, bo reguła zezwalająca tylko na adres routera całkowicie blokuje nowe źródło. Zawęź zamianę do klientów i portów, które jej potrzebują, a następnie potwierdź, że nie przepuszcza po cichu całego tailnetu.

sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'

Jeden węzeł pełniący jednocześnie rolę węzła wyjściowego i routera podsieci to udokumentowana kombinacja, która może gubić ruch w górę, gdy SNAT podsieci jest wyłączony. Rozdzielenie tych ról na różne węzły usuwa to zastrzeżenie i daje każdej trasie i polityce zapory jednego właściciela. Jeśli role muszą pozostać razem, oczekuj tego zachowania i przetestuj je, zanim obwinisz klienta. Trzymaj trasę, ustawienie przełącznika i przypisanie ról w jednej notatce, bo czyta się je razem, gdy następne połączenie zawiedzie.