Anti-tespit tarayıcısı WebRTC sızıntısı gösterdiğinde ne yapmalı? MostLogin ile sorun giderme ve düzeltme kılavuzu

İçerik Özeti: İşlemleriniz sırasında WebRTC kontrolü sızıntı gösterdiğinde, önce önemli hesaplarınıza giriş yapmayı veya işlem yapmayı durdurmalı, mevcut ortamı kapatmalı, ardından proxy bağlantısını, WebRTC modunu, IPv6'yı ve proxy atlama kurallarını kontrol etmelisiniz. MostLogin kullanıcıları için yaygın çözüm yöntemleri şunlardır: Proxy bağlantısının başarılı olduğunu doğrulayın, ortamın WebRTC ayarını Private (Gizli) olarak ayarlayın; işleminiz web ses/video veya uçtan uca iletişime hiç ihtiyaç duymuyorsa, Disabled (Devre Dışı) seçeneğini de tercih edebilirsiniz; aynı zamanda proxy arızası durumunda ortamın açılmasını engelleyen koruma kuralını etkinleştirin.

Test sayfasında birden fazla adres görünmesinin mutlaka sızıntı anlamına gelmediğini unutmamak gerekir. Yalnızca sayfa gerçek genel IPv4 adresinizi, gerçek genel IPv6 adresinizi ifşa ettiğinde veya o ortamla ilişkilendirilmemesi gereken ağ çıkışları ortaya çıktığında, acilen müdahale edilmesi gereken yüksek riskli bir sorun söz konusudur.

WebRTC nedir? Neden normal proxy ayarlarını atlayabilir?

WebRTC'nin açılımı Web Real-Time Communication, yani "Web Gerçek Zamanlı İletişim"dir. Tarayıcıların doğrudan sesli arama, video konferans, ekran paylaşımı ve noktadan noktaya veri aktarımı yapmasına olanak tanır; birçok çevrimiçi toplantı, müşteri hizmetleri çağrısı ve işbirliği aracı bunu kullanır.

İki cihaz arasında kullanılabilir bir bağlantı yolu bulmak için WebRTC, ICE aracılığıyla birden fazla "aday adres" toplar. Bu aday adresler, cihazın ağ arayüzü adreslerini, STUN sunucusu aracılığıyla keşfedilen genel ağ haritalama adreslerini ve TURN sunucusu aracılığıyla aktarılan adresleri içerebilir. MDN'deki ICE aday türleri açıklamasına göre, host adayları cihazın doğrudan adreslerini temsil eder, srflx adayları STUN/TURN etkileşimi tarafından oluşturulur, relay adayları ise TURN aktarımı üzerinden geçer. MDN'nin WebRTC bağlantı açıklaması

Bu aynı zamanda WebRTC sızıntısının temel nedenidir: Web sayfası JavaScript aracılığıyla WebRTC bağlantısı oluşturur ve ICE adaylarını okur; tarayıcı bu adresleri doğru şekilde kısıtlamazsa, sayfanın gördüğü ağ bilgileri proxy çıkışıyla tutarsız olabilir. MDN ayrıca, ICE aday adreslerinin kullanıcının beklediğinden fazla cihaz konumu ve ağ topolojisi bilgisini ifşa edebileceğini ve tarayıcı parmak izi tanımlamasında kullanılabileceğini açıkça belirtmektedir. MDN'nin RTCIceCandidate güvenlik açıklaması

Basit bir şekilde anlayın: Normal web istekleri proxy üzerinden gidebilir, ancak WebRTC gerçek zamanlı iletişim için ayrı yollar da arar. Bu iki yol birleşik olarak kısıtlanmadığında, web sitesi aynı anda hem "proxy IP" hem de "başka bir grup ağ adresi" görebilir.

Ne zaman WebRTC sızıntısı sayılır?

Sızıntıyı belirlemek için yalnızca test sayfasında IP görünmesine bakmak yetmez; "sayfada ne göründüğü" ile "ortamın normalde ne göstermesi gerektiğini" karşılaştırmak gerekir.

