Dns fallback openvpn что это

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 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

Openvpn

Помогите пожалуйста разобраться с маршрутизацией (openvpn)

После подлючения к openvpn мой IP-шник в браузере остаётся прежним

openvpn ovpn vpn

OpenVPN. Проблема маршрутизации? bad source address from client, packet dropped

Доступ к локалке за pFsense через OpenVPN сервер на VPS

Добавление подключения OpenVPN в автозагрузку

OpenVPN замедляет работу по сети LAN

Возможность предоставления интернета клиентам локальной сети находящимся за клиентом Openvpn

network openvpn интернет

Opnsense клиенты OpenVPN не могут попасть LAN

nat openvpn доступ

Настройка нескольких DNS для OpenVPN клиента

dns network openvpn

openvpn перестал работать на заграничном сервере

OpenVPN нет интернета (проблема с MTU)

openvpn не признает сертификат

Нестандартная настройка OpenVPN на сервере

devops openvpn работа

Openvpn соединение в xfce

Проблема при подключении MullvadVPN в кали

help kali openvpn

Помогите настроить OpenVPN

OpenVPN на роутере, нет интернета

debian openvpn роутер

openssl openvpn ssl

Не могу воспользоваться openvpn.

Настроить фильтр iptables для прокси

iptables openvpn proxy

Помогите найти удобный апплет для настройки VPN-клиента под LXQt.

desktop environment gui lxqt

не запускается OpenVPN.

задача написать openVPN через socks5 udp

openvpn proxy socks

Не монтируется раздел по NFS

mount nfs openvpn

OpenVPN — няшка или кака?

socks5 UDP backconnect делал кто ?

android freebsd openvpn

Адекватное количество уровней безопастности на сетевом уровне для лабы и прода

Анонимный VPN роутер на pfSense

Итак, у нас есть туннель до VPN-провайдера и мы хотим быть уверены что весь трафик, включая DNS запросы, идёт только через этот туннель, а в случае его недоступности пользователи ни в коем случае не должны выходить напрямую через сеть провайдера. Установлена pfSense CE версии 2.6.0, регистрация на CyberGhost пройдена — поехали.

CyberGhost

У вас может быть и другой VPN-провайдер,- CyberGhost выбран ввиду простоты настройки и для демонстрации настройки получения DNS серверов при подключении. Если в вашей стране не заблокирован ExpressVPN, то настройки будут практически идентичны.

Регистрация пройдена, оплачено нужное количество месяцев. На странице VPN > Управление устройствами выбираем Ручная установка -> Настроить устройство. В появившемся окне в качестве протокола выбираем просто OpenVPN, какую хочется страну и группу серверов. Называем это pfSense.

Далее на странице VPN > Управление устройствами видим pfSense в списке активных VPN-устройств. Нажимаем на «просмотреть» в новом окне и скачиваем архив с конфигураций. Username и Password нам также пригодятся при настройке клиента.

Сертификаты

Распаковываем скачанный архив pfsense_openvpn.zip и видим там несколько файлов. Для начала нам нужны ca.crt, client.crt и client.key.

Переходим в pfSense на страницу System / Certificate Manager / CAs и жмём кнопку Add.

Называем это дело GyberGhost VPN CA, выбираем в качестве метода Import an existing Certificate Authority и вставляем содержимое файла ca.crt данные в поле Certificate data. CA импортирован.

Теперь переходим на вкладку System / Certificate Manager / Certificates, кнопка Add, выбираем в качестве метода Import an existing Certificate, называем CyberGhost Client Certificate и копируем содержимое файла client.crt в поле Certificate data, а файла client.key — в поле Private key data.

OpenVPN клиент

Настроим OpenVPN клиент. Жмём Add на странице VPN / OpenVPN / Clients, а также открываем содержимое файла openvpn.ovpn из архива. В моём случае это выглядит так:

client remote 87-1-at.cg-dialup.net 443 dev tun proto udp auth-user-pass resolv-retry infinite redirect-gateway def1 persist-key persist-tun nobind cipher AES-256-CBC ncp-disable auth SHA256 ping 5 ping-exit 60 ping-timer-rem explicit-exit-notify 2 script-security 2 remote-cert-tls server route-delay 5 verb 4 ca ca.crt cert client.crt key client.key 

Начинаем заполнять поля настройки клиента. Если что-то не указано, то оставляем по умолчанию. Поехали:

