Чи мої зв'язки 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

— Мухаммед
джерело

Чи можемо ми запитати, в якій країні?

— Кев

Я це свідомо не згадував. Але тепер, коли ви запитаєте, я не можу придумати причину, чому б не сказати. Це одна з моїх щоденних проблем в Ірані.

— Мохаммед

Чи зроблено захоплення, зняте з вашої машини, намагаючись встановити з'єднання?

— ваббіт

Так. Я виконую tcpdump -w gmail.pcap, а потім telnet gmail.com 443.

— Мохаммед

telnet не працюватиме, вам потрібно побачити мою відповідь нижче :-)

— Двірник Unix,

Відповіді:

З лінії cmd:

openssl s_client -connect serveryourtryingtocontact.com:443

Це має підтвердити, чи можна SSL підключитися до віддаленого хоста. Можливо, зробіть Wireshark цього трафіку.

Якщо у вас немає openssl, тоді ви можете apt-get install openssl.

Ми повинні визначити, де створюється RST. Чи трапляється це на всіх SSL-сайтах? Чи маєте пряме з'єднання з вашим NAT-шлюзом? Ви використовуєте проксі?

За допомогою цього методу виключається будь-яка проблема з вашим стеком SSL.

— Двірник Unix
джерело

Проблема не в SSL. Це TCP. З'єднання TCP не встановиться спочатку, тому SSL навіть не почне надсилати свій заголовок. це не тільки номер 443 порту, наприклад, я навіть не можу запустити звичайне http-з'єднання з сервером на порту 8000, і ваша команда openssl призведе до "підключення: Час з'єднання вичерпано"

— Мохаммад

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

Здається, що вхідний SYN, ACK відфільтрований - у вас немає iptablesправила для tcp-трафіку у вашій мережі INPUT, який REJECT --reject-with tcp-resetнацілений на будь-який випадок?

— вабіт
джерело

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

— Mohammad

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

— Мохаммед

@Mohammad Пакет дійсний. Навіть якби не він, стек не зробив би обох: відповісти RST та продовжити так, ніби він не був отриманий. Щось ловить це на шляху до стека. Я пропоную завантажувати відому чисту установку (наприклад, живий компакт-диск Linux) та повторно запускати тести

— wabbit

Дякую. Я також не міг знайти жодної проблеми з пакетом ACK. Але річ у тому, що ця проблема трапляється щодня (з 4 днів тому) вранці на моєму робочому місці! У кожного організму (близько 50 чоловік) є точно однакова проблема, і мені все ще цікаво, чому? У мене немає такої ж проблеми вдома, але я чую від своїх друзів, що Інтернет має серйозні проблеми в наші дні.

— Мохаммед

@Mohammad перевірити наявність шкідливих програм. Запуск відомої чистої установки, як було запропоновано вище, є легким та вагомим тестом для цього випадку.

— the wabbit