Czy moje połączenia TCP są sabotowane przez rząd mojego kraju?

Jestem podejrzany, że rząd mojego kraju w jakiś sposób niszczy otrzymany pakiet ACK na połączeniach TCP.

Podczas próby nawiązania połączenia TCP z hostem zewnętrznym na portach innych niż 80 uzgadnianie TCP nie powiedzie się. Przechwyciłem plik pcap (gmail.pcap: http://www.slingfile.com/file/aWXGLLFPwb ) i dowiedziałem się, że mój komputer otrzyma ACK po wysłaniu TCP SYN, ale zamiast odpowiedzi za pomocą SYN ACK wyśle RST.

Sprawdziłem pakiet ACK z zewnętrznego hosta, ale wydaje się całkowicie uzasadniony. Numer sekwencyjny i wszystkie znane mi flagi są poprawne. Czy ktoś mógłby mi powiedzieć, dlaczego mój komputer (maszyna z systemem Linux) wyśle pakiet RST?

zrzut ekranu pcap

— Mohammad
źródło

Czy możemy zapytać, w jakim kraju?

— Kev,

Celowo o tym nie wspominałem. Ale teraz, kiedy pytasz, nie mogę znaleźć powodu, dla którego miałbym tego nie mówić. To jeden z moich codziennych problemów w Iranie.

— Mohammad,

Czy przechwytywanie jest pobierane z komputera i próbuje nawiązać połączenie?

— the-wabbit

Tak. Wykonuję tcpdump -w gmail.pcap, a następnie telnet gmail.com 443.

— Mohammad

telnet nie zadziała, musisz zobaczyć moją odpowiedź poniżej :-)

— The Unix Janitor,

Odpowiedzi:

Z linii cmd:

openssl s_client -connect serveryourtryingtocontact.com:443

To powinno sprawdzić, czy możesz połączyć się SSL ze zdalnym hostem. Być może zrób Wireshark tego ruchu.

Jeśli nie masz openssl, możesz apt-get install openssl.

Musimy ustalić, gdzie generowany jest RST. Czy zdarza się to we wszystkich witrynach SSL? Czy masz bezpośrednie połączenie z bramą NAT? Czy korzystasz z serwera proxy?

Zastosowanie tej metody wyklucza wszelkie problemy ze stosem SSL.

— The Unix Janitor
źródło

Problemem nie jest SSL. To jest TCP. Połączenie TCP nie zostanie ustanowione w pierwszej kolejności, więc SSL nawet nie zacznie wysyłać swojego nagłówka. to nie tylko numer portu 443, np. nie mogę nawet nawiązać normalnego połączenia HTTP z serwerem na porcie 8000, a polecenie openssl spowoduje „połączenie: upłynął limit czasu połączenia”

— Mohammad

Chociaż podobno od czasu irańskiego rządu łamią HTTPS, z podanych przez ciebie danych wygląda tylko, że odpowiadający SYN, pakiet ACK z 173.194.32.22 dociera do twojego hosta, ale nigdy nie trafia do twojego stosu TCP. Stos próbuje wysłać SYN po upływie odpowiednio sekundy, dwóch sekund, czterech sekund i ośmiu sekund - ale najwyraźniej nigdy nie widzi odpowiedzi.

Przychodzące SYN, ACK wydaje się być filtrowane - nie masz iptablesreguły dla ruchu TCP w swoim łańcuchu INPUT, który ma jakiś REJECT --reject-with tcp-resetcel?

— the-wabbit
źródło

Nie, moje iptables w ogóle nie mają żadnych reguł, a z drugiej strony muszę powiedzieć, że mogę pomyślnie nawiązać połączenie TCP z dowolnym hostem w Iranie lub nawet z kilkoma zagranicznymi stronami internetowymi (właściwie tylko kernel.org!)

— Mohammad

Domyślam się, że rząd zmienia drugi pakiet (SYN / ACK), więc pakiet nie jest prawidłowy i dlatego nigdy nie trafia do stosu TCP.

— Mohammad

@Mohammad Pakiet jest prawidłowy. Nawet gdyby tak nie było, stos nie zrobiłby obu: odpowiedz RST i kontynuuj tak, jakby nie został odebrany. Coś go łapie w drodze na stos. Sugeruję uruchomienie znanej czystej instalacji (np. Live CD z Linuksem) i ponowne uruchomienie testów

— the-wabbit

Dziękuję Ci. Sam też nie mogłem znaleźć problemu z pakietem ACK. Ale chodzi o to, że ten problem zdarza się codziennie (od 4 dni temu) rano w moim miejscu pracy! Każde ciało (około 50 osób) ma dokładnie ten sam problem i wciąż zastanawiam się, dlaczego? Nie mam tego samego problemu w domu, ale słyszę od znajomych, że Internet ma obecnie poważne problemy.

— Mohammad,

@Mohammad następnie sprawdź, czy nie ma złośliwego oprogramowania. Uruchamianie znanej instalacji, jak sugerowano powyżej, jest łatwym i znaczącym testem w tym przypadku.

— the-wabbit