Modern tarayıcılar yerel ağ IP'si yerine mDNS ana bilgisayar adları kullanabilir; bu nedenle test sayfasında rastgele bir dize ve .local son eki görünmesi, gerçek genel IP'nin ifşa olduğu anlamına gelmez. Gerçekten dikkat edilmesi gereken nokta şudur: Tarayıcı ortamınızın dışında sorguladığınız gerçek ISS genel adresi görünüyor mu?

WebRTC sızıntısının sonuçları nelerdir?

1. Proxy kimliği ile gerçek ağ kimliği çakışıyor

Diyelim ki bir MostLogin ortamı New York, ABD proxy'si ile yapılandırılmış ve web istekleri de New York IP'sini gösteriyor, ancak WebRTC kullanıcının yerel ağının genel IP'sini ifşa ediyor. Platform doğal ve istikrarlı bir tarama ortamı yerine, iki farklı coğrafi konum veya ağ operatörünün çakışan bağlantı sinyallerini görür.

Bu durum kullanıcının kim olduğunu otomatik olarak kanıtlamaz, ancak proxy izolasyon etkisini zayıflatır ve anormal risk kontrolü, ek doğrulama veya oturum incelemesi sinyallerinden biri haline gelebilir.

2. Farklı tarayıcı ortamları aynı gerçek IP ile ilişkilendirilebilir

Ekip farklı test projeleri için birden fazla bağımsız ortam oluşturur ve her ortam farklı proxy kullanır. Eğer bu ortamların hepsi WebRTC aracılığıyla aynı ofis genel IP'sini ifşa ederse, web sitesi ortamlar arası tekrarlanan bir ilişkilendirme sinyali elde edebilir. Cookie, Canvas ve WebGL her biri bağımsız olarak izole edilse bile, tekrarlanan gerçek ağ çıkışları ortamlar arası bağımsızlığı azaltır.

3. Yaklaşık konum, ağ operatörü ve ağ yapısı ifşa olur

Genel IP genellikle ülke, şehir düzeyinde bölge ve ağ operatörünü belirlemek için kullanılabilir; yerel ağ adresleri, IPv6 veya farklı ağ arayüzleri daha fazla ağ topolojisi özelliğini ortaya çıkarabilir. IP tek başına genellikle kesin adres veya gerçek kimlik belirleyemez, ancak giriş hesapları, cookie'ler, cihaz parmak izi ve davranış verileriyle birlikte kullanılabilir.

4. Video konferans ve web aramalarında "gizlilik ve kullanılabilirlik" dengesi gerekebilir

WebRTC'yi doğrudan devre dışı bırakmak genellikle ilgili saldırı yüzeyini azaltır, ancak WebRTC'ye bağımlı video konferans, sesli müşteri hizmetleri, ekran paylaşımı veya doğrudan dosya aktarımı düzgün çalışmayabilir. Bu nedenle doğru yaklaşım tüm senaryolarda toplu olarak kapatmak değil, iş ihtiyaçlarına göre Private ve Disabled arasında seçim yapmaktır.

Anti-tespit tarayıcısı WebRTC sızıntısı gösterdiğinde önce bu 6 adımı uygulayın

Adım 1: Mevcut ortamdaki hassas işlemleri durdurun

Eğer test sayfası zaten gerçek genel IP'yi gösteriyorsa, giriş yapmaya, ödeme yapmaya, içerik yayınlamaya veya önemli hesap geçişleri yapmaya devam etmeyin. Önce test sonuçlarını kaydedin:

• Normal IP algılama sayfasının gösterdiği adres;
• WebRTC algılama sayfasının gösterdiği IPv4 ve IPv6;
• MostLogin'de yapılandırılan proxy adresi ve ülke/bölge;
• Test zamanı, ortam adı ve VPN kullanılıp kullanılmadığı.

Bilgileri kaydetmek sorunu tespit etmek içindir; ekran görüntülerinde proxy şifreleri, hesap cookie'leri veya diğer kimlik bilgilerinin korunması önerilmez.

