Комментарии 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)? Тогда это сильно ограничивает эту схему.
Увы нету. Вероятнее всего это из-за не популярности данного способа шифрования трафика. Да и представь себе как это высасывало аккумулятор.
А почему интересно обфускатор требует расшифровки проходящего трафика и нервно реагирует на сжатие?
Я не очень шарю в криптографии. Но как я понял, обфускатор не может проверить целостность данных после дешифровки.
Три вопроса
1 - разве obfs4 определяется dpi? Насколько я помню он давно детектиться.
2 - зачем городить костыль когда есть ssl VPN?
3 - оставлять VPN только на шифрование obfs, не столь надёжное решение.
Суммирую, для нагруженного VPN по трафику (а учитывая какие сервера берут под vpn) Решение не очень в плане оверхеда с обусфикацией. Есть тот же wireguard быстрое решение даже быстрее ipsec, далее ikev2 тоже отличный вариант, теперь варианты обхода жестких блокировок по протоколам openconnect/anyconnect, Ms sstp, outline VPN (для ленивых, медленнее), и уже в конце как самый запасной вариант это openvpn+обусфускатор (wstunnel, stunnel, socks5, и другие). Не openvpn'ом единым, даже wg на udp можно завернуть в wstunnel через tls.
obfs4 не определяется ни чем.
Haproxy +SNI что бы держать и сайт на https и sstp, самое разумное решение. Но это уже нюансы настройки sstp
За то работает, даже если будут блочить протоколы, outline для ленивых разработан для китайского фаервола. Или ssh vpn (заблокировать протокол управления сервера когда они переходят на отечественный linux? Чем черт не шутит). Решений много. Проще всего заблочить народные протоколы (ovpn, wg, ipsec, ikev2) и то ipsec может быть под вопросом бизнес будет много материться когда отвалится несколько десятков офисов. Ситуация двоякая конечно. 100% сделать свое решение чтобы завернуть весь трафик и dns в ssl тунель, и сделать это стандартезированно через openssl на 443 порту с ngnix proxy letsencrypt и легетимным сайтом (не заблочат же они ssl?)
Да да, цензоры не отличаются умом особенно блокировками целыми подсетями. Да все это известно. По этому и говорю про свое решение о котором ни кто не будет знать, единственное сервер нужен будет по мощнее чтоб бы выкинуть туда сайт с медиаконтентом и пусть ковыряются что там.
Потребовалось создал решение для раздачи и обновления сертификатов wildcard по всем сайтам, контейнерам и виртуалкам. И для обхода сделаем если будет необходимость. Ведь можно просто изолировать рунет вот вам вк, одноклассники и рутуб, а все остальное экстремистический контент, и что делать тогда ?
Была здесь на Хабре статья "Туннели и VPN, устойчивые к DPI". На мой взгляд, отличное решение с маскировкой личного VPN сервера под вебсайт с котиками. Сейчас она снята с публикации, но по русскоязычному интернету осталось немало её копий.
Хмм. Я вторую статью не читал, а первую, получается, прочитал, не очень внимательно, или следовал ей не очень четко. Потому что на её основе успешно построил себе VPN сервер. Программку оттуда взял со смешным названием, а также stunnel,и openvpn. Все поставил на роутер, которым у меня тогда работал маленький комп на атоме. Сайт, который хостился в Германии, уже был.
А, понятно тогда. Ну, что ж , время показало, что с той стороны окошко стали прикрывать быстрее, чем с этой. От того немецкого хостинга пришлось отказаться, а потом у меня и вовсе поменялась ситуация, теперь мне актуален ВПН в обратную сторону, "сервер" стоит в моей московской квартире. А тогда был именно stunnel, не wstunnel. В этой схеме он, может быть, и не нужен, но у меня получилось сделать с ним, а дальше мне стало уже не до этого, заработал канал, и ладно.
А, кстати, не может ли оказаться более перспективным именно такой вариант, чтобы подключение инициировалось из-за границы, а сервер с ВПН жил в РФ ? Будут ли они так же вдумчиво проверять вебсервера внутри страны?
#соберет мелкие пакеты в один,но более крупный #уменьшит нагрузку на сервер и на клиент #при отсутствии трафика незначительно увеличит пинг socket-flags TCP_NODELAY
TCP_NODELAY не делает ли абсолютно противоположное описанному? No Delay как раз убирает задержку на "сборку" и отправляет доступные данные сразу же, мелкими пакетами.
Обфускация русского языка в виде "ту-же" и прочих "что-бы" — вообще отдельный привет...
Маскировка трафика OpenVPN при помощи обфускации