hint000

домен переправляет пакет

Эта фраза столь же осмысленна, как "мясорубка предсказывает будущее".
Домен не может ничего переправлять. Домен - это абстракция, а не физическая сущность.

Устройство обращается к домену

Устройство не может обращаться к домену. Устройство обращается к DNS, чтобы резолвить доменное имя в IP-адрес. Затем устройство обращается к хосту по IP-адресу.

DNS может отдавать несколько IP-адресов по схеме round robin, т.е. циклически из пула. В случае недоступности хоста это будет плохой вариант, т.к. DNS не отслеживает доступность и часть клиентов будет всё время стучаться на недоступный хост (они закешируют ответ DNS).
Вариант номер раз: DNS отдаёт клиенту сразу весь пул, клиент сам выбирает адрес из пула, в случае недоступности клиент сам же выбирает другой адрес.
Вариант номер два: кто-то (программа) отслеживает доступность хостов и динамически обновляет пул в DNS.
Вариант номер три: найти хостинг, гарантирующий обещающий высокий уровень доступности; если один раз за три года оно таки стало недоступно, то можно и руками поправить DNS (лишь бы уведомление о недоступности было).

Попробуйте в Windows вручную прописать DNS (ip-адрес пусть получает по DHCP, только DNS вручную): 8.8.8.8 или лучше 1.1.1.1.

ip firewall filter export
Вангую, что там 1812/udp и 1813/udp могут быть не разрешены.

Это вообще разные категории. Может быть одновременно PON, WDM, и FTTH.
Это как: пить кофе или водку (PON или другое),
пить в ресторане или в парке (FTTH или что-то ещё),
пить из кружки или из одноразового стаканчика (WDM или два волокна).

FTTH - это о том, до какого места доходит оптика (до дома).
WDM - это о том, что для приёма и передачи используется одно волокно, а не два отдельных.
PON - это о том, что провайдер не использует активное оборудование в подъезде дома (не надо перезагружать при зависаниях, не надо платить за электричество, не надо менять при выгорании портов, но есть и минусы).

Если бы там был адрес реального клиента, то nginx и ответ отправил бы реальному клиенту.
Ситуация: 192.168.1.100 отправляет запрос на 192.168.1.2, а получает ответ от 192.168.1.3, от которого он ничего не ждёт. Клиент не знает, что ему делать с неожиданным ответом неизвестно от кого, и выбрасывает ответ в мусор. В итоге ничего не работает. Вот чтобы такого не происходило, оно и работает так, как вы наблюдаете. Типа прокси.

Когда-то это могло быть загадкой Сфинкса, но с технологиями последних десяти лет решается на раз-два.
Хром запускайте в виртуальной машине. Для виртуальной машины назначьте адрес статически (не через DHCP) и статически же укажите шлюзом другой роутер (предполагается, что оба роутера в одной LAN).

Обход блокировки раздачи мобильным оператором практиковали? Имею в виду шаманство с TTL.

Писать скрипт, который будет запускаться по cron'у, проверять доступность и перенастраивать маршрут.
Само собой (без скрипта) будет работать при двух условиях:
1) каждый шлюз подключен через свой интерфейс;
2) должен физически падать линк на одном из интерфейсов, тогда маршрут пойдёт через другой, в соответствии с метрикой; если нет пинга, но есть линк - хоть ты тресни, будет долбиться по минимальной метрике. Согласен, что это довольно тупо для 2020 года, но как есть.

P.S. ну или всякие протоколы динамической маршрутизации использовать, это отдельный разговор.

Вот в этой теме Почему я вижу кучу других сетей за пределами моего завода, более того моей страны? было про левый DHCP. Там я писал в комментариях алгоритм поиска при условии, что свитчи неуправляемые (с управляемыми всё гораздо проще). Вот он:

