Обновить

SSH как корпоративный L3-туннель: когда классические VPN-протоколы больше не работают

Уровень сложностиСредний
Время на прочтение17 мин
Охват и читатели27K
Всего голосов 40: ↑36 и ↓4+33
Комментарии88

Комментарии 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 бывает много трафика? И пока еще просто по объему трафика зарубежные сервера не банят? Почему должны-то?

на мобильных считай не работает. несколько пакетов и привет

xhttp отлично работает на МТС, Т2, ТМобайл, йоте, мегафоне при подключениях 24\7. Билайн не проверял, негде

t2-билайн не работает

Спасибо ценная информация.

Один говорит, что не т2 не работает, другой — что работает

Я думаю дело вообще не в xhttp, а в наличии конкретных серверов в чёрных/белых списках

я пробовал 3 разных сервера, в разных подсетях.

На мобильном интернете SSH на стандартном порту уже массово блокируется, даже когда нет белых списков На домашнем и рабочем тоже встречаются проблемы с нестабильностью подключения.

Здравствуйте. У какого оператора?

Много ваших комментариев под постом, отвечу тут.

Вам про обрезание SSH в комментариях всё правильно пишут. Стабильно режут уже некоторое время (не вчера началось).

У какого оператора?

Мегафон. Чаще всего дольше минуты не держится. В большинстве случаев гораздо быстрее, нередко даже залогиниться не получается.

А ранее, до агрессивных блокировок были разъединения при передаче файлов (т.е. по нетипичному трафику).

Есть у меня уверенность что можно немного пошаманить с клиентом и заработает нормально

Очень, очень хочу узнать что можно подшаманить в Путти (и на сервере, если надо), чтобы обычный, густой советский SSH просто заработал. И туннели не нужны, чисто для реальной работы с сервером. Без шуток, реально надо.

В связи с этим уже третий раз пишу примерно такое:

Знатоки SSH! В том же PuTTY есть немало настроек, например, в Connection -> SSH (обмен ключами, ключи, шифры, и т.д.).

Можно ли там настроить какие-то манипуляции с пакетами наподобие того, как это делается у современных ПНВ, чтобы соединение не резалось особо активными провайдерами, считающими, что я не работу работаю, а иду “куда-то не туда”?

Пробовал повыбирать разные комбинации вариантов, получилось немного улучшить время до разрыва, но работать нормально всё равно невозможно.

Ничего "подшаманить" нельзя.

Спасибо за развернутый ответ попробую потестировать, напишу по результату.

С каким сервером? Какой хостинг?

Заблокировать по объёму трафика можно многое, но тогда неизбежно начинаются ложные срабатывания по легитимному SSH.

Да им плевать там на ложные срабатывания.

>А как в таком сценарии отличать VPN-туннель от обычного scp, rsync, бэкапов, CI/CD, администрирования серверов или длительной SSH-сессии с большим объёмом данных?

А никак - у меня уже давно scp просто не работает без заворачивания SSH в ещё один туннель (дом ру - selectel spb)

У Китайцев сделали. Тексты редактировать можно нормально, а начинаешь качать файл - скорость падает до 64Кб/с на 15 минут.

Недавно был в Китае. В гостиничном вай-фае VPN и SSH подключаются, но стоит делать что-то более тяжёлое, чем отправка текста / пинги то связь пропадает на несколько минут. Ограничения в 64 кб/с не наблюдал.

Через туристическую e-sim интернет работает полноценно.

время прочтения статьи — 17 минут, а комментарий появился через 5 минут после публикации.

А что там такого, что не понятно из заголовка на что стоит тратить 17 минут?

чего я не найду в, условно, man ssh

если можно, тезисно, без воды.

да там вся статья - нейрослоп
не стоит внимания
очередной хацкер обнаружил что ssh это не только команды вводить

риск зацепить легитимный SSH, который массово используется в администрировании, DevOps, Git, облаках.

Вообще никого не волнует, у меня несколько недель интерактивный SSH до vps в nl зависал почти сразу после старта.

