Czy proxy nadal tkwi na starym adresie tunelu po ponownym połączeniu VPN?

Ponowne uruchomienie klienta VPN dowodzi tylko, że tunel wrócił. Nie mówi nic o proxy, któremu kazano wychodzić przez niego. Squid, tinyproxy i większość innych forwarderów trzyma lokalny adres źródłowy ustalony przy starcie, dopóki coś nie zmusi ich do ponownego wczytania. Gdy ponowne połączenie przydzieli nowy adres tunelu, forwarder albo zawodzi przy każdym połączeniu wychodzącym, albo zaczyna wychodzić zwykłą trasą.

Ten drugi błąd jest groźny: tunel działa, strony się ładują, a zły jest tylko adres wyjściowy.

Zacznij od nasłuchu, nie od tunelu

W grze są trzy adresy, a ponowne połączenie przesuwa tylko niektóre z nich. Nasłuch to miejsce, na które wskazuje przeglądarka, zwykle 127.0.0.1 lub adres sieci lokalnej, i nie obchodzi go, że tunel się zmienił. Wychodzące źródło lokalne to to, o co forwarder prosi jądro przy wybieraniu następnego skoku, i jest ono związane z urządzeniem tunelu. Wyjście publiczne to to, co zapisuje serwer WWW, i może to być adres przetłumaczony kilka skoków dalej.

Wyszukiwanie publicznego IP odpowiada tylko na ostatnie pytanie. Nie powie ci, do którego lokalnego adresu forwarder ma się przypiąć, bo jedno wyjście publiczne może ukrywać kilka źródeł wewnętrznych. Czytaj adres od tego, kto posiada połączenie: z wyjścia stanu klienta, z samego interfejsu albo z przestrzeni nazw, w której żyje tunel. Wzięcie pierwszego interfejsu o nazwie przypominającej tunel daje złą odpowiedź, gdy tylko istnieje drugi profil.

Układy kontenerów i przestrzeni nazw po cichu łamią to założenie. Forwarder w jednej przestrzeni nazw sieci nie może przypiąć się do tunelu, który istnieje w innej, i żadna edycja konfiguracji tego nie naprawi.

Cztery kontrole, zanim cokolwiek zmienisz

Przechodź je po kolei. Pierwsza nieudana kontrola to miejsce, w którym się zatrzymujesz, bo kolejne zakładają, że poprzednie obowiązują.

1. Potwierdź, że używany tunel to profil, wokół którego zbudowano proxy, a nie drugi profil, który połączył się sam.
2. Wypisz adres, który jest teraz na tym urządzeniu, i porównaj go z adresem w działającej konfiguracji.
3. Zapytaj forwarder, jakie źródło ustalił, a nie co twierdzi plik na dysku.
4. Potwierdź, że ruch z forwardera rzeczywiście podlega polityce trasowania i zapory, której oczekujesz.

Adres urządzenia jest łatwy: ip -4 addr show dev tun0 wypisuje bieżący, a ip -4 route get 1.1.1.1 pokazuje, który interfejs jądro wybrałoby dla tego celu. Forwarder przypięty do dokładnego adresu zawodzi głośno, gdy adres znika. Forwarder przypięty do urządzenia albo wracający do źródła domyślnego działa dalej i przecieka, i to jest cichy wynik.

Dopasuj dokumentację do wydania, które uruchamiasz, a nie do pierwszego wyniku wyszukiwania. Dyrektywa adresu wychodzącego Squida jest udokumentowana dla v7 i starszych, a dokumentacja v8 mówi wprost, że dyrektywa nie jest tam dostępna, więc skrypt zbudowany wokół niej nie przetrwa tej granicy (zobacz referencję Squid tcp_outgoing_address). Sprawdź parserem samego produktu, zanim cokolwiek zostanie ponownie wczytane: squid -k parse zgłasza błędy i kończy pracę, nie dotykając działającego procesu.

Numeruj każdy tunel i odrzucaj nieaktualne podmiany

Ponowne połączenie to przekazanie, a przekazania wymagają kolejności. Oznacz każde zaobserwowane połączenie licznikiem lub znacznikiem czasu, który rośnie przy każdym udanym zestawieniu, a potem nieś ten znacznik w konfiguracji kandydującej. Gdy znacznik kandydata jest starszy od bieżącego, odrzuć kandydata zamiast go stosować, bo wolna aktualizacja napisana dla poprzedniego tunelu nadpisałaby ustawienia bieżącego. Scal serie zdarzeń, aby migoczące łącze dawało jedno przejście zamiast piętnastu.

Ułóż pracę w cztery kroki: unieważnij stary stan wyjścia, poczekaj, aż właściciel połączenia zgłosi zakończenie, zbuduj tylko zarządzany fragment, a potem sprawdź i aktywuj przez menedżera usług. Regenerowanie całego pliku z dwóch wartości adresu to sposób, w jaki ograniczenia nasłuchu, uwierzytelnianie i polityka celu po cichu znikają. Szanuj też świadome zatrzymanie. Pomocnik, który dalej wybiera tunel wyłączony przez użytkownika, to błąd, a nie odporność.

Otwarte gniazda nie pójdą za nowym adresem

Rekonfiguracja forwardera nie mówi nic o połączeniach już zestawionych. Czy się wyczerpią, czy zginą, zależy od produktu, więc obserwuj zachowanie, zamiast je zakładać.

Żądanie obsłużone przez gniazdo otwarte przed podmianą nadal wychodzi starą ścieżką, nawet gdy nowa konfiguracja jest poprawna. Jeśli to ma znaczenie, zdecyduj wprost: pozwól na krótkie okno wyczerpania i przestań przyjmować nową pracę, albo zamknij stare gniazda i zaakceptuj błędy. Potem przetestuj świeżym połączeniem i trzymaj ten wynik osobno od kontroli wyczerpania. Przypięcie źródła też nie jest granicą bezpieczeństwa. Gdy ruch nigdy nie może dotknąć zwykłej trasy, wymuszaj to znacznikami i regułami zapory, z DNS i IPv6 włącznie, aby nieudane wczytanie zostawiło proxy wyraźnie wyłączone, a nie otwarte.

Udowodnij nowe wyjście świeżym żądaniem

Liczy się żądanie otwarte po aktywacji, nie ping i nie strona już w pamięci podręcznej. Poproś proxy o prawdziwy URL i odczytaj adres wyjściowy, który zgłasza drugi koniec, a potem porównaj go z własnym widzeniem tunelu przez klienta, gdy dostawca je pokazuje.

Trzymaj parsowanie, ponowne wczytanie i żądanie jako osobne polecenia, aby niepowodzenie wskazywało jeden krok. Pierwsze dwa nie zmieniają nic, gdy zawiodą, i właśnie dlatego działają przed restartem.

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

Jeśli ponowne wczytanie zawiedzie, zatrzymaj usługę i napraw fragment; proxy obsługujące ze starym wyjściem jest gorsze niż krótka przerwa. Jeśli wczytanie się powiedzie, ale świeże żądanie nadal wychodzi gdzieś nieoczekiwanie, wróć do kontroli trasowania zamiast ponownie edytować adresy. Zapisz generację tunelu, względem której sprawdzałeś, aby następne ponowne połączenie miało coś konkretnego do porównania.