Le persone trattano socks5h come socks5 con un'ortografia più amichevole, e si aspettano che entrambi inviino la stessa richiesta nello stesso posto. La lettera in più sposta invece la query DNS. Su una macchina il cui resolver e il cui proxy stanno in reti diverse, questa è la differenza tra una richiesta che funziona e una che fallisce.

Una lettera, due resolver

Lo schema decide dove il nome di destinazione diventa un indirizzo. La risoluzione locale usa il resolver configurato sulla vostra macchina. La risoluzione remota mette il nome host dentro la richiesta SOCKS, e il proxy lo cerca con il proprio resolver e la propria visione della rete. Entrambe le forme si connettono ancora allo stesso indirizzo proxy sulla stessa porta, quindi la differenza è nel corpo della richiesta, non nel percorso.

Niente dello schema cambia la cifratura o l'autenticazione; si sposta solo il percorso DNS. Per questo la lettera è facile da ignorare e costosa da sbagliare.

Stesso proxy, richiesta diversa

Le due invocazioni differiscono di un solo carattere. Tutto il resto è identico:

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

La documentazione proxy di curl descrive questi schemi separatamente, ed è la ragione autorevole per non trattarli come alias. Eseguite entrambi contro un endpoint innocuo che siete autorizzati a usare e leggete la differenza. Una ricerca remota riuscita non dice nulla sulle altre applicazioni, perché browser, gestori di pacchetti e runtime dei linguaggi scelgono ciascuno per sé.

Il nome del proxy stesso viene risolto localmente

In quel comando, proxy.example deve diventare un indirizzo prima che accada qualcos'altro, e quella ricerca è sempre locale. Spostare la risoluzione di service.example sul proxy non fa nulla per il nome del proxy stesso, che ha ancora bisogno di un resolver raggiungibile dalla vostra macchina. È qui che una VPN cambia il quadro.

Se il nome del proxy viene risolto solo dentro il tunnel, la connessione dipende dal fatto che il tunnel sia attivo prima che curl parta. Quale schema vince allora dipende da quale lato può rispondere. Quando la vostra macchina non riesce a risolvere la destinazione ma il proxy sì, socks5 fallisce e socks5h riesce. Quando la vostra macchina la risolve attraverso il tunnel e il proxy no, socks5 funziona e socks5h fallisce.

Lo schema non colloca la connessione al proxy dentro o fuori la VPN; è la tabella di routing a farlo, e lo schema non la vede mai. Per questo un tunnel può riparare uno schema e rompere l'altro sulla stessa macchina. La lettera decide solo chi pone la domanda.

Che cosa può risolvere ciascun lato

Un proxy pubblico non può risolvere un nome che esiste solo in azienda, quindi inviargli il nome host fallisce sul proxy e appare come errore del proxy invece che come errore DNS locale. Un proxy dentro la stessa rete privata di solito riesce a risolvere quei nomi, ed è lì che socks5h si guadagna il posto. Scegliete la posizione del resolver secondo la policy che vi serve davvero, perché il DNS remoto non è automaticamente più capace e consegna davvero il nome a una terza parte. Per una destinazione pubblica funzionano entrambe le forme, quindi preferite quella che i vostri altri strumenti usano già.

Scrivete quella scelta nel runbook e non in un commento, e tenete le credenziali fuori dalla cronologia condivisa e dall'output diagnostico. Poi cambiate una variabile alla volta: stessa destinazione, stesso binario, stesso resolver, una lettera.

Quale binario ha risposto

Due binari curl sulla stessa macchina possono differire per versione e funzionalità di build. In una shell simile a Unix, type -a curl elenca ogni corrispondenza sul percorso e curl --version mostra le funzionalità di quello che verrebbe eseguito. Uno script wrapper o un alias più avanti nel percorso è una causa comune di risultati che non corrispondono al binario che credete di stare testando.

Uno schema non supportato, un proxy che non riesce a risolvere il nome e una destinazione irraggiungibile sono tre errori diversi, quindi leggete il messaggio prima di cambiare la lettera. Una build senza la sintassi socks5h segnala la stringa del proxy come non supportata, il che non è lo stesso di un nome che non è stato risolto. Non trasformate un vecchio resoconto su un curl di sistema in una regola permanente per ogni piattaforma.

Articoli correlati