TCP bağlantılarım ülkemin hükümeti tarafından sabote ediliyor mu?

Ülkemin hükümetinin TCP bağlantılarında alınan ACK paketini bir şekilde yok ettiğinden şüpheliyim.

80 dışındaki bağlantı noktalarında dış bir ana bilgisayara TCP bağlantısı kurmaya çalıştığımda TCP el sıkışması başarılı olmayacak. Pcap dosyasını (gmail.pcap: http://www.slingfile.com/file/aWXGLLFPwb ) yakaladım ve bilgisayarımın TCP SYN gönderdikten sonra ACK alacağını öğrendim, ancak bir SYN ACK ile yanıtlamak yerine bir RST.

ACK paketini dış ana bilgisayardan kontrol ettim, ancak tamamen yasal görünüyor. Sıra numarası ve bildiğim tüm bayraklar doğrudur. Biri bana neden bilgisayarımın (linux makinesi) RST paketini göndereceğini söyleyebilir mi?

pcap ekran görüntüsü

— Mohammad
kaynak

Hangi ülkeyi sorabilir miyiz?

— Kev

Ben kasten bahsetmedim. Ama şimdi sorduğunuza göre, söylememeniz için bir neden düşünemiyorum. Bu İran'daki günlük problemlerimden biri.

— Muhammed

Makinenizden yakalama bağlantıyı kurmaya çalışıyor mu?

— the-wabbit

Evet. Ben tcpdump -w gmail.pcap ve sonra telnet gmail.com 443 yürütmek

— Muhammed

telnet çalışmaz, cevabımı aşağıda görmelisiniz :-)

— The Unix Janitor

Yanıtlar:

Cmd hattından:

openssl s_client -connect serveryourtryingtocontact.com:443

Bu, uzak ana bilgisayara SSL bağlanıp bağlanamayacağınızı doğrulamalıdır. Belki de bu trafiğin Wireshark'ını yapın.

Eğer openssl'niz yoksa, yapabilirsiniz apt-get install openssl.

RST'nin nerede üretildiğini belirlemeliyiz. Tüm SSL sitelerinde oluyor mu? NAT ağ geçidinizle doğrudan bir bağlantınız var mı? Proxy kullanıyor musunuz?

Bu yöntemi kullanmak SSL yığınınızla ilgili herhangi bir sorunu ortadan kaldırır.

— Unix Kapıcısı
kaynak

Sorun SSL değil. TCP. TCP bağlantısı ilk etapta kurulmaz, bu nedenle SSL üstbilgisini göndermeye bile başlamaz. sadece 443 port numarası değildir, örneğin 8000 portunda bir sunucuya normal bir http bağlantısı bile başlatamıyorum ve openssl komutunuz "connect: Connection timed out" ile sonuçlanacak

— Mohammad

İran hükümetinin zaman zaman HTTPS'yi kırdığı söyleniyor olsa da, sağladığınız verilerden sadece yanıt veren SYN'ye benziyor, 173.194.32.22'den gelen ACK paketi ana makinenize geliyor, ancak asla TCP yığına gelmiyor. Yığın, sırasıyla bir saniye, iki saniye, dört saniye ve sekiz saniye sonra SYN'leri göndermeyi dener - ancak görünüşe göre hiçbir zaman bir yanıt görmez.

Gelen SYN, ACK filtrelenmiş gibi görünüyor - iptablesINPUT zincirinizde REJECT --reject-with tcp-resetherhangi bir şansı olan bir hedef olan tcp trafiği için bir kuralınız yok mu?

— -tavşansın
kaynak

Hayır, iptables'mın hiç bir kuralı yok ve başka bir notta iran içindeki herhangi bir ana bilgisayara veya hatta birkaç yabancı web sitesine başarıyla TCP bağlantısı kurabildiğimi söylemeliyim (aslında sadece kernel.org!)

— Mohammad

Benim tahminim hükümet ikinci paketi (SYN / ACK) değiştiriyor, bu yüzden paket geçerli değil ve bu yüzden asla TCP yığınına yapmıyor.

— Muhammed

@Mohammad Paket geçerlidir. Olmasa bile, yığın her ikisini de yapmazdı: bir RST ile yanıt verin ve alınmamış gibi devam edin. Bir şey onu yığın yolunda yakalıyor. Bilinen temiz bir yüklemeyi (örn. Canlı bir Linux CD'si) önyüklemenizi ve testleri yeniden çalıştırmanızı

— öneririm

Teşekkür ederim. ACK paketinde kendim de sorun bulamadım. Ama sorun şu ki, bu sorun her gün (4 gün öncesinden) işyerimde sabah oluyor! Her beden (yaklaşık 50 kişi) tamamen aynı soruna sahiptir ve hala nedenini merak ediyorum? Evde de aynı sorunum yok ama arkadaşlarımdan bugünlerde İnternet'in ciddi sorunları olduğunu duyuyorum.

— Muhammed

@Mohammad kötü amaçlı yazılım olup olmadığını kontrol edin. Yukarıda önerildiği gibi bilinen ve temiz bir kurulum çalıştırmak bu durum için kolay ve önemli bir testtir.

— the-wabbit