Proxy Üzerinden DNS: socks5 vs socks5h, Uzak Çözümleme ve Sızıntılar

Bir sahne hayal edin. İstediğiniz bölgenin proxy'sine bağlandınız, IP adresini kontrol ettiniz - her şey doğru, şehir ve ülke eşleşiyor. Ancak hedef site inatla size farklı içerik gösteriyor ve dolandırıcılık önleme sistemi oturumu şüpheli olarak işaretliyor. Tanıdık geldi mi? Büyük ihtimalle proxy kullanımındaki en sinsi olaylardan biriyle karşılaştınız - DNS sızıntısı veya yanlış alan adı çözümleme yolu.

Bu makale, trafik proxy üzerinden geçerken alan adının IP adresine nasıl dönüştürüldüğüne dair kapsamlı bir rehberdir. socks5 ve socks5h şemalarının temelde nasıl farklılaştığını, DNS sorgusunu kimin ve hangi aşamada gönderdiğini, sitenin neden bazen beklediğiniz bölgeyi göstermediğini ve popüler istemcilerde ve kütüphanelerde uzak çözümlemeyi nasıl yapılandıracağınızı inceleyeceğiz. Konu dar ama son derece önemli. Görünüşte doğru yapılandırılmış binlerce konfigürasyon, tam da ad çözümleme aşamasında çöküyor.

Giriş: Proxy bağlıyken neden site farklı bölge görüyor?

Okuyucuların çoğunu bu konuya getiren semptomla başlayalım. Proxy'yi ayarladınız. IP adresi doğru bir şekilde değiştirilmiş - bunu herhangi bir IP belirleme servisinde kolayca kontrol edebilirsiniz. Yine de bir şeyler ters gidiyor: site başka bir ülkenin yerelleştirmesini gösteriyor, CDN sizi beklenmedik bir düğüme yönlendiriyor ve bazen hedef kaynağın güvenlik sistemi, görünür bir neden olmaksızın isteği engelliyor.

Nedeni neredeyse her zaman aynıdır. HTTP veya uygulama trafiğiniz gerçekten proxy üzerinden geçiyor, ancak DNS sorgusu - example.com gibi bir adı belirli bir IP adresine dönüştüren sorgu - proxy'yi atlayarak doğrudan makinenizden çıkıyor. Ve bu sorgu sizi ele veriyor.

Neden böyle olur? Çünkü ad çözümleme ve veri iletimi iki farklı aşamadır ve farklı yollar izleyebilir. Birçok istemci varsayılan olarak adı yerel olarak çözümler ve proxy'ye zaten hazır olan IP bağlantısını gönderir. Ağ açısından mantıklıdır. Gizlilik ve coğrafi konum açısından ise bir felakettir.

Bu materyalin sonunda şunları anlayacaksınız:

• ad çözümlemeyi tam olarak kim yapar - işletim sistemi, uygulama kütüphanesi, tarayıcı mı yoksa proxy sunucusu mu;
• socks5 şemasının socks5h'den protokol düzeyinde nasıl farklılaştığı ve neden tek bir harfin her şeyi değiştirdiği;
• HTTP proxy'deki CONNECT yönteminin çözümleme sorununu neredeyse otomatik olarak nasıl çözdüğü;
• görünüşte doğru yapılandırmada bile DNS'nin hangi kanallardan sızdığı;
• curl, Python, Node.js, Go, Chrome, Firefox, Selenium ve Playwright'ta uzak çözümlemenin nasıl etkinleştirileceği;
• dig, nslookup ve tcpdump gibi araçlarla fiili çözümleme yolunun nasıl kontrol edileceği.

Sınırları hemen belirleyelim. Hangi genel DNS sunucusunun daha iyi olduğunu tartışmıyoruz veya belirli sağlayıcılar önermiyoruz. Konumuz yalnızca proxy üzerinden çalışırken çözümleme yolu. Ne fazla ne eksik.

Temeller: Ad çözümleme nedir ve kim yapar?

Sızıntıları anlamak için öncelikle çözümleme mekaniğini iyice kavramalısınız. Adım adım inceleyelim.

Alan adı çözümleme nedir?

Bilgisayarlar IP adresleriyle iletişim kurar, insanlar ise adlarla. Çözümleme (İngilizce resolve, çözmek), shop.example.com gibi insan tarafından okunabilir bir adı 93.184.216.34 gibi bir makine IP adresine dönüştürme işlemidir. Bu adım olmadan hiçbir bağlantı mümkün değildir: tarayıcı, IP'yi alana kadar hangi sunucuya bağlanacağını bilemez.

Çözümleme, ayrı bir ağ işlemidir. Genellikle 53 numaralı bağlantı noktasında UDP veya TCP üzerinden DNS protokolünü kullanır. İstemci, çözümleyiciye bir sorgu gönderir, çözümleyici bir yanıt döndürür. Kilit nokta: bu sorguyu tam olarak kimin ve hangi yoldan gönderdiği, tüm konumuzun merkezindeki sorudur.

Dört olası çözümleme uygulayıcısı

Bir uygulama example.com ile iletişim kurmak istediğinde, çözümlemeyi dört katılımcıdan biri gerçekleştirebilir. Her birini inceleyelim.

1. İşletim sistemi

Çoğu uygulama adları kendisi çözümlemez. Sistem işlevine - C dünyasında bu getaddrinfo'dur - başvururlar. İşletim sisteminin kendi çözümleyicisi (stub resolver) vardır; hangi DNS sunucusuna başvuracağını bilir, yerel bir önbellek tutar ve hosts dosyasını dikkate alır. Bu en yaygın yoldur. Ve sızıntılar açısından en tehlikelisidir: sistem çözümleyicisi varsayılan olarak doğrudan ağa gider, proxy'nizi yok sayar.

2. Uygulama kütüphanesi

Bazı programlar ve kütüphanelerin kendi çözümleme mantığı vardır; bu mantık, görevi işletim sistemine devredebilir, kendisi gerçekleştirebilir veya - en önemlisi - adı proxy sunucusuna iletebilir, böylece çözümleme uzak tarafta gerçekleşir. socks5h şemaları ve proxy barındırma tam olarak bu mekanizmayı uygular.

3. Tarayıcı

Modern tarayıcılar başlı başına bir evrendir. Kendi çözümleme politikaları, kendi DNS önbellekleri, DoH (DNS over HTTPS), bağlantı ön yükleme ve WebRTC gibi mekanizmaları vardır. Tarayıcı, adı sistem ayarlarından tamamen bağımsız olarak çözümleyebilir, bu da başlı başına bir sızıntı sınıfı oluşturur.

4. Proxy sunucusu

Gizlilik için ideal senaryo. İstemci adı hiç çözümlemez. Ana bilgisayar adı dizesini proxy sunucusuna iletir, proxy kendi tarafında çözümlemeyi yapar ve gerekli IP'ye bağlanır. Hedef site açısından DNS sorgusu sizin ağınızdan değil, proxy ağından gelir.

