Здравствуйте.
Калуга, Билайн, Мобильный интернет.
С августа наблюдаю очень частые разрывы SSH соединений.
В качестве примера: открываю по 2-3 SSH сессии на 3 разных серверах и жду. Через какое то время, может в течении часа, может больше хоть одна сессия разрывается.
KeepAlive настроен так же, как и много лет назад, когда разрывов не наблюдалось.
Решил начать записывать трафик и о чудо, я обнаруживаю HTTP пакет (с редиректом на blackhole.beeline.ru) среди SSH соединения, с флагами “FIN, PSH, ACK” после чего мой ssh клиент инициирует завершение соединения пакетом “FIN, ACK”.
Для пример настроил отправку keepAlive пакета на каждые 10 сек. от сервера к клиенту.
В /etc/ssh/sshd_config:
ClientAliveInterval 10
ClientAliveCountMax 2
На скриншоте ниже показана сессия с SSH сервером, сессия открыта из обычного терминала Konsole.
192.168.1.2 - мой ip адрес компьютера, подключённого к моему роутеру.
193.124.*.* - ip адрес, где запущен SSH сервис (OpenSSH).
SSH сервис поднят на порту 47570.
На записе трафика на сервере видно, что сервер в 12:55:56 отправляет очередной keepAlive пакет с флагами “PSH, ACK” и размером 126 байт.
А на клиенте уже получаем HTTP пакет с флагами “FIN, PSH, ACK” и размером 128 байт. После чего клиент начинает завершать соединение, но оно не завершается корректно.
Трафик со стороны сервера:
Трафик со стороны клиента:
Так же видно что в HTTP пакете имеется заголовок редиректа:
HTTP/1.1 307 Temporary Redirect
Location: http://blackhole.beeline.ru
На сервере в логе auth.log было зафиксировано следующее:
2024-09-10T12:56:16.455022+03:00 srv1 sshd[15189]: Timeout, client not responding from user root 85.249.19.17 port 17280
2024-09-10T12:56:16.468118+03:00 srv1 sshd[15189]: pam_unix(sshd:session): session closed for user root
2024-09-10T12:56:16.479025+03:00 srv1 systemd-logind[374]: Session 141 logged out. Waiting for processes to exit.
2024-09-10T12:56:16.481726+03:00 srv1 systemd-logind[374]: Removed session 141.
Видно, что клиент не инициировал корректно закрытие ssh сессии, а произошёл таймаут соединения.
Чем чаще отправляется keepAlive пакет, тем больше шансов словить HTTP пакет.
Бывает и разрыв ssh соединения, но уже без http пакета, просто приходит пакет с флагом “FIN,PSH,ACK”, вместо отправленного “PSH, ACK”.
При отправке keepAlive пакет раз в 10 сек. на 3 запущенных ssh соединений можно словить дисконект уже через 10 мин.
При отправке keepAlive пакет раз в 60 сек. на 3 запущенных ssh соединений можно словить дисконект через 50 мин. или больше часа.
Я прав или как? Если что не так, поправьте пожалуйста и объясните что не так?
Спасибо.
Возникло пару вопросов:
Наблюдаются ли у кого нибудь в России с начала августа разрывы SSH сессий?
Наблюдал ли кто нибудь вообще за свою практику подобные HTTP пакеты в SSH сессии?
Как мне подсказали, это результат работы DPI и он почему то видит в keepAlive пакетах на SSH соединении заблокированный паттерн и блокирует его.
Предполагаю, что DPI от ТСПУ, от РКН, но возможно и на стороне самого Билайна, т.к. у них тоже свои DPI. Остаётся пока ещё загадкой кто блокирует именно.
хз вы писали или нет, но до отката форума из бекапа тут уже была такая тема про билайн и ssh
//val: да
Я пытался воспроизвести данный HTTP пакет. Пакет отправляется, но клиент не пытается разорвать сессию.
Вот таким python скриптом мне удаётся отправлять пакет:
from scapy.all import *
ether = Ether(src="00:00:00:00:00:11", dst="00:00:00:00:00:22")
ip = IP(src="192.168.1.120", dst="192.168.1.2")
tcp = TCP(sport=11000, dport=24050, flags="FPA", seq=2506070044, ack=2444551231)
http_response = (
"HTTP/1.1 307 Temporary Redirect\r\n"
"Location: http://blackhole.beeline.ru\r\n\r\n"
)
pkt = ether/ip/tcp/http_response
sendp(pkt, iface="re0")
Кто понимает такие детали, объясните пожалуйста почему клиент инициирует разрыв в оригинальном случае и почему у меня не получается воспроизвести этот разрыв со стороны клиента с моим скриптом?
============
Добавляю после восстановления сообщения: на проблему с воспроизведением пакета уже забил, поэтому не актуально.
Надо смотреть пакет RST,ASK, скорее всего он инвалидный. Это обычное дело, провайдер подменяет src.ip и присылает фейковый RST пакет для разрыва соединения, а потом вам присылает страницу-заглушку.
Попробуйте в вашем фаерволе заблокировать входящие инвалидные пакеты.
iptables -I INPUT -m state --state INVALID -j DROP
Т.к. запись трафика велась на моём компьютере, а RST,ASK пакет исходящий, то этот пакет инициировал мой SSH клиент, а не провайдер.
INVALID пакеты блокируются на стороне моего роутера, через цепочку FORWARD. Поэтому до меня доходят только правильные пакеты.
Наблюдаются у T2 Сибирь ~ года, но в трансграничном направлении.
SSH сессия с VPS не живет и 10 минут, происходит гарантированный разрыв.
Частично восстановил топик.
Можете сделать pcap?
INVALID пакеты блокируются на стороне моего роутера, через цепочку FORWARD. Поэтому до меня доходят только правильные пакеты.
Выложил 2 скриншота с трафиком на сервере и на клиенте. Забыл изначально добавить в 1й пост 
Скриншоты не подойдут
А на записе трафика как это выглядит? Вы где нибудь описывали данный случай, скриншоты может какие? Если нет, то можете сделать запись трафика на клиенте и сервере, как я сделал и выложить скриншоты.
13 сентября в ЛС отправил 3 разных SSH сессии. Подтвердите пожалуйста прочтение.
Не прокатит. DPI активный. После http redirect ничего от сервера больше не идет, а клиент шлет ретрансмиссии FIN,ACK до тех пор, пока ему это не надоедает, и он отсылает RST
Подтвержаю, такая же проблема и точно такую картину наблюдаю через Wireshark. Домашний интернет Ростелеком (МО, Красногорск) и режут трафик ShadowSocks (без надстроек). На мобильных операторах все стабильно работает и SSH и SS.
Можете скиншот выложить, где в SSH соединении подменяется keepAlive пакет и приходит HTTP пакет или пакет с флагами “FIN, PSH, ACK” (когда он не HTTP).
Если посмотреть внимательно на скриншотах в 1 сообщении, то можно заметить что SEQ и ACK поля разные у отправляемых и получаемых TCP пакетов.
Разве они не должны быть одинаковыми?
Или это признак активного DPI, который прям проксирует через себя TCP соединение?
Не углублялся так глубоко, поэтому не знаю таких деталей.
Спустя месяц после подачи заявки в техподдержку Билайна проблема была решена.
Сейчас разрывов в SSH нет.
Техподдержку кого, хостера или провайдера? А то непонятно.
Билайна
Спасибо.