Выбор внутреннего IP-адреса источника DNS в Mikrotik (Закрыто)

У меня точно такая же проблема. OSPF добавляет маршрут по умолчанию, но подсети, используемые для OSPF-связи между роутерами, не маршрутизируются и добавлены в NAT (особенность сетевого дизайна). Мне также нужно использовать конкретный исходный IP для DNS-подключений или, что еще лучше, для трафика, который генерирует сам роутер (DNS-запросы, обновления Mikrotik, NTP и так далее).

Извини, я не совсем понял, что ты имеешь в виду. Любая служба, которая слушает запросы, должна отвечать на тот IP, с которого пришел запрос. Так что, что ты хотел сказать? Забей на путь — серверам всё равно, какой он, главное, чтобы они могли ответить. Проблема в дизайне маршрутизации, а не в самом сервере. Будь то IP, слушающий на физическом интерфейсе, или на loopback, или где угодно — пока клиент запрашивает правильный IP сервиса, сервер ответит.

Предположим, что твоя mgmt VLAN 11 — это частный блок 11.0/24, и на маршрутизаторе MT router4 в DNS настроено несколько IP. Тогда клиент в сети mgmt должен получить ближайший IP DNS для конкретной mgmt VLAN 11.100/24, чтобы ответ прошел через mgmt VLAN. И DNS ответит с IP 11.100, а не с каким-то другим, иначе клиент отбросит ответ.

IX BGP — это совсем другая тема. Разделение маршрутов, полный IP-маршрутизатор против натированных IP и так далее.

Ты говорил о MT как о клиентах NTP/DNS, но не знаешь, какой IP они будут использовать для доступа к этим серверам. Потому что ни клиенты, ни серверы не задуманы об этом. Главное — чтобы они могли достучаться до серверов, и их задача выполнена. Это касается и серверов тоже. (Можешь привести любой другой клиент-серверный протокол — суть будет та же.) Забудь про маршруты.

Хорошо, давай вернёмся к основам. Инженеры придумали динамические протоколы маршрутизации не просто так, одна из причин — упростить администрирование маршрутов. Тебе не захочется забивать статические маршруты на сервере, и это нормально. Концепция VLAN для управления — именно чтобы упростить тебе работу. Размести DNS и NTP серверы в этом VLAN — и всё, задача решена. Забудь, какой IP будут использовать клиенты, они сами выберут тот, с которого смогут достучаться до серверов. Если клиенты увидят, что VLAN для управления может легко достучаться до серверов, они будут использовать IP из этого VLAN.

Динамическая маршрутизация сделала всё ещё проще. Тебе не нужно волноваться о том, что запрос и ответ пойдут асимметрично. Главное, чтобы обмен работал — и задача выполнена.

Окей. Ты смотришь на таблицу маршрутизации и шлюз по умолчанию, чтобы добраться до 1.1 или 8.8 — базовая концепция маршрутизации: если это не локально, то маршрутизируй. Теперь — как можно винить роутер за то, что он использует 10.1 в качестве шлюза для доступа к 8.8? Будет ли он использовать 10.1, если его подсеть была бы публичным блоком? Что-то, сделанное с опциями source, — это дополнение, а не повод выбрасывать работающую основу. Я не говорю тебе делать NAT — просто посмотри на таблицу маршрутизации и шлюз по умолчанию.

У меня всё работает отлично. Для ping (без src-address), dns — для всех. Исходящий адрес выбирается согласно поиску в FIB. Значение pref-src по умолчанию выбирается вместо рекурсивного локального (как и должно быть).

Дело не в простоте. В вашем случае есть два маршрута: 10.66.66.0.30 on-link local-address=10.66.66.1 0.0.0.0/0 через 10.66.66.2 pref-src=2.3.4.5. При отправке запроса на 8.8.8.8 исходящий адрес будет 2.3.4.5. Если вы не указываете pref-src, то, конечно, по умолчанию будет использоваться 10.66.66.1. Что у вас задано в pref-src? Он игнорируется? Например, в моём тестовом сценарии в логах указано: in:(unknown 0) out:, connection-state:new proto ICMP (type 8, code 0), 2.3.4.5->8.8.8.8, len 56 (пинг был зафиксирован, но исходящий адрес не указан, и нет, я не “владею” 2.3.4.5).

Почему бы и нет?

Я правда не пытаюсь спорить. Возможно, в твоём случае это как-то невозможно. А у меня, по крайней мере, установка pref-src A.B.C.D; accept; сработала отлично.