• Server host or address: хост из строки remote, в моём случае 87-1-at.cg-dialup.net
• Server port: порт из строки remote, в моём случае 443
• Description: CyberGhost VPN
• Username/Password: копируем со страницы предварительного просмотра роутера (см. выше)
• TLS Configuration: убираем
• Peer Certificate Authority: CyberGhost VPN CA
• Client Certificate: CyberGhost VPN Client Certificate
• Data Encryption Negotiation: отключаем (строка ncp-disable)
• Fallback Data Encryption Algorithm: оставляем AES-256-CBC (строка cipher)
• Auth digest algorithm: оставляем SHA256 (строка auth)
• Pull DNS: позволяет использовать предоставляемый клиенту DNS, включаем

Сохраняем и на странице Status / OpenVPN проверяем что клиент подключился (Status = up):

Настройка DNS

Нашей задачей является запрет на использование публичных DNS серверов клиентами сети,- мы не хотим показывать куда ходят клиенты через VPN туннель (т.е. исключить DNS Leak).

Для начала назначим OpenVPN интерфейс, это нам пригодится в дальнейшем. На странице Interfaces / Interface Assignments выбираем ovpnc1 и нажимаем Add. Называем CyberGhost_VPN, чекаем Enable и сохраняем.

Переходим на страницу System / General Setup и убираем всё из списка DNS Servers. Ставим галочку DNS Server Override, — это позволит использовать получаемый от OpenVPN сервер DNS в качестве форвардера.

Настроим DNS сервер на Services / DNS Resolver / General Settings. Разрешаем запросы только на LAN и loopback интерфейсах — Network Interfaces = LAN, Localhost. Выбираем в Outgoing Network Interfaces только CyberGhost_VPN и ставим галочку у DNS Query Forwarding.

В pfSense 2.6.0 появилась важная опция — Strict Outgoing Network Interface Binding. Смело ставим этц галочку. Теперь, если по каким-то причинам OpenVPN не подключится/отвалится, то pfSense не будет отправлять DNS запросы через шлюз по умолчанию, исключая DNS Leak.

Исключаем DNS Leak

Вот тут начинаются хитрости. В зависимости от типа подключения к провайдеру нам нужно произвести разные настройки чтобы исключить попадание провайдерских DNS в список форвардеров,- иначе при отвале VPN’а все DNS запросы пойду через следующий по приоритету DNS, т.е. тот что мы автоматически получаем от провайдера.

Для начала добавим на странице Services / DNS Resolver > Host Overrides адреса VPN сервера. Сперва получим их с помощью команды `dig a 87-1-at.cg-dialup.net`:

$ dig a 87-1-at.cg-dialup.net . пропущено. ;; ANSWER SECTION: 87-1-at.cg-dialup.net. 30 IN A 37.19.223.231 87-1-at.cg-dialup.net. 30 IN A 37.19.223.5 87-1-at.cg-dialup.net. 30 IN A 37.19.223.10 87-1-at.cg-dialup.net. 30 IN A 37.19.223.203 87-1-at.cg-dialup.net. 30 IN A 37.19.223.32 87-1-at.cg-dialup.net. 30 IN A 37.19.223.217 87-1-at.cg-dialup.net. 30 IN A 89.187.168.165 87-1-at.cg-dialup.net. 30 IN A 37.19.223.251 87-1-at.cg-dialup.net. 30 IN A 37.19.223.8 87-1-at.cg-dialup.net. 30 IN A 37.19.223.250

Создадим Host Entry перечислив полученные адреса через запятую:

Если для подключения к провайдеру используется статический адрес — то по данной части всё готово, никакие другие DNS’ы кроме тех что прилетают при подключении по OpenVPN у нас не появятся.

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

Скопируем скрипт запускаемый при подключении по DHCP:

cp /usr/local/sbin/pfSense-dhclient-script /usr/local/sbin/pfSense-dhclient-script.nodns

И закомментируем в нём строки 359, 388-390. Скопируем автоматически сгенерированный конфиг DHCP клиента:

cp /var/etc/dhclient_wan.conf /usr/local/etc/nodns_dhcp.conf

И поменяем там лишь строку `script`:

script "/usr/local/sbin/pfSense-dhclient-script.nodns";

Указываем путь к нашему конфигу в Configuration File Override:

Вот и всё — теперь настройки DNS получаемые по DHCP будут игнорироваться.