Adım 2: "Gerçek IP — Proxy IP — WebRTC IP" karşılaştırması oluşturun

İş hesaplarını açmadan üç grup kontrol yapın:

1. Proxy kullanmadan normal tarayıcıda mevcut genel IPv4 ve IPv6'yı sorgulayarak gerçek ağ taban çizgisini belirleyin.
2. MostLogin'de Proxy sekmesinde proxy IP kontrolüne tıklayarak beklenen çıkışı kaydedin.
3. İlgili ortamı açın ve WebRTC test sayfasında aday adresleri okuyun.

Eğer WebRTC sonuçları birinci grup taban çizgisine eşit ve ikinci grup proxy çıkışına eşit değilse, büyük olasılıkla sızıntı var demektir. Sonuçlar proxy IP'siyle tutarlıysa, bu muhtemelen normal WebRTC aday gösterimidir.

Adım 3: Önce proxy'yi düzeltin, ardından WebRTC'yi ayarlayın

WebRTC ayarları zaten çevrimdışı, kimlik doğrulaması başarısız veya yanlış yapılandırılmış bir proxy'yi düzeltemez. Hedef ortamın düzenleme sayfasına gidin, Proxy sekmesini açın, protokol, ana bilgisayar, port, hesap adı ve şifreyi doğrulayın, ardından proxy IP kontrolünü çalıştırın. MostLogin resmi ortam oluşturma kılavuzu, mevcut olarak direct, http, https ve socks5 yapılandırılabilir olduğunu ve "Check proxy IP" ile bağlantı sonucunun doğrulanabileceğini belirtir. MostLogin: Yeni ortam oluşturma

Sadece proxy kontrolü başarılı olduktan ve gösterilen ülke ile şehir beklendiği gibi olduktan sonra bir sonraki adıma geçin.

Adım 4: MostLogin'de uygun WebRTC modunu seçin

İşlem yolu genellikle şöyledir:

Profiles (Ortam Listesi) → Hedef ortamı seçin → Edit (Düzenle) → Fingerprint (Parmak İzi) → WebRTC

MostLogin resmi belgeleri WebRTC açılır menü ayarlarını göstermektedir; Private WebRTC işlevselliğini korurken gerçek IP'yi gizlemek için kullanılır, ayrıca Public ve Disabled seçenekleri de sunulabilir. MostLogin: WebRTC parmak izi ayarları açıklaması

Normal proxy ortamları için önce Private kullanılması önerilir. Sadece iş WebRTC'ye bağımlı olmadığında veya Private modu izolasyon gereksinimlerini karşılamadığında Disabled test edilmelidir. Sadece test sayfasında "WebRTC enabled" göründü diye sızıntı olduğu sonucuna varmayın; önemli olan hangi adresin döndürüldüğüdür.

Adım 5: Proxy arıza korumasını etkinleştirin ve proxy atlama listesini kontrol edin

MostLogin'in genel ayarlarına veya ortam tercih ayarlarına giderek aşağıdaki korumaları etkinleştirin:

• Proxy ağ hatası olduğunda ortamı açma;
• Proxy IP değiştiğinde ortamı açma;
• Proxy IP ülkesi veya bölgesi değiştiğinde ortamı açma;
• Ortam senkronizasyonu başarısız olduğunda ortamı açma.

MostLogin bu ayarları başlatma öncesi koruma önlemleri olarak tanımlar; proxy ağ hatası koruması, proxy devre dışı kaldığında gerçek ISS IP'sinin yanlışlıkla ifşa olmasını engeller. MostLogin: Profil tercihleri

Ayrıca Settings → Proxy bypass bölümünü de kontrol edin. Atlama listesine eklenen etki alanları, mevcut ortamın proxy'si yerine doğrudan yerel ağı kullanır. MostLogin resmi açıklaması da açıkça, atlanan etki alanlarının gerçek yerel bağlantı üzerinden erişileceğini belirtir. MostLogin: Proxy bypass Test siteleri, kimlik doğrulama etki alanları veya bunların API/CDN etki alanları burada bulunuyorsa, gereksiz istisnaları kaldırın ve kaydedin.

