Назад | Перейти на главную страницу

Клиент OpenVPN Linux не вызывает интерфейс tap0

У меня есть клиент OpenVPN в Linux, подключающийся к серверу OpenVPN. Сервер назначает IP-адреса через DHCP, поэтому я подключаюсь через нажмите интерфейс, а не тун интерфейс.

OpenVPN подключается, аутентифицируется, общается с сервером и берет чашку кофе, но не запускает интерфейс tap0. После подключения мне нужно вручную запустить ifup tap0 чтобы открыть интерфейс и получить IP.

Я попытался добавить скрипт вверх в файл конфигурации, который запустил 

ip link set tap0 up
dhclient tap0

но он только вызвал устройство, он не получил IP.

очищенный client.conf:

# Openvpn config to connect to <DOMAIN>
tls-client
dev tap0
; dev tap ; this didn't work either

; run script after init (supposedly)
; script-security 2 ; to run up script
; up /etc/openvpn/tap0up.sh ; bring up tap0
; up-delay ; Didn't work with or without this; 

proto udp
remote <DOMAIN> 1194
resolv-retry infinite
nobind
persist-key
persist-tun

ca ca.crt
cert monkey.crt
key monkey.key

ns-cert-type server
comp-lzo
verb 3

И ifcfg-tap0, потому что я отказываюсь верить в NetworkManager

DEVICE=tap0
BOOTPROTO=dhcp
ONBOOT=yes
PEERDNS=no
ZONE=trusted

Заранее спасибо!

Редактировать: Интересный факт: он добавляет правильные статические маршруты в мою таблицу маршрутизации для сети, которую забыл вызвать.

Edit2: Конфигурация OpenVPN Server, по запросу:

local <my.ext.ip>
port 1194
mode server
tls-server
proto udp

dev tap0
; dev tap

ca keys/ca.crt
cert keys/zombie.crt
key keys/zombie.key
dh keys/dh2048.pem

keepalive 10 120
comp-lzo

persist-key
persist-tun

status zombievpn-status.log
verb 3

По моему опыту, заставить устройства TAP хорошо работать в Ubuntu 17.10 и более поздних версиях (и в других ОС, использующих systemd-resolved и / или network-manager), но после долгих экспериментов я пришел к настройке, которая хорошо работает .

Прежде чем я опишу свое решение, вот моя ситуация и требования. Я запускаю сервер OpenVPN на маршрутизаторе (Asus RT-AC87U с прошивкой Asus Merlin) в домашней сети, который также запускает DHCP-сервер. DHCP-сервер настроен на выдачу IP-адресов для интерфейса TAP, а также продвигает поисковый домен DNS. Это позволяет обнаруживать подключенные системы по имени хоста (так, например, система с именем хоста "рабочий стол" может быть обнаружена как "рабочий стол", которая расширяется до "desktop.mydomain.com" из-за поискового домена "mydomain.com"). Я использую TAP-сеть, чтобы я мог использовать wake-on-lan прямо через туннель (волшебные пакеты wake-on-lan должны транслироваться по адресу xxx255 на MAC-адрес сетевого адаптера, который должен разбудить систему , то, что TUN-устройство не может сделать, потому что оно работает на неправильном сетевом уровне, чтобы разрешить широковещательную передачу пакетов уровня 2). Сервер должен иметь возможность передавать клиенту параметры DNS. Я НЕ хочу, чтобы весь интернет-трафик проходил через туннель - это не такая VPN (я запускаю отдельный TUN-сервер на другом порту для этого варианта использования, но это выходит за рамки данного ответа). Наконец, когда я закрываю туннель, мне нужно, чтобы все вернулось в исходное состояние (что не происходит автоматически).

Оказывается, сложно было провести все эксперименты. В конце концов, решение совсем не сложно настроить. Я установил OpenVPN из репозиториев Ubuntu, на момент написания была версия 2.4.4.

Сервер OpenVPN использует следующую конфигурацию (сервер запускает DNSMasq по адресу 10.75.233.1 (также IP шлюза), который функционирует как DHCP-сервер):