Anahtar benzetme

Başka bir şehre bir kurye (proxy) ile paket gönderdiğinizi düşünün. İki yol vardır. Birincisi: Alıcının tam adresini evinizdeki rehberden kendiniz öğrenir, koordinatları paketin üzerine yazarsınız ve kuryeye yalnızca koordinatları verirsiniz. Şehrinizdeki rehber, hedef şehirdeki rehberden farklı bir adres verebilir - ve siz bunu fark etmezsiniz. İkinci yol: Kuryeye yalnızca alıcının adını verirsiniz, o da adresi yerinde, yerel rehberden bulur. İkinci yol uzak çözümlemedir. Adresin ağın doğru noktasından belirlenmesini garanti eder.

socks5 ve socks5h: Çözümleme kararı nerede alınır?

Şimdi konunun kalbine geliyoruz. socks5 ve socks5h arasındaki fark kozmetik değildir ve eş anlamlı değildir. Bunlar temelde farklı çözümleme yollarıdır, ancak SOCKS5 protokolü aynıdır.

SOCKS5 protokolü ne diyor?

SOCKS5 protokolü esnektir. Bağlantı kurma komutunda istemci, hedef adres türünü belirtir. Üç seçenek mümkündür:

• IPv4 adresi - istemci hazır bir IP iletir;
• IPv6 adresi
• - aynı, ancak IPv6 için;
• alan adı - istemci bir ad dizisi iletir ve bu durumda çözümlemeyi proxy sunucusu yapmak zorundadır.

Yani protokolün kendisi hem yerel hem de uzak çözümlemeyi destekler. Sorun yalnızca istemcinin hangi adres türünü göndereceğidir. İşte bu noktada şemaların adlandırma kuralları devreye girer.

socks5 şeması: Yerel çözümleme

İstemci socks5 şemasını (h harfi olmadan) kullandığında, yerleşik kural gereği bu şu anlama gelir: adı yerel olarak çözümle. İstemci önce kendi çözümleyicisine (genellikle sistem çözümleyicisi) example.com'un IP'sini sorar, adresi alır ve ardından proxy sunucusuna hazır IPv4 veya IPv6'yı iletir.

Hedef site ne görür? Proxy'den gelen bağlantıyı görür - bu doğrudur. Ancak DNS sorgusu sizin ağınızdan, sizin tarafınızdan, yerel çözümleyiciniz aracılığıyla gönderilmiştir. Çözümleyiciniz coğrafi veya mantıksal olarak bölgenize bağlıysa, hedef altyapı CDN ve DNS coğrafi konumu aracılığıyla tam olarak sizin bölgenizi belirleyebilir, proxy bölgesini değil. Girişteki semptom da buradan gelir.

socks5h şeması: Uzak çözümleme

socks5h'deki h harfi hostname - ana bilgisayar adı anlamına gelir. Bu şema istemciye şunu söyler: kendin çözümleme, adı proxy sunucusuna ilet. İstemci, adres türü alan adı olan bir komut gönderir ve proxy sunucusu kendi tarafında çözümlemeyi gerçekleştirir.

Hedef site şimdi ne görür? DNS sorgusu, proxy'nin kullandığı çözümleyiciden, yani proxy ağından gelir. DNS'ye göre coğrafi konum, proxy bölgesini işaret eder. Yerel çözümleyiciniz hiç devreye girmez ve nereye gittiğiniz hakkında hiçbir şey bilmez. Bu, çoğu görev için doğru, temiz yoldur.

Mekanik karşılaştırma tablosu

Farkları kompakt bir şekilde toplayalım:

• socks5: Çözümlemeyi istemci (İS/kütüphane) yapar. Proxy IP alır. DNS sorgusu sizin ağınızdan gider. Coğrafi uyumsuzluk ve sızıntı olasıdır.
• socks5h: Çözümlemeyi proxy yapar. Proxy adı alır. DNS sorgusu proxy ağından gider. Bölge tutarlıdır, sızıntı yoktur.

Basit bir kuralı hatırlayın: gizlilik ve coğrafi konum doğruluğu önemliyse her zaman socks5h kullanın. Tek bir harf saatlerce sürecek hata ayıklamayı kurtarır.

Bu kural neden böyle?

Tarihsel bir not anlamaya yardımcı olur. Başlangıçta SOCKS istemcileri kendileri çözümlerdi çünkü protokolün ilk sürümleri (SOCKS4) adları iletemiyordu. SOCKS5 alan adı desteğini ekledi, ancak araç ekosistemi davranışı açıkça ayırt etmek için h sonekini getirdi. Bugün curl, Python ve birçok HTTP istemcisinin anladığı socks5 / socks5h ikilisi böyle doğdu. Bu, bir RFC parçası değil, fiili bir adlandırma standardıdır.

HTTP ve HTTPS proxy'si: CONNECT yöntemi neden proxy'de çözümler?

SOCKS tek proxy türü değildir. İş görevlerinin büyük bir kısmı HTTP proxy'si kullanır. Ve burada çözümleme mekaniği farklıdır, birçok durumda daha başarılıdır.

Proxy üzerinden normal HTTP isteği

Bir HTTP kaynağına (şifresiz) HTTP proxy'si üzerinden gittiğinizde, istemci proxy'ye mutlak URL ile tam bir istek gönderir. İstek satırı ana bilgisayar adını içerir. Proxy adı görür, kendisi çözümler ve sunucuya bağlanır. Yani normal HTTP proxy'sinde çözümleme doğal olarak proxy tarafında gerçekleşir. İstemcinin IP'yi bilmesine gerek yoktur.

HTTPS için CONNECT yöntemi

HTTPS ile işler daha ilginçtir. Şifreli trafiği proxy okuyamaz - ve okumamalıdır. Bu nedenle HTTPS için özel bir CONNECT yöntemi kullanılır. İstemci proxy'ye CONNECT example.com:443 şeklinde bir komut gönderir. Dikkat edin - burada ana bilgisayar adı iletilir, IP değil.

Sonra ne olur? Proxy sunucusu adı alır, kendi tarafında çözümler, hedef IP'ye bir TCP tüneli açar ve şeffaf bir boru haline gelir. Bu borunun içinde istemciniz ile hedef sunucu arasında tam bir TLS el sıkışması gerçekleşir - proxy bunu çözmez.

Anahtar sonuç: CONNECT yöntemiyle HTTP proxy'sinin doğru uygulanmasında, çözümleme varsayılan olarak uzaktır. Ad proxy'ye gider, proxy kendisi çözümler. Bu, HTTP proxy'sinin HTTPS trafiği için genellikle yanlış yapılandırılmış SOCKS'den daha doğru davranmasının nedenlerinden biridir.

İstemci optimizasyonu uyarısı

