curl socks5h proti socks5: kdo překládá jméno hostitele

Lidé považují socks5h za socks5 s příjemnějším pravopisem a očekávají, že oba pošlou stejný požadavek na stejné místo. Písmeno navíc místo toho přesouvá dotaz DNS. Na stroji, jehož resolver a jehož proxy jsou v různých sítích, je to rozdíl mezi požadavkem, který funguje, a tím, který selže.

Jedno písmeno, dva resolvery

Schéma rozhoduje, kde se jméno cíle stane adresou. Místní překlad používá resolver nakonfigurovaný na vašem stroji. Vzdálený překlad vkládá jméno hostitele dovnitř požadavku SOCKS a proxy ho hledá svým vlastním resolverem a svým vlastním pohledem na síť. Oba tvary se stále připojují ke stejné adrese proxy na stejném portu, takže rozdíl je v těle požadavku, ne v cestě.

Nic ve schématu nemění šifrování ani ověřování; přesouvá se jen cesta DNS. Proto je písmeno snadné ignorovat a drahé splést.

Stejná proxy, jiný požadavek

Obě volání se liší jediným znakem. Všechno ostatní je u nich totožné:

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

The reference proxy v curl dokumentuje tato schémata odděleně, a to je autoritativní důvod, proč je nepovažovat za aliasy. Spusťte oba proti neškodnému koncovému bodu, který smíte používat, a přečtěte si rozdíl. Úspěšné vzdálené hledání nic neříká o jiných aplikacích, protože prohlížeče, správci balíčků a běhová prostředí jazyků si každý volí sám.

Vlastní jméno proxy se překládá místně

V tom příkazu se proxy.example musí stát adresou dřív, než se stane cokoli jiného, a toto hledání je vždy místní. Přesunutí překladu service.example na proxy nic nedělá pro vlastní jméno proxy, které stále potřebuje resolver, na který se váš stroj dostane. Tady VPN mění obrázek.

Pokud se jméno proxy překládá jen uvnitř tunelu, spojení závisí na tom, že tunel bude nahoru dřív, než curl začne. Které schéma pak zvítězí, závisí na tom, která strana umí odpovědět. Když váš stroj neumí přeložit cíl, ale proxy ano, socks5 selže a socks5h uspěje. Když ho váš stroj přeloží přes tunel a proxy ne, socks5 funguje a socks5h selže.

Schéma neumisťuje spojení s proxy dovnitř ani vně VPN; to dělá směrovací tabulka a schéma ji nikdy nevidí. Proto může jeden tunel opravit jedno schéma a rozbít druhé na stejném stroji. Písmeno rozhoduje jen o tom, kdo položí otázku.

Co která strana umí přeložit

Veřejná proxy neumí přeložit jméno, které existuje jen ve firmě, takže poslání jména hostitele tam selže na proxy a projeví se jako chyba proxy, ne jako místní chyba DNS. Proxy uvnitř stejné privátní sítě taková jména obvykle přeložit umí, a právě tam si socks5h vydělává místo. Vyberte umístění resolveru podle zásady, kterou skutečně potřebujete, protože vzdálené DNS není automaticky schopnější a jméno opravdu předává třetí straně. Pro veřejný cíl fungují oba tvary, takže dejte přednost tomu, který už používají vaše další nástroje.

Zapište tu volbu do runbooku, ne do komentáře, a držte přihlašovací údaje mimo sdílenou historii a diagnostický výstup. Pak měňte jednu proměnnou po druhé: stejný cíl, stejný binární soubor, stejný resolver, jedno písmeno.

Který binární soubor odpověděl

Dva binární soubory curl na stejném stroji se mohou lišit verzí a možnostmi sestavení. V unixovém shellu type -a curl vypíše každou shodu v cestě a curl --version ukáže vlastnosti toho, který by se spustil. Obalový skript nebo alias dřív v cestě je častým důvodem, proč výsledky neodpovídají binárce, o které si myslíte, že ji testujete.

Nepodporované schéma, proxy, která neumí přeložit jméno, a nedostupný cíl jsou tři různé chyby, takže si přečtěte zprávu, než změníte písmeno. Sestavení bez syntaxe socks5h hlásí řetězec proxy jako nepodporovaný, což není totéž jako jméno, které se nepodařilo přeložit. Nedělejte z jednoho starého hlášení o systémovém curlu trvalé pravidlo pro každou platformu.