# Automatically generated configuration
daemon ovpn-server1
server-bridge   # proxy the DHCP server
push "route 0.0.0.0 255.255.255.255 net_gateway"
proto udp
port 1194
dev tap21
ncp-ciphers AES-256-GCM
auth SHA384
comp-lzo adaptive
keepalive 15 60
verb 2
push "dhcp-option DNS 10.75.233.1"   # Pushes the DNS server
tls-crypt static.key
ca ca.crt
dh dh.pem
cert server.crt
key server.key
crl-verify crl.pem
status-version 2
status status 5

# Custom Configuration
mssfix 1420  # You might not need this, it depends on your local network conditions
tun-mtu 1500  # You might not need this, it depends on your local network conditions
tls-version-min 1.2
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384

Все это не так уж и интересно. Это конфигурация клиента:

client
dev tap0
persist-tun
persist-key
proto udp
remote mydomain.com 1194
float
ncp-ciphers AES-256-GCM
auth sha384
comp-lzo adaptive
remote-cert-tls server
auth-nocache
tls-version-min 1.2
verb 2

ca /etc/openvpn/secrets/mydomain/ca.crt
cert /etc/openvpn/secrets/mydomain/client.crt
key /etc/openvpn/secrets/mydomain/client.key
tls-crypt /etc/openvpn/secrets/mydomain/ta.key

resolv-retry infinite
nobind

Что тоже не так уж и интересно, кроме одного - скриптов вверх / вниз нет (здесь гифка).

Причина этого в том, что я считаю наиболее элегантным позволить существующим службам операционной системы обрабатывать как можно больше - другими словами, двигаться в соответствии с зерном ОС, а не против нее. По умолчанию устанавливаемые скрипты вверх / вниз предназначены для управления /etc/resolv.conf, который Ubuntu 18.04 больше не использует (напрямую). Он использует systemd-resolved. Прямое изменение файла resolv.conf вызовет много слез, юные джедаи. Однако это не привело к тому, что разработчики Ubuntu также по умолчанию устанавливали скрипты повышения / понижения для systemd-resolved. Это оставлено на ваше усмотрение (sudo apt install openvpn-systemd-resolved - скрипты будут расположены в /etc/openvpn). Они отлично работают с TUN-устройствами, но, по моему опыту, не справляются и с TAP-устройствами.

Что действительно работает очень хорошо, так это явное добавление устройства tap0 к вашим сетевым интерфейсам (/etc/network/interfaces):

# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback

allow-hotplug tap0
iface tap0 inet dhcp

Перезагрузите сетевой стек, используя:

sudo systemctl daemon-reload
sudo systemctl restart networking

БУМ! ОС теперь сама запросит DHCP-сервер и вызовет адаптер, как обычный интерфейс. Когда вы подключаетесь к своему серверу, ifconfig tap0 должен показать вам адаптер с назначенным IP-адресом. Также, systemd-resolve --status должен показать вам в самых первых строках вывода, что домен поиска DNS и DNS-сервер, выдвинутый сервером OpenVPN, заданы как глобальная конфигурация, а быстрый nslookup desktop теперь должен работать (при условии, что хост существует где-то по другую сторону туннеля).

Однако это вызывает некоторые проблемы, когда вы обрушиваете туннель. Он выходит из строя, и устройство tap0 больше не отображается в выводе ifconfig. Тем не мение, systemd-resolve --status покажет вам, что ваш поисковый домен и DNS-сервер в значительной степени продолжают быть частью вашего существования. В моем случае, поскольку домен, на котором я запускаю свой VPN-сервер, - это «mydomain.com», а поисковый домен - также «mydomain.com», это привело к тому, что я не смог снова подключиться к VPN-серверу после того, как туннель отключился. , потому что его фактический IP-адрес больше не может быть разрешен, пока systemd-resolved остается сбитым с толку из-за надоедливого домена поиска. Перезапуск службы systemd-resolved проблему не решает, а вот перезагрузка решает. О смертельная агония!

К счастью, для этого тоже есть решение. Оказывается, что-то вроде временного файла конфигурации создается по адресу /run/systemd/resolved.conf.d/isc-dhcp-v4-tap0.conf что вызывает Systemd-решимости упорно остаются привязаны к DNS серверу моего VPN-сервера. Удаление файла с последующим перезапуском службы устраняет проблему (sudo rm /run/systemd/resolved.conf.d/isc-dhcp-v4-tap0.conf && sudo systemctl restart systemd-resolved.service).

