Dns fallback openvpn что это

OpenVPN Support Forum

I create a VPN server with openVPN, and I can connect with my Android.
So All works.

But I have a problem.
The DNS Fallback is enable.
And I don’t want to forward my traffic on the DNS on Google.
But When I disable this option, the VPN tunnel doesn’t work.
I can connect but I have access to Internet .
How can I make to use the VPN with my DNS ?

Config on my Android:

client dev tap proto udp remote 80.134.226.156 56789 resolv-retry infinite nobind # Try to preserve some state across restarts. persist-key persist-tun ca ca.crt cert Server.crt key Server.key remote-cert-tls server tls-auth ta.key 1 cipher BF-CBC comp-lzo verb 3 route-method exe route-delay 2 

laclac OpenVpn Newbie Posts: 7 Joined: Thu Feb 19, 2015 5:04 pm

Re: Use VPN without the DNS Fallback option

Post by laclac » Sun May 17, 2015 3:59 am

For information I found the problem.
The tethering system service (DHCP and DNS) was blocking on my Android.
I unlocked and now, OpenVPN client works without the fallback.

2 posts • Page 1 of 1

• Announcements
• Forum & Website Support
• Community Project
• ↳ Server Administration
• ↳ Configuration
• ↳ Examples
• ↳ Routed Example
• ↳ Installation Help
• ↳ Tutorials
• ↳ Testing branch
• ↳ Scripting and Customizations
• ↳ Authentication Scripts
• ↳ Routing and Firewall Scripts
• ↳ Rolling Your Own Installer
• ↳ Wishlist
• ↳ Cert / Config management
• ↳ Easy-RSA
• OpenVPN Inc. enterprise business solutions
• ↳ The OpenVPN Access Server
• ↳ CloudConnexa (previously OpenVPN Cloud)
• ↳ OpenVPN Connect (Windows)
• ↳ OpenVPN Connect (macOS)
• ↳ OpenVPN Connect (Android)
• ↳ OpenVPN Connect (iOS)
• Off Topic, Related
• Braggin’ Rights
• ↳ My VPN
• ↳ Doh!
• Pay OpenVPN Service Provider Reviews/Comments

• HomeBoard index
• All times are UTC
• Delete cookies

systemd-resolved не работает с OpenVPN

Устав от постоянных глюков и костылей решил сделать чтобы OpenVPN резолвил имена через systemd-resolved, по итогу получил не работающий клиент.

Порядок действий был следующий:

2. На стороне OpenVPN в своем конфиге прописал:

push "dhcp-option DNS 10.90.0.1" push "dhcp-option DOMAIN corp.domain.net" 

3. После старта клиента вижу следующее:

$ resolvectl status [. ] Link 31 (tun0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: allow-downgrade DNSSEC supported: no Current DNS Server: 10.90.0.1 DNS Servers: 10.90.0.1 DNS Domain: corp.domain.net [. ] Link 2 (enp42s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: allow-downgrade DNSSEC supported: no Current DNS Server: 192.168.35.1 DNS Servers: 192.168.35.1 

После этого не резолвится имя server.corp.domain.net. Сами сервера в VPN пингуются, все остальное резолвится также норм.

Где может быть проблема?

alex07 ★
31.05.19 23:20:44 MSK

Покажи /etc/resolv.conf и /etc/nsswitch.conf .

Алсо, правильный тег — «systemd». На тег «systemd-resolved» подписано ровно 0 человек.

intelfx ★★★★★
( 01.06.19 00:20:41 MSK )
Последнее исправление: intelfx 01.06.19 00:21:32 MSK (всего исправлений: 1)

Это давнишняя дыра, Поттеринг извивается как уж и говорит что всё нормально работает и мол not a bug.

Так-то надо в openvpn’ский скрипт up запихать невменяшку типа

busctl call org.freedesktop.resolve1 /org/freedesktop/resolve1 org.freedesktop.resolve1.Manager SetLinkDNS 'ia(iay)' 2 0.0.0.0 

Оно удалит DNS со второго интерфейса. Можно сохранить что было, а потом при openvpn down скормить то же самое только вместо 0.0.0.0 IP сохранённого старого DNS

Пляски с /etc/resolv.conf мало помогают, тем более что непонятно, когда и как оно его перечитывает, да и systemd лазает в /etc/resolvconf/resolv.conf.d/ где может быть куча дополнительного барахла, а реально пользуется /run/resolvconf/resolv.conf который вроде как создаётся из кучи разных мест, в том числе и из вышеупомянутых.

Stanson ★★★★★
( 01.06.19 00:40:16 MSK )
Последнее исправление: Stanson 01.06.19 00:46:38 MSK (всего исправлений: 1)

Ответ на: комментарий от intelfx 01.06.19 00:20:41 MSK

Ещё возможно, DNSSEC «мешает», если на основном domain.net он включен, а на corp.domain.net — выключен.

intelfx ★★★★★
( 01.06.19 00:47:25 MSK )
Ответ на: комментарий от intelfx 01.06.19 00:20:41 MSK

Вот это я сделал потому что в мануале было написано:

$ ls -la /etc | grep resolv lrwxrwxrwx 1 root root 37 May 31 21:20 resolv.conf -> /run/systemd/resolve/stub-resolv.conf 

$ cat /etc/resolv.conf # This file is managed by man:systemd-resolved(8). Do not edit. # # This is a dynamic resolv.conf file for connecting local clients to the # internal DNS stub resolver of systemd-resolved. This file lists all # configured search domains. # # Run "resolvectl status" to see details about the uplink DNS servers # currently in use. # # Third party programs must not access this file directly, but only through the # symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way, # replace this symlink by a static file or a different symlink. # # See man:systemd-resolved.service(8) for details about the supported modes of # operation for /etc/resolv.conf. nameserver 127.0.0.53 options edns0 

$ cat /etc/nsswitch.conf # Name Service Switch configuration file. # See nsswitch.conf(5) for details. passwd: files mymachines systemd group: files mymachines systemd shadow: files publickey: files hosts: files mymachines myhostname resolve [!UNAVAIL=return] dns networks: files protocols: files services: files ethers: files rpc: files netgroup: files 

Ещё возможно, DNSSEC «мешает», если на основном domain.net он включен, а на corp.domain.net — выключен.

Насколько я знаю оно у меня нигде не используется.

alex07 ★
( 01.06.19 02:18:05 MSK ) автор топика
Ответ на: комментарий от Stanson 01.06.19 00:40:16 MSK

Оно удалит DNS со второго интерфейса.

Я вот не совсем понимаю как они DNS вешают на интерфейс? Ведь это же просто IP на который надо отправить запрос: разве интерфейс не от раутинга на этот IP зависит в данном случае?

alex07 ★
( 01.06.19 02:19:18 MSK ) автор топика
Ответ на: комментарий от alex07 01.06.19 02:18:05 MSK

Вот это я сделал потому что в мануале было написано

Да, всё правильно. Должно работать, у меня работает.

Насколько я знаю оно у меня нигде не используется.

Попробуй глобально отключить (resolved.conf).

intelfx ★★★★★
( 01.06.19 02:19:49 MSK )
Последнее исправление: intelfx 01.06.19 02:21:08 MSK (всего исправлений: 2)

Ответ на: комментарий от intelfx 01.06.19 02:19:49 MSK

Попробуй глобально отключить (resolved.conf).

Link 19 (tun0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Current DNS Server: 10.90.0.1 DNS Servers: 10.90.0.1 DNS Domain: corp.domain.net 

Сделал, все равно не работает.

alex07 ★
( 01.06.19 02:26:41 MSK ) автор топика
Ответ на: комментарий от alex07 01.06.19 02:26:41 MSK

Странно. Не воспроизвёл.

Сам внутренний DNS-сервер (10.90.0.1) отвечает правильно, если его напрямую nslookup’ом попросить? systemd-resolve server.corp.domain.net что-нибудь говорит? Логи самого resolved?

Напиши дистрибутив и версию, попробую поднять в контейнере и поковырять.

intelfx ★★★★★
( 01.06.19 03:07:04 MSK )
Последнее исправление: intelfx 01.06.19 03:07:47 MSK (всего исправлений: 3)

Ответ на: комментарий от alex07 01.06.19 02:19:18 MSK

Я вот не совсем понимаю как они DNS вешают на интерфейс? Ведь это же просто IP на который надо отправить запрос: разве интерфейс не от раутинга на этот IP зависит в данном случае?

Разумеется, пока ещё, DNS никак не вешается, да и не связан вообще с интерфейсом. Просто почему-то создатель systemd считает, что у каждого интерфейса должна быть настройка DNS и это со всеми этими танцами вокруг всенепременного fallback DNS, приездом DNS при DHCP ACK и прочая вылилось в тонну завязанных в узел костылей, которые хрен поймёшь как работают. Если у тебя много интерфейсов и на каждый из них каким-либо образом приезжает информация о DNS, то проще отстранить systemd от руления сетью, чем заставить это работать так, как тебе нужно.

Stanson ★★★★★
( 01.06.19 03:32:40 MSK )
Ответ на: комментарий от alex07 01.06.19 02:19:18 MSK

Я вот не совсем понимаю как они DNS вешают на интерфейс?

Очень просто: для этого запроса будут учитываться только те маршруты, которые уходят с этого интерфейса. Полезно, когда у тебя несколько default маршрутов.

intelfx ★★★★★
( 01.06.19 03:37:03 MSK )
Последнее исправление: intelfx 01.06.19 03:37:27 MSK (всего исправлений: 1)

Ответ на: комментарий от intelfx 01.06.19 03:37:03 MSK

Э-э-э. Кагбе, чтобы понять какой маршрут будет, надо сначала узнать IP. Чтобы узнать IP надо сначала отправить запрос на DNS. Т.е. до отправки запроса DNS совершенно неизвестно какой будет маршрут. Поэтому как-то привязывать DNS к интерфейсам совершенно бессмысленно и вредно. Получить адреса DNS при поднятии интерфейсов — это нормально. Но как-то в процессе решать за юзера, каким из полученных DNS пользоваться, и тем более выдумывать какие-то fallback DNS — это совершенно никуда не годится.

Stanson ★★★★★
( 01.06.19 03:50:17 MSK )
Последнее исправление: Stanson 01.06.19 03:51:43 MSK (всего исправлений: 2)

Ответ на: комментарий от Stanson 01.06.19 03:50:17 MSK

Кагбе, чтобы понять какой маршрут будет, надо сначала узнать IP

Маршрут до DNS-сервера, а не до ответа.

intelfx ★★★★★
( 01.06.19 04:14:47 MSK )
Ответ на: комментарий от intelfx 01.06.19 04:14:47 MSK

Маршрут до DNS-сервера, а не до ответа.

До какого из них? Есть 10 DNS на 10 интерфейсах. Как systemd-resolved решает каким из них пользоваться и с какого перепугу он вообще это делает?

Stanson ★★★★★
( 01.06.19 06:44:23 MSK )
Ответ на: комментарий от intelfx 01.06.19 03:07:04 MSK

Сам внутренний DNS-сервер (10.90.0.1) отвечает правильно

Да, разумеется. Это рабочая система VPN.

если его напрямую nslookup’ом попросить?

$ systemd-resolve server.corp.domain.net server.corp.domain.net: resolve call failed: Invalid argument 

Кстати говоря, когда поднимаю OpenVPN вижу вот такие строки:

UN/TAP device tun0 opened TUN/TAP TX queue length set to 100 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 /usr/bin/ip link set dev tun0 up mtu 1500 /usr/bin/ip addr add dev tun0 10.90.0.2/16 broadcast 10.90.255.255 /etc/openvpn/scripts/update-systemd-resolved tun0 1500 1555 10.90.0.2 255.255.0.0 init Jun 1 09:41:57 update-systemd-resolved: Link 'tun0' coming up Jun 1 09:41:57 update-systemd-resolved: Adding IPv4 DNS Server 10.90.0.1 Jun 1 09:41:57 update-systemd-resolved: Adding DNS Domain corp.overlap.net Jun 1 09:41:57 update-systemd-resolved: SetLinkDNS(20 1 2 4 10 90 0 1) Jun 1 09:41:57 update-systemd-resolved: SetLinkDomains(20 1 corp.domain.net false) /usr/bin/ip route add 172.16.1.0/24 metric 1 via 10.90.0.1 

Из интересного только это:

$ sudo journalctl -u systemd-resolved Jun 01 09:41:57 crow systemd-resolved[8615]: Flushed all caches. Jun 01 09:42:18 crow systemd-resolved[8615]: Failed to send hostname reply: Invalid argument 

Но это похоже вывод когда nslookup делаю.

Напиши дистрибутив и версию, попробую поднять в контейнере и поковырять.

$ sudo uname -a Linux crow 5.0.13-arch1-1-ARCH #1 SMP PREEMPT Sun May 5 18:05:41 UTC 2019 x86_64 GNU/Linux $ sudo systemctl --version systemd 242 (242.19-1-arch) +PAM +AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid 

alex07 ★
( 01.06.19 10:47:54 MSK ) автор топика
Ответ на: комментарий от Stanson 01.06.19 06:44:23 MSK

Есть 10 DNS на 10 интерфейсах. Как systemd-resolved решает каким из них пользоваться

и с какого перепугу он вообще это делает?

Потому что такая семантика адекватнее, чем историческая «рандомно выберем один сервер из resolv.conf».

intelfx ★★★★★
( 01.06.19 10:51:23 MSK )
Ответ на: комментарий от alex07 01.06.19 10:47:54 MSK

resolve call failed: Invalid argument

Failed to send hostname reply: Invalid argument

А вот это уже интересно.

intelfx ★★★★★
( 01.06.19 10:53:08 MSK )
Последнее исправление: intelfx 01.06.19 10:53:26 MSK (всего исправлений: 1)

Ответ на: комментарий от intelfx 01.06.19 10:53:08 MSK

Ну вот да, я подтверждаю что это появляется когда я делаю nslookup.

С другой стороны есть еще более интересная деталь, а именно:

Jun 01 10:08:56 crow systemd-resolved[8615]: Using degraded feature set (TCP) for DNS server 10.90.0.1. Jun 01 10:08:56 crow systemd-resolved[8615]: Using degraded feature set (UDP) for DNS server 10.90.0.1. Jun 01 10:08:56 crow systemd-resolved[8615]: Failed to send hostname reply: Invalid argument 

То есть все таки 10.90.0.1 таки используется.

alex07 ★
( 01.06.19 11:11:34 MSK ) автор топика
Ответ на: комментарий от Stanson 01.06.19 03:32:40 MSK

Разумеется, пока ещё, DNS никак не вешается, да и не связан вообще с интерфейсом. Просто почему-то создатель systemd считает, что у каждого интерфейса должна быть настройка DNS

Ты спрашиваешь «зачем вообще нужно сопоставлять DNS-серверы интерфейсам». Ответ: потому что DNS-серверы прилетают с автонастройки какого-то конкретного интерфейса. Исторически, на каждом запросе из всех известных системе DNS-серверов выбирается один, а на остальные кладётся хер. Это банально неудобно. systemd-resolved раскладывает DNS-серверы по группам, которые называются «интерфейсами». Внутри «интерфейса» DNS-сервер выбирается по кругу, и запрос отправляется со всех «интерфейсов» одновременно.

Если у тебя много интерфейсов и на каждый из них каким-либо образом приезжает информация о DNS, то проще отстранить systemd от руления сетью, чем заставить это работать так, как тебе нужно.

Ну вот получается, что строго наоборот.

Я тебе приведу пример, почему это может быть удобно: например, я подключен к нескольким провайдерам, foo и bar. Каждый провайдер предоставляет доступ к одному и тому же Интернету + своему собственному интранету (foonet и barnet). Делается это через свои собственные DNS-сервера (основной и резервный), которые умеют отвечать соответственно на запросы foonet.foo.ru и barnet.bar.ru. Теперь я пытаюсь зайти на foonet.foo.ru. Классический линуксовый DNS-ресолвер выберет из четырёх серверов один, отправит запрос на него и с вероятностью 50% я получу хер, потому что запрос о foonet.foo.ru уйдёт в сервер провайдера bar.

systemd-resolved решает эту проблему автоматически, т. к. он разделяет эти 4 DNS-сервера на две группы и отправит запрос одновременно в обе, а вернёт тот ответ, который завершился успешно.

Понимаешь? systemd-resolved — это автоматический инструмент, который автоматически решает стандартную пользовательскую проблему. Если у тебя сложный сетап

Теперь ты приведи пример, почему такое поведение якобы плохо и неправильно.

intelfx ★★★★★
( 01.06.19 11:13:06 MSK )
Ответ на: комментарий от alex07 01.06.19 11:11:34 MSK

Получается, что логика выбора DNS-сервера работает правильно, а ломается уже на этапе отправки запроса/получения ответа. Я не смог воспроизвести это на своём арчике. Могу предложить разве что запустить resolved с SYSTEMD_LOG_LEVEL=debug:

mkdir -p /etc/systemd/system/systemd-resolved.service.d echo -e '[Service]\nEnvironment=SYSTEMD_LOG_LEVEL=debug' >> /etc/systemd/system/systemd-resolved.service.d/override.conf systemctl daemon-reload systemctl restart systemd-resolved 

Потом сделать это ещё раз и посмотреть в логи. Но я смотрю в код и что-то там очень мало отладочной распечатки вокруг этой функции. Возможно, придётся зарепортить баг в апстрим.

intelfx ★★★★★
( 01.06.19 11:19:18 MSK )
Последнее исправление: intelfx 01.06.19 11:19:36 MSK (всего исправлений: 1)

Ответ на: комментарий от intelfx 01.06.19 11:13:06 MSK

и отправит запрос одновременно в обе, а вернёт тот ответ, который завершился успешно.

Интересное решение. Но что же делать если ответили обе группы, но при этом разными ответами?

Ну то есть опять же, банальный пример, VPN через другую страну. Запрос о google.com вернет два разных IP.

alex07 ★
( 01.06.19 11:19:54 MSK ) автор топика
Ответ на: комментарий от alex07 01.06.19 11:19:54 MSK

Но что же делать если ответили обе группы, но при этом разными ответами?

VPN через другую страну. Запрос о google.com вернет два разных IP.

Этот юзкейс и эта проблема описывается в «DNS Leakage» в мануале того плагина, на который ты сослался. В таких случаях нужно форсировать отправку запросов только через VPN.

intelfx ★★★★★
( 01.06.19 11:23:28 MSK )
Последнее исправление: intelfx 01.06.19 11:23:45 MSK (всего исправлений: 1)

Ответ на: комментарий от intelfx 01.06.19 11:19:18 MSK

Могу предложить разве что запустить resolved с SYSTEMD_LOG_LEVEL=debug

Да не вопрос. Сейчас сделаю.

А пока что такой вопрос: пинг на хост 10.90.0.1 проходит. Есть ли какая то утилита чтобы конкретно на этот хоть отправить DNS запрос и посмотреть способен ли он ответить? Спрашиваю, потому что не силен в nslookup и не уверен что он именно на этот хост запрос отправляет.

Может там реально udp по какой то причине блочится, а я тут на systemd гоню.

alex07 ★
( 01.06.19 11:23:46 MSK ) автор топика
Ответ на: комментарий от alex07 01.06.19 11:23:46 MSK

Есть ли какая то утилита чтобы конкретно на этот хоть отправить DNS запрос и посмотреть способен ли он ответить?

nslookup server.corp.domain.net 10.90.0.1

intelfx ★★★★★
( 01.06.19 11:24:12 MSK )
Последнее исправление: intelfx 01.06.19 11:24:59 MSK (всего исправлений: 1)

Ответ на: комментарий от intelfx 01.06.19 11:23:28 MSK

В таких случаях нужно форсировать отправку запросов только через VPN.

Да, действительно. Так и есть.

alex07 ★
( 01.06.19 11:24:33 MSK ) автор топика
Ответ на: комментарий от intelfx 01.06.19 11:24:12 MSK

$ nslookup server.corp.domain.net 10.90.0.1 ;; connection timed out; no servers could be reached 

По ходу я что то перемудрил с конфигурацией. Если сделать nslookup на «реальный» адрес сервера, а именно 172.16.1.2, то ответ приходит.

$ nslookup io.corp.domain.net 172.16.1.2 Server: 172.16.1.2 Address: 172.16.1.2#53 Name: io.corp.domain.net Address: 172.16.1.101 

Теперь вопрос, почему наш админ решил что IP DNS сервера должно быть в ранге адресов отдаваемых OpenVPN (10.90.xxx.yyy).

Поменяв конфиг в моем ccd файле на 172.16.1.2 DNS отлично работает.

Надо бы отметить что тема решена.

alex07 ★
( 01.06.19 11:26:00 MSK ) автор топика
Последнее исправление: alex07 01.06.19 11:33:39 MSK (всего исправлений: 2)

Ответ на: комментарий от intelfx 01.06.19 10:51:23 MSK

Потому что такая семантика адекватнее, чем историческая «рандомно выберем один сервер из resolv.conf».

Не надо придумывать какие-то левые семантики которых никогда не было. Семантика была — «рандомно выбираем один сервер из помещённых с дозволения пользователя в resolv.conf и никакой другой».

А вот то, чем занимается systemd — как раз совершенно неадекватно.

Stanson ★★★★★
( 01.06.19 11:48:34 MSK )
Ответ на: комментарий от alex07 01.06.19 11:26:00 MSK

Поменяв конфиг в моем ccd файле на 172.16.1.2 DNS отлично работает.

Через resolved тоже?

intelfx ★★★★★
( 01.06.19 11:48:41 MSK )
Последнее исправление: intelfx 01.06.19 11:56:11 MSK (всего исправлений: 1)

Ответ на: комментарий от Stanson 01.06.19 11:48:34 MSK

Не надо придумывать какие-то левые семантики которых никогда не было

С чего бы это? Конечно, надо.

Семантика была — «рандомно выбираем один сервер из помещённых с дозволения пользователя в resolv.conf и никакой другой».

Это бестолковая семантика. Она не решает реальные пользовательские задачи. А systemd-resolved решает. Я достаточно подробно описал, как именно.

А вот то, чем занимается systemd — как раз совершенно неадекватно.

Разумное обоснование будет или как всегда?

intelfx ★★★★★
( 01.06.19 11:53:53 MSK )
Ответ на: комментарий от intelfx 01.06.19 11:13:06 MSK

Теперь ты приведи пример, почему такое поведение якобы плохо и неправильно.

Тебе уже привели примеры. Какие-то DNS могут выдавать правильные, годные ответы, а какие-то находятся, например, в РФ. А Поттерингу с его systemd-resolved на это совершенно насрать, и его поделка выдаст пользователю первый пришедший адрес, который, очевидно будет вовсе не от годного DNS, а от того, который тупо физически ближе, т.е. в РФ.

И да — это нынче, стараниями законотворцев в РФ и не только, совершенно стандартная пользовательская проблема.

Stanson ★★★★★
( 01.06.19 12:02:21 MSK )
Ответ на: комментарий от intelfx 01.06.19 11:53:53 MSK

Она не решает реальные пользовательские задачи.

Ты в курсе что пользовательская задача — это чтобы компьютер делал только то, что приказал пользователь, а не то, что придумал Поттеринг.

Лучше бы он вообще ничего не делал, чем решать так как он «решает».

Stanson ★★★★★
( 01.06.19 12:04:36 MSK )
Ответ на: комментарий от Stanson 01.06.19 12:02:21 MSK

в твоем случае рандомного выбора — будет тоже самое. Не надо всякий шлак писать в резолф.конф

anonymous
( 01.06.19 12:06:36 MSK )
Ответ на: комментарий от intelfx 01.06.19 11:13:06 MSK

Классический линуксовый DNS-ресолвер выберет из четырёх серверов один, отправит запрос на него и с вероятностью 50% я получу хер, потому что запрос о foonet.foo.ru уйдёт в сервер провайдера bar.

а какой-нибудь кеширующий днс-сервер тут разве не поможет?

Установка и настройка OpenVPN сервера под Windows

30.12.2021

itpro

Windows 10, Windows 11, Windows Server 2019

комментариев 108

OpenVPN – это набор open source программ, который заслуженно является одним из самых популярных и легких решений для реализации защищенной VPN сети. OpenVPN позволяет объединить в единую сеть сервер и клиентов (даже находящиеся за NAT или файерволами), или объединить сети удаленных офисов. Серверную часть OpenVPN можно развернуть практически на всех доступных операционных системах (пример настройки OpenVPN на Linux). Вы можете установить OpenVPN сервер даже на обычный компьютер с десктопной редакцией Windows 10.

OpenVPN чрезвычайно популярен в сегменте SOHO для организации доступа удаленных сотрудников: не нужно приобретать отдельное железо, лицензии для организации VPN сервера на базе Windows Server, или выставлять открытый RDP порт Windows в интернет, создавая дополнительные меры для защиты от подбора пароля по RDP.

В этой статье, мы покажем, как установить OpenVPN сервер на компьютер с Windows 10, настроить OpenVPN клиент на другом Windows хосте и установить защищенное VPN подключение.

Установка службы OpenVPN сервера в Windows

Скачайте MSI установщик OpenVPN для вашей версии Windows с официального сайта (https://openvpn.net/community-downloads/). В нашем случае это OpenVPN-2.5.5-I602-amd64.msi (https://swupdate.openvpn.org/community/releases/OpenVPN-2.5.5-I602-amd64.msi).

Если вы планируете, OpenVPN сервер работал в автоматическом режиме, можно не устанавливать OpenVPN GUI. Обязательно установите OpenVPN Services.

Начиная с версии OpenVPN 2.5, поддерживается драйвер WinTun от разработчиков WireGuard. Считается, что этот драйвер работает быстрее чем классический OpenVPN драйвер TAP. Установите драйвер Wintun, откажитесь от установки TAP-Windows6.

Установите OpenSSL утилиту EasyRSA Certificate Management Scripts.

По умолчанию OpenVPN устаналивается в каталог C:\Program Files\OpenVPN.

После окончания установки появится новый сетевой адаптер типа Wintun Userspace Tunnel. Этот адаптер отключен, если служба OpenVPN не запущена.

Создаем ключи шифрования и сертификаты для OpenVPN

OpenVPN основан на шифровании OpenSSL. Это означает, что для обмена трафиком между клиентом и серверов VPN нужно сгенерировать ключи и сертификаты с использованием RSA3.

Откройте командную строку и перейдите в каталог easy-rsa:

cd C:\Program Files\OpenVPN\easy-rsa

Создайте копию файла:

copy vars.example vars

Откройте файл vars с помощью любого текстового редактора. Проверьте пути к рабочим директориям.

Обязательно поправьте переменную EASYRSA_TEMP_DIR следующим образом:

set_var EASYRSA_TEMP_DIR "$EASYRSA_PKI/temp"

Можете заполнить поля для сертификатов (опционально)

set_var EASYRSA_REQ_COUNTRY "RU" set_var EASYRSA_REQ_PROVINCE "MSK" set_var EASYRSA_REQ_CITY "MSK" set_var EASYRSA_REQ_ORG "IT-Company" set_var EASYRSA_REQ_EMAIL " [email protected] " set_var EASYRSA_REQ_OU " IT department "

Срок действия сертификатов задается с помощью:

#set_var EASYRSA_CA_EXPIRE 3650 #set_var EASYRSA_CERT_EXPIRE 825

Сохраните файл и выполните команду:

Следующие команды выполняются в среде EasyRSA Shell:

Должна появится надпись:

init-pki complete; you may now create a CA or requests. Your newly created PKI dir is: C:/Program Files/OpenVPN/easy-rsa/pki

Теперь нужно сгенерировать корневой CA:

Задайте дважды пароль для CA:

CA creation complete and you may now import and sign cert requests.

Данная команда сформировала:

• Корневой сертификат центра сертификации: «C:\Program Files\OpenVPN\easy-rsa\pki\ca.crt»
• Ключ центра сертификации «C:\Program Files\OpenVPN\easy-rsa\pki\private\ca.key»

Теперь нужно сгенерировать запрос сертификата и ключ для вашего сервера OpenVPN:

./easyrsa gen-req server nopass

Утилита сгенерирует два файла:

req: C:/Program Files/OpenVPN/easy-rsa/pki/reqs/server.req key: C:/Program Files/OpenVPN/easy-rsa/pki/private/server.key

Подпишем запрос на выпуск сертификата сервера с помощью нашего CA:

./easyrsa sign-req server server

Подтвердите правильность данных, набрав yes.

Затем введите пароль CA от корневого CA.

В каталоге issued появится сертификат сервера («C:\Program Files\OpenVPN\easy-rsa\pki\issued\server.crt»)

Теперь можно создать ключи Диффи-Хеллмана (займет длительное время):
./easyrsa gen-dh

Для дополнительной защиты VPN сервера желательно включить tls-auth. Данная технология позволяет использовать подписи HMAC к handshake-пакетам SSL/TLS, инициируя дополнительную проверку целостности. Пакеты без такой подписи будут отбрасываться VPN сервером. Это защитит вас от сканирования порта VPN сервера, DoS атак, переполнения буфера SSL/TLS.

Сгенерируйте ключ tls-auth:

cd C:\Program Files\OpenVPN\bin
openvpn —genkey secret ta.key

Должен появиться файл «C:\Program Files\OpenVPN\bin\ta.key». Переместите его в каталог C:\Program Files\OpenVPN\easy-rsa\pki

Теперь можно сформировать ключи для клиентов OpenVPN. Для каждого клиента, который будет подключаться к вашему серверу нужно создать собственные ключи.

Есть несколько способов генерации ключей и передачи их клиентам. В следующем примере, мы создадим на сервере ключ клиента и защитим его паролем:

./easyrsa gen-req kbuldogov
./easyrsa sign-req client kbuldogov

Данный ключ («C:\Program Files\OpenVPN\easy-rsa\pki\private\kbuldogov.key») нужно передать клиенту и сообщить пароль. Клиент может снять защиту паролем для ключа:

openssl rsa -in «C:\Program Files\OpenVPN\easy-rsa\pki\private\kbuldogov.key»-out «C:\Program Files\OpenVPN\easy-rsa\pki\private\kbuldogov_use.key»

Если вы хотите сгенерировать ключ, не защищенный паролем, нужно выполнить команду:

./easyrsa gen-req имяклиента nopass

На сервере с OpenVPN вы можете создать неограниченное количество ключей и сертификатов для пользователей. Аналогичным образом сформируйте ключи и сертфикаты для других клиентов.

Вы можете отохвать скомпрометированные сертификаты клиентов:
cd C:\Program Files\OpenVPN\easy-rsa
EasyRSA-Start.bat
./easyrsa revoke kbuldogov

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

Конфигурационный файл OpenVPN сервера в Windows

Скопируйте типовой конфигурационный файл OpenVPN сервера:

copy «C:\Program Files\OpenVPN\sample-config\server.ovpn» «C:\Program Files\OpenVPN\config-auto\server.ovpn»

Откройте файл server.ovpn в любом текстовом редакторе и внесите свои настройки. Я использую следующий конфиг для OpenVPN:

# Указываем порт, протокол и устройство port 1194 proto udp dev tun # Указываем пути к сертификатам сервера ca "C:\\Program Files\\OpenVPN\\easy-rsa\\pki\\ca.crt" cert "C:\\Program Files\\OpenVPN\\easy-rsa\\pki\\issued\\server.crt" key "C:\\Program Files\\OpenVPN\\easy-rsa\\pki\\private\\server.key" dh "C:\\Program Files\\OpenVPN\\easy-rsa\\pki\\dh.pem" # Указываем настройки IP сети, адреса из которой будет будут получать VPN клиенты server 10.24.1.0 255.255.255.0 #если нужно разрешить клиентам подключаться под одним ключом, нужвно включить опцию duplicate-cn (не рекомендуется) #duplicate-cn # TLS защита tls-auth "C:\\Program Files\\OpenVPN\\easy-rsa\\pki\\ta.key" 0 cipher AES-256-GCM # Другая параметры keepalive 20 60 persist-key persist-tun status "C:\\Program Files\\OpenVPN\\log\\status.log" log "C:\\Program Files\\OpenVPN\\log\\openvpn.log" verb 3 mute 20 windows-driver wintun

OpenVPN позволяет использовать как TCP, так и UDP для подключения. В этом примере я запустил OpenVPN на 1194 UDP. Рекомендуется использовать протокол UDP, это оптимально как с точки зрения производительности, так и безопасности.

Не забудьте открыть на файерволе порты для указанного вами порта OpenVPN на клиенте и на сервере. Можно открыть порты в Windows Defender с помощью PowerShell.
Правило для сервера:

New-NetFirewallRule -DisplayName «AllowOpenVPN-In» -Direction Inbound -Protocol UDP –LocalPort 1194 -Action Allow

Правило для клиента:

New-NetFirewallRule -DisplayName «AllowOpenVPN-Out» -Direction Outbound -Protocol UDP –LocalPort 1194 -Action Allow

Теперь нужно запустить службу OpenVPN и изменить тип ее запуска на автоматический. Воспользуйтесь таким командами PowerShell, чтобы включить службу:

Set-Service OpenVPNService –startuptype automatic –passthru
Get-Service OpenVPNService| Start-Service

Откройте панель управления, и убедитесь, что виртуальный сетевой адаптер OpenVPN Wintun теперь активен. Если нет, смотрите лог «C:\Program Files\OpenVPN\log\server.log»

Если при запуске OpenVPN вы видите в логе ошибку:

Options error: In C:\Program Files\OpenVPN\config-auto\server.ovpn:1: Maximum option line length (256) exceeded, line starts with..

Смените в файле server.ovpn символы переноса строки на Windows CRLF (в notepad++ нужно выбрать Edit -> EOL Conversion -> Windows CR LF). Сохраните файл, перезапустите службу OpevVPNService.

Данный конфиг позволит удаленным клиентам получить доступ только к серверу, но другие компьютеры и сервисы в локальной сети сервера для них недоступны. Чтобы разрешить клиентам OpenVPN получить доступ к внутренней сети нужно:

Включить опцию IPEnableRouter в реестре (включает IP маршрутизацию в Windows, в том числе включает маршрутизацию меду сетями Hyper-V): reg add «HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters» /v IPEnableRouter /t REG_DWORD /d 1 /f

Добавьте в конфгурационный файл сервера OpenVPN маршруты до внутренней IP сети:

push "route 10.24.1.0 255.255.255.0" push "route 192.168.100.0 255.255.255.0"

Если нужно, назначьте клиенту адреса DNS серверов:

push "dhcp-option DNS 192.168.100.11" push "dhcp-option DNS 192.168.100.12"

Если нужно завернуть все запросы клиента (в том числе Интернет трафик) на ваш OpenVPN сервер, добавьте опцию:

push "redirect-gateway def1"

Настройка OpenVPN клиента в Windows

Создайте на сервере шаблонный конфигурационный файла для клиента VPN (на базе iшаблона client.ovpn) со следующими параметрами (имя файла kbuldovov.ovpn)

client dev tun proto udp remote your_vpn_server_address 1194 resolv-retry infinite nobind persist-key persist-tun ca ca.crt cert kbuldogov.crt key kbuldogov.key remote-cert-tls server tls-auth ta.key 1 cipher AES-256-GCM connect-retry-max 25 verb 3

В директиве remote указывается публичный IP адрес или DNS имя вашего сервера OpenVPN.

Теперь на компьютер с клиентом OpenVPN нужно с сервера скопировать файлы:

• ca.crt
• kbuldogov.crt
• kbuldogov.key
• dh.pem
• ta.key
• kbuldogov.ovpn

Теперь импортируйте файл с профилем *.ovpn и попробуйте подключиться к вашему VPN серверу.

Если все настроено правильно, появится такая картинка.

Проверьте теперь лог OpenVPN на клиенте «C:\Program Files\OpenVPN Connect\agent.log»

Mon Dec 27 08:09:30 2021 proxy_auto_config_url Mon Dec 27 08:09:31 2021 TUN SETUP TAP ADAPTERS: guid='' index=22 name='Local Area Connection' Open TAP device "Local Area Connection" PATH="\\.\Global\.tap" SUCCEEDED TAP-Windows Driver Version 9.24 ActionDeleteAllRoutesOnInterface iface_index=22 netsh interface ip set interface 22 metric=1 Ok. netsh interface ip set address 22 static 10.24.1.6 255.255.255.252 gateway=10.24.1.5 store=active IPHelper: add route 10.24.1.1/32 22 10.24.1.5 metric=-1

Клиент успешно подключится к OpenVPN серверу и получил IP адрес 10.24.1.6.

Проверьте теперь лог на сервере («C:\Program Files\OpenVPN\log\openvpn.log»). Здесь также видно, что клиент с сертификатом kbuldogov успешно подключится к вашему серверу.

2021-12-27 08:09:35 192.168.13.202:55648 [kbuldogov] Peer Connection Initiated with [AF_INET6]::ffff:192.168.13.202:55648 2021-12-27 08:09:35 kbuldogov/192.168.13.202:55648 MULTI_sva: pool returned IPv4=10.24.1.6, IPv6=(Not enabled) 2021-12-27 08:09:35 kbuldogov/192.168.13.202:55648 MULTI: Learn: 10.24.1.6 -> kbuldogov/192.168.13.202:55648 2021-12-27 08:09:35 kbuldogov/192.168.13.202:55648 MULTI: primary virtual IP for kbuldogov/192.168.13.202:55648: 10.24.1.6

Предыдущая статья Следующая статья

OpenVPN DNSLeak prevention (боремся с утечкой DNS)

Даже несмотря на то, что сервер OpenVPN пушит клиенту список DNS серверов для использования, клиент OpenVPN все равно может пытаться использовать DNS провайдера (или другие, заданные в системе).

Для минимизации риска использования не тех DNS, которые задаются сервером OpenVPN, в конфиг клиента добавляют опцию:

Можете проверить сначала до включения опции — откройте https://dnsleaktest.com. Высока вероятность того, что вы все еще используете DNS вашего провайдера.

Теперь включите вышеуказанную опцию и перезапустите клиент. Вы должны увидеть разницу.

Для Windows 8 и 10

это не совсем так (а что вы хотели?). В этих ОС Microsoft заботится о своих неразумных пользователях, которые, очевидно, не желают использовать именно те настройки, которые они настроили 🙂 А именно, Windows 8 и 10 рассылают dns-запросы по всем возможным интерфейсам в системе и используют самый быстрый ответ, в результате чего вероятность незапланированного использования dns вашего провайдера вместо dns openvpn-сервера весьма высока. Этот момент описан здесь (автор ValdikSS).

Отследить проблему (и возможные варианты решения) можно согласно инструкции так:

Определяем интересующий нас подключенный интерфейс (в данном примере по-английски, на момент написания русской версии не было):

> netsh interface show interface

Очищаем кеш резолвера dns:

Запрещаем dns сервер на этом интерфейсе:

> netsh interface IPv4 set dnsserver «Local Area Connection» static 0.0.0.0 both

Проверяем (например, на https://dnsleaktest.com).

После отсоединения возвращаем настройки dns обратно:

> netsh interface IPv4 set dnsserver «Local Area Connection» dhcp

Снова чистим кеш резолвера:

По крайней мере, это позволит протестировать, в чем проблема и принять соответствующие меры.

Как вы понимаете, аналогичные проблемы могут быть и при использовании VPN других вендоров. Просто на это можно обращать внимание. А можно и не обращать 🙂

Авторизуйтесь для добавления комментариев!

Почтовый сервер Mikrotik VPN 3proxy Шифрование Squid Резервное копирование Защита почты Виртуальные машины Настройка сервера java kvm Групповые политики SELinux OpenVPN IPFW WDS Lightsquid Samba firewalld systemd Mobile libvirt Remote desktop WiFi Iptables NAT Postfix Dovecot Удаление данных Софт Безопасность Winbox User agent Хостинг Передача данных Онлайн сервисы Privacy LetsEncrypt VPN сервер Настройка прокси RRDTool sendmail Rsync Linux SSH Система Windows Синхронизация Облако fail2ban FreeBSD