А что если PPPoE подключение? Придётся кое-что поправить в скрипте вызываемом при подключении,- /usr/local/sbin/ppp-linkup . Чуть заменим одну строку:

- if [ "$" = "true" ]; then + if [ "$" = "X" ]; then

Аналогично, теперь получаемые по PPPoE настройки DNS будут игнорироваться. Но это ещё не всё.

Тут внимательные пользователи pfSense могут спросить — а зачем все эти правки, если получаемый по OpenVPN DNS сервер будет иметь приоритет над теми что прилетают через DHCP/PPPoE? Дело в том, что если по каким-то причинам DNS сервер VPN провайдера не отвечает, то резолвер начнёт пробовать отправлять запрос к следующему по приоритету DNS серверу, и запросы пойдет мимо туннеля.

Настройка Firewall

Нужно исключить возможность использования пользователями/программами нашей локалки каких-либо других DNS серверов кроме того предоставляется VPN провайдером.

Для этого создадим правило блокирующее DNS-over-TLS трафик (853 TCP порт) на вкладке Firewall / Rules / LAN — Add со стрелочкой вверх(!):

• Action: Reject
• Address Family: IPv4
• Protocol: TCP
• Source/Destination: Any

И создадим Port Forwarding правило перенаправляющее все DNS запросы наружу на наш pfSense. Вкладка Firewall / NAT / Port Forward -> Add:

• Interface: LAN
• Address Family: IPv4
• Protocol: TCP/UDP
• Destination:Invert match — включить, Type: LAN Address
• Destination port range: DNS
• Redirect target IP: LAN address
• Redirect target port: DNS
• Filter rule association: Add associated filter rule

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

На странице System / Advanced / Miscellaneous включаем Skip rules when gateway is down, — это нужно для того, чтобы при отвале VPN’а не создавались правила использующие шлюз этого VPN. В этом случае правила как бы «не будет», а следом нет и других правил,- соответственно deny, трафик будет дропаться.

Создадим же само правило (Add со стрелочкой вниз):

Итого у нас должен получиться следующий порядок правил:

Настроим Outbound NAT для клиентов локальной сети. На Firewall / NAT / Outbound переключаем Mode в «Hybrid Outbound NAT rule generation» и нажимаем Save. Теперь можно добавить следующее правило:

• Interface: CYBERGHOST_VPN
• Address Family: IPv4
• Protocol: any
• Source: адрес нашей LAN сети, в моём случае — 192.168.3.0/24
• Destination: Any
• Address: Interface Address

Теперь IP адреса хостов LAN сети попадая в туннель будут автоматически транслироваться в адрес OpenVPN-интерфейса (маскарадинг).

Настройка pfBlockerNG

Подробнее про настройку этого чудо-блокировщика я уже писал ранее, поэтому пробежимся только по тому что нам от него нужно. Для начала установим пакет pfBlockerNG-devel через System / Package Manager / Available Packages, сделаем дефолтную настройку с помощь визарда на Firewall / pfBlockerNG и перейдём к специфичным для нас вещам.

А именно блокировке DoH серверов. На странице Firewall / pfBlockerNG / DNSBL / DNSBL SafeSearch переводим DoH/DoT Blocking в Enable и выбираем через Ctrl+A все сервера в DoH/DoT Blocking List.

В принципе, это основное что нам нужно от pfBlockerNG — исключить DNS leak через DoH сервера. При желании можно настроить фиды для блокировки IP или DNS адресов, например использовать фиды из категории Firebog_Trackers для блока трек-адресов или блокировать рекламу с помощью Firebog_Advertisement, ADs и Easylist фидов.

Не забываем запустить Force / DNSBL на Firewall / pfBlockerNG / Update для применения изменений.

Готово

Можно дополнительно проверить что трафик не пойдёт мимо VPN’а если тот отвалится,- просто остановите OpenVPN клиент на Status / OpenVPN (иконка с «кирпичиком») и убедитесь что клиенты даже не смогут ничего пинговать по IP адресу.

Как уже говорилось в начале, данная конфигурация применима и к другим VPN провайдерам работающим по OpenVPN, незначительные отличия могут быть лишь в правильной «интерпретации» .ovpn конфига и для настройки OpenVPN клиента в pfSense.

P.S. обновление 18.02.22 — добавлена информация о включении опции Strict Outgoing Network Interface Binding, появившейся в pfSense 2.6.0.

• Блог компании Timeweb Cloud
• Информационная безопасность
• Системное администрирование
• Сетевые технологии