VPN włączony, a localhost przestaje działać: nazwa, proxy czy bind?

Twój serwer deweloperski odpowiedział minutę temu, a teraz, gdy tunel jest podniesiony, żądanie kończy się przekroczeniem czasu z nazwą hosta, której nigdy nie wpisałeś. Prawie każdy przypadek wyjaśniają dwa mechanizmy, a z zewnątrz wyglądają identycznie. Sufiks wyszukiwania zmienia krótką nazwę w firmową, natomiast proxy wysyła ruch loopback do hosta, który nie może go osiągnąć. Rozdzielenie tych dwóch kosztuje jedno zapytanie i oszczędza regułę zapory, którą właśnie zamierzałeś napisać.

Gdy localhost rozwiązuje się w strefie firmowej

Sprawdź, na co rozwiązuje się nazwa, gdy tunel jest podniesiony, następnie wykonaj to samo zapytanie z opuszczonym tunelem i porównaj obie odpowiedzi. Zdemaskowaniem jest adres w zakresie firmowym tam, gdzie oczekiwałeś 127.0.0.1. Wpis taki jak localhost.mycompany.corp wygrywa z wpisem loopback, gdy klient doda ten sufiks do listy wyszukiwania, a żądanie wędruje do prywatnego hosta, na którym nic nie nasłuchuje na tym porcie. Czytaj listę wyszukiwania zamiast jej zgadywać, bo klient może dodać więcej niż jedną domenę, a kolejność decyduje, który kandydat jest próbowany pierwszy:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Zastąp nazwę hosta dosłownym adresem w aplikacji, kliencie bazy danych lub adresie URL notatnika, a następnie powtórz żądanie. Jeśli awaria zniknie, miałeś problem z nazewnictwem, a tunel był tylko wyzwalaczem. Jeśli się utrzyma, nasłuchujący lub trasa jest następnym podejrzanym, a nazwa była tylko fałszywym tropem.

Ustawienia proxy, które przechwytują loopback

Proxy systemowe zastosowane przy podnoszeniu tunelu przyjmie żądanie do 127.0.0.1 i przekaże je do zdalnego proxy, które nie ma pojęcia, co miałeś na myśli. Pusta lista wyjątków zamienia żądanie lokalne w zdalne, a komunikat błędu rzadko to mówi. Dodaj adresy loopback do listy wyjątków na całą sesję, a nie na jedno polecenie, a następnie potwierdź, że narzędzie to respektuje, zanim wyciągniesz wnioski o sieci.

Frameworki aplikacji czytają własne zmienne środowiskowe, a czasem własny plik konfiguracyjny, więc wyjątek działający dla jednego narzędzia niczego nie dowodzi dla następnego. Przeglądarki dodają niuans: przeglądarki oparte na Chromium domyślnie omijają proxy dla loopback, a token wyjątku może usunąć to zachowanie. Sprawdź faktyczną decyzję proxy, zamiast zakładać, że ustawienie systemu operacyjnego to cała historia. Dwa polecenia rozstrzygają to dla wszystkiego uruchamianego z powłoki:

curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool

Adres bindu decyduje, kto może się połączyć

Serwer uruchomiony na 127.0.0.1 przyjmuje połączenia tylko z tej maszyny, co zwykle jest właściwym ustawieniem domyślnym dla programowania. Serwer na 0.0.0.0 odpowiada na każdym interfejsie, w tym adapterze VPN, co jest większą ekspozycją, niż zamierza większość ludzi. Gdy dosłowny adres loopback zawodzi, najpierw sprawdź bind.

Spójrz na nasłuchujące gniazdo i zanotuj adres, do którego jest przypisane, nie tylko port. Jeśli inne urządzenie lub kontener musi dotrzeć do usługi przez tunel, przypisz do konkretnego interfejsu, którego użyje, i świadomie zezwól na ten port. Jeśli potrzebuje go tylko twoja maszyna, zachowaj wąski bind i napraw klienta zamiast poszerzać serwer. Przekierowanie portu lub warstwa tuneli może połączyć oba, ale każde dodaje komponent, który później będzie wymagał własnego debugowania.

Gdzie narzędzie debugowania oczekuje LAN

Narzędzia debugowania niosą założenia, które tunel cicho łamie. Mostek debugowania telefonu traci urządzenie, gdy VPN przechwyci podsieć urządzenia, więc ponowne połączenie przez adres LAN lub kabel unika konfliktu. Hub automatyzacji przeglądarki kończy się przekroczeniem czasu, gdy hub jest osiągalny tylko przez proxy albo gdy lokalna zapora porzuca jego port sterujący. Zdalny debugger może wymagać podniesienia uprawnień i adresu loopback tam, gdzie klient przepisał trasę.

Rozróżnij port sterujący i port danych osobno, bo często jeden przeżywa, a drugi nie. Potem zdecyduj, czy poprawka należy do konfiguracji narzędzia, do trasy dla tej podsieci czy do reguły podzielonego tunelu. Edycja pliku hosts na każdej maszynie dewelopera skaluje się najgorzej i jest zapominana pierwsza. Preferuj ustawienie, które żyje z profilem i może przejrzeć każdy, kto posiada tunel.

Zatrzymaj się na pierwszym nieudanym etapie

Przejdź przez trzy etapy: rozwiąż nazwę, otwórz gniazdo do dosłownego adresu, a potem pozwól narzędziu utworzyć własne połączenie. Każdy etap usuwa jedną warstwę, więc pierwsza awaria nazywa warstwę do naprawy, a wszystko po niej pozostaje niesprawdzone. Zapisz wynik, zanim cokolwiek zmienisz, bo poprawki zastosowanej przed pomiarem nie da się odróżnić od szczęścia. Jeśli pierwsza próba zawiedzie, a powtórka zadziała, tunel prawdopodobnie nie był gotowy, gdy narzędzie startowało.

Zastąp stałe oczekiwanie ograniczonym sprawdzeniem gotowości, które czeka na trasę, i zostaw nieudany etap w logu, aby następna osoba zobaczyła, gdzie się zatrzymało. Narzędzie, które samo się naprawia, nie jest naprawione, ma szczęście, a szczęście kończy się na cudzej maszynie. Zmieniaj tunel na końcu i tylko dla etapu, który naprawdę zawiódł. Ta kolejność jest też najkrótszą drogą do działającego builda, bo powstrzymuje cię przed odbudową komponentu, który nigdy nie był zaangażowany.