☰

Ubuntu 20.04 Networkmanager OpenVPN: принимать push-запросы DNS, но не направлять весь трафик на интерфейс tun

tag-icon • tag-icon openvpn networkmanager ubuntu-20.04
Ubuntu 20.04 Networkmanager OpenVPN: принимать push-запросы DNS, но не направлять весь трафик на интерфейс tun

Я пытаюсь подключить несколько клиентов Ubuntu 20.04 на работе к новому серверу OpenVPN, предоставленному нашим новым провайдером серверов.

Цель состоит в том, чтобы направлять в туннель только определенный трафик (соответствующие маршруты передаются сервером OpenVPN) и заставлять клиентов использовать DNS-сервер, также передаваемый сервером OpenVPN.

Это работает с клиентами Windows 10 и OpenVPN GUI 2.5 из коробки. Это также работает с использованием openvpn(2.4.7) из терминала, как здесь: sudo openvpn --config config.ovpnи следующий файл конфигурации клиента config.ovpn:

dev tun
tun-ipv6
persist-tun
persist-key
cipher AES-128-GCM
ncp-ciphers AES-128-GCM
auth SHA256
tls-client
client
resolv-retry infinite
remote <ipadressOfProvider> <port> udp4
verify-x509-name "<name>" name
auth-user-pass
remote-cert-tls server
compress 
# The following is added only in the config for Ubuntu 20.04 
dhcp-option DOMAIN <domainToResolveWithRemoteSiteDNS>
script-security 2
up /etc/openvpn/update-systemd-resolved
up-restart
down /etc/openvpn/update-systemd-resolved
down-pre

Проблемы начинаются при использовании network-manager-openvpn(1.8.12) и вышеуказанного файла конфигурации. Соединение устанавливается и push-сервер DNS обновляется в systemd-resolved (даже без дополнительных upи downскриптов в конфигурации openvpn) правильно.

Однако,всеТрафик направляется в tun0интерфейс, даже публичный трафик. Результатом является то, что яможетдоступ к ресурсам на удаленном сайте даже с использованием внутренних доменных имен, ноне могу получить доступИнтернет, поскольку подсеть OpenVPN не имеет прямого доступа в Интернет.

Изменение опцииИспользуйте это подключение только для ресурсов в своей сети.в конфигурации сетевого менеджера openvpn (которая соответствует опции, ipv4.neverdefaultотображаемой через nmcli c show config) решает проблему маршрутизации: теперь в туннель направляется только трафик, касающийся отправленных маршрутов. Однако это также предотвращает применение отправленного DNS-сервера к /run/systemd/resolve/resolv.conf.

До сих пор я не нашел возможности принять отправленный DNSимаршрутизирует только трафик, который касается переданных маршрутов одновременно с сетевым менеджером.

Вот некоторые, возможно, интересные наблюдения:

1. Маршруты

Network Manager ipv4.neverdefault=noсоздает второй шлюз по умолчанию с более низкой метрикой в ​​дополнение к отправленным маршрутам:

$ ip route
default via 10.*.*.* dev tun0 proto static metric 50 
default via 192.168.***.** dev wlp3s0 proto dhcp metric 600 
10.*.*.*/24 dev tun0 proto kernel scope link src 10.*.*.* metric 50 
158.***.**.** via 192.168.***.** dev wlp3s0 proto static metric 600 
169.254.0.0/16 dev wlp3s0 scope link metric 1000 
172.**.***.*/24 via 10.*.*.* dev tun0 proto static metric 50 
192.168.*.*/24 via 10.*.*.* dev tun0 proto static metric 50 
192.168.*.*/24 via 10.*.*.* dev tun0 proto static metric 50 
192.168.***.*/24 dev wlp3s0 proto kernel scope link src 192.168.***.*** metric 600 
192.168.***.** dev wlp3s0 proto static scope link metric 600

Сетевой менеджер ipv4.neverdefault=yesне создает второй шлюз по умолчанию в дополнение к отправленным маршрутам (то же, что и выше, без первой строки).

openvpnв терминале не создается вторичный шлюз по умолчанию в дополнение к отправленным маршрутам:

default via 192.168.***.** dev wlp3s0 proto dhcp metric 600 
10.*.*.*/24 dev tun0 proto kernel scope link src 10.*.*.* 
169.254.0.0/16 dev wlp3s0 scope link metric 1000 
172.**.***.*/24 via 10.*.*.* dev tun0 
192.168.*.*/24 via 10.*.*.* dev tun0 
192.168.*.*/24 via 10.*.*.* dev tun0 
192.168.***.*/24 dev wlp3s0 proto kernel scope link src 192.168.***.*** metric 600

2. DNS-сервер

Сетевой менеджер с ipv4.neverdefault=noвозможностью перезаписи /run/systemd/resolve/resolv.conf:

nameserver 172.**.***.**

Сетевой менеджер ipv4.neverdefault=yesне выполняет следующие функции:

nameserver 192.168.***.**
nameserver ****:***:****:****::**

openvpnв терминаледобавляетDNS-сервер к существующим и добавляет доменное имя, обслуживаемое удаленным DNS-сервером, как определено в config.ovpn:

nameserver 192.168.***.**
nameserver ****:***:****:****::**
nameserver 172.**.***.***
search <domainToResolveWithRemoteSiteDNS>

Если у вас есть идеи, какие параметры можно изменить в сетевом менеджере, чтобы обрабатывать данные config.ovpnтак же, как это делает терминальный клиент OpenVPN, я буду рад услышать ваши мысли.

Спасибо, Валентин.

решение1

После некоторых дополнительных «исследований» (в основном методом проб и ошибок) мне удалось успешно подключиться к удаленному сайту через сетевой менеджер, при этом маршрутизируя только трафик отправленных маршрутов.ис использованием push-сервера DNS.

  1. Настройка VPN-подключения в сетевом менеджере neverdefault(как уже обсуждалось в OP):

    nmcli c modify <connectionname> ipv4.never-default yes

  2. Настройка подключения dns-searchк внутренним доменам удаленного сайта:

    nmcli c modify <connectionname> ipv4.dns-search <domainname>

Эта опция заставляет NetworkManager каким-то образом снова добавить DNS-сервер run/systemd/resolve/resolv.conf(добавляет, а не перезаписывает), несмотря на то, что ipv4.never-defaultон активен.

В качестве альтернативы <domainname>можно заменить на ~., что приведет к перезаписи run/systemd/resolve/resolv.confи, таким образом, сделает отправленный DNS-сервер единственным, отвечающим на все DNS-запросы.

решение2

Спасибо @Valentin!
Ваше решение просто идеальное!
В моем случае при использовании клиента Ubuntu 20.04, подключающегося к серверу 20.04, а также с использованием параметров openvpn gnome-network-manager, не было необходимости устанавливать dns-search — только параметр never-default.
Чтобы разрешить подключение к папке/сети (samba), мне также пришлось отредактировать параметр "interfaces" в директиве "Networking" файла smb.conf на моем сервере следующим образом

interfaces = 127.0.0.0/8 eth0
interfaces = 127.0.0.0/8 enp2s0
interfaces = X.X.X.X/XX enp2s0

Где последняя строка была добавлена ​​с XXXX/XX, представляющими собой CIDR-нотацию диапазона IP-адресов, который будет назначен тем же сервером OpenVPN.

Связанный контент