curl socks5h kontra socks5: kto rozwiązuje nazwę hosta

Ludzie traktują socks5h jak socks5 z przyjaźniejszą pisownią i oczekują, że oba wyślą to samo żądanie w to samo miejsce. Dodatkowa litera przenosi jednak zapytanie DNS. Na maszynie, której resolver i proxy znajdują się w różnych sieciach, to różnica między żądaniem, które działa, a tym, które zawodzi.

Jedna litera, dwa resolvery

Schemat decyduje, gdzie nazwa miejsca docelowego staje się adresem. Rozwiązywanie lokalne używa resolvera skonfigurowanego na twojej maszynie. Rozwiązywanie zdalne umieszcza nazwę hosta w żądaniu SOCKS, a proxy szuka jej własnym resolverem i własnym spojrzeniem na sieć. Obie formy nadal łączą się z tym samym adresem proxy na tym samym porcie, więc różnica jest w treści żądania, a nie w ścieżce.

Nic w schemacie nie zmienia szyfrowania ani uwierzytelniania; przesuwa się tylko ścieżka DNS. Dlatego literę łatwo przeoczyć, a pomyłka jest kosztowna.

To samo proxy, inne żądanie

Dwa wywołania różnią się jednym znakiem. Wszystko inne jest identyczne:

curl --proxy socks5://proxy.example:1080 https://service.example/
curl --proxy socks5h://proxy.example:1080 https://service.example/

The dokumentacja proxy curla opisuje te schematy osobno i to jest miarodajny powód, by nie traktować ich jako aliasów. Uruchom oba wobec nieszkodliwego punktu końcowego, którego wolno ci używać, i odczytaj różnicę. Udane wyszukiwanie zdalne nic nie mówi o innych aplikacjach, ponieważ przeglądarki, menedżery pakietów i środowiska uruchomieniowe języków wybierają każdy sam.

Sama nazwa proxy jest rozwiązywana lokalnie

W tym poleceniu proxy.example musi stać się adresem, zanim cokolwiek innego się wydarzy, a to wyszukiwanie jest zawsze lokalne. Przeniesienie rozwiązywania service.example na proxy nic nie daje samej nazwie proxy, która nadal potrzebuje resolvera osiągalnego z twojej maszyny. Tu VPN zmienia obraz.

Jeśli nazwa proxy jest rozwiązywana tylko wewnątrz tunelu, połączenie zależy od tego, czy tunel jest podniesiony przed startem curla. Który schemat wtedy wygra, zależy od tego, która strona może odpowiedzieć. Gdy twoja maszyna nie potrafi rozwiązać celu, ale proxy potrafi, socks5 zawodzi, a socks5h się udaje. Gdy twoja maszyna rozwiązuje go przez tunel, a proxy nie potrafi, socks5 działa, a socks5h zawodzi.

Schemat nie umieszcza połączenia z proxy wewnątrz ani na zewnątrz VPN; robi to tabela routingu, a schemat nigdy jej nie widzi. Dlatego jeden tunel może naprawić jeden schemat i zepsuć drugi na tej samej maszynie. Litera decyduje tylko o tym, kto zadaje pytanie.

Co każda strona może rozwiązać

Publiczne proxy nie potrafi rozwiązać nazwy istniejącej tylko w firmie, więc wysłanie mu nazwy hosta zawodzi po stronie proxy i pojawia się jako błąd proxy, a nie jako lokalny błąd DNS. Proxy w tej samej sieci prywatnej zwykle potrafi rozwiązać takie nazwy i właśnie tam socks5h się sprawdza. Wybierz miejsce resolvera według polityki, której naprawdę potrzebujesz, bo zdalny DNS nie jest automatycznie wydajniejszy i faktycznie przekazuje nazwę stronie trzeciej. Dla publicznego celu obie formy działają, więc wybierz tę, której używają już inne twoje narzędzia.

Zapisz ten wybór w runbooku, a nie w komentarzu, i trzymaj dane logowania poza wspólną historią i wyjściem diagnostycznym. Potem zmieniaj jedną zmienną na raz: ten sam cel, ten sam plik binarny, ten sam resolver, jedna litera.

Który plik binarny odpowiedział

Dwa pliki binarne curla na tej samej maszynie mogą różnić się wersją i funkcjami kompilacji. W powłoce podobnej do Uniksa type -a curl wymienia każde dopasowanie na ścieżce, a curl --version pokazuje funkcje tego, który zostałby uruchomiony. Skrypt opakowujący lub alias wcześniej na ścieżce to częsty powód, dla którego wyniki nie pasują do pliku binarnego, który, jak myślisz, testujesz.

Nieobsługiwany schemat, proxy, które nie potrafi rozwiązać nazwy, i nieosiągalny cel to trzy różne błędy, więc przeczytaj komunikat, zanim zmienisz literę. Kompilacja bez składni socks5h zgłasza ciąg proxy jako nieobsługiwany, co nie jest tym samym co nazwa, której nie udało się rozwiązać. Nie zamieniaj jednego starego raportu o systemowym curlu w trwałą regułę dla każdej platformy.