Итак, для простой установки это подойдет. Однако мне нравится моя роскошь, и мы можем воспользоваться прекрасным сервисом systemd, чтобы предоставить ее нам! Обратите внимание, что с пакетом OpenVPN Ubuntu служба systemd с «подстановочными знаками» доступна для всех конфигураций OpenVPN в /etc/openvpn/client. Вы можете взглянуть на файл модуля, который должен находиться по адресу /lib/systemd/system/openvpn-client@.service. Его можно контролировать с помощью sudo systemctl start openvpn-client@my-config-name-without-.conf. Он отлично работает для туннелей в стиле TUN, так что оставьте его в покое. Мы продублируем его для работы на TAP-устройствах.

Создайте файл /lib/systemd/system/openvpn-my-tap-service-name.service и добавить:

[Unit]
Description=OpenVPN tunnel for mydomain.com
After=syslog.target network-online.target
Wants=network-online.target
Documentation=man:openvpn(8)
Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO

[Service]
Type=notify
PrivateTmp=true
WorkingDirectory=/etc/openvpn/client
ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config mydomain.com.conf
ExecStopPost=/etc/openvpn/post-tap0-service-stop.sh  # Removes search domain and DNS server from systemd-resolved config
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE
LimitNPROC=10
DeviceAllow=/dev/null rw
DeviceAllow=/dev/net/tun rw
ProtectSystem=true
ProtectHome=true
KillMode=process

[Install]
WantedBy=multi-user.target

Это простая адаптация службы по умолчанию. Чтобы он работал, конфигурация вашего клиента должна быть расположена по адресу /etc/openvpn/client/mydomain.com.conf. Добавлено только одно - небольшой скрипт для удаления "временного" конфигурационного файла, разрешенного systemd.

Создайте файл /etc/openvpn/post-tap0-service-stop.sh и установите его исполняемый файл (с помощью chmod +x /etc/openvpn/post-tap0-service-stop.sh):

#!/bin/bash

FILE_MESSING_WITH_SYSTEMD_RESOLVED=/run/systemd/resolved.conf.d/isc-dhcp-v4-tap0.conf

echo "Removing $FILE_MESSING_WITH_SYSTEMD_RESOLVED..."
rm -f $FILE_MESSING_WITH_SYSTEMD_RESOLVED 

echo "Restarting systemd-resolved service..."
systemctl restart systemd-resolved.service

Тадаа! Теперь вы можете управлять OpenVPN с помощью sudo systemctl start/stop/restart/status openvpn-my-tap-service-name (после быстрого sudo systemctl daemon-reload после того, как вы создали служебный файл, конечно).

Остался только один последний штрих. Больно постоянно контролировать службу с помощью пароля. Мы можем исправить это, добавив команды, необходимые для управления службой, в файл sudoers.

Выполните следующую команду pkexec visudo -f /etc/sudoers.d/openvpn и введите следующее:

Cmnd_Alias OPENVPN = /bin/systemctl start openvpn-my-tap-service-name, \
                     /bin/systemctl stop openvpn-my-tap-service-name, \
                     /bin/systemctl restart openvpn-my-tap-service-name

%my-username ALL= NOPASSWD: OPENVPN

Теперь вы можете выполнить sudo systemctl команды для вашего сервиса без пароля.

Надеюсь, это поможет!

Я тоже столкнулся с этой странной ситуацией. Openvpn работал нормально, пока я не внес следующие три изменения в неудачную попытку отключить сервер openvpn dhcp и использовать свой собственный (режим моста / подключения). Возможно, в вашем случае вам может потребоваться применить противоположные изменения к вашей конфигурации (добавить директиву сервера, удалить tls-server и server x y).

  1. В конфигурации сервера я закомментировал server X Y директива
  2. В конфигурации сервера я добавил tls-server и mode server и закомментировал параметр пула IP, все в ответ на сообщения о фатальных ошибках, полученных при запуске openvpn без server x y