
Комментарии 88
плохой сценарий. dpi уже давно знает эти ваши ссш и усепшно блочит длительные и нехарактерные для паттерна обычного ссш сессии. таким образом вы вообще потеряете контроль над своим сервером.
попробуйте, потом раскажете.
зачем мне пробовать - сосед по парте так погорел
Я эту технологию тестирую не первый месяц, а не “по соседу за партой”. DPI действительно может искать паттерны, но у такого анализа есть цена: вычислительная стоимость, ложные срабатывания и риск зацепить легитимный SSH, который массово используется в администрировании, DevOps, Git, облаках.
Поэтому вопрос не в том, “можно ли теоретически распознать”, а в том, насколько это реально выгодно и стабильно блокировать на большом потоке. Я не называю это серебряной пулей, но как рабочий транспорт при правильной настройке и fallback-сценариях - это вполне жизнеспособная история.
Особенно смешно получать такой уверенный хейт, когда время прочтения статьи — 17 минут, а комментарий появился через 5 минут после публикации. Кажется, статью всё-таки сначала стоит прочитать, а уже потом рассказывать, почему “у соседа по парте сгорело”.
первое что приходит на ум для более "успешной" работы dpi - искать не только паттерны а дополонительно к ним проверять превышение порога объем траффика в единицу времени, и если вы сделаете такой туннель для проброса траффика из-за рубежа то легко пробьете этот порог при активном пользовании видеоресурсов людьми ...
просто нет смысла распыляться dpi еще и на это - пока процент таких решений очень мал. начнет расти - включат и будет автоматом блочить ... ((
А как в таком сценарии отличать VPN-туннель от обычного scp, rsync, бэкапов, CI/CD, администрирования серверов или длительной SSH-сессии с большим объёмом данных?
Более того, откуда DPI заранее знает, что это не канал связи с партнёром, подрядчиком, инфраструктурой, госресурсом или условным контрагентом из ОДКБ? Заблокировать по объёму трафика можно многое, но тогда неизбежно начинаются ложные срабатывания по легитимному SSH.
Да, теоретически можно включить дополнительные эвристики: паттерны, длительность сессии, объём трафика, направление, частоту соединений. Но с таким же успехом можно пытаться блокировать VLESS, XHTTP и вообще любой транспорт, если он становится массовым. Вопрос не в том, “можно ли придумать правило”, а в том, насколько это правило будет точным, дешёвым и безопасным для легитимного трафика.
Плюс любой массовый блок - это не магическая кнопка, а движение большой и неповоротливой бюрократической машины: согласования, риски, исключения, жалобы, побочные эффекты.
Я в статье это и не позиционирую как вечную решение на все времена. Это рабочий транспорт на текущем этапе. А если когда-нибудь дойдёт до массового автоблока SSH-туннелей - значит, как я и написал, пора в Ереван, технологиями в такой среде заниматься нельзя.
А не надо отличать. Странный трафик? Баним. Пусть юзер сам потом доказывает что не верблюд.
Может вы знаете тогда ответ на вопрос. Почему xhttp еще активно работает?
Потому что xhttp - это не странный трафик и в https бывает много трафика? И пока еще просто по объему трафика зарубежные сервера не банят? Почему должны-то?
на мобильных считай не работает. несколько пакетов и привет
На мобильном интернете SSH на стандартном порту уже массово блокируется, даже когда нет белых списков На домашнем и рабочем тоже встречаются проблемы с нестабильностью подключения.
Здравствуйте. У какого оператора?
Много ваших комментариев под постом, отвечу тут.
Вам про обрезание SSH в комментариях всё правильно пишут. Стабильно режут уже некоторое время (не вчера началось).
У какого оператора?
Мегафон. Чаще всего дольше минуты не держится. В большинстве случаев гораздо быстрее, нередко даже залогиниться не получается.
А ранее, до агрессивных блокировок были разъединения при передаче файлов (т.е. по нетипичному трафику).
Есть у меня уверенность что можно немного пошаманить с клиентом и заработает нормально
Очень, очень хочу узнать что можно подшаманить в Путти (и на сервере, если надо), чтобы обычный, густой советский SSH просто заработал. И туннели не нужны, чисто для реальной работы с сервером. Без шуток, реально надо.
В связи с этим уже третий раз пишу примерно такое:
Знатоки SSH! В том же PuTTY есть немало настроек, например, в Connection -> SSH (обмен ключами, ключи, шифры, и т.д.).
Можно ли там настроить какие-то манипуляции с пакетами наподобие того, как это делается у современных ПНВ, чтобы соединение не резалось особо активными провайдерами, считающими, что я не работу работаю, а иду “куда-то не туда”?
Пробовал повыбирать разные комбинации вариантов, получилось немного улучшить время до разрыва, но работать нормально всё равно невозможно.
Заблокировать по объёму трафика можно многое, но тогда неизбежно начинаются ложные срабатывания по легитимному SSH.
Да им плевать там на ложные срабатывания.
>А как в таком сценарии отличать VPN-туннель от обычного scp, rsync, бэкапов, CI/CD, администрирования серверов или длительной SSH-сессии с большим объёмом данных?
А никак - у меня уже давно scp просто не работает без заворачивания SSH в ещё один туннель (дом ру - selectel spb)
У Китайцев сделали. Тексты редактировать можно нормально, а начинаешь качать файл - скорость падает до 64Кб/с на 15 минут.
время прочтения статьи — 17 минут, а комментарий появился через 5 минут после публикации.
А что там такого, что не понятно из заголовка на что стоит тратить 17 минут?
чего я не найду в, условно, man ssh
если можно, тезисно, без воды.
риск зацепить легитимный SSH, который массово используется в администрировании, DevOps, Git, облаках.
Вообще никого не волнует, у меня несколько недель интерактивный SSH до vps в nl зависал почти сразу после старта.
Тут cf, fastly и прочие банятся ркн, 90% интернета не работает, kernel.org и gitlab.com не открываются, а вы о каких-то девопсах рассуждаете
Идея не плохая, явно, хотя наверно, для всех очевидно, что до поры до времени.
Статья длинная, нагружена большим объемом "воды", и всяких выкладок, которые могу предположить на генерировал ИИ.
Идея же записана в заголовке, если ты умеешь настраивать туннель через SSH, маршрутизацию, и пользоваться iptables чтоб настроить NAT, читать все это можно по касательной.
Попробуй передать суть, а не выкладки, сравнения, анализы, почему то лучше, это хуже, или спрятать это за спойлера и, чтобы не нагружать статью, она станет короче в время ее прочтения в разы уменьшится. Краткость сестра таланта.
Грохают даже легитимный SSH... Срок соединения жизни по большей части зависит только от белизны двух IP адресов - клиент и сервер. Соединиться позволяет, а вот насколько быстро в дальнейшем дропнется соединение - вопрос открытый, при этом глубокий анализ не нужен - по трафику или по времени можно резать. Делов - то RST пакет кинуть от имени далёкого участника - весь трафик как на ладони в том месте, которое присматривает за трафиком, так что сымитировать корректный пакет - данных достаточно.
попробуйте, потом раскажете.
Уже пробовали, рассказываю.
У некоторых сотрудников (Ростов-на-Дону) соединение стабильно рвется по таймауту (около 5 минут), через тоннель гоняли git, целевой сервер в Санкт-Петербурге.
Проблема региональная, на проводных провайдерах.
В других регионах пока работает, но быть уверенным, что это надолго, точно нельзя.
Пробоавл - блочит. Случайным образом. Сегодня блочит. Завтра - нет. Послезавтра снова блочит. Иногда блочит после 20 секунд. Иногда после пары минут. Иногда по трафику. Но блочит часто и уже больше года.
Да, блокируют, проверено лично, могу подтвердить. Несколько запросов на какой-нибудь твиттер и ssh начинает сильно хромать.
Кстати, скорость, наверное, было бы проще проверять с помощью iperf3:
- s на одном сервере
- с serverIP на клиенте
и погнали. Инструмент из серии проще не бывает, а скорость показывает очень неплохо. У браузера, который сейчас напичкан чем угодно, показания могут быть далеки от корректных. В общем, рекомендую. :)
Не понимаю как запросы в Твиттер через крипто туннель может быть распознан промежуточным оборудованием. Спасибо за рекомендацию iperf3.
Не понимаю как запросы в Твиттер через крипто туннель может быть распознан промежуточным оборудованием
А они и не распознают ничего внутри туннеля, как уже неоднократно выше писали, срабатывание происходит просто при превышении определенного объема переданных данных за временной промежуток.
Подверждаю, уже больше полугода РКН блокирует ssh подключения к серверам в hetzner. Симптомы такие, через 5секунд (или какое-то количество байт) сессия ssh зависает намертво и всё.
Для SSH решается с помощью jumphost (поэтому доступ к серверу всё же можно получить), но конечно вся эта ситуация очень неприятная
Давно использую этот вариант, более того изначально им и пользовался. Сервер вг (протокол без управлерия - важно) доступный через ssh и набор правил на кастомном роутере. Из минусов иногда сессии тормозятся так, что только консоль работает и то притормаживает. Иногда обрываются. Но в целом редко. Рабочий вариант уже не первый год.
Спасибо за статью. Метод вполне известный и рабочий, но поначалу. Через какое-то время начинают срабатывать блокировки и ssh перестаёт работать даже на другом порту.
Когда нужно быстро получить доступ не на постоянную основу - вполне можно так делать.
оптимизации http2 от cloudflare: https://blog.cloudflare.com/http-2-prioritization-with-nginx/
возможно поможет и в данном случае, ведь весь трафик идёт через 1 tcp соединение как и http2
TLDR:
sysctl -w net.ipv4.tcp_congestion_control=bbr #выше скорость
sysctl -w net.ipv4.tcp_notsent_lowat=16384 #меньше bufferbloat(в идеале на обеих концах)
проверьте, если не сложно. скорость можно проверить `curl -o /dev/null tunnelIP/bigfile`, bufferbloat `ping tunnelIP` во время скачивания файла через туннель
PermitTunnel yes в конфиге SSHD — тихое превращение сервера в маршрутизатор для всех авторизованных пользователей. Match-блок с ограничением по ключу обязателен, иначе это не туннель, а шлюз.
Если из-за популяризации SSH туннелей РКН решит заблокировать SSH по сигнатуре, то гореть писателям таких статей вместе с РКН в аду.
Вот тоже не пойму, нахрена орать на всю Ивановскую? Славы и популярности захотелось? Запилил работающее решение - сиди тихо пользуйся, не пали.
Не совсем согласен с тезисом «молчать — значит безопаснее». Если технология реально работает и закрывает боль пользователей, её всё равно начнут внедрять коммерческие сервисы — и уже внедряют. Причём без публичного обсуждения, без разбора слабых мест и без нормальной обратной связи от технического сообщества. В этом смысле статья не про «смотрите, как я всех победил», а про MVP и инженерный эксперимент: можно ли прямо сейчас решить проблему для части людей, какие у подхода ограничения, где он ломается, как это детектится и что можно улучшить. Блокировки, к сожалению, при массовом использовании почти неизбежны для любой рабочей технологии: хоть SSH-туннель, хоть VLESS, хоть XHTTP, хоть что угодно ещё. Вопрос не в том, чтобы сделать вид, что решения не существует, а в том, чтобы понимать его свойства, риски и границы применимости. А насчёт славы — мне её вроде хватает. Статьи обычно и пишут для того, чтобы обсудить идею с сообществом и услышать аргументированную критику, а не чтобы прятать рабочие подходы в стол..
Не совсем согласен с тезисом «молчать — значит безопаснее».
Когда ходит маньяк и херачит всех кого заметит, то молчать — значит безопаснее. В этой бойне либо хоть кому-то повезёт и он будет жить, либо всех расхерачат.
Блокировки, к сожалению, при массовом использовании почти неизбежны
А вы побольше прилагайте усилий чтобы оно появилось, это массовое использование! Что у нас ещё осталось в резерве? Да ничего у нас уже не осталось!
Лично мое мнение, что тем админам, которые до этого не дошли своим умом - не стоит так делать. Вы своей статьей зашли на пикник к далеко не глупым ребятам, спокойно пьющим пиво и во весь голос начали кричать: Ааа вы тут пЫЫЫво пьете?
Дай бог, чтобы только ваши серваки забанили.
Оно не работающее уже года два наверное как, выше верно написали. Скорость деградирует. Как аварийный вариант ок, не более того
У какого оператора связи не работает?
Спасибо за статью и вашу выдержку. (: просто для информации. ростелек мск lan. коннект по ssh разрывается после первых двух символов (в ssh соединении) до впс, но только из moba. Tермиус, ps виндовый итп, всё работает. очевидно ssh уже начали резать, скоро полупроводникам запретят полупроводить, вот тогда заживём ){..}
К примеру у меня SSH между белыми айпишниками домашних провайдеров (АльфаНетТелеком => Ростелеком GPON) скорсть репликации TrueNAS по SSH низкая и обрывается, хотя интерактивные сессии вроде как норм.
Вот тоже не пойму, нахрена орать на всю Ивановскую?
А как по вашему происходят блокировки? С бюджетом в 60 млрд и карт-бланшем от президента РКН сидит гуглит, читает форумы и паблики? Или всё-таки способен нанять высококвалифицированных инженеров?
Меня вот это желание иметь "хату с краю" неприятно поражает. Общество и так достаточно атомизировано
А как по вашему происходят блокировки?
Конкретный опер ловит конкретного преступника, который использует конкретное техническое средство для своей преступной деятельности. По результатам таких дел РКН принимает меры. Чем больше таких случаев, тем сильнее блокировки.
Именно поэтому Телеграм блокируют. Именно поэтому блокируют уже не конкретных VPN провайдеров, а протоколы VPN. И именно запрещено популяризировать средства обхода блокировок.
Меня вот это желание иметь "хату с краю" неприятно поражает. Общество и так достаточно атомизировано
В военном деле это называется рассредоточение. А против нас ведётся война.
Помоги себе сам, своим друзьям и родственникам, максимум. Другой соберёт какое-то другое решение, непохожее на остальные. Так хоть есть шанс не привлекать внимание массовостью.
Да-да, в органах же слепые котята сидят) И пока им автор на хабре не рассказал про флаг -w, они про мануалы к openssh даже не подозревали))
TCP over TCP, мммм, вкусно, но медленно :)
только вот UDP не работает через этот тунель
С помощью SSH нормально пробрасывается L2 туннель, а это возможность пробросить необходимый vlan. Не забываем про overhead, чудес на свете не бывает.
Да, через OpenSSH действительно можно поднять не только L3/TUN, но и L2/TAP-туннель: PermitTunnel ethernet, ssh -w, дальше TAP-интерфейс можно добавить в bridge и при желании протащить через него VLAN. Технически это рабочая история.
Но я сознательно описывал именно L3-вариант, потому что для массового пользовательского VPN он сильно проще и предсказуемее: меньше broadcast-мусора, меньше сюрпризов с ARP/STP, проще маршрутизация, NAT, split-tunnel, исключения по подсетям и диагностика. L2 через SSH — это скорее точечный админский инструмент “пробросить сегмент/VLAN куда-то”, а не хороший дефолт для тысяч пользовательских клиентов.
И да, overhead там будет заметнее: Ethernet-over-TCP-over-SSH-over-TCP, MTU надо резать, широковещательный трафик аккуратно контролировать, а чудес действительно не бывает. Поэтому как отдельный эксперимент — интересно, но цель MVP иметь доступ к своей инфре, а не матчить две сети.

Интересно, есть ли мобильные клиенты..
Вы открыли Америку, чюдно...
Помню, как когда-то давно я хвалился другу в Израиле, что у нас в России интернет дешёвый. Он 40 баксов, а я 10 платил. А сейчас, с тремя гигабитными vps для сети квн, чтобы всё бесшовно работало как раньше, у меня выходит примерно как в Израиле :)
Это выстрел в ногу заворачивать TCP поверх TCP , при первых же потерях пакетов на магистрали алгоритмы контроля перегрузки устроят тебе такой дедлок, что консоль отвалится
Безразборное блокирование ssh ведет к полной парализации IT.
ssh используется для rsync, бэкапов, CI/CD - отличить этот трафик dpi по объему нельзя, НО абсолютно можно когда трафик идет с мобильной связи. Естественно, разбираться как можно с телефона это обойти простой юзер не будет, но поскольку такую (с телефона через стационарный комп) цепочку создать можно, то люди будут на этом зарабатывать, упрощая жизнь приложениями для телефона (надеюсь у Вас не iPhone). Но, как все понимают, на сегодня все идет к белым спискам для мобильной связи.
SSH как корпоративный L3-туннель: когда классические VPN-протоколы больше не работают