Саботируются ли мои TCP-соединения правительством моей страны?

Я подозреваю, что правительство моей страны каким-то образом уничтожает полученный пакет ACK по TCP-соединениям.

Когда я пытаюсь установить TCP-соединение с внешним хостом на портах, отличных от 80, квитирование TCP не будет успешным. Я захватил файл pcap (gmail.pcap: http://www.slingfile.com/file/aWXGLLFPwb ) и обнаружил, что мой компьютер будет получать ACK после отправки TCP SYN, но вместо ответа с SYN ACK он отправит RST.

Я проверил пакет ACK от внешнего хоста, но он кажется вполне законным. Порядковый номер и все известные мне флаги верны. Может кто-нибудь сказать мне, почему мой компьютер (машина Linux) будет отправлять пакет RST?

скриншот pcap

— Мохаммад
источник

Можем ли мы узнать, в какую страну?

— Кев

Я сознательно не упомянул об этом. Но теперь, когда вы спросите, я не могу придумать причину, почему бы не сказать. Это одна из моих повседневных проблем в Иране.

— Мохаммед

Захватывается ли с вашей машины попытка установить соединение?

— The wabbit

Да. Я выполняю tcpdump -w gmail.pcap, а затем telnet gmail.com 443.

— Мохаммад

Telnet не будет работать, вы должны увидеть мой ответ ниже :-)

— The Unix Janitor

Ответы:

Из строки cmd:

openssl s_client -connect serveryourtryingtocontact.com:443

Это должно проверить, если вы можете SSL-соединение с удаленным хостом. Возможно, сделайте Wireshark из этого трафика.

Если у вас нет openssl, тогда вы можете apt-get install openssl.

Мы должны определить, где генерируется RST. Это происходит со всеми сайтами SSL? Есть ли у вас прямое подключение к вашему NAT-шлюзу? Ты используешь прокси?

Использование этого метода исключает любые проблемы с вашим стеком SSL.

— Уникс Дворник
источник

Проблема не в SSL. Это TCP. Соединение TCP не будет установлено в первую очередь, поэтому SSL даже не начнет отправлять свой заголовок. это не только номер порта 443. Например, я не могу даже запустить обычное http-соединение с сервером через порт 8000, и ваша команда openssl приведет к «connect: Connection timed out»

— Mohammad

Хотя иранское правительство, по слухам, время от времени нарушает HTTPS, из предоставленных вами данных просто выглядит как ответный SYN, пакет ACK из 173.194.32.22 прибывает на ваш хост, но никогда не попадает в ваш стек TCP. Стек повторяет отправку SYN через секунду, две секунды, четыре секунды и восемь секунд соответственно - но, очевидно, никогда не видит ответа.

Кажется, что входящий SYN, ACK отфильтрован - у вас нет iptablesправила для tcp-трафика в цепочке INPUT, у которого есть REJECT --reject-with tcp-resetцель?

— заместитель Wabbit
источник

Нет, у моих iptables вообще нет никаких правил, и, с другой стороны, я должен сказать, что могу успешно установить TCP-соединение с любым хостом внутри iran или даже с несколькими иностранными веб-сайтами (на самом деле, только kernel.org!)

— Мохаммад

Я предполагаю, что правительство изменяет второй пакет (SYN / ACK), поэтому пакет недействителен и поэтому никогда не попадает в стек TCP.

— Мохаммед

@ Мохаммед Пакет действителен. Даже если бы это было не так, стек не смог бы сделать и то и другое: ответить RST и продолжить, как если бы он не был получен. Что-то ловит его на пути к стеку. Я предлагаю загрузить известную чистую установку (например, живой компакт-диск с Linux) и повторно запустить тесты

— the-wabbit

Спасибо. Я тоже не смог найти никаких проблем с пакетом ACK. Но дело в том, что эта проблема случается каждый день (с 4 дня назад) утром на моем рабочем месте! У каждого тела (около 50 человек) точно такая же проблема, и я до сих пор удивляюсь, почему? У меня нет той же проблемы дома, но я слышу от своих друзей, что в интернете сейчас серьезные проблемы.

— Мохаммед

@ Мохаммед проверять на наличие вредоносных программ. Выполнение известной чистой установки, как предложено выше, является простым и значительным тестом для этого случая.

— the-wabbit