Исходим из того, что есть левый DHCP-сервер.
Также исходим из того, что настоящим DHCP-сервером является ваш роутер Микротик (или это не так?)
Сколько у вас свитчей на заводе? Пусть десять-двадцать, если это мелкие 8-портовые свитчи.
Ноутбук в хозяйстве найдётся? С ним просто намного меньше бегать придётся, чем без него.
Идёте с ноутом к первому свитчу (любому на выбор).
1. определяете, какой из кабелей в свитче является ап-линком, т.е. идёт в сторону вашего главного роутера. Если через несколько промежуточных свитчей идёт к роутеру - неважно, всё равно - это up-link. Надеюсь, не надо подробно рассказывать, как определить? :) Помечаете этот кабель изолентой (если он ещё не был помечен).
2. выдёргиваете из свитча ап-линк и цепляете к свитчу ноутбук. На ноутбуке смотрите одно из двух: либо левый DHCP выдаст адрес, либо ноут подождёт-подождёт, не увидит DHCP и сам себе выберет адрес 169.254.*.* От правильного DHCP не может быть ответа, т.к. ап-линк выдернут.
Лучше конечно, чтобы сейчас попался левый DHCP. Если не попался, то втыкаем ап-линк на место и идём к любому другому свитчу. За одну-две минуты без интернета пользователи (которые висят на этом свитче) сильно не обломаются. Знаем мы все эти заводы, работали, :) главное, чтобы директору не отрубить интернет, а все остальные потерпят, если недолго. :) Хотя можно и согласовать заранее, как выше советовали. Только в этом случае вы же не выключаете все компы, а просто делаете кратковременные перебои с интернетом - сущие пустяки, пф-ф-ф...
3. дошли до N-го свитча, повторили всё, и поймали ответ левого DHCP. Ура! Выдёргиваем все-все кабели из свитча (и ноут тоже), вставляем один кабель (не ап-линк!) и вставляем ноут. Ловим DHCP. нет? выдёргиваем ноут, добавляем один кабель в свитч (не ап-линк!) Ловим DHCP. и т.д. Поймали? помечаем как-то последний кабель (изолентой другого цвета, и назовём это условно "злым" кабелем). Ура! Уже большой прогресс: знаем, что левый DHCP где-то на этом кабеле (если мы не ошиблись, лучше сразу ещё раз проверить).
4. дальше по обстановке: есть возможность тупо идти вдоль этого кабеля и дойти до следующего свитча? Отлично! Идём и там всё повторяем с пункта 3.
5. Нет возможности проследить по кабелю, например, пучок кабелей уходит в стену или в потолок. Тогда выдёргиваем из свитча "злой кабель" и ходим по заводу - ищем комнату с компами, на которых пропал интернет, или сразу свитч, на котором не горит индикатор на ап-линке. Нашли такой свитч? Проверяем: втыкаем "злой кабель", возвращаемся к найденному свитчу. Появился ап-линк? значит не ошиблись. Повторяем на этом свитче пункт 3.
6. Если запутались и сил нет дальше искать, то оставляем выдернутым последний (только последний!) найденный "злой кабель". Раз непонятно, куда он идёт, то сидим ждём, кто из пользователей начнёт жаловаться на отсутствие интернета. Как пожалуются - идём туда и ищем свитч. А если никто не пожалуется, то и хрен с ним. Источник проблем мы ведь изолировали от локальной сети, может позже выяснится, кто это.

Всё! конец алгоритма поиска! В итоге должны прийти к устройству с левым DHCP.

Тут https://m.habr.com/ru/company/nag/blog/411605/ понравилось одно решение для open space:

Можно на форумах потусоваться: https://forum.nag.ru/index.php?/forum/66-montazh-t...

Бродкаст (а лучше по-русски: широковещательный) домен на уровне L3 (хотя и L2 тоже - для ARP-запросов).
Коллизионный домен на уровне L1, и он утратил актуальность с тех пор, как хабы были вытеснены свитчами.