Adım 6: Ortamı tamamen kapatıp yeniden açın ve çapraz yeniden test yapın

Ayarları kaydettikten sonra tüm tarayıcı ortamını kapatıp yeniden başlatın; sadece test sayfasını yenilemeyin. En az iki bağımsız test sayfası kullanarak kontrol edin:

• Tarayıcının dışarıya gösterdiği normal genel IP;
• WebRTC adaylarındaki IPv4;
• WebRTC adaylarındaki IPv6;
• DNS, saat dilimi, dil ve coğrafi konumun proxy bölgesiyle tutarlı olup olmadığı.

Yeniden testin geçme kriterleri şunlardır: Test sayfası artık gerçek ISS genel IPv4/IPv6 göstermiyor; WebRTC'nin gösterdiği genel adresler proxy, aktarma çıkışı veya ürünün beklenen davranışıyla tutarlı olmalıdır; ortam yeniden başlatıldıktan sonra sonuçlar hâlâ kararlı olmalıdır.

MostLogin kullanım örneği: New York proxy ortamında gerçek IPv6 algılandı

Senaryo

Bölgesel bir web sitesi QA ekibi US-NewYork-QA-01 adında bir MostLogin ortamı oluşturdu; HTTP proxy kontrolü ABD New York IPv4'ünü gösterdi. Test sayfası açıldığında, normal IP hâlâ New York'tu, ancak WebRTC bölgesinde yerel ISS'den gelen bir genel IPv6 adresi belirdi.

Tanılama

Bu gerçek bir sızıntıdır, "birden fazla IP görünmesi" durumu değildir. Bunun nedeni HTTP proxy'nin IPv4 web isteklerini kapsaması, ancak ana makinenin IPv6 ağ yolunun aynı şekilde işlenmemiş olmasıdır; WebRTC adayları hâlâ bu adresi ifşa edebilir.

Çözüm

1. Ortamı kapatın ve giriş testlerine devam etmeyin.
2. Proxy hizmetinin açıkça IPv6'yı destekleyip desteklemediğini kontrol edin; desteklemiyorsa, IPv4/IPv6'yı tam olarak kapsayabilen bir proxy çözümü kullanın veya sistem ağ katmanında korunmamış IPv6 yolunu devre dışı bırakın.
3. Ortamı düzenleyin, Fingerprint → WebRTC bölümünde Private seçeneğini seçin.
4. "Proxy ağ hatası olduğunda ortamı açma" seçeneğini etkinleştirin.
5. Proxy atlama listesini kontrol edin ve test siteleriyle ilgili istisna etki alanlarını kaldırın.
6. Ortamı yeniden açın ve gerçek IPv6'nın artık görünmediğini doğrulayın.

Bu senaryoda, sadece WebRTC modunu değiştirmek algılama sonuçlarını geçici olarak ortadan kaldırabilir, ancak proxy'nin IPv6 kapsamı hâlâ temel sorundur; bu nedenle her ikisi de kontrol edilmelidir.

MostLogin kullanım örneği: Test sayfasında .local görünüyor, ancak genel IP proxy ile tutarlı

Senaryo

Kullanıcı İngiltere proxy'si kullanıyor, normal IP ve WebRTC genel adresleri ikisi de İngiltere'yi gösteriyor; test sayfası ayrıca rastgele bir dize ile biten .local adresi listeliyor ve kullanıcı bunu sızıntı olarak yanlış yorumluyor.

Değerlendirme

.local genellikle tarayıcının yerel ağ adreslerini gizlemek için mDNS adı kullanmasının bir göstergesidir. Gerçek ISS genel IPv4/IPv6 görünmediği ve genel adaylar İngiltere proxy'siyle tutarlı olduğu sürece, sadece .local temelinde gerçek IP sızıntısı belirlenemez.

Çözüm

