Autenticazione del proxy con nome utente e password: connessione e risoluzione degli errori

Con l’autenticazione tramite nome utente e password, l’applicazione invia al proxy le credenziali fornite dal gestore. Il proxy le verifica e consente di usare il servizio. Questo metodo è utile quando lavori da dispositivi e reti diversi: se il servizio non richiede anche l’autorizzazione tramite IP, trasferire uno script su un altro server non richiede di modificare un indirizzo IP consentito.

Per ottenere una connessione funzionante non bastano nome utente e password. Servono anche l’indirizzo, la porta e il protocollo corretti del proxy. L’applicazione deve supportare il metodo di autenticazione richiesto. Un errore di autenticazione, quindi, non significa necessariamente che la password sia sbagliata.

Per confrontare i metodi di accesso e scegliere quello adatto, consulta Autenticazione del proxy. Questo articolo spiega come collegarsi con nome utente e password, dall’inserimento delle impostazioni alla diagnosi dei problemi in uno script in uso.

Che cosa significa autenticazione con nome utente e password

Il nome utente identifica un account o l’accesso a un determinato servizio, mentre la password conferma il diritto di usarlo. Se la verifica riesce, il proxy gestisce la connessione entro i permessi concessi: elenco di indirizzi disponibile, quota acquistata e limiti applicabili.

Le credenziali del proxy non vanno confuse con la password del pannello di controllo. I dati usati da un’applicazione possono essere diversi da quelli per accedere al sito del fornitore. Una chiave API serve per le richieste all’API del servizio, mentre la password di un sito di destinazione serve per accedere a quel sito. Usa una di queste come password del proxy solo se il fornitore indica esplicitamente tale modalità di connessione.

Autenticarsi correttamente sul proxy non comporta l’accesso al sito di destinazione. Se il sito richiede un account, cookie o un token propri, l’applicazione deve comunque fornirli separatamente.

Quando è utile questo metodo

L’accesso con nome utente e password può servire applicazioni situate in più luoghi, sia fissi sia variabili. In assenza di restrizioni IP, ogni applicazione ha bisogno delle credenziali e delle impostazioni di connessione del proxy, senza dover aggiungere separatamente la propria rete all’elenco degli IP consentiti.

Per esempio, un gruppo lavora da due uffici e da casa, ciascuno con un IP pubblico diverso. Le applicazioni possono usare le stesse credenziali del proxy se il servizio permette loro di condividerle senza un vincolo IP. Ogni applicazione mantiene le proprie impostazioni di connessione; il proxy controlla le credenziali inviate da ciascuna.

Questo metodo funziona anche con più server permanenti. Il numero di dispositivi, le connessioni simultanee e le risorse disponibili dipendono però dal piano. Un’unica password non concede un accesso illimitato.

Come un’applicazione invia le credenziali del proxy

La sequenza generale è semplice: l’applicazione contatta il proxy, supera il controllo di accesso e lo usa per raggiungere la risorsa richiesta. I dettagli dipendono dal protocollo.

Un proxy HTTP può inizialmente restituire 407 Proxy Authentication Required e indicare il metodo di autenticazione accettato. L’applicazione invia i dati di autenticazione nell’intestazione Proxy-Authorization. Alcuni client li inviano subito, quindi la richiesta iniziale di autenticazione potrebbe non comparire nel log.

Quando apri un sito HTTPS tramite un normale proxy HTTP, l’autenticazione può avvenire durante la richiesta CONNECT che crea un tunnel. L’applicazione stabilisce poi una connessione protetta con il sito. Le successive richieste al sito attraverso quel tunnel già aperto non ripetono l’autenticazione del proxy usata per aprirlo.

Con SOCKS5, nome utente e password vengono controllati all’inizio della connessione, prima della richiesta di collegamento alla destinazione. Se la verifica fallisce, l’applicazione non ottiene la connessione richiesta tramite il proxy. Un errore di autenticazione nativo di SOCKS5 non è una risposta HTTP 407.

Seleziona il protocollo e il metodo di autenticazione supportati dal servizio. SOCKS4 prevede un campo user-ID, ma non definisce lo scambio di nome utente e password di SOCKS5. Compilare quel campo non può far eseguire a un client SOCKS4 l’autenticazione con password di SOCKS5.

Quali impostazioni inserire nell’applicazione

Parti dai dati di connessione del servizio specifico. Se l’applicazione prevede campi separati, inserisci ogni valore nel proprio campo:

Alcune applicazioni accettano un’unica stringa nel formato protocol://username:password@host:port. Per esempio, in http://client01:River%[email protected]:8080, il nome utente è client01, la password è River@2026, l’host è proxy.example e la porta è 8080. Il carattere @ nella password è rappresentato come %40, per non confonderlo con il separatore che precede l’host.

