Panoramica dei contenuti: quando durante le attività lavorative il test WebRTC mostra una perdita, dovresti prima interrompere il login o le operazioni su account importanti, chiudere l'ambiente corrente, quindi verificare la connessione proxy, la modalità WebRTC, l'IPv6 e le regole di bypass del proxy. Per gli utenti di MostLogin, la procedura comune è: confermare che il rilevamento del proxy abbia successo, impostare WebRTC dell'ambiente su Private; se l'attività non richiede assolutamente audio/video web o comunicazione punto-punto, puoi anche scegliere Disabled; contemporaneamente abilitare la regola di protezione che impedisce l'apertura dell'ambiente in caso di errore del proxy.
Va notato che la comparsa di più indirizzi nella pagina di test non rappresenta necessariamente una perdita. Solo quando la pagina espone il tuo vero IPv4 pubblico reale, il vero IPv6 pubblico reale, o quando compaiono uscite di rete che non dovrebbero essere associate all'ambiente, si tratta di un problema ad alto rischio che richiede un'azione immediata.
Cos'è WebRTC? Perché può aggirare le normali impostazioni del proxy?
WebRTC sta per Web Real-Time Communication, ovvero "comunicazione in tempo reale via web". Consente ai browser di effettuare direttamente chiamate vocali, videoconferenze, condivisione dello schermo e trasferimento di dati punto-punto. Molte piattaforme di meeting online, servizi di assistenza clienti e strumenti di collaborazione lo utilizzano.
Per trovare un percorso di connessione disponibile tra due dispositivi, WebRTC raccoglie più "candidati" tramite ICE. Questi candidati possono includere indirizzi delle interfacce di rete del dispositivo, indirizzi di mappatura pubblica scoperti tramite server STUN e indirizzi inoltrati tramite server TURN. La documentazione MDN sui tipi di candidati ICE indica che i candidati host rappresentano gli indirizzi diretti del dispositivo, i candidati srflx sono generati dall'interazione STUN/TURN e i candidati relay passano attraverso il relay TURN. Spiegazione MDN sulla connettività WebRTC
Questa è anche la causa principale delle perdite WebRTC: le pagine web creano connessioni WebRTC tramite JavaScript e leggono i candidati ICE. Se il browser non limita correttamente questi indirizzi, le informazioni di rete visibili dalla pagina potrebbero non corrispondere all'uscita del proxy. MDN afferma inoltre che gli indirizzi dei candidati ICE possono rivelare informazioni sulla posizione del dispositivo e sulla topologia di rete oltre le aspettative dell'utente e possono essere utilizzati per il fingerprinting del browser. Note di sicurezza MDN su RTCIceCandidate
In sintesi: le normali richieste web possono passare attraverso il proxy, ma WebRTC cerca anche percorsi di comunicazione in tempo reale. Quando questi due percorsi non sono uniformemente limitati, i siti web possono vedere sia l'"IP del proxy" che "un altro gruppo di indirizzi di rete".
Quando si parla effettivamente di perdita WebRTC?
Per determinare una perdita non basta guardare se la pagina di test mostra un IP, bisogna confrontare "ciò che la pagina mostra" con "ciò che l'ambiente dovrebbe mostrare".
| Risultato del test | È una perdita? | Valutazione del rischio |
|---|---|---|
| L'IP pubblico WebRTC corrisponde all'IP proxy rilevato da MostLogin | Di solito no | Normale, continuare a verificare la coerenza di DNS, fuso orario e posizione geografica |
| Mostra il vero IP pubblico di rete domestica, aziendale o hotspot mobile | Sì | Alto rischio, interrompere immediatamente le operazioni sull'account nell'ambiente corrente |
| Il proxy è IPv4, ma la pagina di test mostra il vero IPv6 pubblico | Sì | Alto rischio, indica che l'IPv6 potrebbe non essere coperto dal proxy |
Mostra indirizzi privati come 192.168.x.x, 10.x.x.x | Non necessariamente | Si tratta di esposizione di informazioni LAN, di solito non è una perdita dell'uscita pubblica, ma aumenta le informazioni del fingerprint di rete |
Mostra nomi .local casuali | Di solito no | Nella maggior parte dei casi è il risultato del browser che utilizza mDNS per nascondere gli indirizzi locali |
| Mostra più indirizzi, ma tutti appartengono alla stessa uscita proxy o relay | Di solito no | Potrebbero essere IPv4, IPv6 o diversi tipi di candidati ICE |
I browser moderni possono utilizzare nomi host mDNS al posto degli IP di rete locale, quindi la comparsa di risultati simili a stringhe casuali con .local nella pagina di test non equivale all'esposizione del vero IP pubblico. Ciò che realmente richiede attenzione è: sono apparsi indirizzi ISP pubblici reali che hai verificato essere al di fuori dell'ambiente browser?
Quali sono le conseguenze di una perdita WebRTC?
1. Conflitto tra identità proxy e identità di rete reale
Supponiamo che un ambiente MostLogin sia configurato con un proxy di New York, USA, e le richieste web mostrino l'IP di New York, ma WebRTC esponga l'IP pubblico della rete locale dell'utente. La piattaforma non vede un ambiente di navigazione naturale e stabile, ma due segnali di connessione con posizione geografica o operatore di rete in conflitto.
Questo non prova automaticamente chi sia l'utente, ma indebolisce l'effetto di isolamento del proxy e può diventare uno dei segnali per controlli anomali dei rischi, verifiche aggiuntive o revisioni della sessione.
2. Ambienti browser diversi possono essere associati dallo stesso IP reale
Il team crea più ambienti indipendenti per diversi progetti di test, ognuno con un proxy diverso. Se tutti questi ambienti espongono lo stesso IP pubblico dell'ufficio tramite WebRTC, il sito può ottenere un segnale di correlazione che si ripete tra gli ambienti. Anche se Cookie, Canvas e WebGL sono ciascuno isolati, l'uscita di rete reale che si ripete riduce l'indipendenza tra gli ambienti.
3. Espone posizione approssimativa, operatore di rete e struttura di rete
L'IP pubblico può generalmente essere utilizzato per determinare paese, area a livello cittadino e operatore di rete; gli indirizzi LAN, IPv6 o diverse interfacce di rete possono rivelare ulteriori caratteristiche della topologia di rete. L'IP di solito non può determinare da solo un indirizzo preciso o un nome reale, ma può essere combinato con account registrati, cookie, fingerprint del dispositivo e dati comportamentali.
4. Le videoconferenze e le chiamate web possono presentare un compromesso tra "privacy e usabilità"
Disabilitare direttamente WebRTC può spesso ridurre la superficie di esposizione, ma le videoconferenze, l'assistenza vocale, la condivisione dello schermo o il trasferimento diretto di file che dipendono da WebRTC potrebbero non funzionare correttamente. Pertanto, l'approccio corretto non è chiuderlo indiscriminatamente in tutti gli scenari, ma scegliere tra Private e Disabled in base alle esigenze aziendali.
Dopo che il browser anti-detect mostra una perdita WebRTC, fai prima questi 6 passaggi
Passaggio 1: Interrompi le operazioni sensibili nell'ambiente corrente
Se la pagina di rilevamento ha già mostrato l'IP pubblico reale, non continuare con login, pagamenti, pubblicazione di contenuti o cambio di account importanti. Prima registra i risultati del test, tra cui:
- L'indirizzo mostrato dal rilevamento IP normale;
- L'IPv4 e l'IPv6 mostrati dal rilevamento WebRTC;
- L'indirizzo proxy e il paese/regione configurati in MostLogin;
- Orario del test, nome dell'ambiente e se è stata utilizzata una VPN.
Registrare le informazioni serve a localizzare il problema; non si consiglia di conservare password proxy, cookie dell'account o altre credenziali negli screenshot.
Passaggio 2: Stabilire un confronto tra "IP reale — IP proxy — IP WebRTC"
Eseguire tre gruppi di controlli senza aprire gli account aziendali:
- In un browser normale senza proxy, controllare l'IPv4 e l'IPv6 pubblici correnti come baseline di rete reale.
- Nella scheda
Proxydi MostLogin, fare clic sul controllo IP proxy e registrare l'uscita prevista. - Aprire l'ambiente corrispondente e leggere gli indirizzi candidati nella pagina di test WebRTC.
Se il risultato WebRTC corrisponde al primo gruppo di baseline, non al secondo gruppo di uscita proxy, si può sostanzialmente confermare che esiste una perdita. Se il risultato corrisponde all'IP proxy, è più probabile che si tratti di una normale visualizzazione dei candidati WebRTC.
Passaggio 3: Correggere prima il proxy, poi regolare WebRTC
Le impostazioni WebRTC non possono risolvere un proxy già offline, con autenticazione fallita o configurato in modo errato. Accedere alla pagina di modifica dell'ambiente target, aprire la scheda Proxy, verificare protocollo, host, porta, nome utente e password, quindi eseguire il controllo IP proxy. La guida ufficiale di MostLogin sulla creazione di ambienti indica che attualmente si possono configurare direct, http, https e socks5 e verificare il risultato della connessione tramite "Check proxy IP". MostLogin: Creare un nuovo ambiente
Continuare al passaggio successivo solo dopo che il controllo del proxy ha avuto successo e il paese e la città mostrati corrispondono alle aspettative.
Passaggio 4: Selezionare la modalità WebRTC appropriata in MostLogin
Il percorso operativo è generalmente:
Profiles (Elenco ambienti) → Selezionare l'ambiente target → Edit (Modifica) → Fingerprint (Fingerprint) → WebRTC
La documentazione ufficiale attuale di MostLogin mostra le impostazioni a tendina WebRTC, dove Private viene utilizzato per nascondere l'IP reale mantenendo le funzionalità WebRTC, e potrebbero essere disponibili anche Public e Disabled. MostLogin: Istruzioni sulle impostazioni del fingerprint WebRTC
| Modalità | Scenari consigliati | Note |
|---|---|---|
| Private | Web quotidiano, browser che necessita di audio/video, assistenza clienti o strumenti di collaborazione | Scelta preferita; dopo il salvataggio è necessario ritestare e confermare che i risultati corrispondano al proxy |
| Disabled | Ambienti che non necessitano affatto di videoconferenza, audio o funzionalità P2P | Confine di privacy più definito, ma le funzionalità web correlate potrebbero fallire |
| Public | Solo per test di sviluppo o compatibilità che richiedono esplicitamente candidati di rete pubblici | Non adatto ad ambienti proxy che richiedono di nascondere l'uscita di rete reale |
Per gli ambienti proxy normali, si consiglia di utilizzare prima Private. Solo quando l'attività non dipende da WebRTC o la modalità Private non soddisfa ancora i requisiti di isolamento, testare Disabled. Non considerare automaticamente come perdita il semplice fatto che la pagina di test mostri "WebRTC enabled"; la cosa importante è quale indirizzo restituisce.
Passaggio 5: Abilitare la protezione in caso di errore proxy e controllare la lista di bypass proxy
Accedere alle impostazioni globali di MostLogin o alle preferenze dell'ambiente e abilitare le seguenti protezioni:
- Non aprire l'ambiente in caso di errore di rete del proxy;
- Non aprire l'ambiente quando l'IP proxy cambia;
- Non aprire l'ambiente quando il paese o la regione dell'IP proxy cambia;
- Non aprire l'ambiente in caso di fallimento della sincronizzazione.
MostLogin descrive queste impostazioni come protezioni pre-avvio, dove la protezione dagli errori di rete del proxy impedisce l'esposizione accidentale dell'IP ISP reale quando il proxy non funziona. MostLogin: Profile preferences
Controllare anche Settings → Proxy bypass. I domini aggiunti alla lista di bypass utilizzano direttamente la rete locale invece del proxy dell'ambiente corrente. La documentazione ufficiale di MostLogin afferma inoltre esplicitamente che i domini bypassati vengono accessi tramite connessioni locali reali. MostLogin: Proxy bypass Se il sito di test, i domini di autenticazione o i loro domini API/CDN sono presenti qui, rimuovere le eccezioni non necessarie e salvare.
Passaggio 6: Chiudere completamente e riaprire l'ambiente, eseguire test incrociati
Dopo aver salvato le impostazioni, chiudere l'intero ambiente browser e riaprirlo, non limitarsi ad aggiornare la pagina di rilevamento. Verificare utilizzando almeno due pagine di rilevamento indipendenti:
- L'IP pubblico normale visualizzato dal browser;
- L'IPv4 nei candidati WebRTC;
- L'IPv6 nei candidati WebRTC;
- Se DNS, fuso orario, lingua e posizione geografica corrispondono all'area del proxy.
Il criterio di superamento del ritest è: la pagina di rilevamento non mostra più IPv4/IPv6 pubblici ISP reali; gli indirizzi pubblici mostrati da WebRTC devono corrispondere al proxy, all'uscita relay o al comportamento previsto del prodotto; i risultati rimangono stabili dopo il riavvio dell'ambiente.
Esempio di utilizzo di MostLogin: Ambiente proxy di New York rilevato con vero IPv6
Scenario
Un team QA di siti web transregionali ha creato un ambiente MostLogin chiamato US-NewYork-QA-01, il controllo proxy HTTP mostra un IPv4 di New York, USA. Dopo aver aperto la pagina di test, l'IP normale rimane di New York, ma l'area WebRTC mostra un IPv6 pubblico proveniente dall'operatore di rete locale.
Diagnosi
Si tratta di una perdita reale, non del caso normale di "comparsa di più IP". Il motivo è che il proxy HTTP copre le richieste web IPv4, ma il percorso di rete IPv6 dell'host non viene gestito allo stesso modo e i candidati WebRTC possono ancora esporre quell'indirizzo.
Soluzione
- Chiudere l'ambiente per evitare di continuare i test di accesso.
- Verificare se il servizio proxy supporta esplicitamente IPv6; in caso contrario, utilizzare una soluzione proxy che copra completamente IPv4/IPv6 o disabilitare il percorso IPv6 non protetto a livello di rete di sistema.
- Modificare l'ambiente, in
Fingerprint → WebRTCselezionare Private. - Abilitare "Non aprire l'ambiente in caso di errore di rete del proxy".
- Controllare la lista di bypass proxy e rimuovere i domini di eccezione relativi al sito di test.
- Riaprire l'ambiente e ritestare, confermando che l'IPv6 reale non appaia più.
In questo scenario, cambiare solo la modalità WebRTC potrebbe eliminare temporaneamente il rilevamento, ma la copertura IPv6 del proxy rimane il problema fondamentale, quindi entrambi vanno verificati.
Esempio di utilizzo di MostLogin: La pagina di test mostra .local, ma l'IP pubblico corrisponde al proxy
Scenario
L'utente utilizza un proxy UK, sia l'IP normale che l'indirizzo pubblico WebRTC mostrano il Regno Unito; la pagina di test elenca inoltre una stringa casuale che termina con .local e l'utente pensa erroneamente che ci sia stata una perdita.
Valutazione
.local è tipicamente un modo in cui il browser nasconde gli indirizzi di rete locale utilizzando nomi mDNS. Finché non appare un vero IPv4/IPv6 pubblico ISP e i candidati pubblici corrispondono al proxy UK, non si può stabilire una perdita di IP reale basandosi solo su .local.
Soluzione
Mantenere l'impostazione Private corrente, registrare il risultato e passare a un'altra pagina di test per la verifica incrociata. In questo caso, cambiare frequentemente proxy, randomizzare i fingerprint o ricostruire l'ambiente potrebbe invece introdurre più variazioni in un ambiente di test che dovrebbe rimanere stabile.
Esempio di utilizzo di MostLogin: Le videoconferenze non si connettono dopo aver disabilitato WebRTC
Scenario
Il team di supporto remoto ha impostato WebRTC su Disabled e le chiamate di assistenza clienti web e la condivisione dello schermo non riescono a stabilire una connessione.
Soluzione
Cambiare l'ambiente su Private, mantenere il proxy connesso correttamente, quindi ritestare l'indirizzo WebRTC. Se l'IP reale non appare più e le funzionalità audio/video si ripristinano, si possono conciliare funzionalità e isolamento di rete. Se la perdita persiste in modalità Private, bisogna verificare il protocollo proxy, l'IPv6, lo split tunneling VPN e i domini di bypass, invece di scegliere direttamente Public per ripristinare la chiamata.
La perdita persiste dopo la correzione, dove potrebbe essere il problema?
Se MostLogin è stato impostato su Private ma il test mostra ancora l'IP pubblico reale, continuare a verificare nel seguente ordine:
- Il proxy non è effettivamente connesso. Quando le credenziali sono errate, il nodo è scaduto o il server proxy è offline, il browser potrebbe non ottenere l'uscita prevista.
- L'IPv6 non è coperto. Il proxy gestisce solo IPv4, l'host può ancora accedere alla rete tramite l'IPv6 reale.
- Regole di bypass del proxy. Il sito di test o i sottodomini correlati sono impostati per la connessione diretta.
- Split tunneling VPN o conflitti di routing di sistema. L'uso simultaneo di VPN, proxy di sistema e proxy dell'ambiente può creare diversi percorsi di rete.
- Il processo del vecchio ambiente è ancora in esecuzione. L'ambiente non è stato completamente chiuso dopo il salvataggio delle impostazioni, il vecchio processo utilizza ancora la configurazione originale.
- Le estensioni del browser modificano il comportamento di rete. Le estensioni VPN, proxy, privacy o WebRTC possono entrare in conflitto con le impostazioni dell'ambiente.
- Falso positivo o cache della pagina di rilevamento. Utilizzare una seconda pagina di test e riavviare l'ambiente per verificare, non basarsi su un singolo risultato.
Se due pagine di test indipendenti mostrano entrambe stabilmente lo stesso indirizzo pubblico reale, salvare screenshot senza credenziali sensibili, il numero di versione di MostLogin, il sistema operativo, il protocollo proxy e i passaggi per riprodurre il problema, quindi contattare il supporto MostLogin o il fornitore del proxy.
Checklist per la prevenzione delle perdite WebRTC
Dopo il primo utilizzo di ogni nuovo ambiente, il cambio di proxy, l'aggiornamento del client o il cambio di rete, eseguire una volta i seguenti controlli:
Domande frequenti
Il test WebRTC mostra più IP, significa sicuramente che c'è una perdita?
Non necessariamente. Più risultati possono provenire rispettivamente da IPv4, IPv6, interfacce LAN, mappatura STUN, relay TURN o mDNS. Solo la comparsa di veri IP pubblici ISP, uscite di rete non correlate o indirizzi pubblici in evidente conflitto con la posizione del proxy deve essere considerata una perdita ad alto rischio.
Dopo aver utilizzato un proxy, quale IP dovrebbe mostrare WebRTC?
Idealmente, la pagina web non dovrebbe vedere il tuo vero IP pubblico ISP. A seconda delle strategie del browser e del prodotto, la pagina di test potrebbe mostrare l'indirizzo proxy, l'indirizzo relay, candidati locali nascosti o nessun indirizzo disponibile. Il criterio non è "può apparire solo un IP", ma "non devono apparire vere uscite di rete pubbliche che devono essere isolate".
In MostLogin devo scegliere Private o Disabled?
Quando sono necessarie funzionalità come audio/video web, chiamate di assistenza o condivisione dello schermo, scegliere prima Private e ritestare; quando non si utilizzano affatto le funzionalità WebRTC, si può scegliere Disabled. Disabled potrebbe influire sulle funzionalità del sito, quindi non è la soluzione ottimale predefinita per tutti gli ambienti.
Una perdita WebRTC può rivelare il nome reale e l'indirizzo preciso?
Di solito non è possibile ottenere direttamente il nome reale o l'indirizzo preciso solo dall'IP, ma l'IP pubblico può rivelare l'area approssimativa e l'operatore e può essere combinato con account, cookie, fingerprint del browser e registri comportamentali per formare indizi di correlazione più forti.
È sufficiente correggere le impostazioni dopo una perdita?
La correzione può solo impedire ulteriori esposizioni, non può ritirare i dati già ricevuti dal sito. Per le attività importanti, controllare l'intervallo di tempo in cui si è verificata la perdita, gli ambienti interessati e i registri di accesso; se necessario, terminare le vecchie sessioni, aggiornare le credenziali e monitorare se la piattaforma presenta verifiche anomale.
Conclusione
Il punto centrale delle perdite WebRTC non è "se WebRTC è abilitato", ma se espone indirizzi pubblici reali non coerenti con l'ambiente proxy corrente. Dopo aver rilevato anomalie, interrompere prima le operazioni sensibili, quindi completare il confronto utilizzando i tre gruppi di dati: IP reale, IP proxy e IP WebRTC. Gli utenti di MostLogin possono generalmente risolvere il problema verificando la connessione proxy, selezionando WebRTC Private, abilitando la protezione dagli errori proxy, rimuovendo le regole di bypass non necessarie e verificando il percorso IPv6.
Includere i controlli WebRTC nel processo fisso prima del lancio di un nuovo ambiente è molto più affidabile che cercare di rimediare dopo la comparsa di anomalie dell'account. Ritestare dopo ogni cambio di proxy, rete o versione del client per garantire che l'uscita di rete e il fingerprint del browser rimangano coerenti nel tempo.