Mevcut Private ayarını koruyun, sonucu kaydedin ve çapraz doğrulama için farklı bir test sayfası kullanın. Bu durumda sık sık proxy değiştirmek, parmak izini rastgeleleştirmek veya ortamı yeniden oluşturmak, istikrarlı olması gereken test ortamında daha fazla değişiklik yaratabilir.

MostLogin kullanım örneği: WebRTC kapatıldıktan sonra video konferans bağlanamıyor

Senaryo

Uzaktan destek ekibi WebRTC'yi Disabled olarak ayarladıktan sonra, web tabanlı müşteri hizmetleri çağrıları ve ekran paylaşımı bağlantı kuramıyor.

Çözüm

Ortamı Private olarak değiştirin, proxy bağlantısının normal çalıştığından emin olun ve ardından WebRTC adreslerini yeniden test edin. Gerçek IP artık görünmüyor ve ses/video geri dönüyorsa, hem işlevsellik hem de ağ izolasyonu sağlanmış olur. Private modunda hâlâ sızıntı varsa, doğrudan Public seçmek yerine proxy protokolünü, IPv6'yı, VPN bölünmesini ve atlama etki alanlarını sorunu gidermek gerekir.

Düzeltmeden sonra hâlâ sızıntı varsa, sorun nerede olabilir?

MostLogin Private olarak ayarlanmışsa ancak test hâlâ gerçek genel IP gösteriyorsa, aşağıdaki sırayla kontrol etmeye devam edin:

1. Proxy aslında bağlı değil. Kimlik bilgileri hatalı, düğüm süresi dolmuş veya proxy sunucusu çevrimdışı olduğunda, tarayıcı beklenen çıkışı elde edemeyebilir.
2. IPv6 kapsanmamış. Proxy sadece IPv4'ü işliyor, ana makine hâlâ gerçek IPv6 üzerinden ağa erişebiliyor.
3. Proxy atlama kuralları. Test sitesi veya ilgili alt etki alanları doğrudan bağlantı için ayarlanmış.
4. VPN bölünmesi veya sistem yönlendirme çakışması. Aynı anda VPN, sistem proxy'si ve ortam proxy'si kullanmak farklı ağ yolları oluşturabilir.
5. Eski ortam süreci hâlâ çalışıyor. Ayarlar kaydedildikten sonra ortam tamamen kapatılmamış, eski süreç hâlâ orijinal yapılandırmayı kullanıyor.
6. Tarayıcı uzantıları ağ davranışını değiştiriyor. VPN, proxy, gizlilik veya WebRTC uzantıları ortam ayarlarıyla çakışıyor olabilir.
7. Algılama sayfası yanlış değerlendirme veya önbellek. İkinci bir test sayfası kullanın ve ortamı yeniden başlatarak doğrulayın; tek bir sonuca dayanarak karar vermeyin.

İki bağımsız test sayfası da istikrarlı bir şekilde aynı gerçek genel adresi gösteriyorsa, hassas kimlik bilgilerini içermeyen ekran görüntüleri, MostLogin sürüm numarası, işletim sistemi, proxy protokolü ve yeniden üretim adımlarını kaydedin, ardından MostLogin desteği veya proxy hizmet sağlayıcısı ile iletişime geçin.

WebRTC sızıntı önleme kontrol listesi

Her yeni ortam ilk kez kullanıldığında, proxy değiştirildiğinde, istemci güncellendiğinde veya ağ değiştirildiğinde aşağıdaki kontrolleri bir kez uygulayın:

•  MostLogin proxy IP kontrolü başarılı;
•  WebRTC Private olarak ayarlandı veya gerçek zamanlı iletişim gerekmediğinde Disabled olarak ayarlandı;
•  Normal genel IP beklenen proxy çıkışıyla tutarlı;
•  WebRTC gerçek ISS genel IPv4'ünü göstermiyor;
•  WebRTC gerçek ISS genel IPv6'sını göstermiyor;
•  DNS, saat dilimi, dil ve proxy konumu arasında belirgin çakışma yok;
•  Proxy hata ve IP değişimi koruması etkinleştirildi;
•  Proxy bypass'ta gereksiz doğrudan bağlantı etki alanı yok;
•  Ortam yeniden başlatıldıktan sonra test sonuçları hâlâ tutarlı.