Тут cf, fastly и прочие банятся ркн, 90% интернета не работает, kernel.org и gitlab.com не открываются, а вы о каких-то девопсах рассуждаете

Идея не плохая, явно, хотя наверно, для всех очевидно, что до поры до времени.

Статья длинная, нагружена большим объемом "воды", и всяких выкладок, которые могу предположить на генерировал ИИ.

Идея же записана в заголовке, если ты умеешь настраивать туннель через SSH, маршрутизацию, и пользоваться iptables чтоб настроить NAT, читать все это можно по касательной.

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

Грохают даже легитимный SSH... Срок соединения жизни по большей части зависит только от белизны двух IP адресов - клиент и сервер. Соединиться позволяет, а вот насколько быстро в дальнейшем дропнется соединение - вопрос открытый, при этом глубокий анализ не нужен - по трафику или по времени можно резать. Делов - то RST пакет кинуть от имени далёкого участника - весь трафик как на ладони в том месте, которое присматривает за трафиком, так что сымитировать корректный пакет - данных достаточно.

попробуйте, потом раскажете.

Уже пробовали, рассказываю.

У некоторых сотрудников (Ростов-на-Дону) соединение стабильно рвется по таймауту (около 5 минут), через тоннель гоняли git, целевой сервер в Санкт-Петербурге.

Проблема региональная, на проводных провайдерах.
В других регионах пока работает, но быть уверенным, что это надолго, точно нельзя.

Нужно дебажит связь у некоторых сотрудников.

Я сталкивался у акады в мск был в принцыпе заблокирован 22 порт, написал провайдеру, поправили. Ну или нахрен такой провайдер.

вау вау. нахрен давно закончилось. не из чего выбирать.

Пробоавл - блочит. Случайным образом. Сегодня блочит. Завтра - нет. Послезавтра снова блочит. Иногда блочит после 20 секунд. Иногда после пары минут. Иногда по трафику. Но блочит часто и уже больше года.

Да, блокируют, проверено лично, могу подтвердить. Несколько запросов на какой-нибудь твиттер и ssh начинает сильно хромать.

Кстати, скорость, наверное, было бы проще проверять с помощью iperf3:
- s на одном сервере
- с serverIP на клиенте
и погнали. Инструмент из серии проще не бывает, а скорость показывает очень неплохо. У браузера, который сейчас напичкан чем угодно, показания могут быть далеки от корректных. В общем, рекомендую. :)

Не понимаю как запросы в Твиттер через крипто туннель может быть распознан промежуточным оборудованием. Спасибо за рекомендацию iperf3.

Не понимаю как запросы в Твиттер через крипто туннель может быть распознан промежуточным оборудованием

А они и не распознают ничего внутри туннеля, как уже неоднократно выше писали, срабатывание происходит просто при превышении определенного объема переданных данных за временной промежуток.

Какой оператор связи? тестировал в Мск для акадо, ростелеком, мгтс, теле2, yota. везде работал. Есть у меня уверенность что можно немного пошаманить с клиентом и заработает нормально.

Билайн. SSH на VPS в Я-облаке. Пару месяцев работал, потом перестал, нет ни соединения, ни пинга. VPS живой, через впн зайти на него по SSH можно.

Спасибо за информацию проверю напишу.

Радеют за безопасность

Подверждаю, уже больше полугода РКН блокирует ssh подключения к серверам в hetzner. Симптомы такие, через 5секунд (или какое-то количество байт) сессия ssh зависает намертво и всё.


Для SSH решается с помощью jumphost (поэтому доступ к серверу всё же можно получить), но конечно вся эта ситуация очень неприятная

Ну вообще-то то hetzner под 16кб блокировкой (почти все протоколы). Хотя у меня обычно работает ssh до таких серверов, проверьте ещё раз, возможно тспу уже обновили

Давно использую этот вариант, более того изначально им и пользовался. Сервер вг (протокол без управлерия - важно) доступный через 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-блок с ограничением по ключу обязателен, иначе это не туннель, а шлюз.

Это которое Match User username?

Match User или Match Group, если несколько юзверей. Там и можно указать, с какого IP доступ разрешён или запрещён.

