Bir proxy HTTP trafiğini kapsarken WebRTC, STUN/ICE üzerinden UDP ile aday adresleri değiş tokuş edebilir. Bu yazı, yerel ve özel ağ adreslerinin ne zaman açığa çıkabildiğini ve ağ çıkışı ile tarayıcı ortamının nasıl tutarlı tutulacağını açıklar.
Proxy’yi kurdunuz ve bir IP sorgulama sayfası beklediğiniz bölgeyi ve internet servis sağlayıcısını gösteriyor. Ağ kimliğiniz temiz görünür. Ancak bir sızıntı testi açtığınızda WebRTC bölümü kırmızıya döner ve gerçek internet bağlantınızın adresini gösterir.
Hemen proxy değiştirmeye gerek yok. Çoğu durumda sorun proxy’nin kalitesinden değil, onun denetleyemediği trafikten kaynaklanır.
Proxy HTTP’yi yönetir, WebRTC ise başka bir yol kullanır
Proxy ağ katmanında çalışır. İster tarayıcı eklentisi ister sistem düzeyinde tünel olarak kullanılsın, HTTP/HTTPS isteklerini işler ve bu trafiği proxy çıkışından gönderir.
WebRTC farklı çalışır. Tarayıcıya yerleşik bir gerçek zamanlı iletişim özelliğidir. Sesli/görüntülü aramalar ve P2P aktarımlar uygun bir yol bulabilsin diye tarayıcı harici sunuculara etkin olarak STUN sorguları gönderebilir — özünde “Benim için hangi adresi görüyorsun?” diye sorar — ve ardından yanıtları ICE adayları olarak düzenleyip web sayfasına iletir. Bu sorgular UDP kullanır ve HTTP tünelinden bağımsız bir kanaldan geçer.
Böylece bir uyumsuzluk oluşur: web istekleri proxy’den çıkarken tarayıcı aynı anda yerel bir adresi bildirebilir. Bir proxy yapılandırmanın otomatik olarak tüm ağ kimliğini temizlediğini varsaymak, bu sorunun en yaygın başlangıç noktasıdır.
Yalnızca genel IP adresi açığa çıkmaz
ICE adayları genellikle iki tür adres içerir. Biri genel adrestir; yani gerçek internet servis sağlayıcınızın çıkışı. Diğeri ise örneğin 192.168 ile başlayan özel bir adres gibi yerel adrestir; bazen sanal ağ bağdaştırıcısına ait bir adres de görülebilir.
Özel ağ adresi tek başına çok şey kanıtlamaz; neredeyse her bilgisayarda vardır. Ancak yeterince kararlı olabilir ve birden fazla hesapta aday adreslerin tekrar tekrar örtüşmesi, platforma bu hesapları aynı cihazla ilişkilendirmek için ek bir sinyal verebilir. Genel adres daha doğrudandır: gerçek servis sağlayıcıyı ve yaklaşık coğrafi bölgeyi gösterir. Hassasiyet düzeyi platforma bağlıdır, ancak yön açıktır: adres ne kadar gerçekse ilişkilendirme o kadar kolay olur.
Bir site bu adresi gerçekten ne zaman okuyabilir?
Her site bunu yapmaya çalışmaz. Adres değişimi için sayfanın etkin olarak bir RTCPeerConnection nesnesi oluşturması gerekir; sıradan içerik sayfalarının buna genellikle ihtiyacı yoktur.
Bunu yapanlar çoğunlukla birkaç gruba ayrılır: görüntülü toplantılar, çevrimiçi müşteri desteği ve bazı canlı yayın sayfaları gibi gerçek zamanlı iletişim gerektiren siteler; gelir modeli büyük ölçüde reklam veya dolandırıcılık önlemeye dayanan siteler; ve gelişmiş risk kontrol sistemlerine sahip platformlar. Okuma işlemi görünür arayüzün dışında gerçekleşir; veriler toplandıktan sonra nasıl kullanıldığına dair genellikle bildirim almazsınız.
Siteyle ilgisi olmayan bir durum da vardır. Proxy yeniden bağlanırken veya düğüm değiştirirken geçen kısa sürede tarayıcının STUN isteği yerel ağ üzerinden çıkabilir. Bu pencere çok kısadır, ancak tek bir gözlemin kaydedilmesi için yeterlidir.
Üç yaygın başarısızlık senaryosu
Tarayıcı eklentisi biçimindeki proxy’ler genellikle yalnızca HTTP/HTTPS isteklerini devralır. UDP kapsam dışında kalır ve arayüzde “global” seçeneğini işaretlemek bunu değiştirmez.
Sistem düzeyinde global proxy daha kapsamlı görünür çünkü tüm cihaz trafiğini kapsar. Ancak aday adres toplama işlemi doğrudan yerel bir ağ arayüzüne bağlanabilir ve sistem yönlendirme tablosunu atlayabilir; bu noktada tünelde bir açıklık kalır.
Üçüncü sorun yalnızca teknik değil, kontrollerin zamanla değişmesiyle de ilgilidir. Risk kontrol sistemleri WebRTC adreslerini hesapları ilişkilendirmede kullanılan sinyallerden biri olarak giderek daha fazla dikkate almaktadır. Geçmişte ölçülmeyen veya önemsenmeyen veriler artık değerlendirmeye dahil edilebilir.
Amaç tek bir anahtarı kapatmak değil, tutarlı bir çıkış sağlamaktır
Birkaç genel yaklaşım vardır. Bir iş akışı gerçek zamanlı iletişime hiç ihtiyaç duymuyorsa WebRTC’yi devre dışı bırakmak en kolay seçenektir; bunun bedeli görüntülü aramalar ve çevrimiçi müşteri desteği gibi özelliklerin de çalışmamasıdır.
Bu özelliklerin korunması gerekiyorsa yaygın yaklaşım, WebRTC katmanında dönen adresi proxy çıkışıyla tutarlı hale getirmektir. Daha sağlam bir yöntem, STUN isteklerini de proxy kanalı üzerinden ileterek arayüzün yerel adresi açığa çıkarmamasını sağlamaktır. P2P veya görüntülü arama gerekiyorsa yalnızca HTTP katmanı değil, tüm UDP trafiği proxy üzerinden geçmelidir.
Sık yapılan bir hata, yalnızca WebRTC’yi kapatmanın ortamı temiz hale getirdiğini düşünmektir. Asıl önemli olan ağ çıkışı, DNS çözümleme, IP sahipliği ve ASN, saat dilimi ve dil ile cihaz özelliklerinin birbirleriyle tutarlı olmasıdır. Bunlardan herhangi birindeki uyumsuzluk olağandışı bir sinyal bırakabilir; WebRTC yalnızca en kolay gözden kaçan öğelerden biridir.
Doğrulama basittir. Düğüm değiştirdikten sonra ve ortamı normal kullanıma almadan önce birer test yapın: bir sızıntı testi açın ve WebRTC bölümünün proxy çıkışını mı, yerel bir adresi mi yoksa gerçek genel adresi mi gösterdiğini kontrol edin. Sıradan bir IP sorgulaması bu bilgiyi göstermez.
Tarayıcı motoru düzeyinde ortam izolasyonu, her ortam için ayrı bir WebRTC adres politikası belirleyebilir ve bunu o ortamın ağ çıkışıyla eşleştirebilir. PurpleMark bu tür bir yetenek sunar. Birden fazla ortam aynı çıkışı kullanırsa veya adres politikaları birbiriyle tutarsızsa izolasyonun değeri önemli ölçüde azalır.
Bu metin yalnızca teknik bir açıklamadır. İlgili araçları platform kurallarına ve yerel yasalara uygun şekilde kullanın.