curl, per esempio, supporta questa interpretazione dell’URL di un proxy. Un campo password separato richiede in genere la password stessa, senza codifica URL. Non copiare un valore codificato da un URL a un campo separato senza verificare il formato: l’applicazione potrebbe interpretarlo come una password diversa. Per le stringhe contenenti %, due punti o altri caratteri speciali, segui i requisiti di formato del client.

Codifica una sola volta i caratteri necessari all’interno delle credenziali; codificare l’intera stringa ne danneggerebbe i separatori. Racchiudere un argomento del comando tra virgolette non sostituisce la codifica URL. Anche il metodo di autenticazione può imporre restrizioni: HTTP Basic, per esempio, consente i due punti nella password ma non nel nome utente.

Anche i formati di importazione differiscono. host:port:username:password e username:password@host:port non sono intercambiabili. Valori corretti nell’ordine sbagliato non funzionano se lo strumento di importazione si aspetta una disposizione diversa.

Il prefisso http:// nell’URL di un proxy descrive il collegamento del client al proxy stesso. Non impedisce l’accesso ai siti HTTPS: il client può creare un tunnel per raggiungerli. Sostituire semplicemente il prefisso con https:// non aggiunge al server il supporto per una connessione protetta al proxy.

Alcuni servizi includono nel nome utente un parametro relativo al paese, al gruppo di uscita o alla sessione. Copia l’intera stringa. Questi parametri controllano l’instradamento secondo le regole del fornitore; non inventarne la sintassi e non prenderla da un altro servizio.

Perché verificare il supporto dell’autenticazione nell’applicazione

Il supporto dei proxy e quello dell’autenticazione del proxy sono capacità distinte. La presenza di campi per host e porta non significa necessariamente che il client possa inviare nome utente e password.

Controlla la combinazione esatta di protocollo del proxy, metodo di autenticazione e applicazione. Per esempio, l’implementazione SOCKS5 integrata in Chrome non supporta l’autenticazione dei proxy SOCKS5. Credenziali corrette da sole non possono risolvere questa limitazione. Nemmeno un’estensione per selezionare i proxy aggiunge necessariamente il metodo di autenticazione mancante.

Negli script, il supporto può dipendere dalla libreria, dai suoi componenti facoltativi e dal modo in cui vengono fornite le impostazioni. Un’applicazione non usa necessariamente le impostazioni proxy del sistema o quelle di un browser in cui la connessione funziona già.

Prima di avviare un’attività estesa, prova una richiesta nell’applicazione che dovrà eseguirla. Verifica che usi il proxy specificato e non prosegua con una connessione diretta dopo un errore. Il corretto caricamento di una pagina non conferma, da solo, che le impostazioni siano giuste.

Che cosa succede quando cambia il tuo IP

Con una connessione ADSL che usa un IP dinamico, il fornitore di accesso a Internet può assegnare un nuovo indirizzo dopo il riavvio del router o una riconnessione. Se il proxy controlla soltanto nome utente e password, l’applicazione si collega con le stesse credenziali: non c’è un nuovo IP da aggiungere nel pannello. Lo stesso vale quando passi dalla rete dell’ufficio a quella di casa.

Cambiare rete può però interrompere le connessioni esistenti. Il client deve ricollegarsi e una richiesta incompleta potrebbe dover essere ripetuta. Un errore subito dopo il passaggio dal Wi-Fi alla rete mobile non va automaticamente considerato un problema di password.

Alcuni servizi controllano sia le credenziali sia l’indirizzo di origine. Una password corretta non supera quella restrizione di rete: il nuovo IP deve corrispondere a un indirizzo o a un intervallo consentito. Prima di trasferire uno script, verifica se il servizio accetta connessioni da qualsiasi rete o applica un controllo combinato.

La password è protetta durante la trasmissione?

L’autenticazione determina chi può accedere. La cifratura determina se qualcuno lungo il percorso può leggere i dati trasmessi. La presenza di una password non rende, da sola, cifrata la connessione.

HTTP Basic codifica nome utente e password in Base64. È una rappresentazione reversibile, non una cifratura. Senza protezione sul collegamento al proxy, chi osserva quel percorso di rete può ottenere le credenziali. Neppure l’autenticazione standard di SOCKS5 con nome utente e password ne cifra la trasmissione.

HTTPS sul sito di destinazione protegge la connessione tra l’applicazione e quel sito. Con un proxy HTTP, l’autenticazione durante la creazione del tunnel avviene prima; TLS del sito non protegge le credenziali del proxy già inviate. Analogamente, una richiesta HTTPS tramite SOCKS5 non cifra il precedente controllo della password del proxy.

Proteggere quel tratto del percorso richiede una protezione tra l’applicazione e il proxy, per esempio un proxy HTTPS con TLS, se entrambi il servizio e il client lo supportano. L’applicazione deve convalidare il certificato del proxy. In alcune offerte commerciali, “proxy HTTPS” significa soltanto che si possono raggiungere siti HTTPS: controlla quindi dove venga effettivamente applicato TLS.

