LINUX.ORG.RU

История изменений

Исправление intelfx, (текущая версия) :

Первый вариант так себе, но потенциально рабочий, особенно если синхронизировать кеши различных DNS-серверов будет не lease-скрипт, а скрипт на центральном сервере.

Ну, я имел в виду скорее «из lease-скрипта пинать центр, а оттуда раскидывать по остальным», чтобы список подсетей был ровно в одном месте.

Второй вариант не рабочий, так как если DNS-сервер не знает ответ, он сообщает, что нет такого имени и клиент не пойдёт к другми серверам.

Такое поведение описано в каком-то стандарте? Просто в линуксе nss_dns из glibc (насколько я мог заметить) как раз делает цикл по всем nameserver'ам из resolv.conf, иначе бы ни у кого DNS внутри VPN не работал.

В третьем варианте вы и указали корень проблемы — ущербый DNS-резолвер, который не умеет ходить к разным серверам за разными доменами. И, если не менять встроенный в mikrotik резолвер на что-то получше,

Я бы с радостью. Это возможно?

слать все DNS-запросы к центральному DNS-серверу. Дать центральному DNS-у как-бы ip-адреса провайдерских DNS-ов и намутить что-нибудь с маршрутами/адресами, чтобы при падении тунеля DNS-запросы шли к провайдеру.

Боюсь, это замедлит common path (большая часть запросов всё же будет относиться к доменным именам из Интернета). Впрочем, тут вообще вот что предлагают: матчить содержимое DNS-запросов в prerouting регуляркой и по результатам dstnat'ить их куда надо :)

Исправление intelfx, :

Первый вариант так себе, но потенциально рабочий, особенно если синхронизировать кеши различных DNS-серверов будет не lease-скрипт, а скрипт на центральном сервере.

Ну, я имел в виду скорее «из lease-скрипта пинать центр, а оттуда раскидывать по остальным», чтобы список подсетей был ровно в одном месте.

Второй вариант не рабочий, так как если DNS-сервер не знает ответ, он сообщает, что нет такого имени и клиент не пойдёт к другми серверам.

Такое поведение описано в каком-то стандарте? Просто в линуксе nss_dns из glibc (насколько я мог заметить) как раз делает цикл по всем nameserver'ам из resolv.conf, иначе бы ни у кого DNS внутри VPN не работал.

В третьем варианте вы и указали корень проблемы — ущербый DNS-резолвер, который не умеет ходить к разным серверам за разными доменами. И, если не менять встроенный в mikrotik резолвер на что-то получше,

Я бы с радостью. Это возможно?

слать все DNS-запросы к центральному DNS-серверу. Дать центральному DNS-у как-бы ip-адреса провайдерских DNS-ов и намутить что-нибудь с маршрутами/адресами, чтобы при падении тунеля DNS-запросы шли к провайдеру.

Боюсь, это замедлит common path (большая часть запросов всё же будет относиться к доменным именам из Интернета). Впрочем, тут вообще предлагают матчить содержимое DNS-запросов в prerouting регуляркой и по результатам dstnat'ить их куда надо :)

Исходная версия intelfx, :

Первый вариант так себе, но потенциально рабочий, особенно если синхронизировать кеши различных DNS-серверов будет не lease-скрипт, а скрипт на центральном сервере.

Ну, я имел в виду скорее «из lease-скрипта пинать центр, а оттуда раскидывать по остальным», чтобы список подсетей был ровно в одном месте.

Второй вариант не рабочий, так как если DNS-сервер не знает ответ, он сообщает, что нет такого имени и клиент не пойдёт к другми серверам.

Такое поведение описано в каком-то стандарте? Просто в линуксе nss_dns из glibc (насколько я мог заметить) как раз делает цикл по всем nameserver'ам из resolv.conf, иначе бы ни у кого DNS внутри VPN не работал.

В третьем варианте вы и указали корень проблемы — ущербый DNS-резолвер, который не умеет ходить к разным серверам за разными доменами. И, если не менять встроенный в mikrotik резолвер на что-то получше,

Я бы с радостью. Это возможно?

слать все DNS-запросы к центральному DNS-серверу. Дать центральному DNS-у как-бы ip-адреса провайдерских DNS-ов и намутить что-нибудь с маршрутами/адресами, чтобы при падении тунеля DNS-запросы шли к провайдеру.

Боюсь, это замедлит common path (большая часть запросов всё же будет относиться к доменным именам из Интернета).

Впрочем, тут предлагают матчить содержимое DNS-запросов в prerouting регуляркой и по результатам dstnat'ить их куда надо :)