Какой оператор связи? тестировал в Мск для акадо, ростелеком, мгтс, теле2, yota. везде работал. Есть у меня уверенность что можно немного пошаманить с клиентом и заработает нормально.
Да, через 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 и инженерный эксперимент: можно ли прямо сейчас решить проблему для части людей, какие у подхода ограничения, где он ломается, как это детектится и что можно улучшить. Блокировки, к сожалению, при массовом использовании почти неизбежны для любой рабочей технологии: хоть SSH-туннель, хоть VLESS, хоть XHTTP, хоть что угодно ещё. Вопрос не в том, чтобы сделать вид, что решения не существует, а в том, чтобы понимать его свойства, риски и границы применимости. А насчёт славы — мне её вроде хватает. Статьи обычно и пишут для того, чтобы обсудить идею с сообществом и услышать аргументированную критику, а не чтобы прятать рабочие подходы в стол..
А как в таком сценарии отличать VPN-туннель от обычного scp, rsync, бэкапов, CI/CD, администрирования серверов или длительной SSH-сессии с большим объёмом данных?
Более того, откуда DPI заранее знает, что это не канал связи с партнёром, подрядчиком, инфраструктурой, госресурсом или условным контрагентом из ОДКБ? Заблокировать по объёму трафика можно многое, но тогда неизбежно начинаются ложные срабатывания по легитимному SSH.
Да, теоретически можно включить дополнительные эвристики: паттерны, длительность сессии, объём трафика, направление, частоту соединений. Но с таким же успехом можно пытаться блокировать VLESS, XHTTP и вообще любой транспорт, если он становится массовым. Вопрос не в том, “можно ли придумать правило”, а в том, насколько это правило будет точным, дешёвым и безопасным для легитимного трафика.
Плюс любой массовый блок - это не магическая кнопка, а движение большой и неповоротливой бюрократической машины: согласования, риски, исключения, жалобы, побочные эффекты.
Я в статье это и не позиционирую как вечную решение на все времена. Это рабочий транспорт на текущем этапе. А если когда-нибудь дойдёт до массового автоблока SSH-туннелей - значит, как я и написал, пора в Ереван, технологиями в такой среде заниматься нельзя.
Я эту технологию тестирую не первый месяц, а не “по соседу за партой”. DPI действительно может искать паттерны, но у такого анализа есть цена: вычислительная стоимость, ложные срабатывания и риск зацепить легитимный SSH, который массово используется в администрировании, DevOps, Git, облаках.
Поэтому вопрос не в том, “можно ли теоретически распознать”, а в том, насколько это реально выгодно и стабильно блокировать на большом потоке. Я не называю это серебряной пулей, но как рабочий транспорт при правильной настройке и fallback-сценариях - это вполне жизнеспособная история.
Особенно смешно получать такой уверенный хейт, когда время прочтения статьи — 17 минут, а комментарий появился через 5 минут после публикации. Кажется, статью всё-таки сначала стоит прочитать, а уже потом рассказывать, почему “у соседа по парте сгорело”.
Спасибо. Но глобально цель всё-таки статьи и представленного решения работать, и скорее всего это обычна делается не с телефона. Со всем согласен.
Спасибо ценная информация.
Спасибо за информацию проверю напишу.
Спасибо за развернутый ответ попробую потестировать, напишу по результату.
Видел такую хрень на the.hosting, но там надо прям ловить нормальный ip.
Я не писал, но мне кажется что вероятно на Андроид можно на вайбкодить за день, два базовый MVP.
Какой оператор связи? тестировал в Мск для акадо, ростелеком, мгтс, теле2, yota. везде работал. Есть у меня уверенность что можно немного пошаманить с клиентом и заработает нормально.
Нужно дебажит связь у некоторых сотрудников.
Я сталкивался у акады в мск был в принцыпе заблокирован 22 порт, написал провайдеру, поправили. Ну или нахрен такой провайдер.
Не понимаю как запросы в Твиттер через крипто туннель может быть распознан промежуточным оборудованием. Спасибо за рекомендацию iperf3.
Да, через 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 и инженерный эксперимент: можно ли прямо сейчас решить проблему для части людей, какие у подхода ограничения, где он ломается, как это детектится и что можно улучшить. Блокировки, к сожалению, при массовом использовании почти неизбежны для любой рабочей технологии: хоть SSH-туннель, хоть VLESS, хоть XHTTP, хоть что угодно ещё. Вопрос не в том, чтобы сделать вид, что решения не существует, а в том, чтобы понимать его свойства, риски и границы применимости. А насчёт славы — мне её вроде хватает. Статьи обычно и пишут для того, чтобы обсудить идею с сообществом и услышать аргументированную критику, а не чтобы прятать рабочие подходы в стол..
Здравствуйте. У какого оператора?
Разбирусь отпишусь спасибо.
Может вы знаете тогда ответ на вопрос. Почему xhttp еще активно работает?
А как в таком сценарии отличать VPN-туннель от обычного scp, rsync, бэкапов, CI/CD, администрирования серверов или длительной SSH-сессии с большим объёмом данных?
Более того, откуда DPI заранее знает, что это не канал связи с партнёром, подрядчиком, инфраструктурой, госресурсом или условным контрагентом из ОДКБ? Заблокировать по объёму трафика можно многое, но тогда неизбежно начинаются ложные срабатывания по легитимному SSH.
Да, теоретически можно включить дополнительные эвристики: паттерны, длительность сессии, объём трафика, направление, частоту соединений. Но с таким же успехом можно пытаться блокировать VLESS, XHTTP и вообще любой транспорт, если он становится массовым. Вопрос не в том, “можно ли придумать правило”, а в том, насколько это правило будет точным, дешёвым и безопасным для легитимного трафика.
Плюс любой массовый блок - это не магическая кнопка, а движение большой и неповоротливой бюрократической машины: согласования, риски, исключения, жалобы, побочные эффекты.
Я в статье это и не позиционирую как вечную решение на все времена. Это рабочий транспорт на текущем этапе. А если когда-нибудь дойдёт до массового автоблока SSH-туннелей - значит, как я и написал, пора в Ереван, технологиями в такой среде заниматься нельзя.
Я эту технологию тестирую не первый месяц, а не “по соседу за партой”. DPI действительно может искать паттерны, но у такого анализа есть цена: вычислительная стоимость, ложные срабатывания и риск зацепить легитимный SSH, который массово используется в администрировании, DevOps, Git, облаках.
Поэтому вопрос не в том, “можно ли теоретически распознать”, а в том, насколько это реально выгодно и стабильно блокировать на большом потоке. Я не называю это серебряной пулей, но как рабочий транспорт при правильной настройке и fallback-сценариях - это вполне жизнеспособная история.
Особенно смешно получать такой уверенный хейт, когда время прочтения статьи — 17 минут, а комментарий появился через 5 минут после публикации. Кажется, статью всё-таки сначала стоит прочитать, а уже потом рассказывать, почему “у соседа по парте сгорело”.