Sıkça sorulan sorular

WebRTC testi birden fazla IP gösterdi, bu mutlaka sızıntı mı demek?

Hayır, mutlaka değil. Birden fazla sonuç IPv4, IPv6, yerel ağ arayüzü, STUN haritalaması, TURN aktarımı veya mDNS'den geliyor olabilir. Sadece gerçek ISS genel IP'si, ilgisiz ağ çıkışları veya proxy konumuyla açıkça çakışan genel adresler göründüğünde yüksek riskli sızıntı olarak değerlendirilmelidir.

Proxy kullandıktan sonra WebRTC hangi IP'yi göstermeli?

İdeal olarak, web sayfası gerçek ISS genel IP'nizi görmemelidir. Tarayıcı ve ürün stratejisine bağlı olarak, test sayfası proxy adresini, aktarma adresini, gizlenmiş yerel adayları gösterebilir veya kullanılabilir adres göstermeyebilir. Değerlendirme kriteri "sadece bir IP görünebilir" değil, "izole edilmesi gereken gerçek genel ağ çıkışı görünmemeli"dir.

MostLogin'de Private mi Disabled mi seçmeliyim?

Web ses/video, müşteri hizmetleri çağrıları veya ekran paylaşımı gerektiğinde öncelikle Private seçin ve yeniden test edin; WebRTC işlevlerini hiç kullanmadığınızda Disabled seçebilirsiniz. Disabled web sitesi işlevlerini etkileyebilir, bu nedenle tüm ortamlar için varsayılan en iyi çözüm olmayabilir.

WebRTC sızıntısı gerçek adı ve kesin adresi ifşa edebilir mi?

Genellikle sadece IP ile gerçek ad veya kesin kapı adresi doğrudan elde edilemez, ancak genel IP yaklaşık bölge ve operatörü ortaya çıkarabilir ve hesaplar, cookie'ler, tarayıcı parmak izi ve davranış kayıtlarıyla birleştirilerek daha güçlü ilişkilendirme ipuçları oluşturabilir.

Bir kez sızıntı yaşandı, sadece ayarları düzeltmek yeterli mi?

Düzeltme sadece sonraki ifşayı durdurabilir, web sitesinin zaten aldığı verileri geri alamaz. Önemli işler için sızıntının gerçekleştiği zaman aralığını, etkilenen ortamları ve giriş kayıtlarını kontrol etmelisiniz; gerektiğinde eski oturumları sonlandırın, kimlik bilgilerini güncelleyin ve platformda anormal doğrulama görünüp görünmediğini izleyin.

Özet

WebRTC sızıntısının temel noktası "WebRTC'nin açık olup olmadığı" değil, mevcut proxy ortamıyla tutarsız gerçek genel adresleri ifşa edip etmediğidir. Anormallik tespit edildikten sonra, önce hassas işlemler durdurulmalı, ardından gerçek IP, proxy IP ve WebRTC IP'den oluşan üç grup veri ile karşılaştırma tamamlanmalıdır. MostLogin kullanıcıları genellikle proxy bağlantısını kontrol ederek, WebRTC Private seçerek, proxy arıza korumasını etkinleştirerek, gereksiz proxy atlama kurallarını temizleyerek ve IPv6 yolunu doğrulayarak sorunu çözebilirler.

WebRTC kontrolünü yeni ortam devreye alınmadan önce sabit bir sürece dahil etmek, hesap anormalliği ortaya çıktıktan sonra müdahale etmeye çalışmaktan çok daha güvenilirdir. Her proxy, ağ veya istemci sürümü değişikliğinden sonra yeniden test yapmak, ağ çıkışının ve tarayıcı parmak izinin uzun vadede tutarlı kalmasını sağlar.