Bağlantınızı neyin engellediğini nasıl anlarsınız

Bir bağlantının nasıl başarısız olduğu başlı başına teşhis edicidir. Herhangi bir şey yapmadan önce gördüğünüzü bu tabloyla eşleştirin.

DNS manipülasyonu engellemenin en ucuz biçimidir ve bu yüzden en yaygınıdır; doğrulaması ya da elemesi de en kolay olandır. Test, aynı soruyu iki farklı çözücüye sorup karşılaştırmaktır.

1. 1

   Ağınızın çözücüsüne sorun

   Ağın verdiği çözücüyü kullansın diye başka argüman olmadan `nslookup example.com` (Windows) ya da `dig example.com` (macOS ve Linux) çalıştırın.

2. 2

   Doğrudan bir genel çözücüye sorun

   `nslookup example.com 1.1.1.1` ya da `dig @1.1.1.1 example.com` çalıştırın. Bu, giden DNS'e hiç izin veriliyorsa ağın kendi çözücüsünü atlar.

3. 3

   Yanıtları karşılaştırın

   Farklı adresler, 0.0.0.0 ya da 127.0.0.1 yanıtı, ya da birinden NXDOMAIN diğerinden geçerli yanıt gelmesi — hepsi araya girildiğine işaret eder. Aynı yanıtlar DNS'i eler.

4. 4

   İkinci sorgu da başarısız olur ya da aynı yanlış yanıtı verirse

   Ağ muhtemelen tüm 53 portu trafiğini kendi çözücüsüne yönlendiriyordur ki bu yaygındır. Karşı önlem şifreli DNS'tir (DNS-over-HTTPS ya da DNS-over-TLS) ve çoğu işletim sistemi artık bunu yerel olarak destekler.

DNS'i düzeltmenin ne sağladığı konusunda net olun. Size doğru adresi verir. O adrese ulaşmanıza izin verilip verilmediği konusunda hiçbir şey yapmaz ve ana bilgisayar adı hemen ardından gelen TLS el sıkışmasında yeniden açık olarak gönderilecektir. DNS sorunları ile bağlantı sorunları ayrıdır ve ikisinin birden olması yaygındır.

Ad doğru çözümleniyor ama hiçbir şey bağlanmıyorsa, sıradaki soru adresin erişilemez mi olduğu yoksa ona yapmaya çalıştığınız şeyin mi durdurulduğudur. Uygulamadan bakınca ikisi aynı görünür, komut satırında ise ayırt etmek kolaydır.

1. 1

   Portu düz bir TCP bağlantısıyla test edin

   macOS ya da Linux'ta: `nc -vz <adres> 443`. Windows'ta: `Test-NetConnection <adres> -Port 443`. Bu, çıplak bir TCP bağlantısı açar ve başka bir şey yapmaz.

2. 2

   Sonucu yorumlayın

   TCP bağlantısı başarılı olursa adres ve port erişilebilirdir ve sorun onların üzerinde konuştuğunuz protokoldedir: filtre trafiği sınıflandırmıştır. TCP'nin kendisi başarısız olursa adres ya da port büsbütün engellenmiştir.

3. 3

   Aynı adreste ikinci bir portu test edin

   443 başarısız olup başka bir port başarılı olursa engel porta özgüdür. Tüm portlar başarısız olursa adres engellenmiştir.

4. 4

   Farklı bir uç noktayı test edin

   Aynı ayarlar ve aynı protokolle farklı bir adres çalışıyorsa ilk adres engel listesindedir ve hiçbir protokol ayarı onu geri getirmez.

Bu ayrım bu rehberdeki en değerli şeydir. Adres engeli farklı bir uç nokta gerektirir. Protokol engeli farklı bir protokol ya da taşıyıcı gerektirir. Yanlış çareyi uygulamak, sorunu çözülemez gibi gösterecektir.

