Комментарии 106
Главная проблема каждого «еще одного VPN» — отсутствие поддержки в большинстве ОС без стороннего софта, а не пропускная способность. У того же IPSec с этим намного лучше.
У ipsec гораздо хуже с простотой настройки, все эти фаза 1, фаза 2, потом еще поверх может быть l2tp, ike, сертификаты, psk. У openvpn начинаются проблемы при большой нагрузки по трафику, la сильно растет, т.к. userspace. Дополнительное удобство wireguard, что единожды поднятый интерфейс не пропадает из системы, даже если потеряна связь со всеми пирами.
Главная проблема WireGuard в качестве VPN в том, что это не VPN. Это просто шифрованный тунель. Ближайшим аналогом того, что предоставляет wireguard, является вручную созданная Security Association средствами ядра Linux (например так).
Фаза 1, фаза 2 — это состояния протокола IKE, которые конечного пользователя не затрагивают. PSK — один из режимов аутентификации IKE, как и сертификаты. L2TP — просто один из видов полезной нагрузки, которая может быть инкапсулирована в IPsec, сейчас нет смысла настраивать VPN в таком режиме. Однако, это большой плюс самого IPsec — он, помимо тунельного, может работать и в транспортном режиме, в отличие от wireguard.
По поводу простоты конфигурации — сервер конфигурируется один раз и есть масса готовых рецептов и скриптов развёртывания VPN-серверов. Что же касается клиента:
Кроме этого, IPsec поддерживает массу протоколов шифрования и обмена ключами, и клиент может выбрать оптимальный для себя при согласовании соединения. В случае с Wireguard доступен только один набор криптопримитивов, и возможностей для его расширения не имеется. Кстати говоря, при желании, для IPsec доступны и постквантовые алгоритмы. Для Wireguard — нет.
IPsec на линуксе вообще не поднимает интерфейса, если работает нативно. Если нужно, чтобы какой-то адрес висел постоянно, чтобы на него можно было заранее жестко забиндить какой-то демон, то можно поднять его на lo или dummy-интерфейсе.
Noise protocol как раз для этого и используется в Wireguard. Однако, как верно заметили в комментах, сейчас уже в пору маскироваться под валидный HTTPS-трафик.
В итоге, несмотря на все восторги в адрес Wireguard, пока это даже близко не то же самое, что IKEv2.
У ipsec гораздо хуже с простотой настройки, все эти фаза 1, фаза 2, потом еще поверх может быть l2tp, ike, сертификаты, psk.
Фаза 1, фаза 2 — это состояния протокола IKE, которые конечного пользователя не затрагивают. PSK — один из режимов аутентификации IKE, как и сертификаты. L2TP — просто один из видов полезной нагрузки, которая может быть инкапсулирована в IPsec, сейчас нет смысла настраивать VPN в таком режиме. Однако, это большой плюс самого IPsec — он, помимо тунельного, может работать и в транспортном режиме, в отличие от wireguard.
По поводу простоты конфигурации — сервер конфигурируется один раз и есть масса готовых рецептов и скриптов развёртывания VPN-серверов. Что же касается клиента:
- Wireguard работает на данный момент нативно только на линуксе. IKEv2 работает на Linux, Mac 10.11+, Windows 7+, Android 4+, iOS 9+.
- Для IKEv2 можно авторизовываться по логину и паролю, либо по сертификатам. Для Wireguard будьте добры вбить ключи.
- IKEv2 есть во всех вышеупомянутых системах, для Wireguard даже на линуксе нужно собирать модуль.
- Нормальные VPN-демоны назначают адреса и протокол позволяет протолкнуть IP-конфигурацию соединения. В Wireguard будьте добры вбить вручную, так как это просто туннель.
Кроме этого, IPsec поддерживает массу протоколов шифрования и обмена ключами, и клиент может выбрать оптимальный для себя при согласовании соединения. В случае с Wireguard доступен только один набор криптопримитивов, и возможностей для его расширения не имеется. Кстати говоря, при желании, для IPsec доступны и постквантовые алгоритмы. Для Wireguard — нет.
Дополнительное удобство wireguard, что единожды поднятый интерфейс не пропадает из системы, даже если потеряна связь со всеми пирами.
IPsec на линуксе вообще не поднимает интерфейса, если работает нативно. Если нужно, чтобы какой-то адрес висел постоянно, чтобы на него можно было заранее жестко забиндить какой-то демон, то можно поднять его на lo или dummy-интерфейсе.
Возникает вопрос, возможно ли будет обфусцировать протокол?
Noise protocol как раз для этого и используется в Wireguard. Однако, как верно заметили в комментах, сейчас уже в пору маскироваться под валидный HTTPS-трафик.
В итоге, несмотря на все восторги в адрес Wireguard, пока это даже близко не то же самое, что IKEv2.
Wireguard работает на данный момент нативно только на линуксе. IKEv2 работает на Linux, Mac 10.11+, Windows 7+, Android 4+, iOS 9+.
Wireguard уже есть на Android + под Windows есть Tunsafe (там тоже открытый исходный код).
Он там работает нативно? То есть я получу обещанную скорость, выше чем у IPsec?
На Android — да, при условии наличия модуля в ядре.
На XDA уже масса ядер с модулем внутри.
На XDA уже масса ядер с модулем внутри.
Т.е. это недоступно для большинства обычных пользователей?
Далеко не на всех телефонах можно получить рута без танцев с бубном.
Ещё сложнее подцепить модуль ядра на уже имеющийся телефон.
И сразу молчу про то, что после такого издевательства телефон лишается возможности получать «по воздуху» новые прошивки.
Для гиков подойдёт на ура, кому надо — соберут нужные модули самостоятельно под свой телефон.
Но обычному пользователю все эти фишки не светят.
Далеко не на всех телефонах можно получить рута без танцев с бубном.
Ещё сложнее подцепить модуль ядра на уже имеющийся телефон.
И сразу молчу про то, что после такого издевательства телефон лишается возможности получать «по воздуху» новые прошивки.
Для гиков подойдёт на ура, кому надо — соберут нужные модули самостоятельно под свой телефон.
Но обычному пользователю все эти фишки не светят.
>> Кроме этого, IPsec поддерживает массу протоколов шифрования и обмена ключами, и клиент может выбрать оптимальный для себя при согласовании соединения.
Ну это как бы и фича в то же время. WireGuard как бы говорит, что их протокол как раз использует самые надежные шифронаборы (зачем вам другие?) и в случае нахождения проблем будет обновляться вся программа. В случае например OpenVPN вам придеться самостоятельно за этим следить и менять конфиг.
Ну это как бы и фича в то же время. WireGuard как бы говорит, что их протокол как раз использует самые надежные шифронаборы (зачем вам другие?) и в случае нахождения проблем будет обновляться вся программа. В случае например OpenVPN вам придеться самостоятельно за этим следить и менять конфиг.
как раз использует самые надежные шифронаборы (зачем вам другие?)
Самые надёжные наборы — это спорное утверждение, которого разработчики и не делали вовсе. Разнообразие наборов шифров нужно по следующим причинам:
- Чтобы не делать ставку на одно сочетание всех криптографических примитивов. Если так случится, что один из криптографических примитивов окажется уязвимым, то это делает весь протокол бесполезным без вариантов.
- Чтобы предоставить возможность выбора. Причин для выбора может быть много: скорость работы какого-либо шифра на конкретном устройстве или личные предпочтения, например.
Я понимаю вашу точку зрения. Я веду к тому, что в случае нахождения уязвимостей в шифронаборе WireGuard будут обновлены пакеты програмы, где они будут либо переведены на другие алгоритмы, либо заменены. Не думаю, что в случае WireGuard их заменить прям невозможно и они захардкожены, это очень-очень вряд ли.
С другой стороны, в случае примером с OpenVPN, указаный шифронабор (с каким-то DES примером) будет указан в конфиге, и обновляй OpenVPN или нет — он там будет. Более того, составить корректный шифронабор — это не такая уж и простая задача.
Я не хочу сказать, что OpenVPN — это очень плохо или WireGuard — это мечта. Я веду к тому, что в этом есть смысл.
С другой стороны, в случае примером с OpenVPN, указаный шифронабор (с каким-то DES примером) будет указан в конфиге, и обновляй OpenVPN или нет — он там будет. Более того, составить корректный шифронабор — это не такая уж и простая задача.
Я не хочу сказать, что OpenVPN — это очень плохо или WireGuard — это мечта. Я веду к тому, что в этом есть смысл.
Не думаю, что в случае WireGuard их заменить прям невозможно и они захардкожены, это очень-очень вряд ли.
Просто констатирую факт: да, захардкожены; да, невозможно заменить. Смотрите спецификацию протокола (вот ссылка на форматы сообщений), она вообще не предусматривает вариаций по шифрам в сообщениях. См. также исходный код, к примеру составление хэндшэйка NOISE. Кривая 2255-19 гвоздями вшита. Что в принципе немудрено, с другой провернуть обфускацию не выйдет так просто, это индивидуально.
Ну это как бы и фича в то же время. WireGuard как бы говорит, что их протокол как раз использует самые надежные шифронаборы (зачем вам другие?) и в случае нахождения проблем будет обновляться вся программа.
И в результате мы будем WireGuard v1.0 со старыми шифрами и WireGuard v2.0 с новыми шифрами, которые будут несовместимы. И либо придется НЕ обновлять сервер, чтобы поддержать работу с легаси клиентами, либо клиенты не смогут подцепиться (т.к. не ко всем клиентам, очевидно, будет вторая версия или ее будет возможно установить).
Ну… нет. То, что wireguard не даёт вам выбора шифросьюитов не значит того, что он сам не сможет это делать. Допустим, ломают текущий набор алгоритмов, выходит wg2.0, который может работать по двум алгоритмам — по новому и по старому (сначала пробуем дешифровать по новому, не получилось — по старому), сам определит, какие шифры у peer'a (если на том конце wg1.0, то и шифровать для него надо по-старому, иначе не поймёт).
В общем, каких-то принципиальных ограничений к смене шифров не вижу.
> Главная проблема WireGuard в качестве VPN в том, что это не VPN. Это просто шифрованный тунель.
Можете обьяснить разницу?
> По поводу простоты конфигурации — сервер конфигурируется один раз и есть масса готовых рецептов и скриптов развёртывания VPN-серверов.
Как бы не совсем. Скрипты конечно можно юзать — но это дополнительный уровень абстракции, после которого понимания что и зачем будет меньше. Ну и вопрос поддержки тоже актуален.
> Однако, это большой плюс самого IPsec — он, помимо тунельного, может работать и в транспортном режиме, в отличие от wireguard.
Тунельный и транспортный режимы? Что вы имеете ввиду?
Можете обьяснить разницу?
> По поводу простоты конфигурации — сервер конфигурируется один раз и есть масса готовых рецептов и скриптов развёртывания VPN-серверов.
Как бы не совсем. Скрипты конечно можно юзать — но это дополнительный уровень абстракции, после которого понимания что и зачем будет меньше. Ну и вопрос поддержки тоже актуален.
> Однако, это большой плюс самого IPsec — он, помимо тунельного, может работать и в транспортном режиме, в отличие от wireguard.
Тунельный и транспортный режимы? Что вы имеете ввиду?
Можете обьяснить разницу?
Я привёл сравнение в своём изначальном комментарии:
Главная проблема WireGuard в качестве VPN в том, что это не VPN. Это просто шифрованный тунель. Ближайшим аналогом того, что предоставляет wireguard, является вручную созданная Security Association средствами ядра Linux (например так).
Приведу ещё сопоставление, чтобы разница была ещё более явная: wireguard-у не хватает до VPN-а примерно того же, чего не хватает pppd до pptpd/xl2tpd/sstpd. Все эти демоны в конечном счёте хоть и используют pppd, но занимаются согласованием, созданием соединений и управлением ими. В вайргарде всё руками, как в туннелях, создаваемых прямо средствами ядра или в голом pppd. Все адреса назначает рутовый пользователь заблаговременно, он же вписывает все маршруты и так далее. Всё прибито гвоздями.
Тунельный и транспортный режимы? Что вы имеете ввиду?
Их и имею в виду.
Общие сведения
Более подробно
>> В вайргарде всё руками, как в туннелях, создаваемых прямо средствами ядра или в голом pppd. Все адреса назначает рутовый пользователь заблаговременно, он же вписывает все маршруты и так далее. Всё прибито гвоздями.
Это же еще не конечная реализация. Функционала не очень много, кто знает как будет дальше. Идейной разницы лично я не вижу.
В общем вы ведете к тому, что универсальное средство лучше частичного. Но даже если WireGuard делает что-то лучше — то почему его не использовать в этих случаях?
За ссылки спасибо.
Это же еще не конечная реализация. Функционала не очень много, кто знает как будет дальше. Идейной разницы лично я не вижу.
В общем вы ведете к тому, что универсальное средство лучше частичного. Но даже если WireGuard делает что-то лучше — то почему его не использовать в этих случаях?
За ссылки спасибо.
Я немного о другом. Если, к примеру, у вас где-то есть VPN-сервер для удалённого доступа сотрудников к рабочему месту, то заменить его на вайргард не выходит потому что много чего не хватает до того, к чему все привыкли у VPN. Для личного пользования — годится, я сам его использую на OpenWRT, так как он там весьма к месту пришёлся. И памяти не требует, и с реконнектами дело хорошо обстоит.
Другие достоинства wireguard — один ciphersuite и протокол noise на достоинства не совсем тянут. Про один набор шифров я написал, это не так круто как кажется. А noise просто окажется несостоятелен, когда станут блокировать весь мутный трафик. В таких условиях даже SSTP на 443ем порту будет выигрывать.
А как VPN общего назначения IKEv2 до сих пор в топе, и на всех устройствах/системах хорошо поддерживается.
Другие достоинства wireguard — один ciphersuite и протокол noise на достоинства не совсем тянут. Про один набор шифров я написал, это не так круто как кажется. А noise просто окажется несостоятелен, когда станут блокировать весь мутный трафик. В таких условиях даже SSTP на 443ем порту будет выигрывать.
А как VPN общего назначения IKEv2 до сих пор в топе, и на всех устройствах/системах хорошо поддерживается.
На самом деле я понял вас, а вы, надеюсь, хоть немного поняли меня.
Прятать впн трафик под https — это не так о скорости, как об обходе блокировок.
Прятать впн трафик под https — это не так о скорости, как об обходе блокировок.
Да я понял. Да, об обходе блокировок.
Про скорость — приведу в пример проприетарный VPN, который использует несколько соединений для передачи данных, замаскированных под https. У меня временами в тестах получалась скорость по спидтесту через VPN в два раза больше, чем с тем же сервером без VPN вообще (!). Там у них вроде идёт программная регулировка передачи через каждый канал и обнаружение потери скорости по каждому с перераспределением на другие. Таким образом этот VPN даже скрадывает потери пакетов, вызывающие сокращение окна TCP и потерю скорости передачи по одному соединению. Называется, «было бы желание».
Про скорость — приведу в пример проприетарный VPN, который использует несколько соединений для передачи данных, замаскированных под https. У меня временами в тестах получалась скорость по спидтесту через VPN в два раза больше, чем с тем же сервером без VPN вообще (!). Там у них вроде идёт программная регулировка передачи через каждый канал и обнаружение потери скорости по каждому с перераспределением на другие. Таким образом этот VPN даже скрадывает потери пакетов, вызывающие сокращение окна TCP и потерю скорости передачи по одному соединению. Называется, «было бы желание».
> Однако, как верно заметили в комментах, сейчас уже в пору маскироваться под валидный HTTPS-трафик.
HTTPS — это TCP, т.е. TCP over TCP в случае с ВПН sites.inka.de/bigred/devel/tcp-tcp.html
Но как опция может и не лишним будет.
HTTPS — это TCP, т.е. TCP over TCP в случае с ВПН sites.inka.de/bigred/devel/tcp-tcp.html
Но как опция может и не лишним будет.
HTTPS — это TCP, т.е. TCP over TCP в случае с ВПН sites.inka.de/bigred/devel/tcp-tcp.html
Но как опция может и не лишним будет.
Есть альтернативное мнение на этот счёт. Я сторонник использования дейтаграмм для этих целей, однако не всегда есть такой выбор.
Думаю, это скорее вопрос времени.
Ситуация сейчас такова, что пора уже сделать VPN, который целиком и полностью работает через https. Не мимикрирует под него, а действительно делает GET/POST по https в качестве транспорта при включении определенных настроек.
Да, медленно. Но пора.
Да, медленно. Но пора.
типа такого?
github.com/unbit/vpn-ws
github.com/unbit/vpn-ws
Выглядит замороченно для конечного потребителя, но примерно такое я и имел в виду, да.
Агаа, Ну-Ну… Использовал этот гит-репозторий, весьма годная штука… была… пока через месяц после установки не протух CRL, а продакшн-клиентов уже было за сотню! Притом автор сего решения даже не соизволил об этом упомянуть, никак от слова вообще!!! Не говоря уже о решении этой траблы. Имхую, что цель такого сервака ни разу не продакшн, а сервак-однодневка — проработать месяц на одном VPS-хостинге, затем протухнуть/выпилиться и подняться «с нуля» на другом. Продлить CRL у меня получилось только на следующие 30 дней. Последующее продление так и не заработало. Скрипт CRL-обновления ругался на какие-то кривые атрибуты в СА. Проблема еще в том, что конкретно по CRL-проблеме на openVPN-е гугл знает не много. Пришлось заколхозить всё это дело скриптом в cron-е, по «откату» системного времени каждую ночь. До такой стыдобы я еще не скатывался. Надеюсь этот костыль выпилить в ближайшее время. Вторая трабла — все VPN-клиенты за-NAT-ченные, что тоже крайне неудобно для eterprise-структур, т.е. из LAN-ки клиента никак не достать. И поменять NAT на routing вообще никак и судя по всему, OpenVPN тупо не умеет раутить клиентов. Хотя тот же самый MS ISA умел это дело переключать одной галочкой. Третий трабл — около-нулевая секьюрность — *.ovpn-ключ-настройка на клиентах OpenVPN храниться в явном виде в папочке профиля фраерка и спикрасть его, имея доступ к ПК — как два байта отослать. Единственный плюс решения — работает даже через параноидально-защищенные фаерволлы, где хоть как-то разрешен TCP:443.
> OpenVPN тупо не умеет раутить клиентов
Вообще-то умеет.
Вообще-то умеет.
поделитесь маном, пожалуйста. Желательно реально рабочим, а не кусочным.
Маном к чему? К openvpn? Родной неплохо написан.
Для роутинга в openvpn (в разных направлениях) есть как минимум 3 параметра:
1) push-route (который на клиенте заворачивает маршруты в vpn)
2) iroute (для роутинга клиентов внутри vpn-сети)
3) client-to-client, который позволит клиентам общаться между собой (через vpn-сервер, но всё же).
Выбирайте любой подходящий для вашего случая.
А писать готовые рецепты на все возможные случаи для монстра, подобного openvpn — неблагодарная работа.
Для роутинга в openvpn (в разных направлениях) есть как минимум 3 параметра:
1) push-route (который на клиенте заворачивает маршруты в vpn)
2) iroute (для роутинга клиентов внутри vpn-сети)
3) client-to-client, который позволит клиентам общаться между собой (через vpn-сервер, но всё же).
Выбирайте любой подходящий для вашего случая.
А писать готовые рецепты на все возможные случаи для монстра, подобного openvpn — неблагодарная работа.
> *.ovpn-ключ-настройка на клиентах OpenVPN
> храниться в явном виде в папочке профиля фраерка
єє, так зашифруй сертификаты для VPN доступа, никто не заставляєт их хранить в открытом виде рядом с конфигами OpenVPN.
> храниться в явном виде в папочке профиля фраерка
єє, так зашифруй сертификаты для VPN доступа, никто не заставляєт их хранить в открытом виде рядом с конфигами OpenVPN.
Мэээ, так подскажи, как шифровать. Понятно, что шифровать файловую систему нет особого смысла нет — сел за «залогиненную» учетку пользователя и слил *.ovpn. В идеале была бы технология как в винде — свое хранилище сертификатов и клей к ним, где можно ставить либо пароль на ключ либо метку «неэкспортируемый.»
Так на ключ в текстовом формате как раз и можно ставить пароль (на деле он шифруется ключом, выведенным из пароля).
Где можно наглядно посмотреть?
Если Вы генерируете сертификаты и ключи с помощью easy-rsa 2 из комплекта OpenVPN, то скрипт
./build-key-pass как раз такой и генерирует. А вообще средствами openssl это генерится например так:openssl genrsa -aes256 2048 > mykey.pemСкрипт генерации *.ovpn файла такой:
#! /bin/bash
# Script to automate creating new OpenVPN clients
#
# H Cooper — 05/02/11
# Y Frolov — 08/06/16 — bundle config added (unified format)
# Usage: newclient.sh <common-name>
echo «Script to generate unified config for Windows App»
echo «sage: newclient.sh <common-name>»
# Set vars
OPENVPN_DIR=/etc/openvpn
OPENVPN_RSA_DIR=/etc/openvpn/easy-rsa
OPENVPN_KEYS=$OPENVPN_RSA_DIR/keys
BUNDLE_DIR=/etc/openvpn/bundles
# Either read the CN from! or prompt for it
if [ -z "!" ]
then echo -n «Enter new client common name (CN): „
read -e CN
else
CN=$1
fi
# Ensure CN isn't blank
if [ -z “$CN» ]
then echo «You must provide a CN.»
exit
fi
# Check the CN doesn't already exist
if [ -f $OPENVPN_KEYS/$CN.crt ]
then echo «Error: certificate with the CN $CN alread exists!»
echo " $OPENVPN_KEYS/$CN.crt"
exit
fi
# Establish the default variables
export EASY_RSA="/etc/openvpn/easy-rsa"
export OPENSSL=«openssl»
export PKCS11TOOL=«pkcs11-tool»
export GREP=«grep»
export KEY_CONFIG=`$EASY_RSA/whichopensslcnf $EASY_RSA`
export KEY_DIR="$EASY_RSA/keys"
export PKCS11_MODULE_PATH=«dummy»
export PKCS11_PIN=«dummy»
export KEY_SIZE=2048
export CA_EXPIRE=3650
export KEY_EXPIRE=1825
export KEY_COUNTRY=«US»
export KEY_PROVINCE=«CA»
export KEY_CITY=«xxxxxxxx»
export KEY_ORG=«xxxxxxxxxx»
export KEY_EMAIL=«xxxxxxx»
export KEY_OU=«RG»
export KEY_NAME=«EasyRSA»
# Copied from build-key script (to ensure it works!)
export EASY_RSA="${EASY_RSA:-.}"
"$EASY_RSA/pkitool" --batch $CN
# Add all certs to unified client config file
# Default config for client
cp $OPENVPN_DIR/client.ovpn $BUNDLE_DIR/$CN.ovpn
# CA
echo "" >> $BUNDLE_DIR/$CN.ovpn
cat $OPENVPN_KEYS/ca.crt >> $BUNDLE_DIR/$CN.ovpn
echo "" >> $BUNDLE_DIR/$CN.ovpn
# Client cert
echo "" >> $BUNDLE_DIR/$CN.ovpn
cat $OPENVPN_KEYS/$CN.crt >> $BUNDLE_DIR/$CN.ovpn
echo "" >> $BUNDLE_DIR/$CN.ovpn
# Client key
echo "" >> $BUNDLE_DIR/$CN.ovpn
cat $OPENVPN_KEYS/$CN.key >> $BUNDLE_DIR/$CN.ovpn
echo "" >> $BUNDLE_DIR/$CN.ovpn
if openvpn --version | grep 2.3; then
# ta tls auth OpenVPN 2.3.x
echo «key-direction 1» >> $BUNDLE_DIR/$CN.ovpn
echo "<tls-auth>" >> $BUNDLE_DIR/$CN.ovpn
cat $OPENVPN_KEYS/ta.key >> $BUNDLE_DIR/$CN.ovpn
echo "</tls-auth>" >> $BUNDLE_DIR/$CN.ovpn
else
# ta tls crypt OpenVPN 2.4.x
echo "<tls-crypt>" >> $BUNDLE_DIR/$CN.ovpn
cat $OPENVPN_KEYS/ta.key >> $BUNDLE_DIR/$CN.ovpn
echo "</tls-crypt>" >> $BUNDLE_DIR/$CN.ovpn
fi
# DH key
echo "" >> $BUNDLE_DIR/$CN.ovpn
cat $OPENVPN_KEYS/dh.pem >> $BUNDLE_DIR/$CN.ovpn
echo "" >> $BUNDLE_DIR/$CN.ovpn
#echo ""
echo «COMPLETE! Copy the new unified config from here: /etc/openvpn/bundles/$CN.ovpn»
Где здесь можно еще пароль прикрутить?
#! /bin/bash
# Script to automate creating new OpenVPN clients
#
# H Cooper — 05/02/11
# Y Frolov — 08/06/16 — bundle config added (unified format)
# Usage: newclient.sh <common-name>
echo «Script to generate unified config for Windows App»
echo «sage: newclient.sh <common-name>»
# Set vars
OPENVPN_DIR=/etc/openvpn
OPENVPN_RSA_DIR=/etc/openvpn/easy-rsa
OPENVPN_KEYS=$OPENVPN_RSA_DIR/keys
BUNDLE_DIR=/etc/openvpn/bundles
# Either read the CN from! or prompt for it
if [ -z "!" ]
then echo -n «Enter new client common name (CN): „
read -e CN
else
CN=$1
fi
# Ensure CN isn't blank
if [ -z “$CN» ]
then echo «You must provide a CN.»
exit
fi
# Check the CN doesn't already exist
if [ -f $OPENVPN_KEYS/$CN.crt ]
then echo «Error: certificate with the CN $CN alread exists!»
echo " $OPENVPN_KEYS/$CN.crt"
exit
fi
# Establish the default variables
export EASY_RSA="/etc/openvpn/easy-rsa"
export OPENSSL=«openssl»
export PKCS11TOOL=«pkcs11-tool»
export GREP=«grep»
export KEY_CONFIG=`$EASY_RSA/whichopensslcnf $EASY_RSA`
export KEY_DIR="$EASY_RSA/keys"
export PKCS11_MODULE_PATH=«dummy»
export PKCS11_PIN=«dummy»
export KEY_SIZE=2048
export CA_EXPIRE=3650
export KEY_EXPIRE=1825
export KEY_COUNTRY=«US»
export KEY_PROVINCE=«CA»
export KEY_CITY=«xxxxxxxx»
export KEY_ORG=«xxxxxxxxxx»
export KEY_EMAIL=«xxxxxxx»
export KEY_OU=«RG»
export KEY_NAME=«EasyRSA»
# Copied from build-key script (to ensure it works!)
export EASY_RSA="${EASY_RSA:-.}"
"$EASY_RSA/pkitool" --batch $CN
# Add all certs to unified client config file
# Default config for client
cp $OPENVPN_DIR/client.ovpn $BUNDLE_DIR/$CN.ovpn
# CA
echo "" >> $BUNDLE_DIR/$CN.ovpn
cat $OPENVPN_KEYS/ca.crt >> $BUNDLE_DIR/$CN.ovpn
echo "" >> $BUNDLE_DIR/$CN.ovpn
# Client cert
echo "" >> $BUNDLE_DIR/$CN.ovpn
cat $OPENVPN_KEYS/$CN.crt >> $BUNDLE_DIR/$CN.ovpn
echo "" >> $BUNDLE_DIR/$CN.ovpn
# Client key
echo "" >> $BUNDLE_DIR/$CN.ovpn
cat $OPENVPN_KEYS/$CN.key >> $BUNDLE_DIR/$CN.ovpn
echo "" >> $BUNDLE_DIR/$CN.ovpn
if openvpn --version | grep 2.3; then
# ta tls auth OpenVPN 2.3.x
echo «key-direction 1» >> $BUNDLE_DIR/$CN.ovpn
echo "<tls-auth>" >> $BUNDLE_DIR/$CN.ovpn
cat $OPENVPN_KEYS/ta.key >> $BUNDLE_DIR/$CN.ovpn
echo "</tls-auth>" >> $BUNDLE_DIR/$CN.ovpn
else
# ta tls crypt OpenVPN 2.4.x
echo "<tls-crypt>" >> $BUNDLE_DIR/$CN.ovpn
cat $OPENVPN_KEYS/ta.key >> $BUNDLE_DIR/$CN.ovpn
echo "</tls-crypt>" >> $BUNDLE_DIR/$CN.ovpn
fi
# DH key
echo "" >> $BUNDLE_DIR/$CN.ovpn
cat $OPENVPN_KEYS/dh.pem >> $BUNDLE_DIR/$CN.ovpn
echo "" >> $BUNDLE_DIR/$CN.ovpn
#echo ""
echo «COMPLETE! Copy the new unified config from here: /etc/openvpn/bundles/$CN.ovpn»
Где здесь можно еще пароль прикрутить?
без понятия что это за скрипт.
В моем коменте ниже, я написал как зашифровать.
Оpenssl спросит пароль в процессе шифрования.
После чего OpenVPN, видя что файл зашифрован, будет каждый раз при коннекте спрашивать пароль для дешифровки сертификата.
В моем коменте ниже, я написал как зашифровать.
Оpenssl спросит пароль в процессе шифрования.
После чего OpenVPN, видя что файл зашифрован, будет каждый раз при коннекте спрашивать пароль для дешифровки сертификата.
Я заметил одно серьезное отличие — в вашем мане *.pem, а в моем конфиге *.ovpn. Что в деталях делает этот скрипт — я ХЗ, и как туда вставить *.pem тоже. И еще вопрос — поймет ли OpenVPN GUI формат pem?
ну как-то так видимо:
openssl pkcs12 -export -in temp.pem -out encrypted_key.p12
а в конфиге опенвпна прописывается как обычно
pkcs12 encrypted_key.p12
Ничего сложного ;-)
openssl pkcs12 -export -in temp.pem -out encrypted_key.p12
а в конфиге опенвпна прописывается как обычно
pkcs12 encrypted_key.p12
Ничего сложного ;-)
надеюсь вы понимаете что вот эта метка «неэкспортируемый.», это чисто софтверная примочка, а сами ключи всеравно хранятся на жестком диске, а не в каком-то специальном хранилище которое они никогда не покидают.
Всё лучше, чем хранить ключ в открытом виде. Буду рад если скинете пруф, что эта галочка бесполезная. На может и ЖД хранятся, но явно не в открытом виде.
я не говорил что она бесполезная. Только о том что не стоит переоценивать ее возможности.
Лучше чем ничего. Как мера против школоты и войтишников спасет наверняка. Среднему энетрпрайсу бОльшего и не надо. А сломать любую галочку (АКА любое шифрование) всегда возможно в этом мире — вопрос денег и времени. Обязательно сломают, не сегодня, так завтра, когда алгоритмы шифрования подпротухнут, а ASIC-и станут немного быстрее. Так что не стОит переоценивать возможности ничего и никогда.
Cisco Anyconnect, если не ошибаюсь, может так работать. Для Shadowsocks есть обфусцирующие плагины, которые могут эмулировать POST-запрос. Obfsproxy тоже так может работать.
Зря заминусовали. Сейчас в странах Среднего Востока с цензурой уже почти весь нераспознанный трафик просто обрезают и всё. Поэтому где-то как-то можно пропустить шифрованный трафик только внутри валидного HTTPS-соединения.
Есть ещё вот такой интересный инструмент.
Как с поддержкой радиуса, назначения ip клиентам, работа на 443 порту по tcp, доступ с мобильных, разные сети для разных учетных записей?
Никак, это просто туннель. По сути ближайший аналог того, что и сейчас доступно средствами IPsec через команду
ip xfrm. Примеры.
Кроме этого поддерживаются… Android… но в них WireGuard выполняется в userspace со всеми вытекающими последствиями для производительности.
Если вендор наложил патчи на ядро (или есть возможность установки кастомного ядра), то будет выполняться на уровне ядра.
В системах с systemd вместо этого можно использовать sudo systemctl start wg-quick@wg0.service.
В системах с относительно свежим systemd ≥237 можно использовать встроенную в systemd‑networkd поддержку wireguard. С использованием юнитов .netdev и .network
Для Windows доступен «альтернативный» клиент TunSafe.
Им занимается автор μTorrent, OpenTTD и ScummVM: Ludvig Strigeus
Им занимается автор μTorrent, OpenTTD и ScummVM: Ludvig Strigeus
WireGuard, с моей точки зрения, вообще идеален для пользователя
Генерируются ключи шифрования утилитой wg
создать серверный конфиг /etc/wireguard/wg0.conf
поднять туннель скриптом wg-quick
Но самое интересное
sudo wg-quick up /etc/wireguard/wg0.conf
Я сравниваю два подчёркнутых слова и чего-то не понимаю 8-)
Боюсь скоро государство захочет поставить централизованный вайлдкард сертификат и будет пытаться чекать весь https трафик и не спасет нас мимикрирование под известные протоколы…
Или не государство. Некоторые провайдеры и операторы тоже этим балуются, исключительно в силу того, что «могут».
Будущее интернета, а не чебурнета некоторых нефтебанановых республик.
Здесь нет сложной системы сертификатов и всего этого корпоративного ужаса, короткие ключи шифрования распространяются примерно как SSH ключи.Сертификаты защищают от MITM атак и не относяться только к корпоративному сегменту. Без них у вас не будет другого выхода, кроме как передавать ключи по другим каналам связи, что неудобно для обычных пользователей. А если хотите передать безопасно и не в открытом виде, то это будет или передача при личной встрече или что-то с шифрованием и с теми же сертифкитами. Для vpn это, по моему, минус.
Да и «ужас» бывает не всегда, использую сертификаты letsencrypt для ipsec, вся настройка — это указать путь к сертификату на сервере, на клиенты сертификат ставить не надо.
А у Вас есть клиенты на Windows? Там вроде как особые требования к сертификатам и к значению маршрутов: wiki.strongswan.org/projects/strongswan/wiki/Win7CertReq
Прошу заметить, что помимо описанного в статье wg-quick, wireguard интерфейсы умеет создавать systemd-networkd (с какой-то там версии, уточните в документации):
Если у вас сервер на systemd — не используйте wg-quick, это очень… Странная штука.
# cat /etc/systemd/network/15-vpn.netdev
[NetDev]
Name=vpn
Kind=wireguard
[WireGuard]
PrivateKey = SOME_PRIVATE_KEY
ListenPort = 51820
[WireGuardPeer]
PublicKey = SOME_PUBLIC_KEY
PresharedKey = SOME_PSK_KEY
AllowedIPs = 172.16.0.0/12
Endpoint = 1.2.3.4:1234
Если у вас сервер на systemd — не используйте wg-quick, это очень… Странная штука.
Такую простоту использования и компактность кодовой базы удалось достичь за счет отказа от функционала дистрибьюции ключей. Здесь нет сложной системы сертификатов и всего этого корпоративного ужаса, короткие ключи шифрования распространяются примерно как SSH ключи. Но в связи с этим возникает проблема: WireGuard будет не так просто внедрять в некоторых уже существующих сетях.
openvpn.net/community-resources/static-key-mini-howto
А как правильно прописывать маршруты через интерфейс wg на андроиде, если есть рут, и есть необходимость задавать их вручную? (Android использует iproute2 и несколько таблиц маршрутизации)
Вы упомянули высокую производительность и даже результаты бенчмарков, а могли бы вы добавить что-нибудь насчёт системных требований?
Полагаю, что наиболее важным параметром будет объём оперативной памяти.
Т.е. VPS'а с какими параметрами будет достаточно для УайрГарда?
А то у них на сайт только kernel requirements есть.
Полагаю, что наиболее важным параметром будет объём оперативной памяти.
Т.е. VPS'а с какими параметрами будет достаточно для УайрГарда?
А то у них на сайт только kernel requirements есть.
Мизерные требования, основной ресурс — cpu, на {де,}шифрование трафика и логику с ключами. Оперативной памяти вообще крохи — буквально несколько десятков килобайт.
VPS — любой совершенно, главное, чтобы ядро было своё родное. Т.е. предпочтительно kvm, можно xen, ни в коем случае openvz.
Прошу извинить, что отвечаю так поздно — из-за работы совсем не до хабра было.
Спасибо за уточнение, информация очень кстати на фоне испытаний нового The Great Firewall of Russia.
Если вас не затруднит, подскажите ещё пожалуйста: а почему «ни в коем случае openvz»? Там какие-то нужные функции не виртуализировали, нужна свежая версия kernel или что-то ещё?
А то как раз самые лучшие предложения по ВПС, разумеется, на ОупенВЗ.
Спасибо за уточнение, информация очень кстати на фоне испытаний нового The Great Firewall of Russia.
Если вас не затруднит, подскажите ещё пожалуйста: а почему «ни в коем случае openvz»? Там какие-то нужные функции не виртуализировали, нужна свежая версия kernel или что-то ещё?
А то как раз самые лучшие предложения по ВПС, разумеется, на ОупенВЗ.
Подскажите, вот установил wireguard на сервер (все норм), подключаюсь с винды через tunsafe и все вроде хорошо конектится, вот только инет на компе остается прежним (с айпишником моего провайдера, а не сервера) :) Если знаете как это решить напишите пожалуйста, буду вам очень-очень благодарен!
tunsafe.com/support
Q: Can I route all network traffic throgh TunSafe?
A: Yes, TunSafe configures the computer to route all traffic through the peer with AllowedIPs=0.0.0.0/0
т.е. на клиенте нужно прописать AllowedIPs=0.0.0.0/0 и убедиться, что маршрут по-умолчанию — это интерфейс WireGuard, когда он включен.
На сервере нужно не забыть включить IPv4 forwarding и masquerade в iptables, все это описано в мануалах.
Q: Can I route all network traffic throgh TunSafe?
A: Yes, TunSafe configures the computer to route all traffic through the peer with AllowedIPs=0.0.0.0/0
т.е. на клиенте нужно прописать AllowedIPs=0.0.0.0/0 и убедиться, что маршрут по-умолчанию — это интерфейс WireGuard, когда он включен.
На сервере нужно не забыть включить IPv4 forwarding и masquerade в iptables, все это описано в мануалах.
Windows [coming soon]
A Windows client is coming soon. In the meantime, you are strongly advised to stay away from Windows clients that are not released from this site, as they may be dangerous to use, despite marketing efforts.
Для меня это слишком в будущем. Мне крайне необходимо подключаться к домашнему серверу с Windows компьютера и OpenVPN так позволяет, а Wireguard всё ещё нет и так уже не первый год, ни клиента ни сервера с открытыми сырцами под Windows до сих пор нет.
Возможно я в итоге докуплю себе на работу и в рюкзак по мощному роутеру, чтобы могли сами держать VPN, но как это не здорово.
Выше уже написали про тонкости что это не VPN а туннель и если на OpenVPN я могу спокойно подсунуть готовый конфиг для подключения а маршрутизацию по умолчанию настроить прямо на сервере то как это всё делать с Wireguard — вероятно никак, потому что вручную на каждом клиенте ковырять что то это ужас.
Ну а в целом — да, очень хочется высокой скорости уже сейчас, а IPsec я так ниразу и не осилил, особенно вопрос как поднять сервер и как поднять сервер на Windows не смотря даже на подробные разбобры вроде этого habr.com/ru/post/210410. Человечного простого описания как подключиться с Android тоже так и не нашёл.
P.S. плюс ещё не понятно как решать проблему когда кроме SSL по 443 порту больше ничего не работает, а UDP не работает вообще. У OpenVPN клиента под Android даже автоматический костыль на этот случай есть, а для Wireguard как и для IPsec со всем этим беспросветное дно.
P.P.S. в общем я чувствую что заморачиваться нужно с
SoftEther VPN он хотя бы универсальную админку ко всему даёт.
SoftEther VPN он хотя бы универсальную админку ко всему даёт.
И ещё момент: аутентификацию со стороны сервера лучше всего сделать по сертификатам от того же Let's Encrypt, а клиента аутентифицировать всё же удобнее по паролю через ms-chapv2.
Благодарю, очень хорошая статья, схоронил её в закладки, но я пока занялся тюнингом OpenVPN и несколько банальных настроек уже увеличили скорость в полтора раза. Так что пока я заморачиваться VPN который требует кучу портов не стану. Плюс OpenVPN может помочь соблюдать MTU в 1500 байт разбивая пакеты самостоятельно, а потом собирая их, скорость конечно проседает, зато совместимость хорошая.
P.S. постараюсь заняться написанием статьи про OpenVPN «здорового человека», но так времени не хватает, что просто жуть.
P.S. постараюсь заняться написанием статьи про OpenVPN «здорового человека», но так времени не хватает, что просто жуть.
Заметил, что есть много случаев где нужен VPN без шифрования.
Людям нужен простой VPN просто для организации одноранговой сети, без выхода через неё в интернет. Всегда для этого хватало простого в настройке PPTP. Но поняв это PPTP блокируют теперь провайдеры.
Подскажите как поднять (настроить) L2TP VPN сервер без IPSEC шифрования в Linux (Ubuntu).
С L2TP VPN с шифрованием IPSec нашел множество инструкций, и деже готовых скриптов. Но не могу найти ни одной инструкции L2TP VPN без IPSec. (вернее одну нашел 2008 г. там еще l2tp пакеты).
Условия: Комп за роутером, порт 1701 проброшен и ТСР и UDP. ОС Ubuntu 18.04.5 LTS (чистая, со всеми последними обновлениями). Выходить в интернет через этот VPN не надо.
Я установил сервер L2TP
и как только не настраивал файл
не запускается сервер, и подключиться к нему не могу.
port = 1701 пробросил в роутере
Может у кого есть скрипт настройки L2TP VPN без IPSec (шифрование просто не нужно в данном случае).
Может клиенты просто не могут соединиться без шифрования? Где то прочитал что может Windows не дает просто нешифрованное соединение.
Но так же пишут что у многих роутеров и в том же SoftEther VPN есть возможность отключить шифрование IPSec, значит такое соединение без шифрования всё таки бывает что используется и применяется.
Как это настроить в xl2tpd?
Может у кого то стоит настроенный L2TP VPN без IPSec можете скинуть файлы конфигурации
1. /etc/xl2tpd/xl2tpd.conf
2. /etc/xl2tpd/xl2tpd-secrets
3. /etc/ppp/options.xl2tpd
Может еще где то надо что то? Или порты какие то еще пробросить (сервер стоит за роутером, внешний IP белый)
менял-менял настройки xl2tpd сервер вроде запустился
Но подключиться так и не могу.
То ошибка 651 то (сейчас) 868 стала.
Я понимаю что вроде как «делай с шифрованием» как «все делают» «не выпендривайся». Но если честно, сначала хотел без шифрования для минимизации процессов и нагрузки, а теперь уже принципиально хочу добить. Ведь есть протокол L2TP, он же должен работать. Странно почему не пользуются, ведь не всем нужно шифрование, тем кто просто играет по виртуальной сети VPN вообще не нужно шифрование и лишние задержки.
Может есть какое то еще решение простое?
Спасибо!
Людям нужен простой VPN просто для организации одноранговой сети, без выхода через неё в интернет. Всегда для этого хватало простого в настройке PPTP. Но поняв это PPTP блокируют теперь провайдеры.
Подскажите как поднять (настроить) L2TP VPN сервер без IPSEC шифрования в Linux (Ubuntu).
С L2TP VPN с шифрованием IPSec нашел множество инструкций, и деже готовых скриптов. Но не могу найти ни одной инструкции L2TP VPN без IPSec. (вернее одну нашел 2008 г. там еще l2tp пакеты).
Условия: Комп за роутером, порт 1701 проброшен и ТСР и UDP. ОС Ubuntu 18.04.5 LTS (чистая, со всеми последними обновлениями). Выходить в интернет через этот VPN не надо.
Я установил сервер L2TP
apt-get install xl2tpd
и как только не настраивал файл
vi /etc/xl2tpd/xl2tpd.confне запускается сервер, и подключиться к нему не могу.
port = 1701 пробросил в роутере
Может у кого есть скрипт настройки L2TP VPN без IPSec (шифрование просто не нужно в данном случае).
Может клиенты просто не могут соединиться без шифрования? Где то прочитал что может Windows не дает просто нешифрованное соединение.
Но так же пишут что у многих роутеров и в том же SoftEther VPN есть возможность отключить шифрование IPSec, значит такое соединение без шифрования всё таки бывает что используется и применяется.
Как это настроить в xl2tpd?
Может у кого то стоит настроенный L2TP VPN без IPSec можете скинуть файлы конфигурации
1. /etc/xl2tpd/xl2tpd.conf
2. /etc/xl2tpd/xl2tpd-secrets
3. /etc/ppp/options.xl2tpd
Может еще где то надо что то? Или порты какие то еще пробросить (сервер стоит за роутером, внешний IP белый)
менял-менял настройки xl2tpd сервер вроде запустился
root@s:/home/s# /etc/init.d/xl2tpd restart
[ ok ] Restarting xl2tpd (via systemctl): xl2tpd.service.Но подключиться так и не могу.
То ошибка 651 то (сейчас) 868 стала.
Я понимаю что вроде как «делай с шифрованием» как «все делают» «не выпендривайся». Но если честно, сначала хотел без шифрования для минимизации процессов и нагрузки, а теперь уже принципиально хочу добить. Ведь есть протокол L2TP, он же должен работать. Странно почему не пользуются, ведь не всем нужно шифрование, тем кто просто играет по виртуальной сети VPN вообще не нужно шифрование и лишние задержки.
Может есть какое то еще решение простое?
Спасибо!
Заметил, что есть много случаев где нужен VPN без шифрования.
не нужен. С чего Вы взяли, что нужен? Если шифрование достигается условно бесплатно (как в l2tp) — пускай оно будет. Или Вы считаете, что L2TP/IPsec не поддерживается на ряде оборудования? Ну, так я такого оборудования уже давно не видел. Буду признателен, если поясните
Странно почему не пользуются, ведь не всем нужно шифрование, тем кто просто играет по виртуальной сети VPN вообще не нужно шифрование и лишние задержки.
потому что это тупо использовать VPN без шифрования? Ну, так как если задача VPN скрыть трафик от посторонних глаз, то инкапсуляции пакетов недостаточно?
Ну, справедливости ради, иногда задача VPN — не скрыть трафик, а обойти ограничения адресации.
Тогда возможно проще заказать себе ipv6 адрес и ходить через брокера в интернет. По сути тоже туннелирование и получается
Ограничение адресации может накладываться не провайдером, а прикладной программой (пример — старые игры и Garena) или ленью (пример — когда нам нужно было склонировать вручную настроенный стенд с кучей виртуалок, админы помещали копию в закрытой сети с доступом через VPN).
А фактура по старым играм есть?
Ну, т.е. что им нужно? Выделение каких-то выделенных айпи блоков?
Если не очень старые (т.е. уже эпохи Internet Protocol) — то им нужны широковещательные пакеты. Если повезёт — то достаточно такой пакет поймать и доставить до нужного сокета, если нет — понадобится ещё "белые" IP транслировать в "серые" и обратно (собственно, Garena этим и занималась).
Более старым придётся IPX эмулировать (сам не сталкивался, но что-то про это слышал). Самым старым нужно эмулировать нуль-модем, но это уже не VPN.
Да ниже написали правильно. Вот мы играем в игры, нам нужна просто сетка, но у всех серые IP потому что искусственно создан дефицит IP реальных адресов. Зачем шифрование на игры?
Или мы меняемся просто файлами, музыкой — ничего секретного. Да пусть смотрит кому не лень.
Если выбирать между сложным и простым… то лучше иметь нешифрованную VPN и использовать, чем не иметь ничего, просто потому что не смогли настроить.
При этом для шифрования нужно доп ресурсы, пакеты, процессы запускать на не мощном «сервере» типа.
Еще и видимо появятся задержки в играх, хоть не большие но задержки, и ради чего? чтобы зашифровать что кто то выстрелил в кого то?
Просто как пример.
Реально все что с шифрованием сложно настроить.
Я и прошу помощи, потому что не можем настроить, а простой без шифрование PPTP которым пользовались — начали блокировать.
А реально то было всего 2 настройки — создать пользователя и написать диапазон адресов.
просто вопрос — почему нет такого же (простой програмки) для компьютера или того же L2TP
Или мы меняемся просто файлами, музыкой — ничего секретного. Да пусть смотрит кому не лень.
Если выбирать между сложным и простым… то лучше иметь нешифрованную VPN и использовать, чем не иметь ничего, просто потому что не смогли настроить.
При этом для шифрования нужно доп ресурсы, пакеты, процессы запускать на не мощном «сервере» типа.
Еще и видимо появятся задержки в играх, хоть не большие но задержки, и ради чего? чтобы зашифровать что кто то выстрелил в кого то?
Просто как пример.
Реально все что с шифрованием сложно настроить.
Я и прошу помощи, потому что не можем настроить, а простой без шифрование PPTP которым пользовались — начали блокировать.
А реально то было всего 2 настройки — создать пользователя и написать диапазон адресов.
просто вопрос — почему нет такого же (простой програмки) для компьютера или того же L2TP
При этом для шифрования нужно доп ресурсы, пакеты, процессы запускать на не мощном «сервере» типа.
Проблема преувеличена ) как минимум — есть аппаратные шифры, которые на процессоре быстро считаются. Ну, и 5% снижения производительности — это не проблема.
Реально все что с шифрованием сложно настроить.
Не могу прокомментировать )
Я и прошу помощи, потому что не можем настроить, а простой без шифрование PPTP которым пользовались — начали блокировать.
И правильно делают. Там под капотом GRE, который давно прикопать пора
И правильно делают. Там под капотом GRE, который давно прикопать пора
Нет там прозаичнее причина — просят деньги, просто купить более дорогой тариф с белым IP!!! Логика, непостижимая, чтобы сделать сеть — надо купить сеть))))
Проблема преувеличена ) как минимум — есть аппаратные шифры, которые на процессоре быстро считаются. Ну, и 5% снижения производительности — это не проблема.
Ради чего? Вот просто не нужно. А если учесть что под сервер выделяется что то старое или Атом, то это уже не 5%, да и не жалко бы было, если бы было ради чего. Лишние процессы и лишние порты.
Особо жалко порты, во многих бюджетных роутерах ограничено количество пробросов портов. А там разница 4 (с шифрованием) против 1 без. И опять же — ради чего, если шифрования не надо.
Ну и понятно, что сбоев будет больше чем сложнее настройки.
бюджетные роутеру
бюджетные сервера
....
Извините, но это выглядит как безысходность. Не готовы за что-то платить — значит, это и не нужно. К сожалению. Все в этом мире так или иначе стоит чего-то.
Помню, мы раньше с ребятами собирали топовые игровые компы. Чтобы комфортно играться и это вылетало в копеечку. Ну, что поделать.
А попытки скроить… по опыту… приводят к самому обычному результату «скупой платит дважды».
Извините, ещё раз )
Не готовы за что-то платить — значит, это и не нужно.
За все заплачено и все работало, и все очень простое. Проблема не в деньгах, а в искусственно созданных препятствиях. Если что то работало и перестало работать по причине блокирования — это не проблема софта или роутера.
Или вы сторонник покупать проф решения для дома? У вас поди дома сервер в 3 стойках стоит?
Вы во всех темах просто тролль, я уже приметил вас ка ки многие другие. Лишь бы ляпнуть вам. Ни в чем не разбираетесь, только бла бла бал — плати те, платите.
Вся ваша суть везде сводится во всех постах — «платите больше». Вас кто то нанял для улучшения продаж?
Вас уже заминусовали ниже дна, нет вы всё брызжете и оттуда.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
WireGuard — прекрасный VPN будущего?