Önemli bir nüans var. Bazı istemciler bağlantıyı optimize etmek için yine de CONNECT'i göndermeden önce adı yerel olarak çözümler ve ardından CONNECT'e ad yerine IP adresini iletir. Biçimsel olarak bu kabul edilebilir, ancak uzak çözümlemenin tüm faydasını ortadan kaldırır. Bu nedenle HTTP proxy'sinde bile davranışa körü körüne güvenmeyin - kontrol edin. Kontrol yöntemlerini ayrı bir bölümde ele alacağız.

Ayrı bir terim olarak HTTPS proxy'si

İki anlamı karıştırmayın. Bazen HTTPS proxy'si, HTTPS trafiğini (CONNECT aracılığıyla) proxy'leyen proxy anlamına gelir. Bazen de kendisine olan bağlantının TLS ile şifrelendiği (yani istemci-proxy kanalının korunduğu) proxy anlamına gelir. Bunlar farklı şeylerdir. Çözümleme açısından birincisi daha önemlidir: hedef adın nasıl iletildiği. Proxy'ye giden kanalın şifrelenmesi, çözümleme yolunu doğrudan etkilemez, ancak adın sizinle proxy arasındaki bir gözlemciye karşı korunmasını sağlar.

DNS sızıntıları: Oluşma mekaniği ve tipik senaryolar

Şimdi en ilginç kısım - sızıntıların anatomisi. DNS sızıntısı, DNS sorgusunun proxy'yi atlayarak gerçek çözümleyicinizi, bölgenizi veya belirli bir alana eriştiğiniz gerçeğini açığa çıkardığı durumdur. Her biri farklı bir tedavi gerektirdiği için senaryoları tek tek inceleyelim.

Senaryo 1: Sistem çözümleyicisi proxy'yi atlıyor

En yaygın durum. Uygulamayı socks5'e (h'siz) yapılandırdınız veya istemci uzak çözümlemeyi desteklemiyor. Uygulama sistem getaddrinfo'sunu çağırır, işletim sistemi DNS sorgusunu kendi çözümleyicisine doğrudan ağ üzerinden, proxy'yi atlayarak gönderir. Veriler daha sonra proxy üzerinden gider, ancak ad zaten sızmıştır.

Nasıl tanınır: Proxy'ye IP bazında bağlantılar gelir, ad bazında değil. Makinenizin ağ dökümünde proxy tüneline sarılmamış, 53 numaralı bağlantı noktasına giden giden paketler görülür.

Tedavi: socks5h'ye geçin, istemcide uzak çözümlemeyi etkinleştirin veya uygulamayı DNS için doğrudan ağ erişimi olmayacak şekilde yalıtın.

Senaryo 2: Tarayıcıda WebRTC

WebRTC, tarayıcılar arasında doğrudan ses, video ve veri aktarımı için gerçek zamanlı bir teknolojidir. Bağlantı kurmak için WebRTC, ICE mekanizmasını kullanır; bu mekanizma adayları toplar - STUN sunucularının ana bilgisayarlarını çözümler ve yapılandırılmış proxy'yi atlayan istekler başlatabilir. Tarihsel olarak WebRTC, çalışan bir proxy varken bile gerçek adresleri açığa çıkarmasıyla bilinir. Modern tarayıcılar politikaları önemli ölçüde sıkılaştırmış olsa da, yapılandırma dikkatli değilse risk devam eder.

Tedavi: Tarayıcıda WebRTC politikasını kontrol edin, ICE aday işlemeyi devre dışı bırakın veya sınırlayın, WebRTC dahil tüm trafiği proxy üzerinden yönlendiren tarayıcı ayarlarını kullanın.

Senaryo 3: Tarayıcıda yerleşik DoH

Modern tarayıcılar DNS over HTTPS - kendi DoH sağlayıcısına şifreli bir HTTPS isteği aracılığıyla çözümleme - yapabilir. Sorun şu ki, bu istek SOCKS şemanızı atlayarak, doğrudan makineden gidebilir; eğer tarayıcı kendi DoH'si aracılığıyla çözümleyecek şekilde yapılandırılmışsa ve bu trafiği proxy'ye sarmıyorsa. Bir paradoks oluşur: ad, sağlayıcıdan şifreli ve gizli bir şekilde çözümlenir, ancak proxy'nizi atlar, bu da coğrafi konum görevleri için en kötü durumdur. Bu mekanizmayı DoH bölümünde ayrıntılı olarak inceleyeceğiz.

Senaryo 4: Paralel IPv6 yolu

En sinsi senaryo. Proxy'niz IPv4 üzerinde çalışıyor, uzak çözümlemeyi yapılandırdınız. Ancak makinenizde çalışan bir IPv6 var ve istemci, Happy Eyeballs algoritmasını (IPv4 ve IPv6 ile eş zamanlı denemeler) takip ederek AAAA kayıtlarını çözümlemeye ve doğrudan proxy'yi atlayarak IPv6 üzerinden bağlanmaya çalışır. Trafiğin bir kısmı ve DNS, proxy'yi atlar. Bölge kayar, bağlantının bir kısmı yanlış yere gider.

Tedavi: Proxy'lenen uygulama için IPv6'yı devre dışı bırakın veya proxy'nin IPv6'yı desteklediğinden ve AAAA çözümlemesi dahil tüm trafiğin onun üzerinden gittiğinden emin olun. Birçok görev için istemciyi yalnızca IPv4 ile sınırlamak daha kolaydır.

Senaryo 5: Önbellek ve ön yükleme

Tarayıcılar ve işletim sistemleri DNS'yi agresif bir şekilde önbelleğe alır ve bağlantıları önceden kurar (preconnect, prefetch). Proxy yapılandırmasından önce önbellek doldurulmuşsa, uygulama yeni yapılandırmayı atlayarak eski kayıtları veya önceden kurulmuş bağlantıları kullanabilir. Küçük bir şey, ancak hata ayıklama sırasında çileden çıkarabilir.

Tedavi: İşletim sistemi ve tarayıcı DNS önbelleğini temizleyin, yeniden başlatın, tanılama sırasında agresif ön yüklemeyi devre dışı bırakın.

Sızıntıların genel kalıbı

Ortak bir kalıp fark ettiniz mi? Tüm sızıntılar tek bir noktaya indirgenir: adın veya bağlantının proxy üzerinden gitmediği bir kanal vardır. Mühendisin görevi, tüm bu kanalları bulup kapatmaktır. Sızıntı her zaman kapalı olmayan bir kapıdır, mistisizm değil.

Araçlara göre pratik: Uzak çözümleme nasıl etkinleştirilir

İşe koyulalım. Belirli istemcileri inceleyelim ve yerel çözümlemeyi önleyerek uzak çözümlemeyi nasıl etkinleştireceğinizi gösterelim. Bu en uygulamalı bölüm - elinizin altında bulunsun.

curl: socks5 ve socks5-hostname

curl, farkı anlamak için referans bir araçtır. Açık bir seçim sunar.

