OpenVPN & SplitDNS в Linux, часть 1
В прошлом выпуске журнала "Мурзилка" я рассматривал варианты виртуальных TUN-адаптеров для работы с OpenVPN под Windows и вскользь затронул тему Split DNS. Например, когда нужно IP-адреса внутрикорпоративных ресурсов разрешать через "внутренние" же DNS-сервера, а все остальные - через "внешние". С неких пор под форточками этот вопрос решается ( Read more... )
И еще, кажется, перенаправление всех DNS-запросов в VPN обычно считается средством от утечек информации о запросах мимо VPN, ну и от подделки ответов.
А зачем может понадобиться одному клиенту ходить к разным серверам? Ну если это не тестирование "как это выглядит с той стороны".
Reply
> на мой взгляд, это уже не SplitDNS
Вопрос в терминологии. Давайте тогда придумаем какое-нибудь другое название рассматриваемому явлению. Например, "Ы-DNS". Только опасаюсь, что кроме меня и вас больше никто не поймет.
> когда разные ответы отдаются разным клиентам ... а когда один и тот же клиент спрашивает разные домены у разных серверов
Я это называю "Multi-view DNS". B в рассматриваемом мной примере по сути речь идёт об одном и том же. Одна и та же инфраструктура, один и тот же админ. И один и тот же клиент запрашивает одну и ту же запись с одного и того же авторитетного сервера либо "изнутри", либо "снаружи". Но в общем случае, да, может быть по-всякому.
> А зачем может понадобиться одному клиенту ходить к разным серверам?
Ситуация. Есть энное количество внутрикорпоративных ресурсов, которые ну никак не хочется выставлять внаружу. Всякие там тикетницы, гитлабы, вики, не знаю что ещё. Белых адресов в закромах маловато, на всё на это не хватит. И очень хочется ко всему к этому прикрутить "честные" X509-сертификаты от Lets Encrypt ( ... )
Reply
Ну споры о терминологии - они ж самые увлекательные, они же самые бесплодные. Я для себя термин SplitDNS узнал, когда разбирался с view в BIND (named), и оно относилось исключительно с настройке сервера. Собственно, эта часть документации до сих пор так и называется: https://bind9.readthedocs.io/en/v9_16_4/advanced.html#split-dns Не исключаю, что с тех пор общепринятое значение термина сместилось в сторону особенностей настройки клиента, про что и написано в посте.
> Ситуация. Есть энное количество внутрикорпоративных ресурсов, которые ну
никак не хочется выставлять внаружу. Всякие там тикетницы, гитлабы,
вики, не знаю что ещё. Белых адресов в закромах маловато, на всё на это
не хватит. И очень хочется ко всему к этому прикрутить "честные"
X509-сертификаты от Lets Encrypt. Как будем решать?
Я ее всегда решал вот тем самым SplitDNS, который настройка view в сервере (ну или два сервера на разных адресах, если view почему-то нет). Особенных настроек резолверов клиентов это не требует, кроме указания правильного сервера.
Собственно, я ( ... )
Reply
Хорошо. Упрощаю ситуацию. Есть контора с кучей разных внутренних ресурсов (да хотя бы обычные виндовые файловые шары). Есть сотрудник "на удалёнке", который цепляется по OpenVPN в сеть конторы. Как клиент должен понять с каких DNS-серверов запрашивать те или иные ресурсы: с конторских или с провайдерских?
Reply
О! Вот этот сценарий (VPN внутрь корпоративной сети) мне в голову не пришел, хотя он, конечно, очевидный.
Я бы в этом случае пустил весь трафик DNS на внутренние DNS-сервера конторы. В конце концов, VPN затем и нужен, чтобы попасть во внутреннюю сеть, так пусть и DNS будут от внутренней сети. Если из внутренней сети можно ходить во внешний мир, то и конторские сервера дадут для этого нужные ответы. А если нельзя, то логично это запретить и подключенному через VPN.
Reply
> весь трафик DNS на внутренние DNS-сервера конторы
Во-первых, если контора и удалённый сотрудник находятся в разных странах или просто очень далеко друг от друга, то это поломает работу всяких сервисов, которые используют поиск географически ближайшего сервера на основании DNS-запросов. CDN разные и иже с ними. Да банально какие-нибудь YouTube могут начать "не на том языке" открываться у сотрудника дома.
Во-вторых, ладно. Договорились пускать весь трафик через корпоративные сервера, ок. Как это объяснить клиенту? Как ему сказать, что начиная с момента XX:XX:XX он должен прекратить использовать DNS-сервера провайдера и начать использовать корпоративные сервера?
Reply
Нуу, CDN, ухудшившиеся на время работы в корп. сети - не самое страшное, на мой взгляд.
Завернуть все DNS в OpenVPN - есть параметр конфига block-outside-dns.
Reply
Читаю описание директивы.
Block DNS servers on other network adapters to prevent DNS leaks. This
option prevents any application from accessing TCP or UDP port 53 except one inside the tunnel. It uses Windows Filtering Platform (WFP) and works on Windows Vista or later.This option is considered unknown on
non-Windows platforms and unsupported on Windows XP, resulting in fatal error.
Во-первых, она работает только на форточках. Во-вторых, она про фильтрацию, а не про настройку системного ресолвера. То есть реально это может выглядеть так, что не будут доступны вообще никакие DNS-ы: провайдерские мы запретили / отфильтровали, а на корпоративные клиент не переключился.
Reply
Эмм, ну чтобы переключиться на корпоративные, нужно или в конфиге сервера
push "dhcp-option DNS X.X.X.X"
или в конфиге клиента
dhcp-option DNS X.X.X.X
Я проверил - работает (на Windows).
Ну а на Linux, если там не сработает то же самое (надеюсь, что в OpenVPN все же есть что-то для переписывания DNS встроенное, у меня сейчас линукса с клиентом OpenVPN под рукой нет), то в посте да, описаны рецепты. С Linux проще: всегда можно полностью переписать набор серверов DNS, он же не привязан к интерфейсу, как в Windows (или в NetworkMAnager привязан? не копался в нем так глубоко).
Reply
> Я проверил - работает (на Windows).
Ха-ха, не всё так просто. Начиная с 10ки в винде полностью переделали механизм приоритезации DNS. Так что несмотря на то, что информация о DNS-сервере "приедет", софсем не факт, что системный ресолвер действительно будет его использовать. Я об этом выпустил один из предыдущих постов.
> надеюсь, что в OpenVPN все же есть что-то для переписывания DNS встроенное
Нет. Он может дёрнуть какой-нибудь скрипт или выплюнуть полученный от сервера / из собственного конфига набор на StdOut / в лог. А дальше "проблемы индейцев шерифа не волнуют".
Reply
> Ха-ха, не всё так просто. Начиная с 10ки в винде полностью переделали
механизм приоритезации DNS. Так что несмотря на то, что информация о
DNS-сервере "приедет", софсем не факт, что системный ресолвер
действительно будет его использовать. Я об этом выпустил один из
предыдущих постов.
Ну встроенный nslookup начинает по умолчанию ходить к новому серверу. Дальше я не копал.
> Нет. Он может дёрнуть какой-нибудь скрипт или выплюнуть полученный от
сервера / из собственного конфига набор на StdOut / в лог. А дальше
"проблемы индейцев шерифа не волнуют".
Я бы, как представитель "старой школы", из такого скрипта бы нафиг переписал /etc/resolv.conf, созранив в сторонку старый, а после разрыва соединения восстановил бы назад. Хотя с systemd это может оказаться сложнее.
Reply
> встроенный nslookup начинает по умолчанию ходить к новому серверу
На грабли можно наступить при одновременном выполнении двух условий.
1. Интернет подведен по гигабитному линку.
2. Запрашиваемый домен является реально существующим.
В остальных случаях проблема может и не проявиться.
> нафиг переписал /etc/resolv.conf, созранив в сторонку старый
Работать будет, не спорю. Но в 2023м году так делать - всё равно что пытаться разбудить спящего ударом кувалды по голове. Есть способы куда изящнее.
Reply
>Начиная с 10ки в винде полностью переделали механизм приоритезации DNS.
Эта опция и была сделана для Windows 10.
https://habr.com/ru/post/268173/
Reply
Запретить-то можно, ок. А вот ли будет ли система запрашивать DNS через интерфейс с не-минимальной метрикой, вопрос. Можно проверить wireshark-ом, конечно. Если не забуду, погляжу.
Reply
Да, будет. block-outside-dns меняет метрику VPN-интерфейса на "3", насколько помню.
Reply
Не на "3", но она становится меньше, чем метрика "основного" интерфейса, да. У меня в эксперименте получилось что-типа "253 против 281". Так что опция работает, согласен. Хотя конечно, кишки винды - загадка.
Reply
Leave a comment