Если из-за популяризации SSH туннелей РКН решит заблокировать SSH по сигнатуре, то гореть писателям таких статей вместе с РКН в аду.

Вот тоже не пойму, нахрена орать на всю Ивановскую? Славы и популярности захотелось? Запилил работающее решение - сиди тихо пользуйся, не пали.

Не совсем согласен с тезисом «молчать — значит безопаснее». Если технология реально работает и закрывает боль пользователей, её всё равно начнут внедрять коммерческие сервисы — и уже внедряют. Причём без публичного обсуждения, без разбора слабых мест и без нормальной обратной связи от технического сообщества. В этом смысле статья не про «смотрите, как я всех победил», а про MVP и инженерный эксперимент: можно ли прямо сейчас решить проблему для части людей, какие у подхода ограничения, где он ломается, как это детектится и что можно улучшить. Блокировки, к сожалению, при массовом использовании почти неизбежны для любой рабочей технологии: хоть SSH-туннель, хоть VLESS, хоть XHTTP, хоть что угодно ещё. Вопрос не в том, чтобы сделать вид, что решения не существует, а в том, чтобы понимать его свойства, риски и границы применимости. А насчёт славы — мне её вроде хватает. Статьи обычно и пишут для того, чтобы обсудить идею с сообществом и услышать аргументированную критику, а не чтобы прятать рабочие подходы в стол..

Не совсем согласен с тезисом «молчать — значит безопаснее».

Когда ходит маньяк и херачит всех кого заметит, то молчать — значит безопаснее. В этой бойне либо хоть кому-то повезёт и он будет жить, либо всех расхерачат.

Блокировки, к сожалению, при массовом использовании почти неизбежны

А вы побольше прилагайте усилий чтобы оно появилось, это массовое использование! Что у нас ещё осталось в резерве? Да ничего у нас уже не осталось!

остались забугорные sim на забугорных же планшетах и многое другое, а чем больше будут обижать ssh , https итд. - тем очевиднее будут выводы.

Лично мое мнение, что тем админам, которые до этого не дошли своим умом - не стоит так делать. Вы своей статьей зашли на пикник к далеко не глупым ребятам, спокойно пьющим пиво и во весь голос начали кричать: Ааа вы тут пЫЫЫво пьете?

Дай бог, чтобы только ваши серваки забанили.

Добавлю-разъясню: сейчас распивать пиво в общественных местах запрещено.

Т.е. сидят ребята, тихо потягивают пивас на лавочке. И тут прибегает дурачок: "поцики, смотрите, я пиво принёс!". Мимо проходящий ППС тут же обращает внимание. Дурачок: "нуачо, они бы всё равно заметили".

Оно не работающее уже года два наверное как, выше верно написали. Скорость деградирует. Как аварийный вариант ок, не более того

У какого оператора связи не работает?

Спасибо за статью и вашу выдержку. (: просто для информации. ростелек мск lan. коннект по ssh разрывается после первых двух символов (в ssh соединении) до впс, но только из moba. Tермиус, ps виндовый итп, всё работает. очевидно ssh уже начали резать, скоро полупроводникам запретят полупроводить, вот тогда заживём ){..}

До впс на каком хостинге?

Видел такую хрень на the.hosting, но там надо прям ловить нормальный ip.

К примеру у меня SSH между белыми айпишниками домашних провайдеров (АльфаНетТелеком => Ростелеком GPON) скорсть репликации TrueNAS по SSH низкая и обрывается, хотя интерактивные сессии вроде как норм.

Вот тоже не пойму, нахрена орать на всю Ивановскую?

А как по вашему происходят блокировки? С бюджетом в 60 млрд и карт-бланшем от президента РКН сидит гуглит, читает форумы и паблики? Или всё-таки способен нанять высококвалифицированных инженеров?

Меня вот это желание иметь "хату с краю" неприятно поражает. Общество и так достаточно атомизировано

А как по вашему происходят блокировки?

