Po zmianie adresu IP serwera reguła SNAT wciąż wskazuje stary

Serwer przeniósł się na nowy adres, klienci nadal się łączą, a nic z tego, co wysyłają, nie dociera do internetu. Właśnie ten podział jest wskazówką: gniazdo nasłuchujące i przekierowanie portu przetrwały przeprowadzkę, więc tunel wstaje, podczas gdy tłumaczenie źródła stosowane do przekazywanych pakietów wciąż wskazuje adres, którego host już nie posiada. Odpowiedzi na te przepisane pakiety trafiają do maszyny, której już nie ma.

Łączenie i przekazywanie zawodzą w różnych miejscach

Ustanowienie zależy od punktu końcowego, który klienci już znają: publicznego adresu, przekierowania portu przed nim i odbiornika w środku. Przekazywany ruch zależy od drugiej decyzji podejmowanej po wejściu pakietu do tunelu, gdy host przepisuje swoje źródło, aby odpowiedzi znalazły drogę powrotną.

Zmiana adresu psuje tylko drugą decyzję, dlatego objaw czyta się jako "połączono, ale bez internetu". To wyjaśnia też, dlaczego zwykłe kontrole po stronie klienta wyglądają zdrowo: uścisk dłoni się kończy, klient dostaje adres, a nawet ping na adres tunelu serwera może odpowiedzieć. Godziny traci się na kliencie z powodu usterki, która mieszka po drugiej stronie, dlatego tabela reguł jest pierwszym miejscem do sprawdzenia.

Przeczytaj regułę i jej liczniki przed edycją

Wypisz reguły tłumaczenia z licznikami i porównaj skonfigurowane źródło z adresami, które host naprawdę posiada. Reguła przepisana na martwy adres zwykle pokazuje ruch na drodze wejściowej, bo pakiety do niej docierają i są tłumaczone, a na drodze powrotnej nic.

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

Sprawdź trzy pola, póki tam jesteś: pulę w dopasowaniu źródła, interfejs wyjściowy, jeśli reguła go nazywa, oraz wykluczenie, które chroni ruch między tunelami przed przepisaniem. To wykluczenie łatwo zgubić podczas edycji, a jego utrata sprawia, że ruch między partnerami wygląda na działający, choć jego odpowiedzi idą dziwną drogą.

Jeśli liczniki stoją na zerze, pakiety nigdy nie docierają do tej reguły i adres nie jest bieżącym problemem. Szukaj konkurencyjnej reguły wyżej w łańcuchu, co zdarza się, gdy ktoś dodaje zamiennik zamiast edytować oryginał. Porównaj numery reguł z wynikiem, który zapisałeś minutę temu. Kolejność jest częścią konfiguracji, a nie kosmetycznym detalem.

Zastąp źródło albo przestań je nazywać

Gdy host ma stabilny adres, zastąp regułę na miejscu, zamiast dodawać kolejną. Zastąpienie według numeru reguły zachowuje kolejność, od której zależy reszta łańcucha.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

Gdy adres jest przydzielany dynamicznie, nie nazywaj żadnego źródła i pozwól jądru wybrać bieżące z interfejsu wyjściowego. Ten wariant przetrwa kolejną przeprowadzkę bez edycji, za cenę ukrycia, który adres został użyty.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

Potwierdź, że przekazywanie IPv4 jest nadal włączone przez zarządzaną konfigurację, a następnie utrwal regułę własnym mechanizmem dystrybucji. Zmiana zrobiona tylko w działającym jądrze wraca przy następnym restarcie, zwykle w oknie konserwacyjnym, którego nikt nie łączy ze zmianą.

Dwa sposoby, by zrobić zamianę źle

Tłumaczenie puli na adres tunelu serwera zamiast na jego adres LAN odsyła odpowiedzi prosto do tunelu, gdzie są kierowane do klienta, który nigdy o nie nie prosił. Połączenie zatrzymuje się w sposób wyglądający jak pętla routingu, bo nią jest.

Układanie drugiego tłumaczenia nad starym to drugi błąd. Wygrywa pierwsza pasująca reguła, więc nieaktualny wpis nadal obsługuje pakiety, dopóki nie zostanie usunięty, a liczniki nowej reguły pozostają na zerze, podczas gdy wszyscy obwiniają zamianę. Usuń duplikat, zanim cokolwiek nowego dodasz. Potem przeczytaj listę jeszcze raz i potwierdź, że z pulą pasuje dokładnie jedno tłumaczenie.

Jeśli tunel przenosi też IPv6, powtórz cały przegląd na drugim stosie. Domyślna trasa IPv6 bez tłumaczenia i bez trasowanego prefiksu zawodzi równie cicho, a łatwo o tym zapomnieć, bo wszystko powyżej wygląda identycznie.

Usługi przychodzące potrzebują odwrotnego tłumaczenia

Usługa na kliencie VPN, która musi być osiągalna z zewnątrz, potrzebuje tłumaczenia celu, a nie źródła: publiczny port jest przepisywany na adres tunelu klienta, zanim wejdzie. Ścieżka przekazywania potrzebuje wtedy wyraźnej reguły zezwalającej na ten ruch.

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

Nigdy nie tłumacz portu, który przenosi sam tunel, bo to przepisanie przerywa połączenie utrzymujące usługę osiągalną. Trzymaj port tunelu całkowicie poza regułami celu. Na koniec sprawdź z obu stron: liczniki na nowej regule, krótki zapis na urządzeniu tunelu i jedno żądanie do adresu wewnątrz tunelu, zanim spróbujesz publicznego.