Comments 30
Насколько старые? Разработчики obfs4
Вы комментарий выдрали из контекста. Читайте внимательней!
Ой. До этого, сказав про "у нас obfs4 уже шифрует" вы отключили шифрование на уровне OpenVPN, и трафик на "прямой порт" с мобилок у вас будет ходить в открытом для всех глаз виде.
Данная статья описана с максимальной гибкостью. Ни кто Вам не запрещает отконфигурировать по своему.
Shapeshifter Dispatcher Проект не плохой. Но они отказались от поддержки протокола obfs4
"они" имеется в виду shapeshifter-dispatcher
#comp-lzo не указываем #не хочет дружить с обфускацией
Не знаю как comp-lzo работает с обфускацией, но во-первых, это устаревшая функция, а во-вторых, она небезопасна и имеет уязвимости.
Вместо нее теперь можно использовать “compress lz4”.
Клиента для мобильных систем нет (android/ios)? Тогда это сильно ограничивает эту схему.
А почему интересно обфускатор требует расшифровки проходящего трафика и нервно реагирует на сжатие? Мне казалось что он должен молча съедать любой трафик на входе вообще и не важно что там внутри и как оно устроено, и на выходе выдавать идентичный входному.
push "dhcp-option DNS 1.1.1.1" push "dhcp-option DNS 1.0.0.1"
DNS лучше пускать через шифрованный канал, иначе будет утечка метаданных.
Клиента для мобильных систем нет (android/ios)? Тогда это сильно ограничивает эту схему.
Увы нету. Вероятнее всего это из-за не популярности данного способа шифрования трафика. Да и представь себе как это высасывало аккумулятор.
А почему интересно обфускатор требует расшифровки проходящего трафика и нервно реагирует на сжатие?
Я не очень шарю в криптографии. Но как я понял, обфускатор не может проверить целостность данных после дешифровки.
Была здесь на Хабре статья "Туннели и VPN, устойчивые к DPI". На мой взгляд, отличное решение с маскировкой личного VPN сервера под вебсайт с котиками. Сейчас она снята с публикации, но по русскоязычному интернету осталось немало её копий.
Хмм. Я вторую статью не читал, а первую, получается, прочитал, не очень внимательно, или следовал ей не очень четко. Потому что на её основе успешно построил себе VPN сервер. Программку оттуда взял со смешным названием, а также stunnel,и openvpn. Все поставил на роутер, которым у меня тогда работал маленький комп на атоме. Сайт, который хостился в Германии, уже был.
А, понятно тогда. Ну, что ж , время показало, что с той стороны окошко стали прикрывать быстрее, чем с этой. От того немецкого хостинга пришлось отказаться, а потом у меня и вовсе поменялась ситуация, теперь мне актуален ВПН в обратную сторону, "сервер" стоит в моей московской квартире. А тогда был именно stunnel, не wstunnel. В этой схеме он, может быть, и не нужен, но у меня получилось сделать с ним, а дальше мне стало уже не до этого, заработал канал, и ладно.
А, кстати, не может ли оказаться более перспективным именно такой вариант, чтобы подключение инициировалось из-за границы, а сервер с ВПН жил в РФ ? Будут ли они так же вдумчиво проверять вебсервера внутри страны?
#соберет мелкие пакеты в один,но более крупный #уменьшит нагрузку на сервер и на клиент #при отсутствии трафика незначительно увеличит пинг socket-flags TCP_NODELAY
TCP_NODELAY не делает ли абсолютно противоположное описанному? No Delay как раз убирает задержку на "сборку" и отправляет доступные данные сразу же, мелкими пакетами.
Обфускация русского языка в виде "ту-же" и прочих "что-бы" — вообще отдельный привет...
Маскировка трафика OpenVPN при помощи обфускации