Клиент OpenVPN Linux не поднимает интерфейс tap0

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

1. В конфигурации сервера я закомментировал директиву server XY
2. В конфигурации сервера я добавил tls-server и сервер режима и закомментировал параметр пула IP, все в ответ на сообщения о фатальной ошибке, полученные при запуске openvpn без server xy

По моему опыту, заставить устройства 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 server):

# 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

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

Это, однако, вызывает некоторые проблемы при отключении туннеля. Все идет нормально,и устройство 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 (скрыто). Он отлично работает для туннелей в стиле TUN, так что оставьте его в покое. Мы продублируем его для работы с TAP-устройствами.

[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

#!/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

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