Комментарии 26
У вас в конфигурации написано, что
Как при этом вы передаете пакеты больше 1500 через интернет? Или я чего-то не понимаю?
# Определяем MTU
tun-mtu 1500Как при этом вы передаете пакеты больше 1500 через интернет? Или я чего-то не понимаю?
«Мы засунули твой VPN в VPN, чтобы… ». Не совсем понятна причина разнесения узлов с OpenVPN по каким-то VPS, при том, что «сервис клиента», к которому нужно получать доступ, находится в другом ДЦ/офисе, с одним или несколькими каналами. В это самое место и надо ставить OpenVPN. Если ДЦ несколько, с разными блоками адресов (но предположительно L2 VPN между ними), то ставить в каждый ДЦ OpenVPN.
Выдавать адреса ДНСом с TTL 0 — ну в принципе не самая плохая затея, но неплохо бы проверять доступность узлов, и выкидывать их при авариях. Но все равно будут перерывы в доступности из-за кэширования ДНС записей.
Выдавать адреса ДНСом с TTL 0 — ну в принципе не самая плохая затея, но неплохо бы проверять доступность узлов, и выкидывать их при авариях. Но все равно будут перерывы в доступности из-за кэширования ДНС записей.
Нет, перерывов не будет, будет лишь задержка во время коннекта на таймаут подключения к недоступной ноде.
По поводу разнесения нод на отдельных узлах — это было желание клиента. Сервис клиента в разных ДЦ, серверы также объединены по tinc, поэтому суть настройки не меняется.
Не совсем ясно, зачем нужны дополнительные точки отказа, у клиента могут быть для этого какие-то свои причины, а может быть просто непонимание этого. Может пропасть связанность между VPS и ДЦ клиента, может отвалиться туннель tinc в ДЦ клиента. Обычно стараются терминировать VPN как можно ближе к оборудованию, к которому будет предоставлен доступ.
Статичное количество клиентов на сервер и «балансировка» с помощью DNS — это не самое лучшее решение. В своё время решал аналогичную задачу для 1k+ клиентов. Это долгая история, но стоит упомянуть, что клиент OpenVPN будет переподключаться к следующему сереверу из списка при получении неизвестного control message от сервера (магия), то есть можно организовать централизованное управление подключениями клиентов (со временем доступа, весами/weight для серверов, отозванными сертификатами, гео перераспределением и т.д. и т.п.).
Я, в своё время, получил ответ на канале IRC openvpn-dev. Суть всего этого:
1. Клиент соединяется с первым сервером из списка
2. На сервере запускается скрипт проверки клиента, если клиент соотвествует — пропускаем, если нет — отлуп.
3. Если отлуп пришел «понятный», то клиент мужественно пытается переподключиться к этому же серверу, если же отлуп «неизвестен», то клиент отчаявшись переходит к следующему серверу.
В более старых версиях OpenVPN клиент при получении любого отлупа переходил к следующему серверу, но с какой-то версии разработчики поменяли поведение, поэтому стоит начать с release notes к продукту.
1. Клиент соединяется с первым сервером из списка
2. На сервере запускается скрипт проверки клиента, если клиент соотвествует — пропускаем, если нет — отлуп.
3. Если отлуп пришел «понятный», то клиент мужественно пытается переподключиться к этому же серверу, если же отлуп «неизвестен», то клиент отчаявшись переходит к следующему серверу.
В более старых версиях OpenVPN клиент при получении любого отлупа переходил к следующему серверу, но с какой-то версии разработчики поменяли поведение, поэтому стоит начать с release notes к продукту.
А зачем нужен tinc? Почему для связки входных нод с сервисом клиента не использовали тот же openvpn? Что умеет tinc, чего не может openvpn?
Флант, а чем вас softether не устроил? Открытый код, поддержка кластеризации, балансировка в кластере, отказоустойчивость. Лёгкое масштабирование, как линейное так и вертикальное. Встроенный функционал по связке с ldap\ad который и отвечает за блокировку юзеров. Клиенты одинаково хорошо работают для всех ОС, поддержка подавляющего числа vpn технологий чтобы встроенными в ос клиентами пользоваться.
Поддержвка клиентов, которые находятся за NAT, которым заблокировали порты (работает на 443 порте основной протокол). Изобрели вы велосипед. Встроенный dhcp правда только на поиграться, но легко заменяется на любое другое решение(создаём tun устройство и вешаем на него dhcp или dhcp сервер по L2 подключаем к впн).
Поддержвка клиентов, которые находятся за NAT, которым заблокировали порты (работает на 443 порте основной протокол). Изобрели вы велосипед. Встроенный dhcp правда только на поиграться, но легко заменяется на любое другое решение(создаём tun устройство и вешаем на него dhcp или dhcp сервер по L2 подключаем к впн).
Softether был одним из вариантов. Но в инфраструктуре клиента уже был tinc и было не важно, tinc+OpenVPN или tinc+softether.
Вторая проблема — процесс конфигурации, который сложно автоматизировать.
Третья, самая большая проблема: все вынесено в userspace, включая nat. softether — это решение само в себе, без интеграции в систему. Оно плохо управляется стандартными средствами администрирования. Поэтому мы его исключили при выборе.
Вторая проблема — процесс конфигурации, который сложно автоматизировать.
Третья, самая большая проблема: все вынесено в userspace, включая nat. softether — это решение само в себе, без интеграции в систему. Оно плохо управляется стандартными средствами администрирования. Поэтому мы его исключили при выборе.
Автоматизировать конфигурацию конечно сложно, я вот из-за необходимости сейчас изучаю варианты, но пока всё очень грустно.
NAT вынести из юзер спейса нет проблем, создаёте tun\tap устройство и подключаете это устройство как бридж в софтезер. На tun вешаете айпишник и рулите устройством как на опенвпн. tinc в случае с softether тоже лишний от него вообще можно избавиться.
Хотя раз вы взяли что было тут всё становится на свои места.
NAT вынести из юзер спейса нет проблем, создаёте tun\tap устройство и подключаете это устройство как бридж в софтезер. На tun вешаете айпишник и рулите устройством как на опенвпн. tinc в случае с softether тоже лишний от него вообще можно избавиться.
Хотя раз вы взяли что было тут всё становится на свои места.
У вас нет, слачайно, готового проекта по softether на Git-e? Можно в личку, пожалуйста.
Внесу свои 5 копеек, если часто пользоваться — заводить, отзывать сертификаты — то пользоваться через скрипты быстро надоедает. В свое время перешли на pfsense, где все это доступно через простой web интерфейс.
Тут вы правы, у нас есть немного более расширенный интерфейс сейчас, который автоматом создает клиентский ovpn, и отзыв там проще. Но мысль с вэб-интерфейсом здравая.
Скажите, а вы могли бы помочь в реализации идеи / решения, описанного в этой статье: https://m.habr.com/post/354956/?
Если интересно обсудить, напишите мне, плз
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Наш рецепт отказоустойчивого VPN-сервера на базе tinc, OpenVPN, Linux