Kurulan, biraz trafik geçiren ve sonra aniden ölen bir bağlantı, hiç kurulmayan bir bağlantıdan farklı bir imzadır. Genellikle filtrenin akışı sınıflandırmak için birkaç bayt görmesi gerektiği ve ardından karşı taraftan geliyormuş gibi taklit ettiği bir TCP sıfırlamasıyla onu öldürdüğü anlamına gelir.

• Tekrarlanabilir ve hızlıdır — genellikle bir iki saniye içinde ve her seferinde aynı noktada. Gerçek arızalar düzensizdir.
• Karşı tarafın bundan haberi yoktur. Sunucu açısından istemci ortadan kaybolmuştur.
• Zamanlaması hacme değil el sıkışmaya bağlıdır: daha çok veri aktarmak onu öne çekmez.

Elinizde bir paket yakalama aracı varsa, aynı akıştaki diğer paketlerden gözle görülür biçimde farklı bir TTL değeriyle gelen bir sıfırlama enjeksiyonun güçlü bir göstergesidir; çünkü gerçek uç noktanın olduğundan daha yakında üretilmiştir. Bu bir doğrulamadır, harekete geçmek için ihtiyacınız olan bir şey değil.

Çare protokol düzeyindedir: sınıflandırıcı bir şeyi tanımıştır, dolayısıyla yanıt, tanıdığı şeyi sunmayan bir taşıyıcıdır. Uç noktayı değiştirmek yardımcı olmaz, çünkü aynı sınıflandırma yenisinde de gerçekleşecektir.

Doğrulaması en zor durum, çalışan ama kullanılamayacak kadar yavaş olan bağlantıdır; çünkü bir kontrol ölçümü olmadan sıradan tıkanıklıktan ayırt edilemez.

1. 1

   Tüneli ölçün

   Tünel üzerinden bir aktarım hızı testi yapın ve sonucu kaydedin; tercihen birkaç dakika içinde birkaç kez.

2. 2

   Aynı anda tünelsiz ölçün

   Aynı testi doğrudan yapın. Tekrarlanan testlerde süren büyük bir fark ilk kanıttır.

3. 3

   Yalnızca sayıya değil biçime bakın

   Hızı kısılan akışlar karakteristik olarak bir iki saniye hızlı başlar — sınıflandırıcı henüz karar vermemişken — ve sonra düşük ve alışılmadık biçimde kararlı bir hıza oturur. Gerçek tıkanıklık dalgalanır. Düşük hızdaki kararlılık asıl ipucudur.

4. 4

   Farklı bir port ve farklı bir uç nokta deneyin

   Tavan, uç noktadan bağımsız olarak protokolü izliyorsa bu sınıflandırma tabanlı şekillendirmedir. Uç noktayı izliyorsa daha çok o uç noktadaki kapasite sorunudur.

En bilgilendirici test hiçbir şeye mal olmaz: aynı yapılandırmayı farklı bir ağda deneyin — Wi-Fi yerine mobil veri ya da büsbütün başka bir Wi-Fi ağı.

• Bir ağda çalışıp diğerinde çalışmıyorsa: politika ağa aittir; cihazınıza, yapılandırmanıza ya da uç noktaya değil. Sizin tarafınızda düzeltilecek bir şey yoktur.
• Her ağda başarısız oluyorsa: sorun uç nokta, yapılandırma ya da kimlik bilgileridir ve bakılacak yer orasıdır.
• İkisinde de çalışıyor ama birinde yavaşsa: o ağ engellemiyor, şekillendiriyor.

Filtreleme politikası zamanla değişir ve aynı belirtinin üç ay sonra farklı bir sebebi olabilir. Tarihi, ağı, belirtiyi, neyi değiştirdiğinizi ve sonucu not eden birkaç satır, her olayı üzerinden akıl yürütebileceğiniz bir şeye dönüştürür; her seferinde aynı incelemeye sıfırdan başlamak yerine.