Se una stringa di connessione completa con una password valida viene esposta, qualcun altro potrebbe usare il servizio entro le sue regole, consumando la quota o occupando connessioni. Non equivale a ottenere la password del pannello quando le credenziali sono separate. Il metodo di autenticazione, inoltre, non garantisce che un indirizzo non possa essere identificato come proxy: una richiesta di autenticazione accessibile dall’esterno può rivelare il servizio.

Più applicazioni possono usare le stesse credenziali?

Tecnicamente, più client possono inviare lo stesso nome utente e la stessa password. Il fornitore stabilisce se sia consentito e ne definisce i confini: condizioni di condivisione, limiti delle connessioni attive, quota acquistata ed eventuali ulteriori restrizioni.

Per esempio, due script possono usare un unico account aprendo numeri diversi di connessioni. Una password non significa una connessione. Allo stesso modo, avviare dieci processi non moltiplica per dieci la quota complessiva di connessioni del servizio.

Anche il numero di coppie di credenziali è diverso dal numero di IP di uscita. Un nome utente e una password possono concedere l’accesso a un elenco di proxy statici oppure a un gateway collegato a un pool di indirizzi. L’IP visto dal sito dipende dal proxy selezionato e dalle regole di instradamento del servizio.

Se il servizio offre credenziali separate per applicazioni o membri del gruppo, puoi disabilitare un insieme senza cambiare gli altri. Con una password condivisa, modificarla richiede di aggiornare ogni applicazione che la usa. Credenziali separate non implicano comunque quote separate di connessioni o traffico: controlla quali limiti condividono.

Perché un proxy rifiuta nome utente e password

Per prima cosa identifica chi ha restituito l’errore. HTTP 407 riguarda l’autenticazione del proxy; 401 dal sito di destinazione riguarda l’accesso a quel sito. Un messaggio 403 o un timeout non stabiliscono, senza ulteriori elementi, se la password del proxy sia corretta.

Controlla lo stato del servizio e la quota residua, poi prova una richiesta con le impostazioni fornite nell’applicazione effettiva. Se fallisce, usa la tabella per verificare il supporto del client, il formato delle credenziali e le restrizioni sull’IP di origine, modificando un’impostazione alla volta. Quando la richiesta funziona in modo costante, aumenta il carico e osserva i limiti che compaiono soltanto sotto carico.

Come conservare e cambiare le credenziali negli script in uso

Conserva le credenziali separate dal codice, in una configurazione con controllo degli accessi o nell’archivio dei segreti del tuo ambiente. Un’applicazione può riceverle tramite variabili d’ambiente, ma queste non costituiscono di per sé una cifratura. Tieni le password attive fuori dai repository e dai modelli che condividi con altri.

Un log richiede in genere l’host e la porta del proxy, l’esito della connessione e il codice di errore. Una stringa di connessione completa contiene la password: oscurala prima di scrivere il log. Con gli strumenti da riga di comando, considera che un segreto può rimanere nella cronologia dei comandi o essere visibile negli argomenti del processo, a seconda dell’applicazione e del sistema.

Prima di cambiare una password, individua tutti i punti che la usano: applicazioni locali, processi sui server, attività pianificate e sistemi di compilazione. Dopo la modifica, aggiorna le loro impostazioni e stabilisci una nuova connessione per provarli. Verifica che anche i processi di lunga durata abbiano acquisito il nuovo valore; alcuni richiedono un riavvio.

Se la vecchia password non deve più funzionare, verifica che una nuova connessione che la usa venga rifiutata. Le connessioni esistenti seguono le regole del servizio: cambiare una password non sempre le chiude subito. Per revocare urgentemente l’accesso, usa il metodo di disabilitazione supportato dal fornitore.

Autenticazione combinata: IP e password

Con l’autenticazione combinata, il proxy controlla due condizioni: le credenziali e l’indirizzo da cui si collega l’applicazione. Entrambe devono essere soddisfatte. Una password corretta da sola non supera la restrizione IP.

Per i pacchetti statici di ProxyCompass, la modalità combinata usa una sottorete /24. Se disponi di più indirizzi IPv4 pubblici nella stessa sottorete, è sufficiente aggiungerne uno all’elenco degli IP consentiti. Gli altri indirizzi di quella sottorete possono collegarsi con nome utente e password corretti, senza una voce separata per ogni indirizzo.

Nell’illustrazione, l’IP pubblico dell’applicazione condivide i primi tre numeri con l’indirizzo consentito. Può collegarsi con credenziali valide; un indirizzo esterno a quella sottorete non supera il controllo di rete, mentre una password errata fallisce anche al suo interno. Anche altri IP dei client nella stessa sottorete possono usare questa voce. È utile per applicazioni che richiedono i campi nome utente e password. La regola riguarda gli IP pubblici delle tue applicazioni, non gli IP di uscita dei proxy acquistati.