Многохостинговая конфигурация и источник адреса исходящих ICMP-сообщений…

Старая тема, та же проблема, нет решения? Я собирался попробовать изменить адрес источника маршрута в таблице маршрутизации, думаю, должно сработать, учитывая, что это Linux kernel! Кажется, работает – пинги с этой машины раньше не работали, а теперь работают. Буду надеяться, что сообщения ICMP unreachable и прочие формируются так же! Я просто установил адрес источника на адрес loopback.

Настройка исходного адреса для TCP/IP пакетов, сгенерированных локально.

По умолчанию, исходный адрес, включенный в пакеты Transmission Control Protocol/IP (TCP/IP), сгенерированные локально, такие как трафик FTP, и в пакеты User Datagram Protocol (UDP) и IP, такие как запросы Network Time Protocol (NTP), выбирается как локальный адрес для интерфейса, на котором передается трафик. Это означает, что локальный адрес, выбранный для пакетов для определенного назначения, может меняться от соединения к соединению в зависимости от интерфейса, который протокол маршрутизации выбрал для достижения назначения при установлении соединения. Если для назначения присутствует несколько маршрутов с одинаковой стоимостью, локально сгенерированные пакеты используют адрес lo0.

Чтобы настроить программное обеспечение для выбора фиксированного адреса для использования в качестве источника для локально сгенерированных IP-пакетов, включите оператор default-address-selection в иерархическом уровне [edit system]:

[edit system]
default-address-selection;

Если вы включите оператор default-address-selection в конфигурации, программное обеспечение выбирает системный адрес по умолчанию в качестве источника для большинства локально сгенерированных IP-пакетов. Адрес по умолчанию обычно является адресом, настроенным на интерфейсе обратной связи lo0. Например, если вы указали, что SSH и Telnet используют определенный адрес, но вы также настроили выбор адреса по умолчанию, используется системный адрес по умолчанию. Для получения дополнительной информации о том, как выбирается адрес по умолчанию, обратитесь к руководству по настройке сетевых интерфейсов JUNOS.

Для IP-пакетов, отправляемых протоколами IP-маршрутизации – включая Open Shortest Path First (OSPF), Routing Information Protocol (RIP), Resource Reservation Protocol (RSVP) и многоадресные протоколы, но не включая Intermediate System-to-Intermediate System (IS-IS) – выбор локального адреса часто ограничен спецификацией протокола, чтобы протокол работал правильно. Когда это ограничение существует в протоколе маршрутизации, исходный адрес пакета не затронут наличием оператора default-address-selection в конфигурации. Для протоколов, в которых локальный адрес не ограничен спецификацией протокола, например, для внутренних Border Gateway Protocol (IBGP) и многохоп внешнего BGP (EBGP), если вы не настраиваете определенный локальный адрес при настройке протокола, локальный адрес выбирается тем же методом, что и для других локально сгенерированных IP-пакетов.

Это не настоящее решение из-за лишних накладных расходов. Зачем отмечать пакеты и настраивать правила для чего-то, что работает "из коробки" на любом другом конкурирующем устройстве? Это ошибка, а не фича.

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

В мире Cisco, если у вас, скажем, ISP A на 192.168.1.1 и ISP B на 10.5.5.5, а ещё какая-то сеть на 2.2.2.2, например:
`int gi0/0 ip address 192.168.1.1/30`
`int gi1/0 ip address 10.5.5.5/30`
`int gi2/0 ip address 2.2.2.2/30`
... Теперь у вас такая же настройка ISP, как у BGP neighbor и т.д. Если вы делаете traceroute до 2.2.2.2 и трафик проходит через ISP A, то перед тем, как достигнуть конечного пункта назначения, вы увидите 192.168.1.1/30 – потому что ответ ICMP приходит с того интерфейса, через который вошёл пакет. Проблема с Mikrotik в том, что если у вас другой шлюз (/ip route), основанный на BGP, или дефолт, или каком-нибудь другом протоколе, то Mikrotik отправит ответ ICMP через этот шлюз. Получается странная ситуация, когда traceroute идёт через ISP A, а потом, перед конечным пунктом назначения 2.2.2.2, Mikrotik возвращает дополнительный "хоп", показывающий ISP B, 5.5.5.5. Я считаю это багом. В Cisco, Juniper или где угодно ещё вам пришлось бы явно настраивать правила для отправки ответов ICMP с другого физического интерфейса – например, ISP B, если он появился первым через интерфейс ISP A. Никаких loopback или чего-то подобного не нужно – это базовый принцип, который не учитывается в Mikrotik. Когда у вас несколько ISP и несколько маршрутов или шлюзов, основанных на протоколе, например BGP, где наилучший путь или шлюз может динамически меняться, Mikrotik отправляет ICMP до конечного пункта назначения, как будто случайным образом из того, что видит как "шлюз" в своей таблице маршрутизации. Это приводит к головной боли для конечных пользователей и проблемам с отладкой в окружении с несколькими подключениями, где возникает вопрос, почему вы видите шлюз ISP B после того, как трафик прошёл через ISP A. Очевидно, я здесь немного "перефразирую", это просто напечатанный пример, но его легко воспроизвести. Если у меня будет время, я это сделаю.

Кстати, можно использовать инструменты RouterOS, чтобы заставлять все входящие соединения выходить по тому же маршруту, по которому они пришли. Policy routing для IPv4. Только один сервис, насколько я знаю, работает так, как описал mspeed – SNMP. Ты получаешь ответы через интерфейс UDP, с которого пришел запрос. Остальные корректно используют маршрутизацию для определения исходящего интерфейса.