Openvpn tcp и udp одновременно ubuntu
Обновлено: 04.07.2024
По умолчанию в директории /etc/openvpn/ конфигурационных файлов нет, но есть две директории для них — server и client . Файл конфигурации нужно создать самостоятельно и поместить в директорию server (для сервера) или client (для клиента). Образец файла конфигурации OpenVPN можно взять из документации:
Приведем файл конфигурации к следующему виду:
Директива server является макрокомандой и имеет синтаксис:
Она будет преобразована по следующему алгортиму:
Директива route-gateway используется совместно с директивой route и задает шлюз по умолчанию для VPN-сети. Если параметр gateway директивы route не задан — он будет получен из директивы route-gateway .
Директива topology приобретает смысл совместно с dev tun и предусматривает три варианта: net30 , p2p , subnet .
Универсальным решением для VPN-сервера является net30 — это значение по умолчанию. Сервер будет работать со всеми версиями Windows, Linux, Mikrotik. Недостатком топологии является избыточное расходование адресного пространства — четыре ip-адреса на каждого VPN-клиента. Топология net30 фактически «устарела» и сохраняется исключительно для поддержки старых Windows клиентов.
Значение subnet рекомендуется для VPN-сервера, клиентами которого являются Linux и Windows 8.2 и выше. Устройство tun настроено на использование ip-адреса и маски сети как «традиционная» широковещательная сеть. Сетевой и широковещательный ip-адреса не должны использоваться — хотя tun не имеет понятия о широковещании, клиенты Windows не смогут правильно использовать эти адреса. Все остальные ip-адреса в сети доступны для использования.
Значение p2p не может использоваться в системах Windows и не подходит, если сервер или любой клиент может быть Windows. В этой топологии все узлы настроены как настоящие двухточечные ссылки — каждый ip-адрес может использоваться, включая первый и последний. Другими словами, в сети 10.8.0.0/24 в топологии p2p можно использовать все 256 ip-адресов. Но Windows считает первый и последний ip-адреса сетевым и широковещательным адресами.
Директивы persist-key и persist-tun обеспечивают правильную работу после понижения прав, т.е. при использовании nobody и nogroup .
Директива keepalive является макрокомандой и будет преобразована в директивы ping и ping-restart
Кроме того, эта макрокоманда отправит две директивы на клиент (так что в файле конфигурации клиента они не нужны)
Все готово, можно запускать VPN-сервер (подробности здесь):
Здесь config — это имя файла конфигурации в директории server , но без расширения .conf . Чтобы VPN-сервер запускался при загрузке системы:
Смотрим статус запущенной службы:
Смотрим наличие сетевого интерфейса tun0 :
Файл конфигурации клиента
Первым делом нужно установить пакет OpenVPN:
Создаем директорию keys и копируем ключи:
Копируем образец файла конфигурации клиента:
Приведем файл конфигурации к следующему виду:
Все готово, можно запускать VPN-клиент (подробности здесь):
Здесь config — это имя файла конфигурации в директории client , но без расширения .conf . Чтобы VPN-клиент запускался при загрузке системы:
Смотрим статус запущенной службы:
Смотрим наличие сетевого интерфейса tun0 :
Пингуем сервер по адресу 10.8.0.1 :
Дополнительные настройки сервера
1 Если нужно использовать VPN-туннель для маршрутизации всего трафика клиентов, добавляем в файл конфигурации еще три строки.
Теперь клиенты будут использовать туннель VPN в качестве шлюза по умолчанию и DNS-сервера 208.67.222.222 и 208.67.220.220 . В этом случае надо внести изменения и в файл конфигурации клиента. Какие изменения — зависит от того, используется systemd-resolved или нет.
При подключении к серверу сетевые настройки клиента будут изменяться, а при отключении от сервера — настройки будут возвращаться в нормальное состояние, как было до подключения. Скрипт update-resolv-conf доступен сразу после установки пакета openvpn , чтобы получить скрипт update-systemd-resolved — надо установить пакет openvpn-systemd-resolved .
2 По умолчанию сервер OpenVPN использует порт 1194 и протокол UDP — но это всегда можно изменить.
При переключении протокола на TCP, нужно изменить значение директивы explicit-exit-notify с 1 на 0, так как эта директива используется только для UDP. Иначе, при использовании TCP, эта директива вызовет ошибки при запуске службы.
Кроме того, при изменении протокола и порта сервера в файле конфигурации сервера, надо внести изменения в файл конфигурации клиента — указать тот же порт и протокол.
3 По умолчанию клиенты сети VPN могут «общаться» только с сервером OpenVPN. Для того, чтобы клиенты могли взаимодействовать друг с другом через сеть VPN необходимо в конфигурационном файле раскомментировать соответствующую директиву:
4 Сервер динамически выдает клиентам свободные ip-адреса из заданного диапазона. Наличие директивы ifconfig-pool-persist указывает, что перед тем как выдать клиенту свободный адрес из пула, сервер должен свериться с файлом ipp.txt , в котором прописывается привязка Common Name сертификата к ip-адресу.
5 Директива client-config-dir предписывает читать файлы конфигураций клиентов в указанной директории. Имена файлов конфигурации в этой директории совпадают с Common Name сертификатов клиентов. Директивы из каждого файла конфигурации применяются только для конкретного клиента.
6 Директива ccd-exclusive — VPN-клиент, имеющий сертификат с Common Name «sergey-ivanov», может подключиться к VPN-серверу, только если существует файл с именем sergey-ivanov в директории client-config-dir . Этот файл может быть даже пустым — но он должен существовать.
7 Директива duplicate-cn разрешает одновременное подключение нескольких клиентов с одинаковым Common Name. В отсутствие этой директивы сервер отключит экземпляр клиента при подключении нового клиента с таким же Common Name.
Чтобы избежать ошибки Could not determine IPv4/IPv6 protocol. Using AF_INET при запуске VPN-сервера, нужно явно указать версию протокола:
Настройка двух и более OpenVPN-серверов на одном сервере
Продолжая рассказ о возможностях OpenVPN рассмотрим ситуацию, когда нам нужно иметь на одном сервере несколько разных серверов OpenVPN с различными настройками. Чаще всего такая необходимость возникает на серверах, предназначенных для доступа в интернет, когда имеются клиенты, требующие особых настроек. В корпоративной среде такая возможность позволит с помощью одного физического сервера обеспечить связь для различных подразделений, которые не должны напрямую взаимодействовать друг с другом. Как это сделать - читайте в нашей статье.
Начнем с постановки задачи. В прошлой статье мы рассказали о настройке OpenVPN сервера в Oracle Cloud для доступа в интернет. Сервер работает, клиенты подключаются, но возникла необходимость подключения к нему роутеров Mikrotik, у которых, как известно, особые требования к настройкам OpenVPN. Как быть? Перенастроить сервер для совместимости с Mikrotik в ущерб остальным клиентам? Или поднять второй экземпляр сервера со своими настройками? Естественно, второй способ выглядит более предпочтительно.
Напомним, что все настройки мы производим на сервере с Ubuntu 18.04 в облаке от Oracle, настройка которого описана в статье по ссылке выше, рекомендуем ознакомиться с ней перед прочтением данного руководства. Однако все описанные ниже действия, с соответствующими поправками, применимы к любому Linux-дистрибутиву.
Настройка второго экземпляра сервера
Прежде всего создадим для нового сервера собственный набор ключей, для этого перейдем в папку нашего центра сертификации и загрузим переменные:
После чего создадим новый серверный сертификат:
Где server-tcp имя нашего экземпляра сервера. Мы советуем давать осмысленные имена, чтобы вам потом было понятно, что делает тот или иной экземпляр.
Скопируем ключ и сертификат в папку с ключами OpenVPN:
Затем скопируем шаблон конфигурации и назовем его server-tcp.conf:
После чего откроем файл и приступим к его редактированию. Какие важные особенности нам нужно учесть? RouterOS работает с OpenVPN только по протоколу TCP и не использует сжатие, также есть и некоторые иные особенности, которых мы коснемся позже. Все опции указаны в порядке их следования в файле, если опции нет - ее нужно добавить.
Для того, чтобы несколько серверов OpenVPN могли работать на одном хосте они должны использовать разные порты. Но так как первый экземпляр работает по протоколу UDP, то для второго экземпляра мы также можем использовать порт 1194, но только с протоколом TCP.
Укажем топологию сети:
И пути к ключам и сертификатам:
Диапазон адресов внутри VPN-сети также должен отличаться от остальных экземпляров, поэтому укажем:
Для хранения выданных клиентам адресов, как и для логов, также следует использовать отдельные файлы:
Mikrotik игнорирует опцию настройки шлюза по умолчанию, но мы все-таки советуем добавить данную опцию, так как подключаться к данному серверу могут и иные клиенты.
Передадим собственные DNS:
Параметры проверки активности:
Обязательно выключим дополнительную TLS-аутентификацию:
И укажем параметры шифра, выключив его согласование, RouterOS поддерживает только AES128/192/256 и Blowfish 128:
Обязательно отключаем все опции сжатия:
Убеждаемся в наличии опций понижения прав:
И за сохранение доступа к ключам и адаптерам:
Укажем свой комплект файлов лога:
и его подробность:
При использовании протокола TCP обязательно закомментируем опцию:
А также добавим:
Сохраним файл конфигурации.
Чтобы обеспечить автоматический запуск всех серверных конфигураций OpenVPN откроем в /etc/default/openvpn и раскомментируем в нем строку:
Затем перечитаем конфигурацию юнитов systemd:
Теперь уже можно запустить наш новый экземпляр, но мы пока не будем этого делать, так как нужно перенастроить брандмауэр.
Настройка брандмауэра и маршрутизации
Очевидно, что нам нужно разрешить входящий трафик на порт OpenVPN и транзитный трафик для tun-адаптеров, также потребуется отдельное правило для маскарадинга. В итоге ваш файл /etc/nat должен будет выглядеть следующим образом:
На что следует обратить внимание? Для каждого сервера нужно разрешающее правило в цепочке INPUT, в нашем случае в секции Разрешаем подключения к OpenVPN добавлено два правила для входящих UDP 1194 и TCP 1194. Аналогично следует создать для каждой VPN-сети свое правило маскарадинга в секции Включаем маскарадинг для локальной сети.
В правилах цепочки FORWARD мы заменили tun0 на tun+, что теперь распространяет действие правил на все туннельные интерфейсы.
Если вы используете Oracle Cloud, то не забудьте создать разрешающее правило для входящих TCP 1194 в настройках вашей виртуальной сети:
Теперь можно перезапустить службу OpenVPN и убедиться, что поднялись два туннельных интерфейса:
Настройка клиентов OpenVPN
Если вы будете настраивать в качестве клиента Mikrotik, то вам потребуется только ключевая пара клиента и, опционально, сертификат CA, для проверки подлинности сервера. Для создания ключа клиента перейдите в директорию центра сертификации и загрузите переменные:
Затем выпустите сертификат клиента:
Полученные файлы и сертификат CA скопируем в домашнюю директорию:
И сменим их владельца на вашего основного пользователя, чтобы он мог спокойно скопировать их через FTP или SFTP (по умолчанию владелец файлов root). В нашем случае это пользователь ubuntu.
Если же будет подключаться иной клиент, то ему потребуется клиентский файл конфигурации, можете использовать как образец конфигурацию клиента созданную нами в предыдущей статье. В него потребуется внести следующие изменения: изменить протокол на TCP
и выключить сжатие:
Теперь что касается производительности. OpenVPN через TCP имеет гораздо более высокие накладные расходы, особенно на плохих каналах. На хороших разница обычно невелика, и вы скорее упретесь в иные ограничения. Мы выполнили два замера для нашего сервера в Oracle Cloud, первый для UDP:
Второй для TCP:
Как видим, в нашем случае разница абсолютно незаметна и можно не особенно переживать за возможные потери пропускной способности. Но не следует забывать, что при тестировании использовались хорошие широкополосные каналы, в иных ситуациях, например, с мобильными клиентами, результаты могут существенно отличаться.
Здравствуйте, на virtualbox есть два openvpn сервера и клиент( все debian8), которые используют протокол udp. Клиент одновременно подключается к обоим серверам, при подключении ко второму, появляется ошибка:
TCP/UDP: Socket bind failed on local address [undef]: Address already in use
Инглиш немного знаю, "сокет не может забиндится на локальный адрес: адрес уже используется.
netstat -u на клиенте выдает пустоту.
С tcp все ок:
tcp 0 0 client.lan:51801 ovpn2.lan:10883 ESTABLISHED
tcp 0 0 client.lan:49416 ovpn1.lan:10882 ESTABLISHED
Я немного знаю теорию по соектам в контексте именно слушающего сокета:
Cлушающий tcp сокет, при установлении с ним соединения, создает копию себя и уже с копией устанавливается соединение, слушающий udp-сокет просто принимает дейтаграмму без установления соединения, на один сокет, от любого количества клиентов. И я думаю это както связанно с моей ситуацией.
Оценить 4 комментария
Вообще - два туннеля одновременно с клиента - это штатная задача и работает из коробки. Покажите конфиги чтоли?client
dev tun
proto tcp
remote ovpn1 10882
tun-mtu 1500
persist-key
persist-tun
tls-client
ca ca.crt
cert client.crt
key client.key
ns-cert-type server
comp-lzo
verb 3
keepalive 10 60
Тут механика какая, поведение по умолчанию текущей версии openvpn различается для tcp и udp.
Для tcp соединений с клиента openvpn по-умолчанию автоматом выбирает незанятый непривилегированный порт на машине-клиенте и использует его в соединении с сервером, поэтому получается нормально, те как-то так:
Для udp openvpn с вашими конфигами не будет выбирать порт автоматом на клиенте - а попытается повесить процесс на локальный порт 1194. Первый успевший сделать коннект клиент нормально свяжется с сервером и займет 1194. Второй и последующие клиенты с такими конфигами будут пытаться занять 1194 - и получат отлуп - что и наблюдается в ошибке.
Быстрые варианты это обойти - либо прописать в конфиге клиента локальный занимаемый порт статически те добавить по опции в каждый клиентский конфиг:
либо, указать опцию
nobind в каждом конфиге, в этом случае назначение локальных портов openvpn будет делать аналогично tcp автоматом.
Вообще - задача выбора локального незанятого порта автоматом принципиально для tcp и udp не отличается bind() или connect() смотря где - поэтому такое поведение, на мой взгляд - это личное поведение openvpn продиктованное соображениями его сообщества, без какой-то обязательной привязки к теории.
OpenVPN — свободная реализация технологии Виртуальной Частной Сети (VPN) с открытым исходным кодом для создания зашифрованных каналов типа точка-точка или сервер-клиенты между компьютерами. Она позволяет устанавливать соединения между компьютерами, находящимися за NAT-firewall, без необходимости изменения их настроек.
Хотим соединить в одну виртуальную сеть несколько локальных сетей в офисах, географически расположенных в разных местах, посредством Интернета. Хотим иметь доступ в рабочую локальную сеть из дома или в поездке Имея сервер с белым IP есть желание выходить в сеть с этого IP (например если этот IP за пределами страны или сети, в которой блокируются определенные ресурсы в Интернете)Локальная сеть 1
Локальная сеть 2
Все действия проводятся с правами суперпользователя root.Установка
И на сервере и на клиенте ставим один и тот же пакет.
Создание сервера
Создание ключей и сертификатов
Защита соединения в OpenVPN в данном случае строится на использовании сертификатов и ключей для сервера и для клиентов.
Переходим в созданную директорию, где и займёмся генерацией ключей и сертификатов
Редактируем файл переменных
Здесь можно заполнить например так:
копируем конфиг openssl
Очищаем от старых сертификатов и ключей папку keys и создаем серийный и индексные файлы для новых ключей
Создаем сертификат. По умолчанию поля будут заполняться данными, введенными ранее в vars, поэтому можно ничего не менять.
Создаем ключ сервера
В конце соглашаемся с запросом на подпись и добавление сертификата в базу.
Можно сразу создать ключи для клиента, перейдя в соответствующую часть статьи. Я вынес в отдельный раздел, т.к. ключи клиента могут генерироваться не один раз, чтобы было понятнее с чего начать в том случае когда нужно добавить клиентаСоздаем ключ Диффи-Хеллмана
Cоздаем ключ для tls-аутификации
Создание файла конфигурации сервера
Создадим директорию для клиентских конфигов
Можно запускать наш сервер OpenVPN
Смотрим список интерфейсов
Если среди прочих видим
значит VPN-сервер завелся. Если нет, то смотрим лог
Настройка маршрутизации на стороне сервера
Если сервер имеет «белый» IP то никакой маршрутизации на стороне сервера настраивать не нужно. Если сервер находится в локальной сети за NAT роутера то необходимо настроить маршрутизацию.
Для того, чтобы клиенты могли достучаться до сервера нужно пробросить порты с роутера на сервер. В разных моделях это делается по разному. Суть в том, чтобы стучась на внешний порт, например 12345 1) , клиенты попадали на порт OpenVPN-сервера 1194 (или другой, который мы задали для нашего сервера). Кроме того устройствам в локальной сети нужно сообщить, что для доступа к сети за OpenVPN-сервером нужно обращаться к нему. Но проще задать этот маршрут на роутере, который обслуживает локалку.
Создаем файл в каталоге ccd с тем же именем, что и ключ для клиента, т.е. /etc/openvpn/ccd/client
Включаем ipv4_forwarding
Создание клиента
Создание ключей и сертификатов
Переходим в созданную директорию, где и замёмся генерацией ключей и сертификатов
Создаем ключ клиента
В данном случае название ключа - client. Каждый ключ должен быть со своим именем.Если хотим защитить ключ паролем, то генерируем его другой командой
В этом случае при запуске соединения нужно будет каждый раз вводить пароль на ключ.
Теперь нужно не забыть скопировать ключи (ca.crt, client.crt, client.key, ta.key) на клиента OpenVPN в /etc/openvpn/keys/ Если планируется на клиенте импортировать файл настроек .ovpn вместе с сертификатами и ключами, например, для Android, важно в конфигурации клиента исключить строку tls-auth, вместо нее добавить key-direction 1. В противном случае будет ошибка вида tls error: incoming packet authentication failed from [af_inet].Создание файла конфигурации клиента
/etc/openvpn/client.conf
ИЛИ единый файл конфигурации клиента client.ovpn с сертификатами и ключами для импорта
Можно запускать наш клиент OpenVPN
Настройка маршрутизации на стороне клиента
Машина с openvpn уже готова работать с сервером в чём можно убедится
Но для того, чтобы пользоваться туннелем в другой офис могли другие устройства в локальной сети нужно указать им, чтобы доступ в подсеть 192.168.1.0/24 осуществляется через 192.168.0.100. Или, что часто проще и быстрее прописать это правило маршрутизации на роутере, который является шлюзом для устройств в сети.
Включаем ipv4_forwarding
Также как в случае с сервером.
Настройка выхода в интернет с IP сервера
Если ваши цели были - только организовать VPN сеть или соединится с изолированной сетью (например из дома с локальной сетью на работе), то эта часть статьи вам не нужна.Настройки сервера
Если же вы хотите организовать доступ из VPN сети в интернет с IP адреса сервера, то вам нужно настроить на сервере NAT. Сделать это можно следующей командой (на сервере):
Здесь мы указали, что сеть 10.8.0.0/24 будет выходить наружу через интерфейс eth0.
Для того что бы настройки iptables сохранились после перезагрузки нужно их дополнительно сохранить:
Настройки клиента
К конфиге клиента client.conf нужно добавить строчку
Отзыв сертификата
Если все прошло штатно вы должны увидеть следующий вывод, сообщающий о том, что сертификат отозван:
Скрипт revoke-full создаст CRL-файл (certificate revocation list, список отозванных сертификатов) с именем crl.pem в подкаталоге keys. Файл должен быть скопирован в каталог, в котором сервер OpenVPN может получить к нему доступ. Ранее в конфиге мы прописали, что этот файл должен находится в /etc/openvpn, туда и копируем.
Отключение автозапуска OpenVPN
Это бывает полезно, например для клиента с ключем защищенным паролем, т.к. всё равно при старте системы такое соединение не поднимется в виду отсутствия пароля для ключа. Да и в том случае, если вы сделали ключ с паролем, значит, скорее всего, вам не нужно постоянное соединение.Тест производительности OpenVPN
Сеть гигабит (без шифрования последовательная скорость передачи 120 МБ/с). Скорость буду указывать в мегабайтах, НЕ в мегабитах! Скорость всегда упиралась в ВМ, где процессор бы полностью занят. ЦП клиента был загружен не более 10% - 40% на 1/6 ядер. Отключаем сжатие ;comp-lzo - прибавка не более 1 МБ/с - до 15 МБ/с Отключаем аутентификацию auth none +2 МБ/с - до 17 МБ/с Сжатие comp-lzo сжимает хорошо сжимаемые файлы в 2 раза хуже, чем zlib, зато почти не влияет не загрузку ЦП (в десятки раз быстрее). Проверял на копировании установленного в Windows Libreoffice 5. Сжатие в zip с помощью архиватора 7z дало результат около 35%, сжатие comp-lzo по статистике сетевого интерфейса - около 70%.Максимальный прирост при отключении сжатия, шифрования и аутентификации составил около 35%. Не думаю, что это стоит того, чтобы отключать механизмы защиты, но ситуации бывают разные.
Может кому-то как мне будет интересно влияние опций на производительность и не придется тратить время на проведение замеров, хотя я бы с удовольствием ознакомился с результами других людей. Изначально тестил для себя, поэтому точных замеров не проводил, потом решил поделиться результатами.
может совпадать со внутренним, но в целях защиты лучше левый из 5-значной группыЧитайте также: