LINUX.ORG.RU

Свой ДНС-сервер для ВПН-сети.

 ,


0

1

День Добрый, Уважаемое Сообщество!

Текущее положение дел. Есть несколько виртуальных VDS-серверов, которые находятся у разных хостеров. Есть несколько офисов, а так же отдельные клиенты. Все это потихоньку собирается в новую ВПН-сеть.

К некоторым сервисам, которые запущены на текущих виртуальных машинах, доступ был ограничен либо через iptables, либо через .htaccess

У некоторых клиентов были постоянные белые IP. Их и прописывали для обеспечения доступа.

Что хочу сделать сейчас...

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

Так же отмечу что есть доменное имя, mycompany.domain, например. И те службы, о которых шла речь выше запущены на VDS-серверах. А для них сделаны человеческие адреса. Вроде service01.mycompany.domain, service02.mycompany.domain.

Суть задачи. Нужно организовать подмену IP-адресов для клиентов VPN-сети.

Т.е. если клиент не подключен к сети, то на комманду ping service01.mycompany.domain — он должен видеть реальный IP-адрес под которым работает VDS-сервер. А если подключается к ВПН-сети, то ping service01.mycompany.domain должен вернуть ему серый IP-адрес в моей ВПН-сети.

Суть вопроса. А их два.

Насколько следует заморачиваться с BIND? Нужно ли его выносить в отдельный chroot? Или вряд ли «хомячки» смогут там что-то сломать? Достаточно ограничить к нему доступ при помощи iptables или в самом конфиге?

И второй вопрос о существующих ДНС-записях для текущего домена. Их можно будет перехватить и переопределить, как было написано выше? Т.е. доменное имя один в один с существующим, но только будет серый IP-адрес из ВПН-сети.

У меня никогда не было такой задачи и предполагаю, что где-то есть best practices. НО

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

В этом случае DNS сервер не нужен, при подключении VPN локально проще запустить bash скрипт, который сменит IP в /etc/hosts

Вариант 2. VPN net2net подключается на роутере клиента, тогда да, можно с роутера рулить записями локального DNS. Но нужно будет решить проблемы с кэшированием адресов на клиентах. Кэширование нужно убрать.

constin ★★ ()

По поводу «подмены» адресов, почитай про Bind Views оно позволяет держать 2 описателя зоны, одной и той же зоны, для разных сетевых интерфейсов - один для vpn, второй для real IPs.

Chroot штука хорошая, но selinux эффективнее и не менее надежен.

sparks ()
Ответ на: комментарий от constin

Это не проблема. Совсем не проблема. У меня это уже реализовано.

На стороне сервера можно указать в конфиге клиента переопределить DNS-сервера.

Например:

push "dhcp-option DNS 10.10.3.1"
Где 10.10.3.1 это адрес моего локального DNS-сервера.

Проверял на виндовом клиенте. Полет нормальный. Кушает новые DNS-сервера.

artemich ()
Ответ на: комментарий от sparks

У меня сам домен, поддомены и прочие записи хранятся у дядюшки Яндекса. Так сложилось исторически. Переносить всю зону себе нет желания.

Нужен просто кэширующий ДНС-сервер с возможностью подмены некоторых адресов для своих клиентов.

Похожую штуку делал на Микротике в пару кликов. Там надо включить кэширующий ДНС и в него внести вручную те адреса — для которых нужно сделать подмену ДНС в IP.

В свое время не смог победить selinux на Центосе. Пришлось выключить нафиг.

Сейчас у меня сервера на Убунте и Дебиане. Не особо критичные данные на них.

Хотелось бы просто средствами iptables закрыть доступы из вне. Т.е. из Интернета. А в локальную виртуалньную сеть открыть.

Я так понял что и chroot особо не будет нужен.

artemich ()
Ответ на: комментарий от artemich

допустим у клиента есть внутренний днс и очень важный локальный сервис , который висит на important.domain.localnet.

и тут вы ему пашите свой днс, который ничего про important.domain.localnet не знает. клиент остался без сервиса.

можно,конечно, пашить свой плюс его старый, но это надо под каждого клиента писать свой push.

хз что там у винды по этому поводу, но на линухе конфигурация dns перезапишется полностью.

constin ★★ ()
Ответ на: комментарий от constin

Ну вас и понесло... Господа...

Список важных ресурсов, с точки зрения работы, уже определен.

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

Суть проблемы я изъяснил выше.

Ко всем этим важным ресурсам идет обращение через внешний IP-адрес.

Нужно чтобы было через внутренний из новой ВПН-сети.

Как там будет в рабочем режиме — узнаю позже.

Всегда возникают проблемы и подводные камни.

artemich ()

Т.е. если клиент не подключен к сети, то на комманду ping service01.mycompany.domain — он должен видеть реальный IP-адрес под которым работает VDS-сервер. А если подключается к ВПН-сети, то ping service01.mycompany.domain должен вернуть ему серый IP-адрес в моей ВПН-сети.

Если я правильно понял задачу, то не сработает. Точнее работать будет очень очень криво.
В чем сама задача? Что бы при подключении vpn трафик шел не через инет а через vpn ? Тогда проще зароутить эти внешние ip в тунель.

anc ★★★★★ ()
Ответ на: комментарий от artemich

У меня сам домен, поддомены и прочие записи хранятся у дядюшки Яндекса. Так сложилось исторически. Переносить всю зону себе нет желания.

Нужен просто кэширующий ДНС-сервер с возможностью подмены некоторых адресов для своих клиентов.

dnsmasq То, чего нет в /etc/hosts, ресолвит по-честному.

Т.е. можно подменять адреса поштучно не заморачиваясь с настоящим DNS-ом и зонами.

MumiyTroll ★★ ()
Ответ на: комментарий от artemich

Никого не понесло, это вы хотите костыль сделать. И говорите о том, что у клиентов все локальные сервисы захардкодены. Когда вы пишите «клиенты» , то в данном случае я понимаю какие-то бизнес-клиенты с офисами, своей работой сеткой и сервисами. Так что решение надо делать общее.

constin ★★ ()