• --socks5 host:port - yerel çözümleme. curl IP'yi kendisi belirler, ardından proxy üzerinden gider.
• --socks5-hostname host:port - uzak çözümleme. curl adı proxy sunucusuna iletir.

--proxy seçeneği aracılığıyla da şemayı kontrol edebilirsiniz: socks5://... yerel çözümleme, socks5h://... ise uzak çözümleme verir. Uzak çözümleme için doğru çağrı örneği: curl --proxy socks5h://kullanici:sifre@proxyhost:1080 https://example.com. HTTP proxy'si için http://... şeması CONNECT yöntemiyle varsayılan olarak proxy'de çözümler, ancak yine de gerçek davranışı kontrol etmekte fayda var.

Python: requests ve httpx

Python ekosisteminde socks5h şeması, uzak çözümleme için altın standarttır.

requests için SOCKS desteği paketi gerekir. Proxy bir sözlükle belirtilir: https ve http için socks5h://kullanici:sifre@host:port şemasını kullanın. h'siz socks5:// şeması yerel çözümleme anlamına gelir - yeni başlayanlarda sızıntıların en yaygın nedenidir. Tek bir harf çözer.

httpx için mantık benzerdir: uzak çözümleme için proxy'yi socks5h:// şemasıyla iletin. httpx şemalar konusunda katıdır ve davranışı iyi belgeler, ancak prensip aynıdır - h harfi çözümlemeyi proxy tarafına kaydırır.

Önemli bir gözlem: socks5h belirtmiş olsanız bile, ortam değişkenlerinden (HTTP_PROXY, ALL_PROXY) farklı bir şemayla gelen sistem proxy'sinin devreye girmediğini kontrol edin. Ortam değişkenleri niyetlerinizi geçersiz kılabilir.

Node.js

Node.js'de standart http'de doğrudan SOCKS desteği yoktur. Proxy üzerinden bağlantı kuran SOCKS aracıları kullanılır. Bu tür aracıların kilit parametresi, adın yerel olarak çözümlenip çözümlenmeyeceğini belirleyen seçenektir. Popüler SOCKS aracılarında, genellikle lookup benzeri bir şey olarak adlandırılan ve DNS'den sorumlu bir bayrak bulunur: yerel aramayı devre dışı bırakan değerde ad proxy'ye iletilir. Aracının hostname iletecek şekilde yapılandırıldığından ve dns.lookup aracılığıyla önceden çözümleme yapmadığından emin olun.

Pratik tavsiye: Node'da özellikle bağlantı kurmadan önce kodda bir yerde dns.resolve veya dns.lookup çağrılmadığını dikkatlice kontrol edin. Böyle bir erken çözümleme, uzak yolu geçersiz kılar.

Go

Go'da standart kütüphane proxy ile çalışmak için bir paket sağlar. golang.org/x/net/proxy aracılığıyla bir SOCKS5 dialer oluşturulabilir. Varsayılan davranış, Dial'a bir ad mı yoksa önceden çözümlenmiş bir adres mi ilettiğinize bağlıdır. Anahtar, dialer'a tam olarak alan adını, net.LookupHost sonucunu değil, iletmektir. Kendiniz çözümleme yapıp IP ilettiyseniz, bu yerel çözümlemedir ve tüm sonuçlarıyla birlikte gelir. Doğru yaklaşım: dialer'a host:port dizesini adla birlikte iletin ve önceden çözümleme yapmayın.

Chrome: Başlatma bayrakları

Chrome, komut satırı bayrakları ve politikalar aracılığıyla yönetilir. Proxy belirtmek için proxy-server bayrağı kullanılır. Kritik olan, Chrome'un SOCKS5 üzerinden çalışırken varsayılan olarak yerel çözümleme yapabilmesidir. Proxy'lenen bağlantılar için çözümlemenin proxy tarafında yapılmasını sağlayan bir bayrak vardır - adı host-resolver-rules ile ilgilidir ve tüm ana bilgisayarları proxy üzerinden geçmeye zorlayan bir ayardır. Ayrıca yerleşik DoH kontrolü de önemlidir: tarayıcıda Güvenli DNS etkinse ve kendi sağlayıcısına yapılandırılmışsa, şemanızı atlayabilir. Test saflığı için tanılama sırasında Güvenli DNS genellikle devre dışı bırakılır ve WebRTC politikası sıkılaştırılır.

Firefox: about:config ayarları

Firefox tarihsel olarak çözümleme kontrolü için daha uygundur. Anahtar ayar network.proxy.socks_remote_dns'dir. Bunu true olarak ayarlayın; Firefox, yerel çözümleme yerine SOCKS proxy'sine uzak çözümleme için ana bilgisayar adlarını gönderecektir. Bu, tüm materyaldeki en önemli ayarlardan biridir. Ek olarak şunları kontrol edin:

• network.trr.mode - DoH modu (TRR, Güvenilir Özyinelemeli Çözümleyici). Zorunlu DoH'u devre dışı bırakan bir değer, çözümlemenin yalnızca proxy üzerinden gitmesini istiyorsanız önemlidir.
• media.peerconnection.enabled - ICE aracılığıyla sızıntıyı önlemek için WebRTC yönetimi.
• Paralel bir yol gözlemlenirse IPv6 veya ön yüklemeyi devre dışı bırakan ayarlar.

Selenium

Selenium gerçek bir tarayıcıyı yönetir, bu nedenle çözümleme mantığı Chrome veya Firefox'tan devralınır. Chrome için aynı bayrakları başlatma seçenekleri aracılığıyla iletirsiniz (proxy-server ve çözümlemeyle ilgili argümanlar). Firefox için, profil ayarları nesnesi aracılığıyla network.proxy.socks_remote_dns etkinleştirilmiş bir profil ayarlarsınız. Başarının sırrı: sürücü varsayılanlarına güvenmeyin - uzak çözümleme ayarını profile veya bayraklara açıkça yazın ve ardından fiili yolu kontrol edin.

Playwright

Playwright, bir bağlam veya tarayıcı başlatırken proxy parametresi sağlar. server'ı bir şemayla (örneğin, socks5://host:port) ve kimlik bilgileriyle belirtirsiniz. Burada bir incelik var: çözümleme davranışı, motora (Chromium, Firefox, WebKit) ve proxy'nin nasıl uygulandığına bağlıdır. Chromium motorunda uzak çözümlemeyi garanti altına almak için proxy ayarını ilgili başlatma argümanlarıyla, Firefox motorunda ise socks_remote_dns profil ayarıyla birleştirin. Her zaman ayarı sızıntı testiyle tamamlayın.

Özet tablo: İstemci, uzak çözümleme nasıl etkinleştirilir, nasıl kontrol edilir

Materyalin ana pratik tablosunu burada bulabilirsiniz:

