В сети-2 есть микротик и на нем включен dhcp иногда к нему подключаются например принтеры. Все взаимодействуют с принтерами по DNS. Например mfp-01.sub.domain.com.
В сети-1 Прекрасно работает dhcp windows (роль-dhcp сервер) и регистрирует на DNS сервере. (прямая и обратная зона)
Но перемещение по площадкам неизбежно.
Можно как я понимаю использовать DNS микротика, но он без костыля не вносит hostname в свой DNS.
Какие есть оптимальные решения?
wins не предлагать это технология "древних"))
Интересуют так же PTR записи.
Всё построено на Windows - Aсtive Directory.
Увы увы, это проблема без костылей не решается. Потому что микротик не предназначен для решения подобных задач. В случае с AD, DHCP+DNS должно быть одной сущностью, на одном сервере. Чтобы происходило динамическое обновление ДНС.
Микротик не умеет без костылей раздавать имена хостам, только ip адреса. Как вариант, только писать принтерам статику в leases микротика, запоминать их все по mac адресам, и прописывать в statiс DNS микротика имя этого принтера. И делать микротик основным dns сервером в сети. Только тогда будет работать.
MaxKozlov, DCHP и DNS разнесены на разных серверах, и разных подсетях.
На одной площадке windows dhcp сервер, регистрирует и пишет в dns клиентов.
А на другой площадке, железка, и надо что бы она так же делала записи в dns
Kenny00, Если на другой площадке в качестве dhcp железка-микротик, то оно, действительно, не умеет.
Какое у вас адресное пространство - тоже непонятно.
Если то же самое что и на основной площадке - компы по прямому адресу сами лезут и регистрируются в windows dns, если вы им разрешили.
Проблема тут только в PTR
Можно попросить микротик держать у себя обратную зону с наскриптовать занесение туда в момент выделения адреса - скрипты есть в сети
Если DNS Aсtive Directory из сети 1 доступны на удаленной площадке. То нужно в настройках DHCP микротика сети 2 указать DNS сети 1 для раздачи клиентам, тогда клиенты будут регистрироваться на этих DNS.
Из минусов, когда DNS из сети 1 перестанут быть доступны, у клиентов перестанет работать интернет и все, что завязано на DNS.
Павел, Вопросов к Клиентам нет. МФУ устройство которое не работает с доменом, ее регистрирует в DNS dhcp. Реализация
А тут у нас в роли DHCP микротик.
По поводу DNS, конечно же DNS сервер не один, и для интернет, совершенно отдельный сервер, с анализом запросов.
Сейчас идет речь о том, что принтеры ставят сами пользователе, прописывают hostname у МФУ и находят их по hostname не зная IP.
Хотелось бы как-то резолвить то, что выдал микротик.
Зачем ?
Нужно на 2 микроте включить dhcp-client и всё.. он подтянет данные с первого микрота и сам для себя еще ip-адрес получит... собственно после этого он станет dhcp+dns relay'ем для тех устройств которые к нему будут подключаться
1 первый микрот тоже должен быть dhcp-client'ом для win сервера на котором служба поднята..
Речь идет о том, что например в филиале 3 или 4 подключаем Притер с именем mfp1.sub.domain.com , он получает по DHCP все настройки, а hostname и ip принтера, микротик должен передать / зарегистрировать в DNS сервере головном, это если так в кратце.
poisons, только с МФУ, но могут быть в другом филиале принтеры этикеток еще. Они там сами себе принтеры ставят, а иногда они перемещаются между друг другом. Можно конечно это всё приколотить статикой и прописать, будет как часы работать))
Формально так сейчас и работает, статические записи в головном DNS и обновление mac по звонку. По этому хотелось это как то автоматизировать.
Что мешает сразу выдавать ip на dhcp в головной локаций? все одно впн между ней и филиалом поднимать. dns на микротике сделать кэширующим от головного + поднять dhcp relay на головную локацию и резервный dhcp с задержкой ответа секунд на 3-6 для того, чтобы если впн ляжет можно было до местных ресурсов достучаться. есть еще вариант: рисовать передачу dns зон из филиала в головную локацию. но микротик отдавать зону не умеет(вроде).
На головной локации свои сети, vlans. По этому DHCP relay тут не удобен, да и канал может лечь когда не нужно. Через IPsec конечно же доступ в корп. сеть есть, политики, ресурсы т.п.
Идея в том, что бы при получении МФУ в филиале IP, его hostname резолвился без проблем.
Примерно как WINS, только он не используется давно)
Так оно так и будет работать :) МФУ получает адрес от центрального dhcp, который выдает адреса из пула, который соответствует адресному пространству релея. центральный dhcp сервер прописывает мфу в днс в центральной локации. при первом обращении к мфу по имени в филиале днс на микротике, не найдя такой записи, посылает запрос на днс центральной локации и отдает его клиенту, при этом кэшируя. далее все определяется временем кэширования. В dhcp также можно играть с временем аренды. При установке времени аренды ~1 сутки кратковременные пропадания vpn не критичны. для длительных пропаданий - локальный сервер dhcp с задержкой отдачи, чтобы в APIPA клиентов не искать, если к ним доступ потребуется.
другой вариант - полноценные dhcp и dns серверы в филиале с отдачей зоны на уровень центральной локации.
beerchaser, разве Windows DHCP серверу не нужно иметь интерфейс в области в той которую он обслуживает?
Я задам на DHCPобласть например 10.0.1.100/24, но в центральном таких сетей да же нет.
Еще на сколько я знаю relay-dhcp должен иметь IP в той же сети, что и DHCP сервер, ну и vlan соотвественно.
Да и DCHP сервер не имеет никакой маршрутизации, этим ведают роутеры.
Как тогда сделать relay появляется задача...
на случай отказа vpn - dhcp сервер с задержкой ответа в филиале (см. коментарий выше). Если релей не вернет ответ, то ответит локальный сервер. причем имеется возможность (теоретически, практически не пробовал) через скрипт организовать выдачу таких же адресов, как и на центральном сервере dhcp.
beerchaser, в подразделении кроме микротика ничего и нет, там и серверов нет. Я обычно адреса на 24 часа выдаю, компьютер в конце смены только выключают и редко перезагружают.
В микротоке есть Netwatch в принципе может и прокатит включать и выключать на нем dhcp при отсутствии связи с dhcp центральным.
Меня только смущает, точно ли dhcp будет выдавать IP релею, если таких IP сетей в принципе не существует в центральном узле.
Получается, я просто создаю scope подразделения, и чудесным образом это сработает?
Там сказано, что если NAT то у вас ничего не выйдет.
зачем вам NAT в vpn? там проще с прямой маршрутизацией. это требование говорит о том, что маршрут от релея до dhcp сервера не должен попадать под правило NAT, что логично, т.к. при этом подменяется исходящий адрес релея, а dhcp сервер адрес выдасть из скоупа адреса релея.
Средний
Простой