Конкретный опер ловит конкретного преступника, который использует конкретное техническое средство для своей преступной деятельности. По результатам таких дел РКН принимает меры. Чем больше таких случаев, тем сильнее блокировки.

Именно поэтому Телеграм блокируют. Именно поэтому блокируют уже не конкретных VPN провайдеров, а протоколы VPN. И именно запрещено популяризировать средства обхода блокировок.

Всё с вами понятно

Меня вот это желание иметь "хату с краю" неприятно поражает. Общество и так достаточно атомизировано

В военном деле это называется рассредоточение. А против нас ведётся война.

Помоги себе сам, своим друзьям и родственникам, максимум. Другой соберёт какое-то другое решение, непохожее на остальные. Так хоть есть шанс не привлекать внимание массовостью.

Да-да, в органах же слепые котята сидят) И пока им автор на хабре не рассказал про флаг -w, они про мануалы к openssh даже не подозревали))

Вопрос не в том что не знали, а то что все сейчас скрипткидди побегут поднимать "новый классный КВН". А то и продавать.

TCP over TCP, мммм, вкусно, но медленно :)

Ну для решения рабочих задач вроде хватает.

При bbr во внешнем TCP в общем-то нормально работает

Мы так как-то базу реплицировали по молодости через похожий костыль. Кончилось тем что пинги летали по пять секунд, пока мы не додумались перевести транспорт

только вот UDP не работает через этот тунель

Работает

вы путаете -w и -D

С помощью 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 иметь доступ к своей инфре, а не матчить две сети.

Готов отвечать на технические вопросы, обсуждать ограничения, риски и возможные способы детекта/блокировки. Но оправдываться за то, что я «раскрыл» секрет Полишинеля, не готов. Эта технология не была тайной: кто хотел — давно знал, тестировал и коммерчески использовал. Я просто собрал MVP, описал подход и вынес его на обсуждение, чтобы получить техническую критику, а не играть в молчание вокруг очевидного.
Готов отвечать на технические вопросы, обсуждать ограничения, риски и возможные способы детекта/блокировки. Но оправдываться за то, что я «раскрыл» секрет Полишинеля, не готов. Эта технология не была тайной: кто хотел — давно знал, тестировал и коммерчески использовал. Я просто собрал MVP, описал подход и вынес его на обсуждение, чтобы получить техническую критику, а не играть в молчание вокруг очевидного.

Интересно, есть ли мобильные клиенты..

Я не писал, но мне кажется что вероятно на Андроид можно на вайбкодить за день, два базовый MVP.

Давно использую OpenTunnel. Единственно, не нашел как настроить доступ по ключу, приходится по паролю. Если кто подскажет годный клиент с авторизацией по ключу, буду благодарен.

Вы открыли Америку, чюдно...

Помню, как когда-то давно я хвалился другу в Израиле, что у нас в России интернет дешёвый. Он 40 баксов, а я 10 платил. А сейчас, с тремя гигабитными vps для сети квн, чтобы всё бесшовно работало как раньше, у меня выходит примерно как в Израиле :)

КВН стремится сделать интернет дорогим, у меня тоже стоимость растет.

Но ведь так и делаются состояния, где то ставится шлагбаум, и плати за обход.

Это выстрел в ногу заворачивать TCP поверх TCP , при первых же потерях пакетов на магистрали алгоритмы контроля перегрузки устроят тебе такой дедлок, что консоль отвалится

Безразборное блокирование ssh ведет к полной парализации IT.

ssh используется для rsync, бэкапов, CI/CD - отличить этот трафик dpi по объему нельзя, НО абсолютно можно когда трафик идет с мобильной связи. Естественно, разбираться как можно с телефона это обойти простой юзер не будет, но поскольку такую (с телефона через стационарный комп) цепочку создать можно, то люди будут на этом зарабатывать, упрощая жизнь приложениями для телефона (надеюсь у Вас не iPhone). Но, как все понимают, на сегодня все идет к белым спискам для мобильной связи.

Спасибо. Но глобально цель всё-таки статьи и представленного решения работать, и скорее всего это обычна делается не с телефона. Со всем согласен.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации