Base di conoscenze ProxyCompass
Autenticazione proxy: elenco di IP consentiti o nome utente e password?
L’autenticazione proxy verifica se l’applicazione può usare un servizio proxy. Conoscere indirizzo e porta del proxy di solito non basta: il servizio deve anche distinguere i client consentiti dagli altri sistemi che possono raggiungerlo. Questo limita l’uso dei proxy acquistati ai client che autorizzi.
I due metodi comuni usano prove diverse. Con l’autenticazione tramite IP, il proxy controlla da dove proviene la connessione. Con l’autenticazione tramite nome utente e password, l’applicazione fornisce credenziali. Il primo metodo lega l’accesso a un indirizzo di rete; il secondo può consentire all’applicazione di mantenere l’accesso quando passa a un’altra rete. Un servizio può anche richiedere entrambe le condizioni insieme.
Questa scelta influisce su come ti connetti, sulle applicazioni utilizzabili e su ciò che succede quando cambia l’ambiente di lavoro. È una parte separata della scelta di una configurazione proxy: l’autenticazione non determina se l’IP di uscita sia datacenter o residenziale, statico o a rotazione. Determina chi può usare il servizio che fornisce quell’IP.
Come funzionano i due metodi di autenticazione
Autenticazione tramite IP: permesso per l’origine della connessione
Con l’autenticazione tramite IP, aggiungi un indirizzo client all’elenco consentito del fornitore, spesso chiamato whitelist o allowlist. Quando arriva una connessione, il proxy ne confronta l’IP di origine con l’elenco. Se corrisponde e sono soddisfatte le altre condizioni di accesso del servizio, l’applicazione può usare il proxy senza inviare un nome utente e una password proxy separati.
Per un proxy Internet, l’indirizzo pertinente è normalmente l’IP pubblico in uscita della tua rete. È l’indirizzo da cui l’applicazione raggiunge il proxy, non l’IP di uscita che il proxy presenta successivamente ai siti. Acquistare un proxy statico non rende statica la connessione di casa: questi indirizzi appartengono a parti diverse del percorso.
L’accesso resta quindi comodo finché l’origine consentita rimane la stessa. Un programma può riavviarsi o un altro dispositivo consentito può connettersi attraverso quella rete senza aver bisogno di una propria password proxy. Se l’IP in uscita cambia, il vecchio permesso non copre automaticamente il nuovo indirizzo. La guida all’autenticazione tramite IP spiega come identificare l’indirizzo di origine corretto e gestirne l’elenco consentito.
Nome utente e password: permesso fornito dall’applicazione
Con l’autenticazione tramite nome utente e password, il fornitore rilascia credenziali per usare il proxy. L’applicazione le invia come parte del protocollo proxy supportato. Un browser può chiederle all’utente; uno script può fornirle dalla propria configurazione senza mostrare una finestra di accesso.
Quando le credenziali sono l’unico requisito di autenticazione, l’accesso può seguire l’applicazione tra reti diverse. La stessa configurazione funzionante può continuare a connettersi da un nuovo IP di origine. È utile quando il luogo di esecuzione di un’attività cambia più spesso delle impostazioni proxy.
Le credenziali appartengono alla connessione con il proxy. Non sono automaticamente la password della dashboard del fornitore e non ti fanno accedere al sito di destinazione. Quel sito applica comunque le proprie regole di accesso. La guida all’autenticazione con nome utente e password tratta campi di connessione, client supportati e formati delle credenziali.
Autenticazione tramite IP e tramite nome utente/password
Il confronto seguente descrive separatamente i due metodi. Qui l’accesso con password indica l’accesso senza una restrizione IP aggiuntiva; l’accesso combinato è spiegato più avanti.
| Che cosa cambia nella pratica | Autenticazione tramite IP | Nome utente e password |
|---|---|---|
| Base dell’accesso | La connessione deve provenire da un IP di origine consentito. | L’applicazione deve fornire credenziali proxy valide. |
| Impostazioni dell’applicazione | Non servono credenziali proxy, ma restano necessari protocollo, indirizzo e porta corretti del proxy. | L’applicazione deve supportare lo scambio delle credenziali del proxy. |
| Passaggio a un’altra rete | La nuova origine deve già essere consentita oppure essere aggiunta all’elenco. | Le stesse credenziali possono funzionare dalla nuova rete. |
| Più applicazioni | Le applicazioni che usano la stessa uscita di rete consentita ne condividono il permesso IP. | Ogni applicazione deve inviare credenziali accettate dal servizio; più applicazioni possono usare la stessa coppia, se consentito. |
| Che cosa rivela un indirizzo proxy divulgato | Il solo indirizzo con la porta non supera il controllo dell’IP di origine da una rete non approvata. | Una configurazione completa contenente credenziali valide può concedere accesso da un’altra rete. |
| Che cosa gestisci | Gli indirizzi di origine consentiti e i percorsi di rete che li usano. | Le credenziali e le applicazioni configurate per inviarle. |
Nessuno dei due metodi determina il numero di IP di uscita nel servizio. Un IP client consentito o un insieme di credenziali può dare accesso a molti proxy. Nessuno dei due offre a quei proxy connessioni illimitate o rende i loro indirizzi di uscita esclusivi di un cliente.
Come scegliere per applicazione e rete
Verifica prima se l’applicazione può usare il metodo offerto
Un programma può supportare un protocollo proxy senza supportarne ogni opzione di autenticazione. I soli campi di indirizzo e porta non dimostrano che possa inviare nome utente e password. Per esempio, il supporto SOCKS5 integrato in Chrome non include l’autenticazione SOCKS5 con nome utente e password. Credenziali corrette non possono superare questa capacità mancante del client.
Se l’applicazione richiesta supporta il protocollo offerto ma non può inviarne le credenziali, l’autenticazione tramite IP può fornire un percorso utilizzabile. Serve comunque un indirizzo di origine consentito. Quando quell’indirizzo cambia spesso, passare all’accesso tramite IP risolve il problema delle credenziali ma lascia da gestire quello dell’indirizzo di origine. Potrebbero invece servirti un client con il supporto di autenticazione richiesto o un’uscita di rete stabile.
La verifica utile prima dell’acquisto è quindi precisa: questa applicazione può usare questo protocollo proxy con questo metodo di autenticazione? Il successo in un altro browser o strumento da riga di comando non risolve la questione.
Considera poi che cosa cambia abitualmente nella configurazione
L’autenticazione tramite IP si adatta a un lavoro con un’uscita di rete stabile e controllata. Una volta consentita quell’uscita, cambiare programma dietro di essa non richiede di distribuire credenziali proxy a ogni nuovo processo. Le impostazioni di accesso del servizio restano collegate alla rete usata dal lavoro.
Le credenziali si adattano a un lavoro il cui luogo di esecuzione cambia. Se un’attività viene spostata su un altro server o nuovi processi di lavoro partono da reti diverse, l’accesso non richiede una modifica separata dell’elenco consentito per ogni origine, purché il servizio accetti credenziali senza vincolo IP. La configurazione proxy può spostarsi insieme all’applicazione.
La distinzione importante è quanto spesso cambia l’origine in uscita, non se chiami il computer portatile, VPS o server cloud. Un portatile può restare dietro un’uscita fissa dell’ufficio; una distribuzione di server può passare tra indirizzi pubblici. Scegli per il percorso di connessione effettivo e per i cambiamenti previsti durante il normale lavoro.
Se funzionano entrambi, scegli la soluzione più semplice da gestire
Considera chi manterrà le impostazioni. Un amministratore di rete che controlla un’uscita fissa condivisa da più applicazioni può gestire l’accesso con un unico permesso per l’origine. Uno sviluppatore che sposta attività tra ambienti ma non può controllarne gli IP pubblici può trovare più semplice gestire credenziali senza vincolo IP.
Includi le risorse aggiuntive richieste dalla scelta. Un IP pubblico fisso, ulteriori voci nell’elenco consentito o un gateway gestito possono avere un costo. L’accesso con password può evitarlo, ma solo se funziona dalle reti richieste. Confronta le opzioni effettive del servizio; la presenza di una password non rende di per sé un proxy più economico.
Autenticazione combinata: IP e password
Un fornitore può offrire accesso tramite IP e tramite password come alternative oppure richiederli insieme. Sono configurazioni diverse. In modalità combinata, le credenziali valide vengono accettate solo se la connessione proviene anche da un indirizzo o una rete consentiti. La sola password corretta non basta e neppure la sola origine consentita basta.
Può essere adatta alle applicazioni che richiedono campi nome utente e password, mantenendo una restrizione sull’origine dell’accesso. Può anche limitare l’uso di credenziali copiate al di fuori della rete consentita. Non offre la stessa libertà di spostarsi tra reti arbitrarie dell’accesso con password senza vincolo IP.
Nei pacchetti statici ProxyCompass, la modalità combinata accetta credenziali valide da indirizzi IPv4 pubblici dei client nella stessa sottorete /24 di un IP aggiunto alla whitelist. Questi indirizzi hanno gli stessi primi tre numeri. Più indirizzi client in quella sottorete possono quindi usare le credenziali attraverso una sola voce della whitelist. La regola riguarda i client che si connettono al servizio, non gli IP di uscita acquistati. La guida a nome utente e password collegata sopra mostra gli esempi di connessione.
Quale metodo offre più controllo sull’accesso?
L’autenticazione tramite IP colloca la decisione di accesso sull’uscita di rete. Chi ottiene soltanto l’indirizzo del proxy non può usarlo da un’origine diversa e non approvata. Ma il proxy non può identificare le singole persone solo perché condividono un IP consentito. Se più utenti lo raggiungono tramite lo stesso indirizzo pubblico, quel controllo IP vede la stessa origine per tutti. Conta per le uscite condivise degli uffici e gli indirizzi pubblici condivisi tra abbonati Internet.
L’autenticazione tramite nome utente e password colloca il permesso nelle credenziali, che le applicazioni possono presentare indipendentemente dalla propria posizione. Funziona bene tra reti non correlate. Significa anche che una configurazione copiata contenente credenziali valide può restare utilizzabile altrove. Dove un fornitore offre credenziali separate per utenti o attività diversi, queste possono consentire una gestione più dettagliata dell’accesso; una password condivisa da tutti non crea tale separazione.
La scelta dipende quindi da che cosa controlli con maggiore affidabilità: il gruppo di sistemi dietro un’uscita di rete consentita oppure le credenziali fornite alle applicazioni. L’accesso combinato richiede entrambe le condizioni, quindi limita i luoghi da cui possono essere usate anche credenziali valide.
Controllo degli accessi e cifratura sono questioni separate. L’autenticazione tramite IP non cifra il traffico e una password non crea automaticamente una connessione cifrata. Proteggere le credenziali in transito richiede protezione sulla connessione client-proxy stessa. Aprire un sito HTTPS tramite un proxy non protegge di per sé un precedente scambio di accesso non cifrato con quel proxy.
L’autenticazione tramite IP rende un proxy più veloce?
L’accesso tramite IP può evitare uno scambio di credenziali, ma la configurazione iniziale della connessione è diversa tra HTTP e SOCKS. In SOCKS5, l’autenticazione con nome utente e password aggiunge una richiesta e una risposta durante l’avvio. Con HTTP, un client può attendere una richiesta di autenticazione e ripetere la propria richiesta oppure inviare subito le credenziali appropriate. L’accesso con password non aggiunge quindi sempre un percorso di rete di andata e ritorno.
Questa differenza conta soprattutto quando un’attività crea ripetutamente nuove connessioni per piccole quantità di lavoro. Conta meno quando riutilizza connessioni stabilite. Per esempio, richiedere altre pagine allo stesso sito attraverso un tunnel HTTPS esistente non ripete l’accesso al proxy usato per stabilirlo. È un costo di avvio della connessione, non una riduzione fissa della velocità di trasferimento dei dati del proxy.
Se entrambi i metodi sono adatti alla configurazione, confrontali con lo stesso protocollo, risorse proxy simili e il tuo schema reale di connessioni. Un test che apre una nuova connessione per ogni richiesta risponde a una domanda diversa da uno che le riutilizza. Senza tale confronto, affermare che un metodo di autenticazione sia sempre più veloce aiuta poco a scegliere un servizio.
L’autenticazione può rivelare che un indirizzo ospita un proxy?
Sì. Una password può impedire l’uso non autorizzato permettendo comunque a un sistema esterno di riconoscere il servizio. Per esempio, un verificatore può contattare indirizzo e porta di un proxy HTTP senza credenziali valide. Una risposta 407 Proxy Authentication Required con intestazione Proxy-Authenticate identifica esplicitamente una richiesta di autenticazione proxy. Il verificatore non deve conoscere la password per ricevere questa prova.
Un servizio limitato per IP può rivelare meno se blocca un’origine non approvata prima di restituire una risposta proxy riconoscibile. Ma il solo elenco consentito non garantisce tale comportamento: il server potrebbe restituire un rifiuto caratteristico. Anche un endpoint protetto da password può applicare filtri di rete. La differenza rilevante è ciò che una connessione esterna può raggiungere e quale risposta riceve.
Conta anche l’indirizzo verificato. Quando l’indirizzo d’ingresso del proxy e l’IP di uscita coincidono, una risposta riconoscibile può identificare l’indirizzo visto dai siti. Con un gateway che usa IP di uscita diversi, identificare il gateway non identifica di per sé ogni uscita del pool.
Durante la normale navigazione, il sito di destinazione non riceve automaticamente la richiesta di autenticazione del proxy: quello scambio avviene tra client e proxy. Un sito o il suo servizio di rilevamento necessita di altre prove, che potrebbero includere una verifica separata dell’indirizzo. Cambiare la sola autenticazione non può quindi promettere di rendere un IP irriconoscibile come proxy o eliminare informazioni già note su di esso.