MikroTik не раздает интернет: проверить WAN, NAT и DNS по порядку

Короткий ответ

«Нет интернета» на MikroTik почти никогда не лечится /system reset-configuration. Сначала разделите четыре независимых слоя: есть ли адрес и маршрут на WAN (ether1), есть ли srcnat/masquerade наружу, пускает ли forward трафик из bridge, и отвечает ли DNS. Клиент с адресом 192.168.88.x и шлюзом 192.168.88.1 может «не видеть интернет» из‑за любого из этих слоёв — симптомы с рабочего места одинаковые.

Рабочая последовательность: /interface print → /ip address print → /ip dhcp-client print → /ip route print → /ip firewall nat print → /ip firewall filter print stats → /ip dns print. Чините тот слой, который реально сломан. Не отключайте firewall «навсегда» и не вешайте accept на input с WAN.

Симптомы и как отличить

Типичная жалоба: у ПК есть IP из пула 192.168.88.0/24, шлюз 192.168.88.1, а браузер крутит таймаут. С роутера ping 203.0.113.1 иногда проходит, иногда нет — это уже развилка.

Отличите ещё «интернет есть у одного VLAN и нет у другого» — это уже Bridge VLAN Filtering, а не masquerade на ether1.

Возможные причины

От частых к редким:

1. WAN без адреса или без default route: DHCP-клиент на ether1 не получил аренду, PPPoE не поднялся, шлюз провайдера не пингуется.
2. srcnat смотрит не туда: out-interface=ether1 при живом pppoe-out1, либо правило disabled после правки.
3. Filter forward дропает new с LAN: нет accept из in-interface-list=LAN, либо в конец цепи попал drop раньше accept.
4. Клиентам раздан DNS 192.168.88.1, а /ip dns с allow-remote-requests=no.
5. Два default route с одинаковым distance и «мёртвый» первый провайдер — трафик уходит в чёрную дыру. См. failover.
6. FastTrack + IPsec/WireGuard: часть сессий уезжает в обход политик. Это не «нет интернета у всех», а выборочный сбой.

Диагностика

Плейсхолдеры: WAN ether1 с адресом 203.0.113.10, LAN bridge 192.168.88.1/24. Подставьте свои имена интерфейсов.

1. Кабель, интерфейс, адрес

/interface print
/ip address print
/ip dhcp-client print detail
/ip route print

На ether1 ожидайте R (running). Если no-link — не ходите в NAT. Default route должен смотреть в шлюз провайдера или в pppoe-out1, а не в bridge.

С самого роутера:

/ping 203.0.113.1 count=5
/ping 1.1.1.1 count=5
/ping one.one.one.one count=3

Ping по IP без ping по имени — DNS роутера, не NAT. Оба таймаутят — WAN или маршрут.

2. NAT и filter counters

/ip firewall nat print
/ip firewall filter print stats

У рабочего masquerade растут bytes/packets на правиле chain=srcnat action=masquerade out-interface=ether1 (или out-interface-list=WAN). Нулевые счётчики при живом трафике с LAN — пакеты не доходят до srcnat: их съел filter или нет маршрута.

В filter смотрите chain=forward. Правило drop с ненулевым packets при попытке выхода в интернет — кандидат. Не отключайте его сразу: сначала /ip firewall filter print stats и connection-state, как в статье про firewall.

3. DNS глазами клиента и роутера

/ip dns print
/ip dns cache print
/ip dhcp-server network print

Если сеть DHCP раздаёт dns-server=192.168.88.1, на роутере должно быть allow-remote-requests=yes и непустой servers. Input UDP/53 с WAN при этом должен оставаться закрытым.

4. Снимок до любых правок

/system backup save name=before-wan-diag
/export file=before-wan-diag

Решение

Сценарий A. WAN мёртв

Чините получение адреса, не NAT. Для DHCP на ether1 см. соседнюю статью. Для PPPoE проверьте /interface pppoe-client print и логи pppoe. Адрес LAN 192.168.88.1/24 при этом не трогайте.

Сценарий B. WAN пингуется с роутера, с LAN нет

Верните минимальный srcnat на фактический выход:

/ip firewall nat
print
add chain=srcnat action=masquerade out-interface=ether1 src-address=192.168.88.0/24 comment=lan-out

Если выход — pppoe-out1, out-interface должен быть он, не ether1. Дубли masquerade на оба интерфейса создают хаос при failover — лучше out-interface-list=WAN.

Проверьте, что в forward есть accept из LAN выше общего drop:

/ip firewall filter print where chain=forward

Сценарий C. IP-пинг с LAN есть, браузер нет

Клиенту нужен DNS. Вариант 1: раздавать публичные резолверы в /ip dhcp-server network. Вариант 2: оставить 192.168.88.1 и включить cache:

/ip dns
set allow-remote-requests=yes servers=1.1.1.1,9.9.9.9

На input оставьте UDP/53 только с bridge / in-interface-list=LAN.

Сценарий D. Два провайдера, «интернет моргает»

Не чините masquerade вслепую. Снимите /ip route print detail, distance и check-gateway. Иначе пакеты уходят в down-линк, а NAT выглядит «сломанным».

Как проверить, что проблема устранена

С клиента в 192.168.88.0/24:

• ping 192.168.88.1 — L2/L3 до шлюза;
• ping 1.1.1.1 — транзит и NAT;
• разрешение имени и HTTPS на внешний сайт.

С роутера:

/ip firewall nat print stats
/ip firewall connection print where src-address~"192.168.88."
/ip dns cache print

Счётчики masquerade растут, в conntrack видны src-address=192.168.88.x с srcnat, DNS cache наполняется. Повторите проверку с двух разных ПК, не только с того, «на котором заработало».

Если не помогло

• Есть NAT, нет TCP 443: провайдер режет, либо MTU/MSS на PPPoE. Проверьте /ping 1.1.1.1 size=1472 do-not-fragment.
• Работает traceroute с роутера и не работает с ПК при зелёном NAT: смотрите policy routing и routing marks.
• Интернет есть, VPN-сайты нет: FastTrack ломает VPN.
• Только часть VLAN: bridge VLAN, не default masquerade.

Сброс на default config — последний шаг после backup, не диагностика.

Профилактика

• Interface lists WAN/LAN и NAT/filter по спискам, не по голым ether1 после каждой перестановки патчкорда.
• Мониторинг: наличие адреса на WAN, ping check-gateway, рост counters masquerade в рабочее время.
• Перед апгрейдом RouterOS — backup и export, не «обновим, потом посмотрим NAT».
• Не держите allow-remote-requests=yes без фильтра input на UDP/53 с WAN.

FAQ

Почему с WinBox ping есть, а у бухгалтерии нет?

WinBox пингует с роутера (output). Бухгалтерия идёт через forward. Это разные цепи filter и разный NAT.

Нужно ли выключать FastTrack, чтобы появился интернет?

Нет. FastTrack ускоряет established/related. Если без него интернет появляется только у VPN — чините исключения VPN, а не «убить FastTrack навсегда».

Можно ли поставить action=accept в forward и снять все drop?

Технически да, и это откроет транзит из WAN в LAN. Для «раздать интернет» достаточно accept из LAN и established/related, не дырка на весь forward.

Клиент получил 169.254.x.x — это эта статья?

Нет. Это DHCP, не NAT. Сначала DHCP Server.

Провайдер дал статический 203.0.113.10/30, DHCP-клиент нужен?

Нет. Статический /ip address на ether1 плюс /ip route на шлюз /30. DHCP-клиент на том же интерфейсе будет конфликтовать.