• curl - Etkinleştirme: --socks5-hostname veya --proxy'de socks5h:// şeması kullanın - Kontrol: curl'ü verbose ile çalıştırın ve adın iletildiğini gözlemleyin; 53 numaralı bağlantı noktasına doğrudan istek olmadığından emin olmak için trafik dökümü yapın.
• Python requests - Etkinleştirme: proxies sözlüğünde socks5h:// şeması - Kontrol: çözümleme kaynağını gösteren bir servise istek yapın; ortam değişkenlerini kontrol edin.
• Python httpx - Etkinleştirme: socks5h:// şemasıyla proxy - Kontrol: sızıntı testi, hangi çözümleyicinin görüldüğünün analizi.
• Node.js - Etkinleştirme: hostname ileten SOCKS aracısı, önceden dns.lookup yok - Kontrol: bağlantıdan önce dns.resolve çağrılmadığından emin olun; 53 numaralı bağlantı noktası dökümü.
• Go - Etkinleştirme: SOCKS5 dialer, host:port'u adla iletin, önceden net.LookupHost yok - Kontrol: dialer'a ne gittiğini günlüğe kaydedin; tcpdump.
• Chrome - Etkinleştirme: proxy-server ile SOCKS5, proxy'de host-resolver-rules, tanılama için Güvenli DNS'i devre dışı bırakın - Kontrol: çevrimiçi sızıntı testi, IP bölgesi ile DNS bölgesini karşılaştırın.
• Firefox - Etkinleştirme: network.proxy.socks_remote_dns = true, network.trr.mode kontrolü - Kontrol: about:networking, çevrimiçi sızıntı testi.
• Selenium - Etkinleştirme: Chrome için aynı bayraklar veya socks_remote_dns ile Firefox profili - Kontrol: yönetilen tarayıcı içinde sızıntı testi çalıştırın.
• Playwright - Etkinleştirme: proxy parametresi artı uzak çözümleme için motor argümanları - Kontrol: otomatikleştirilmiş oturumda sızıntı testine gidin.

DoH ve DoT: Proxy ile nasıl etkileşime girerler?

DNS over HTTPS (DoH) ve DNS over TLS (DoT), DNS sorgularının şifrelenmesidir. Sorgu içeriğini gözlemciden korumak için kendi başlarına harikadırlar. Ancak proxy bağlamında, anlaşılması gereken ince etkiler yaratırlar.

DoH ve DoT kısaca nedir?

DoT, DNS'yi ayrılmış bir bağlantı noktasında TLS ile sarar. DoH, DNS sorgusunu normal HTTPS trafiğinin içine gizler, bu da onu web'de gezinmekten ayırt edilemez hale getirir. Her iki protokol de sorguyu şifreler. Ancak - ve bu kritiktir - sorgunun şifrelenmesi, proxy üzerinden yönlendirilmesi anlamına gelmez. Bunlar farklı boyutlardır.

Kilit çatışma: Tarayıcı DoH'si proxy'yi atlıyor

İşte bölümün ana içgörüsü. Tarayıcı kendi DoH'sini etkinleştirdiğinde ve kendi sağlayıcısı aracılığıyla çözümleyecek şekilde yapılandırıldığında, DoH uç noktasına bir HTTPS bağlantısı kurar. Soru: Bu bağlantı proxy'niz üzerinden mi gidiyor? Genellikle hayır. Tarayıcı, çözümlemeyi kullanıcı gezinmesinden ayrı bir hizmet işlemi olarak algıladığı için DoH kanalını doğrudan açabilir.

Sonuç paradoksaldır. Bir yandan DNS sorgusu şifrelenir ve sağlayıcı hangi alanı sorguladığınızı görmez. Diğer yandan bu sorgu gerçek makinenizden, sizin ağınızdan, proxy'yi atlayarak gider. Coğrafi konum için bu bir başarısızlıktır: hedef altyapı, proxy bölgesi yerine sizin bölgenizden çözümleme görür. Güzelce yapılandırılmış socks5h şemanız atlanır çünkü tarayıcı çözümleme için SOCKS'e hiç gitmemiştir - kendi DoH yoluyla gitmiştir.

Tarayıcı DoH'si şemanızı tamamen ne zaman bozar?

DoH'nin proxy'yi atladığı durumları somutlaştıralım:

• tarayıcı, kendi sağlayıcısı aracılığıyla zorunlu DoH'ye ayarlanmış ve proxy yalnızca normal trafik için belirtilmiş, hizmet çözümlemesi için değil;
• işletim sistemi veya uygulamada işletim sistemi düzeyinde etkin DoH var ve tünele sarılmıyor;
• DoH uç noktası önbelleğe alınmış ve ona bağlantı proxy ayarları uygulanmadan önce kurulmuş.

Pratik sonuç: Bölge tutarlılığının önemli olduğu görevler için, proxy üzerinden çalışırken tarayıcı ve sistem DoH'si ya devre dışı bırakılmalı ya da aynı proxy üzerinden açıkça yönlendirilmelidir. İdeal resim: şifreli olsun veya olmasın tüm çözümleme, proxy'yi atlayarak değil, proxy sunucusu (uzak çözümleme) üzerinden gider.

DoT ve proxy

DoT, ayrılmış bir bağlantı noktasında çalışır ve ağ politikasına uyması daha kolaydır, ancak açıkça sarılmamışsa yine de proxy'yi atlayabilir. Görevlerimiz için prensip aynıdır: çözümlemenin bağımsız bir kanaldan değil, proxy üzerinden gittiğinden emin olun.

Proxy bağlamında DoH'nin altın kuralı

Unutmayın: Çözümlemenin şifrelenmesi ve proxy üzerinden yönlendirilmesi bağımsız özelliklerdir. Tamamen bölgenizi ele veren, proxy'yi atlayan şifreli bir çözümlemeniz olabilir. Tutarlılık için her zaman proxy'de uzak çözümleme elde edin ve şifreleme sorununu ayrı ve bilinçli bir şekilde çözün.

Nasıl kontrol edilir: dig, nslookup, tcpdump ve çevrimiçi testler

Yapılandırmak işin yarısıdır. Mühendis, çözümlemenin gerçekten amaçlandığı gibi gittiğini doğrulamalıdır. Tanılama araçlarını basitten ciddiye doğru inceleyelim.

Proxy üzerinden dig ve nslookup

dig ve nslookup, manuel çözümleme için klasik araçlardır. İnce bir nokta: normal DNS UDP üzerinde çalışır, SOCKS proxy'si ise yerel olarak TCP proxy'si yapar. Bu nedenle proxy üzerinden çözümleme kontrolü, DNS sorgusunun TCP üzerinden gitmesini ve aracın SOCKS üzerinden yönlendirilmesini gerektirir. Pratikte, davranışı gözlemlemek için araçları TCP trafiğini SOCKS'e saran programlar aracılığıyla sarmak daha uygundur. Kontrolün anlamı: uzak çözümleme sırasında yerel makinenizin DNS sorgularını kendisinin göndermediğinden ve yalnızca proxy kanalından gelen sonucu gördüğünden emin olmaktır.

