Pull to refresh

Comments 18

А зачем вы такие проблемы себе с адресами создали? У вас же и так указана директива server и ifconfig-pool-persist, зачем вы создаете client-config для каждого клиента, указывая там его адрес?
Да и p2p-топологию не рекомендуют разработчики OpenVPN использовать, хоть она и по умолчанию. Используйте topology subnet.
Не понял в чем проблема? Решение предназначено для удаленных клиентов, которые
  • должны быть изолированы друг от друга
  • используют различные, в том числе устаревшие ОС
  • после подключения продолжают использовать собственный шлюз по-умолчанию для выхода в интернет.
  • Поэтому самым очевидным решением было использовать для каждого подсеть /30 чтобы разделить их на уровне маршрутизации пакетов.
Хм, ну, этого всего можно и с topology subnet добиться, но я вас понял. Однако, не понял, зачем все-таки нужны клиентские конфиги с IP.
Я понял. Это не отмечено в статье, надо будет поправить. Дело в индивидуальном подходе и жестком разграничении доступа — безопасность. Представьте большое предприятие с десятком филилов. У каждого филиала собственная подсеть или несколько. А точка входа одна — корпоративный OpenVPN шлюз. Для разрешения доступа только в те подсети, куда клиенту можно ходить в индивидуальный файл дописываются, например, маршруты в его рабочие сети:
ifconfig-push 172.17.0.6 172.17.0.5
push "route 10.12.0.0 255.255.255.0"
push "route 192.168.100.0 255.255.255.0"</souce>
Но ifconfig-push-то все-равно лишний, или я что-то упустил?
А как же клиенту без ifconfig-push указать адрес в момент открытия соединения? Или я что-то упустил?
Он выдаваться будет из диапазона, указанного в server.
Такой вариант конфига я не тестировал, возможно так будет работать. Но во-первых, это (потенциально) позволит с одним сертификтом открыть несколько сессий — адреса же не будут перескаться. А тут — жесткая блокировка одной сесии по IP адресу. А во вторых, у меня еще биллинг завязан для контроля, который активность клиентов в базу данных пишет. А логин клиента к IP адресу биллинг парсит как раз из этого файлика. Как то так.
Нет, пока вы не используете опцию duplicate-cn, с одним сертификатом несколько раз подключиться не получится.
UFO landed and left these words here
UFO landed and left these words here
Да просто удобно. Но если вы хорошо знаете openssl, то да, пожалуй, для вас бессмысленно.
Думаю, это дело личного вкуса админа. Мне тогда показалось easy-rsa вкуснее.
Я посмотрел сайт SoftEther и пост ValdikSS. Внешне все круто. Лично для себя (для подключения «на коленке») я с удовольствием буду его использовать и заодно тестить. НО!

Когда речь идет о срочной организации ( как обычно — надо было вчера ) VPN-сервера для крупного предприятия, а в репозториях Debian, Archlinux, FreeBSD, Ubuntu нет даже упоминаний о нем… Хм. Без длительного тестирования такой софт на север предприятия я не поставлю. Можете называть меня перестраховщиком, но я сисадмин, а не тестировщик или камикадзе.
Работает уже год. Собрал сервер под OpenWRT есть и в Ubuntu. Клиентов 20-30. Работает на весьма ответственном участке. Сбои по вине SoftEther не было ни разу.

Управление как из менеджеров через сеть — что крайне удобно, так из консоли непосредственно на сервере. Работают как клиенты SoftEther так и OpenVPN и L2TP в Android устройствах. Есть DDNS встроенный. Можно сервера объединять. У нас так объединены клиенты в общую сеть с нами. Правда пришлось адреса NETMAP`ом разруливать из за одинаковых подсетей.

для OpenWRT
тут все очень подробно расписано:
wordpress.tirlins.com/?p=63

Для Ubuntu.
sudo apt-add-repository ppa:dajhorn/softether
sudo apt-get update
sudo apt-get install softether -y
sudo service softether start
Sign up to leave a comment.

Articles