nslookup, hangi çözümleyicinin yanıt verdiğini ve hangi IP'nin döndürüldüğünü hızlıca kontrol etmek için kullanışlıdır. Yerel olarak alınan IP'yi, proxy üzerinden gerçek bağlantının gittiği IP ile karşılaştırın. Farklılık, çözümlemenin farklı yollardan gittiğinin bir göstergesidir.

53 numaralı bağlantı noktasında tcpdump - en dürüst test

Bu benim favori yöntemimdir çünkü yalan söylemez. Makinenizde 53 numaralı bağlantı noktasına (ve DoH şüpheleri için 443'e) bir filtreyle trafik yakalaması başlatın. Ardından proxy'lenen bir istek yapın. Mantık basittir:

• uzak çözümleme sırasında makinenizden doğrudan 53 numaralı bağlantı noktasına giden DNS paketleri görüyorsanız - sızıntı var, çözümleme yerel olarak yapılıyor;
• 53 numaralı bağlantı noktası sessizse ve tüm trafik proxy tüneline gidiyorsa - uzak çözümleme doğru çalışıyor;
• 53 numaralı bağlantı noktası sessiz, ancak proxy'yi atlayan bilinen DoH uç noktalarına şüpheli HTTPS bağlantıları varsa - DoH yoluyla sızıntı var.

tcpdump, ağın fiziksel gerçekliğini gösterir, yapılandırma bildirimlerini değil. Bu nedenle son doğrulamada vazgeçilmezdir.

Çevrimiçi sızıntı testi: Sonuç doğru nasıl okunur

DNS sorgunuzu hangi çözümleyicinin yaptığını ve hangi bölgeden olduğunu gösteren web servisleri vardır. Sonucu doğru okumanın anahtarı iki parametreyi karıştırmamaktır:

• görünür IP'niz - bu, HTTP bağlantısının geldiği IP'dir, yani proxy IP'si;
• DNS çözümleyicisi - bu, çözümlemeyi fiilen gerçekleştirenin adresi ve bölgesidir.

Uzak çözümleme için doğru resim: hem görünür IP hem de çözümleyici proxy bölgesini işaret eder. Endişe verici işaret: görünür IP proxy bölgesi, ancak çözümleyici sizin gerçek bölgeniz. Bu, yerel çözümleme yoluyla klasik bir sızıntıdır. Başka bir sızıntı varyasyonu: çözümleyici büyük bir DoH sağlayıcısına ait, ancak ona giden bağlantı proxy'yi atlamış - bu durumda çözümleyicinin bölgesi nötr olabilir, ancak yol yine de proxy üzerinden geçmez, bu zaten tcpdump ile görülür.

Çözümleme doğrulama kontrol listesi

Maddeleri sırayla uygulayın:

1. İşletim sistemi ve tarayıcı DNS önbelleğini temizleyin, uygulamayı yeniden başlatın.
2. Şemanın socks5h olduğundan veya istemcide uzak çözümlemenin etkin olduğundan emin olun.
3. Çakışan şemalar için proxy ortam değişkenlerini kontrol edin.
4. 53 ve 443 numaralı bağlantı noktalarına filtre uygulayarak tcpdump başlatın.
5. Test kaynağına proxy'lenen bir istek yapın.
6. 53 numaralı bağlantı noktasına doğrudan DNS paketi olmadığından emin olun.
7. DoH uç noktalarına bağımsız HTTPS bağlantısı olmadığını kontrol edin.
8. Çevrimiçi sızıntı testini açın ve IP bölgesini çözümleyici bölgesiyle karşılaştırın.
9. IPv6 yolunu kontrol edin: paralel AAAA sorguları ve bağlantıları yok mu?
10. Referans yapılandırmayı ekip belgelerine kaydedin.

Hemen hemen herkesin yaptığı tipik hatalar

Yıllar içinde bir tırmık koleksiyonu birikir. En yaygın olanları inceleyelim ki siz onlara basmayın.

Hata 1: socks5 ve socks5h'yi karıştırmak

Açık ara lider. Kişi socks5:// yazar ve çözümlemenin uzak olduğundan emindir. Oysa yereldir. Eksik bir h harfi ve tüm bölge kayar. Uzak çözümleme istiyorsanız her zaman açıkça socks5h belirtin ve bunu dökümle kontrol edin.

Hata 2: Proxy'yi ayarlayıp DoH'yi unutmak

Tarayıcılar için klasik. Proxy ayarlanmış, ancak yerleşik Güvenli DNS / DoH etkin ve onu atlıyor. Kullanıcı doğru IP'yi görür ve rahatlar, ancak bu sırada çözümleme sızar. Her zaman DoH politikasını proxy ile senkronize edin.

Hata 3: IPv6'yı görmezden gelmek

Proxy IPv4 üzerinde, makine ise çift yığınlı. Happy Eyeballs işini yapar ve bağlantıların bir kısmı doğrudan IPv6 üzerinden gider. Ya uygulama için IPv6'yı devre dışı bırakın ya da proxy'nin IPv6'yı tam olarak desteklediğinden emin olun.

Hata 4: Kodda önceden yerel çözümleme yapmak

Node.js ve Go'da sık görülen bir sorun. Geliştirici iyi niyetle çözümlemeyi önceden çağırır (kontrol etmek, günlüğe kaydetmek için) ve proxy'ye zaten IP'yi iletir. Uzak çözümleme ölüdür. Adı proxy dialer'a iletmeden önce çözümlemeyin.

Hata 5: Ortam değişkenlerine güvenmek

HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY - sessiz sabotajcılar. Kod ayarlarını geçersiz kılar veya şemayla çakışır. Çalıştırmadan önce ortamı kontrol edin ve fazlalıkları temizleyin.

Hata 6: Kontrol etmek yerine yapılandırmaya inanmak

Doğru satırı yazıp yolunuza devam ettiniz. Ancak yapılandırma bir niyettir, gerçek değil. Gerçek davranış yalnızca trafik dökümü ve sızıntı testi ile kontrol edilir. Doğrulama yapmadan yapılandırmayı asla tamamlamayın.

Hata 7: Unutulan DNS önbelleği

Yapılandırmayı değiştiriyorsunuz, ancak sonuç aynı - çünkü eski kayıtlar ve bağlantılar önbelleğe alınmış. Kontrol etmeden önce her zaman önbelleği temizleyin ve yeniden başlatın.

Hata 8: Aynı işlem hattında farklı proxy türlerini karıştırmak

Bir yerde CONNECT ile HTTP proxy'si, başka bir yerde yerel çözümlemeli SOCKS. Çözümleme davranışı farklıdır ve isteklerin bir kısmı sızar. Tüm işlem hattı boyunca yaklaşımı birleştirin.

Hata 9: Uygulama önbelleğini dikkate almamak

Bazı uygulamalar, ayar değişikliklerinden daha uzun yaşayan kendi DNS önbelleklerini ve bağlantı havuzlarını tutar. İşlemi yeniden başlatmak bazen zorunludur.

Hata 10: Otomasyonda WebRTC'yi görmezden gelmek

Tarayıcı otomasyonunda WebRTC sıklıkla unutulur. Yönetilen tarayıcı rahatça ICE başlatır ve proxy'yi atlayan yolları açığa çıkarır. Otomatikleştirilmiş oturumlarda her zaman WebRTC politikasını kontrol edin.

Proxy üzerinden çözümleme ile çalışmak için araçlar ve kaynaklar

Elinizin altında bulundurmanız gereken cephaneliği toplayalım. Amaca göre ayıralım.

Tanılama araçları

• tcpdump - ağ trafiği yakalama, çözümleme yolları konusunda nihai hakem.
• Wireshark - grafiksel paket analizi, DoH ve IPv6 ile karmaşık durumlar için kullanışlıdır.
• dig ve nslookup - manuel çözümleme, çözümleyici yanıtlarının hızlı kontrolü.
• çevrimiçi DNS sızıntı testleri - çözümleyiciyi ve bölgesini gösterir, hızlı bir karar verir.
• Firefox'ta about:networking - tarayıcı bağlantıları ve DNS'si için yerleşik tanılama.

Yapılandırma araçları ve kütüphaneleri

• curl - socks5 ve socks5-hostname davranışını kontrol etmek için referans, hata ayıklama için idealdir.
• SOCKS TCP trafiği sarmalayıcıları - çözümleme testleri için rastgele bir uygulamayı SOCKS'e sarmanıza olanak tanır.
• Diller için SOCKS kütüphaneleri - Python'da SOCKS desteği paketleri, Node.js'de SOCKS aracıları, Go'da proxy paketi.
• Tarayıcı otomasyon araçları - Selenium ve Playwright, açık proxy ve çözümleme yapılandırması ile.

Bilgi kaynakları

• curl'un proxy seçenekleriyle ilgili resmi belgeleri - socks5 ve socks5h anlam bilgisi için en iyi birincil kaynak;
• Python HTTP istemcilerinin proxy ve şemalarla çalışma belgeleri;
• Firefox'un ağ ve çözümleme parametreleriyle ilgili about:config referansları;
• Seçtiğiniz proxy sağlayıcısının, özellikle MobileProxy.space hizmetinin belgeleri; burada desteklenen şemalar ve mobil proxy'ler için uzak çözümleme önerileri açıklanmıştır.

Yaklaşım seçimi için mini çerçeve

Kaybolmamak için basit bir karar mantığı kullanın:

1. HTTPS trafiği ve uzak çözümleme mi gerekiyor? CONNECT ile HTTP proxy'si veya socks5h şemasıyla SOCKS5.
2. Bir kütüphane veya CLI'den mi çalışıyorsunuz? socks5h'yi veya uzak çözümleme bayrağını açıkça belirtin.
3. Bir tarayıcıdan mı çalışıyorsunuz? Uzak çözümlemeyi etkinleştirin, DoH'yi devre dışı bırakın veya proxy üzerinden yönlendirin, WebRTC ve IPv6'yı sınırlayın.
4. Her zaman yapılandırmayı trafik dökümü ve çevrimiçi testle tamamlayın.

Vakalar ve sonuçlar: Pratikte nasıl görünüyor?

Teori pratik olmadan ölüdür. Tipik durumları yansıtan genelleştirilmiş vakaları inceleyelim. Rakamlar koşulludur, ancak oranlar ve mantık gerçek mühendislik uygulamalarından alınmıştır.

Vaka 1: Veri analistinde bölge uyumsuzluğu

Bir ekip, Python betiği aracılığıyla ihtiyaç duyulan bölgenin proxy'sini kullanarak veri topluyordu. Sonuçlar vakaların yaklaşık yüzde kırkında başka bir ülkenin yerelleştirmesiyle geliyordu. Tanılama, proxies sözlüğünde socks5:// şemasını gösterdi - yerel çözümleme. socks5h:// olarak değiştirmek uyumsuzluğu tamamen ortadan kaldırdı. tcpdump, 53 numaralı bağlantı noktasına doğrudan sorguların kaybolduğunu doğruladı. Ders: Tek bir harf, daha önce iki gün harcanan sorunu çözdü.

Vaka 2: Otomasyonda tarayıcı DoH'si yoluyla sızıntı

Playwright aracılığıyla Chromium otomasyonunda IP bölgesi doğruydu, ancak hedef kaynak inatla başka bir bölge belirliyordu. Çevrimiçi test, proxy bölgesiyle eşleşmeyen bir çözümleyici gösterdi. Wireshark, proxy'yi atlayan bir DoH uç noktasına bağımsız HTTPS bağlantıları ortaya çıkardı. Çözüm: Başlatma yapılandırmasında Güvenli DNS'i devre dışı bırakmak ve zorunlu uzak çözümleme. Düzeltmeden sonra çözümleyici bölgesi IP bölgesiyle eşleşti, dolandırıcılık önleme yanlış alarmları önemli ölçüde azaldı.

Vaka 3: Mikroserviste paralel IPv6

Bir Go servisi SOCKS5 üzerinden gidiyordu, ancak periyodik olarak isteklerin bir kısmı doğrudan gidiyordu. Nedeni - çift yığın ve proxy'yi atlayan IPv6 denemeleri. İstemciyi yalnızca IPv4 ile sınırlamak ve dialer'a adı doğru bir şekilde iletmek sızıntıyı ortadan kaldırdı. tcpdump doğrudan AAAA sorgularını göstermeyi bıraktı. Bölge kararlılığı neredeyse yüzde yüze çıktı.

Vaka 4: Sabotajcı ortam değişkenleri

Bir betik, aynı kodla iki makinede farklı davranıyordu. Birinde uzak çözümleme çalışıyor, diğerinde çalışmıyordu. Sır: Sorunlu makinede, ayarları geçersiz kılan h'siz bir şemayla ALL_PROXY ortam değişkeni ayarlanmıştı. Ortam temizlendikten sonra davranış tutarlı hale geldi. Ders: Ortam, yapılandırmanın bir parçasıdır ve kod kadar sıkı kontrol edilmelidir.

Vakalardan genel sonuç

Bir kalıp fark edin. Tüm vakalarda semptom benzerdi - yanlış bölge veya korumanın devreye girmesi - ancak nedenler farklıydı: şema, DoH, IPv6, ortam. Bu nedenle kontrol listesine dayalı tanılama, sezgiden daha önemlidir. Sistematik yaklaşım, kök nedeni tahminden daha hızlı bulur.

SSS: Sıkça Sorulan Sorular

socks5 ve socks5h arasındaki fark nedir basit bir dille?

socks5, alan adını sizin tarafınızda çözümler ve proxy'ye hazır IP'yi gönderir. socks5h, adı proxy'ye gönderir ve çözümlemeyi proxy yapar. Gizlilik ve doğru coğrafi konum için neredeyse her zaman socks5h gerekir. h harfi hostname - ana bilgisayar adı anlamına gelir, ad uzaktan iletilir.

HTTP proxy'si kullanıyorsam çözümleme konusunda endişelenmeli miyim?

CONNECT yöntemiyle HTTPS'de ad genellikle proxy'ye gider ve proxy kendisi çözümler - bu iyidir. Ancak bazı istemciler önceden yerel olarak çözümler ve CONNECT'e zaten IP'yi iletir. Bu nedenle HTTP proxy'sinde bile fiili davranışı trafik dökümüyle kontrol edin.

IP doğruyken neden site farklı bir bölge görüyor?

Neredeyse kesinlikle DNS sorgunuz proxy'yi atlıyor - yerel çözümleyici veya tarayıcı DoH'si aracılığıyla. Hedef altyapı, DNS coğrafi konumu ve CDN aracılığıyla proxy bölgesi yerine sizin çözümleyicinizin bölgesini belirler. Tedavi: uzak çözümleme ve DoH kontrolü.

WebRTC'nin çözümleme ve sızıntılarla ilişkisi nedir?

WebRTC, bağlantı kurmak için ağ adayları toplar ve proxy'yi atlayan istekler başlatabilir. Bu, yolları ve adresleri açığa çıkarabilir. Proxy üzerinden çalışırken, özellikle tarayıcı otomasyonunda, WebRTC politikasını kontrol etmek veya sınırlamak gerekir.

DoH, proxy ayarlarımı bozar mı?

Bozabilir. Çözümlemenin şifrelenmesi ve proxy üzerinden yönlendirilmesi farklı şeylerdir. Tarayıcı veya sistem DoH'si, proxy'yi atlayarak doğrudan gidebilir ve bölgenizi ele verebilir. Tutarlılık için bu tür DoH'yi devre dışı bırakın veya çözümlemeyi proxy üzerinden yönlendirin.

Sızıntı olup olmadığını hızlıca nasıl kontrol edebilirim?

İki adım. Birincisi: 53 numaralı bağlantı noktasına filtre uygulayarak tcpdump başlatın ve proxy'lenen bir istek yapın: doğrudan DNS paketleri sızıntı anlamına gelir. İkincisi: çevrimiçi bir test açın ve görünür IP bölgesini çözümleyici bölgesiyle karşılaştırın. Eşleşiyorsa iyi, farklıysa sızıntı var.

Proxy yalnızca IPv4'teyken IPv6 ile ne yapmalıyım?

Ya proxy'lenen uygulama için IPv6'yı devre dışı bırakın ya da proxy'nin IPv6'yı desteklediğinden ve AAAA çözümlemesi dahil tüm trafiğin onun üzerinden gittiğinden emin olun. Aksi takdirde Happy Eyeballs algoritması bağlantıların bir kısmını doğrudan proxy'yi atlayarak gönderecektir.

Aynı kod neden iki farklı makinede farklı davranıyor?

Sık görülen neden, proxy ortam değişkenleridir (HTTP_PROXY, ALL_PROXY ve benzerleri). Bunlar kod ayarlarını geçersiz kılar veya farklı bir şema belirler. Davranışı tutarlı hale getirmek için ortamı kontrol edin ve temizleyin.

socks5h belirtmek sızıntıları tamamen önlemek için yeterli midir?

Uygulamanın kendisi için büyük bir adım, ancak tüm sistem için garanti değildir. Tarayıcı DoH'si, WebRTC ve IPv6 gibi kanallar kalır. Tam koruma, uzak çözümleme artı tüm yan kanalların kontrolü artı zorunlu döküm kontrolüdür.

Test için komut satırında proxy üzerinden çözümleme yapabilir miyim?

Evet. curl, --socks5-hostname seçeneği veya socks5h şemasıyla uzak çözümlemeyi test etmenin en basit yoludur. dig gibi araçlar için, TCP trafiğini SOCKS'e sarmak uygundur, ancak klasik DNS'in UDP üzerinden SOCKS ile yerel olarak proxy'lenmediğini unutmayın.

Sonuç: Özet ve sonraki adımlar

Belirtiden derin bir anlayışa kadar bir yol kat ettik. Ana fikirleri akılda kalıcı bir çerçevede toplayalım.

Alan adı çözümlemesi, ana trafiğinizden farklı bir yol izleyebilen ayrı bir ağ işlemidir. Sorunların çoğu tam da bu bağımsızlıktan kaynaklanır. Çözümlemeyi dört kişi yapabilir: işletim sistemi, uygulama kütüphanesi, tarayıcı ve proxy'nin kendisi. Amacınız neredeyse her zaman çözümlemeyi proxy sunucusuna devretmek olmalıdır, böylece ad ağın doğru noktasından belirlenir.

socks5 ve socks5h arasındaki fark temeldir. socks5 - yerel çözümleme, socks5h - uzak çözümleme. Tek bir harf her şeyi değiştirir: bölge, gizlilik, tutarlılık. CONNECT yöntemiyle HTTP proxy'si doğası gereği adı proxy'ye iletir, ancak burada da körü körüne güvenmeyin - kontrol edin.

Sızıntılar tek bir prensibe indirgenir: adın proxy üzerinden gitmediği bir kanal vardır. Sistem çözümleyicisi, WebRTC, tarayıcı DoH'si, paralel IPv6, önbellek - başlıca şüpheliler bunlardır. Kilit içgörüyü unutmayın: çözümlemenin şifrelenmesi, proxy üzerinden yönlendirilmesi anlamına gelmez. Bölgenizi tamamen ele veren şifreli bir DoH'niz olabilir.

Şimdi ne yapmalısınız? İşte eylem planınız:

1. Mevcut yapılandırmalarınızı gözden geçirin ve uzak çözümleme gereken yerlerde socks5'i socks5h ile değiştirin.
2. Tarayıcıları kontrol edin: uzak çözümlemeyi etkinleştirin, DoH ve WebRTC politikasını netleştirin.
3. IPv6'nın proxy'yi atlayarak paralel bir yol oluşturmadığından emin olun.
4. Proxy ortam değişkenlerini çakışan değerlerden temizleyin.
5. Makaledeki kontrol listesine göre tcpdump ve çevrimiçi test ile doğrulama yapın.
6. Referans çalışma yapılandırmasını belgelere kaydedin, böylece ekip tekerleği yeniden icat etmez.

Proxy üzerinden çözümleme konusu dar görünebilir, ancak en pahalı ve can sıkıcı yapılandırmalar tam da burada bozulur. Artık elinizde bir bölge haritası var: kimin çözümlediğini, kararın nerede alındığını, sızıntıların nasıl oluştuğunu ve nasıl kapatılacağını anlıyorsunuz. Bu materyali yer imlerine ekleyin ve proxy bağlıyken site inatla farklı bir bölge gösterdiğinde tabloya ve kontrol listelerine geri dönün. Artık nereye bakacağınızı biliyorsunuz.