Компьютер не пингует микротик

Обновлено: 05.07.2024

[admin@Mikrotik] > ping server
invalid value for argument address:
invalid value of mac-address, mac address required
invalid value for argument ipv6-address
while resolving ip-address: name does not exist

Но, как же так? Ведь DNS от провайдера получен исправно
[admin@Mikrotik] > ip dns print
dynamic-servers: 55.11.192.5,213.233.199.77
allow-remote-requests: yes
max-udp-packet-size: 4096
query-server-timeout: 2s
query-total-timeout: 10s
max-concurrent-queries: 100
max-concurrent-tcp-sessions: 20
cache-size: 2048KiB
cache-max-ttl: 1w
cache-used: 135KiB

В моём случае проблема оказалась в отсутствии ActiveDirectory и DNS серверов в сети. Поскольку никто не резолвил адреса, то и Mikrotik не знал о существовании этих адресов.

Чтобы хосты пинговались, можно прописать статические маршруты и решить таким образом проблему. Но это хорошо, если у вас в сети 5 или 10 хостов, которые никогда не меняются. Когда же в сети хостов от 40 и более, да, к тому же, многие из них мобильные устройства, которые получают IP адрес по DHCP, то прописывать статику уже не вариант.
Чтобы Mikrotik выступал в роли кеширующего DNS сервера, можно использовать скрипт, который проверяет DHCP пул на Mikrotik, и пропишет статические маршруты.
Вот упрощённый пример такого скрипта, полный вариант можно найти в интернете:
:local ttl;
:set ttl "00:14:29";
:local hostname;
:local hostip;
:local free;
/ip dns static;
:foreach a in=[find] do=:if ([get $a ttl] = $ttl) do=:put ("Removing: " . [get $a name] . " : " . [get $a address]);
remove $a;
>
>
/ip dhcp-server lease ;
:foreach i in=[find] do=/ip dhcp-server lease ;
:if ([:len [get $i host-name]] > 0) do=:set free "true";
:set hostname ([get $i host-name]);
:set hostip [get $i address];
/ip dns static ;
:foreach di in [find] do=:if ([get $di name] = $hostname) do=:set free "false";
:put ("Not adding already existing entry: " . $hostname);
>
>
:if ($free = true) do=:put ("Adding: " . $hostname . " : " . $hostip ) ;
/ip dns static add name=$hostname address=$hostip ttl=$ttl;
>
>
>

Чтобы скрипт запускался с некой периодичностью, необходимо добавить задание, которое будет выполнять скрипт через определённый интервал времени.
Для этого, нужно перейти в раздел "System \ Scheduler", где добавить новое задание.
Name - Имя задания, укажите любое, на своё усмотрение.
Start date - Дата, после которой начнёт выполняться задание.
Start time - Время, во сколько начнёт выполняться задание.
Interval - Промежуток времени, через которое будет повторно (или многократно) выполняться ваше задание.
Очень важное поле тут, это On Event. В это поле вписывается команда, которая будет выполнять скрипт. В это поле нужно вписать строку примерно следующего формата:
/system script run имя_скрипта , где имя_скрипта, это то имя, которое было присвоено ему, при создании.

Ситуация. Сеть на основе Mikrotik. Выбираешь незанятый IP, прописываешь на новом ПК, затем в разделе IP --> DHCP Server --> Networks прописываю адрес с шлюзом и DNS (на всякий случай, если DHCP включу на ПК). Проверяю наличие записи в ARP таблице - имеется с верным MACом и IP. Проверяю интернет и сеть с нового ПК - всё работает. Пингую его с других ПК - пинга нет.
При этом, эта ситуация уже была на других ПК и решалась подбором другого IP. Т.е. проблема вряд-ли в ОС (Windows 10). Да и вообще, она была и на других ПК с другими ОС.
Что может быть недонастроено или где посмотреть ограничения?

P.S. С роутера ПК также не пингуется. С ПК роутер пингуется без проблем.

Вопрос задан более трёх лет назад
6844 просмотра

Оценить 3 комментария

Брандмауэр отключать пробовал - ничего не меняется. ПК в домене. при пинге с роутера укажи src-address=<локальный адрес роутера>

По умолчанию, кажется с Vista, в Windows ping запрещен. Поищите в Интернете как разрешить icmp на Windows машине. Нет, здесь проблема не в ОС. Такая же проблема имеется в XP и прочих устройствах, которым я назначаю этот IP. Стоит назначить другой и проблема уходит. Устройств в сети много и если у меня так с 10-ок IPов вылетит, это не дело.

Верить или нет это ваш выбор. Не факт что пингуете именно то устройство, которое вы думаете что пингуете. Если это нет так, то вы большой мастер на ровном месте создать чудо.

Axian Ltd.: 1. IP свободен и здесь нет никакихконфликтов. Чтобы это понять, достаточно прочесть вот это в шапке: "Проверяю наличие записи в ARP таблице - имеется с верным MACом и IP".
2. При чем здесь "вера"? Я даже синоним его не употреблял.
3. Мне это чудо по наследству досталось. Прошлый админ клянется и божится, что у него такого не было.
Я в большинстве своём специализируюсь по Cisco и с Mikrotik`ами имел очень редкие и ни к чему не обязывающие отношения. Просто логически. Нет пинга. Проверить конфликты, хотя при отсуствии настроенной блокировки пинги бы шли, но с разрывами. Либо шли бы ровно, но не на то устройство. Далее, проверить ARP - имеется и верная. Нужный IP и MAC. Далее, проверить, в наличии ли блокировки на уровне Firewall - отсутсвуют. При этом заведомо известно, что на самом ПК ничего не залочено (проверялось на другом IP - всё работает), а также кабель живой, т.к. забрал я его с другого, работающего устройства. Мало того, просто вынул из одного ПК и вставил в другой, даже не меняя порта в свитче. Да и чего кабель обсуждать, если на самом ПК интернет и внутренние ресурсы доступны.

Проблема, совершенно очевидно, где-то в роутере. Но где, пока что не понятно.

Самая распространенная проблема MikroTik (точнее жалоба) — «у меня ничего не работает», причем чаще всего это неправда. Если у босса не открывается вложение в письме с темой «вы выиграли миллион», потому что его заблокировал антивирус, то настраивать роутер в этот день вряд ли придется.

Поэтому один из важных навыков админа — это умение вести диалог с пользователем и выяснять, что именно и как не работает. Увы, эта статья не будет посвящена данному вопросу, так что переходим сразу к технической части.

Ресурсы

Первое, на что обращает внимание любой системный администратор, — потребление ресурсов. Благо WinBox выводит эти данные прямо в главном окне. А если еще не выводит — сейчас же добавляй их туда. Это сэкономит много времени в будущем. Тебе нужно меню Dashboard → Add. И кстати, зеленый квадратик в правой верхней части — это не загрузка процессора. Не обращай на него внимания.

Resources

Если процессор постоянно загружен больше 80% (в зависимости от условий это значение может меняться, но в среднем давай примем такое число), то что‑то неладно. В первую очередь смотрим на местный «диспетчер задач», меню Tools → Profile. Тут мы увидим, что именно нагружает CPU, и поймем, как действовать дальше.

Длительную статистику по нагрузке CPU, трафику на интерфейсах и другим параметрам можно увидеть в Tools → Graphing.

Profile

Объяснение полей вы найдете в вики. Наиболее часто встречаются DNS, Encrypting и Firewall.

Encrypting — роутер тратит много ресурсов на шифрование. Скорее всего, у вас много туннелей VPN и нет аппаратного чипа шифрования. Нужно поменять на железку со специальным чипом или выбрать более слабые алгоритмы.
Firewall — прямое указание, что вы не читали мои предыдущие статьи.
DNS — а вот тут вас ждет кое‑что интересное.

Сам по себе DNS-сервер почти не нагружает роутер в небольших и средних сетях (до нескольких тысяч хостов). А использовать RouterOS в качестве DNS-сервера в больших сетях не лучшая идея. Так откуда нагрузка? Давай разбираться. Если есть нагрузка, значит что‑то ее создает. Вероятно, серверу DNS приходится отвечать на большое количество запросов. Проверим, так ли это. Создадим в файрволе правило.

add action = accept chain = input dst - port = 53 log = yes log - prefix = DNS protocol = udp

И теперь смотрим в лог. Если наши предположения верны, то заметим много сообщений с префиксом DNS. Увидим, с каких адресов и на какие интерфейсы летят запросы. Скорее всего, это будет интерфейс WAN. Но мы не хотим обрабатывать DNS-запросы, пришедшие к нам из интернета. Закроем UDP-порт 53 на интерфейсе WAN, поместим правило в нужном месте — и наслаждаемся снизившейся нагрузкой. Поздравляю! Мы только что обнаружили, что были частью ботнета, закрыли эту дыру и сделали интернет чуточку чище. Подобные атаки часто проводятся с применением протоколов, работающих над UDP.

Firewall

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

Counters

В столбцах Bytes и Packets отображаются количество байтов и пакетов, обработанных правилом. Кнопки Reset Counters сбрасывают эти счетчики. Теперь можно наблюдать, попадает ли трафик в нужное правило или нет.

Полезной часто оказывается вкладка Connections файрвола. Тут видно все потоки, проходящие через роутер: их состояние, количество прошедших байтов, флаги потока (для получения подсказки достаточно навести на значение в столбце). Для большей наглядности нужно добавить поля Reply Dst. Address и Reply Src. Address. В этих полях видно, в какой и из какого адреса был проведен NAT.

Connections

Файрвол со всеми его фичами позволяет детально дебажить весь трафик, проходящий через роутер. Чтобы лучше понимать, что происходит во всех этих вкладках, нужно изучить, как пакеты проходят через роутер. На картинке упрощенная версия схемы. Более подробная есть в документации.

Traffic Flow

Другие способы анализа трафика

Увидеть состояние потока, его адреса, байты и прочее — хорошо. Но файрвол не позволяет удобно и из единого места убедиться, что маршрутизация корректна. Чтобы узнать, в какой интерфейс вылетает пакет, достаточно воспользоваться инструментом Torch.

Torch

Torch можно воспринимать как некое подобие tcpdump. Здесь можно увидеть VLAN ID, source/destination address/port, DSCP, битовую и пакетную скорость. Есть удобные фильтры, которые позволяют делать точные выборки. Если данные в окне меняются слишком быстро, увеличивай значение Entry Timeout. К сожалению, в одном окне он может показывать только трафик на одном интерфейсе, но никто не мешает нажать New Window и наблюдать за несколькими интерфейсами. Если Torch не показывает нужного трафика на нужном интерфейсе — налицо проблемы с маршрутизацией.

Torch позволяет наблюдать за потоками трафика в реальном времени. Но в некоторых случаях нужны более детальные данные о трафике. Их позволяет получить инструмент IP Sniffer.

IP Sniffer

С его помощью можно увидеть параметры трафика и даже содержимое пакета.

Но иногда требуется более детальный анализ — например, чтобы убедиться, что TCP handshake успешно прошел и данные передаются. В таком случае в передаваемых пакетах должен присутствовать флаг ACK. Но искать пакеты в скудном интерфейсе «Винбокса» неудобно.

И тут на помощь приходит всеми любимый Wireshark — мощнейший инструмент для анализа сетевого трафика. В Filter указываем нужные параметры, чтобы не снифать все подряд, в General выбираем Filename, жмем Apply и Start. Теперь в Files на роутере можно найти наш дамп, перекинуть его на компьютер и открыть «Шарком». О нем написано много статей, поэтому даже не буду пытаться писать тут, как с ним работать.

Но это лишь начало. Можно в реальном времени наблюдать за трафиком из Wireshark. И без всяких операций с файлами! Открываем «Шарк», в фильтре пишем udp. port == 37008 , на сниффере RouterOS во вкладке Streaming ставим галочку Streaming Enabled и вписываем IP-адрес компьютера с запущенным «Шарком». Можно поставить галочку Filter stream, чтобы лить в «Шарк» не весь трафик, а только выбранный.

Snif-stream Shark

Лить трафик в сниффер можно и из файрвола. За это отвечает действие sniff-TZSP в таблице Mangle. Работает это по аналогии со Sniffer Streaming, но в файрволе можно сделать более точную выборку пакетов для сниффера.

Mangle-sniff

Wireless

Самая сложная часть диагностики — это Wi-Fi. Он и сам по себе очень сложная технология, к тому же среда передачи данных общая и все соседские роутеры мешают работать твоему, так же как и он им. О работе 802.11 написана не одна книга, пересказывать их я не буду. Посмотрим только на инструменты, которые могут помочь при диагностике.

В RouterOS их немного. Самый главный — вкладка Registration в Wireless. Здесь видно всю информацию о подключенных клиентах: MAC, уровень сигнала, качество сигнала.

Registration

Самые важные поля:

CCQ — Client Connection Quality. Чем ближе к 100%, тем лучше. Ниже 60% означает плохую связь;
TX/RX Signal Strength — уровень сигнала. Отличное значение — от 0 до –45, приемлемое — от –55 до –75. Все, что между, — хорошо. Ниже –75 можно считать отсутствием связи. По крайней мере, я ориентируюсь на такие цифры.
Signal to Noise — отношение сигнал/шум. Чем выше — тем лучше.

Второй инструмент — логи. Собственно, этот инструмент должен активно использоваться не только при диагностике Wi-Fi. Если стандартных логов недостаточно — просто включи расширенные.

Log

Ping, Traceroute

Первым инструментом диагностики у сисадмина всегда был пинг. Но далеко не все знают, сколько возможностей он в себе скрывает.

Многие сталкивались с тем, что текст на сайте отображается, а картинки нет. Или скрипты не загрузились, и сайт «поехал». Это первые признаки несогласованности MTU. С помощью пинга можно проверить этот вариант. Ставим галочку Don’t fragment, выставляем нужный нам размер пакета и смотрим на результат. Если видим packet too large — MTU в канале ниже заданного нами значения пакета. Уменьшаем его и проверяем снова. Таким образом выявляем максимальный пакет, который проходит через сеть без фрагментации.

Ping

По умолчанию пакет отправляется с роутера с src address того интерфейса, в который он вылетает. Бывает, что нужно его поменять. Например, при диагностике маршрутизации внутри VPN или корректности работы файрвола. Для этого нужно заполнить поле src address. Не забывай, что адрес должен быть существующим, чтобы ответный пакет вернулся.

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

Заключение

Невозможно в одной статье и даже в нескольких книгах описать все возможные проблемы и методы их диагностики и решения. Для эффективного дебага нужно понимать, как работает сеть на каждом уровне, ее особенности в конкретной реализации — ведь не бывает двух одинаковых сетей: рецепты, работающие в одной инфраструктуре, будут бесполезными для другой.

Для дебага необходимо понимать, как пакет проходит внутри RouterOS, а в особо сложных случаях — и знать особенности вендора. И это относится не только к MikroTik. Лучший инструмент дебага — знания и опыт!

Микротик не отвечает на пинги через WAN, mangle настроен, интернет есть. Что может быть не так?

Если вы ищете руководство по настройке dual-wan failover на микротике, то среди задач вы будете решать, как сделать, чтобы при пинге через ISP1 микротик направлял бы ответ через шлюз GW1, а при пинге через ISP2 - соответственно, через GW2.

Штука в том, что даже если все правильно настроено, и NAT работает, и локальные клиенты в сеть ходят, и firewall вроде разрешает пинг снаружи, а снаружи к микротику не обратиться. Не пингуется и все тут.

Освоить MikroTik Вы можете с помощью онлайн-куса «Настройка оборудования MikroTik». Курс основан на официальной программе MTCNA. Автор курса – официальный тренер MikroTik. Подходит и тем, кто уже давно работает с микротиками, и тем, кто еще их не держал в руках. В курс входит 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.

Вы наверняка видели что-то вроде:

/ip firewall mangle
add chain=input action=mark-connection new-connection-mark=ISP1->Input passthrough=no dst-address=IP1 in-interface=ether1
add chain=output action=mark-routing new-routing-mark=ISP1 passthrough=no connection-mark=ISP1->Input
add chain=input action=mark-connection new-connection-mark=ISP2->Input passthrough=no dst-address=IP2 in-interface=ether2
add chain=output action=mark-routing new-routing-mark=ISP2 passthrough=no connection-mark=ISP2->Input

Т.е.:
1) если пришел пакет со стороны провайдера ISP1 (через интерфейс ether1) с конечным адресом нашего микротика IP1 (т.е. в input), то пометить это соединение меткой "ISP1->Input".
2) исходящий трафик, связанный с установленным ранее соединеним, помеченным меткой "ISP1->Input", маршрутизировать по правилам таблицы ISP1.

Аналогично для входящих пакетов со стороны провайдера ISP2.

И все бы хорошо, если у вас есть маршрут по-умолчанию без указания таблицы маршрутизации.

Но у вас могут быть только такие дефолтные машруты (до 0.0.0.0/0):

/ip route
add distance=1 gateway=GW1 routing-mark=ISP1
add distance=1 gateway=GW2 routing-mark=ISP2

и ни одного маршрута по-умолчанию без указания routing-mark. Т.е. основная таблица маршрутизации пустая.

При пинге IP1 снаружи через ISP1 (input) из примера выше входящий пакет будет принят, промаркируется соединение (new-connection-mark=ISP1->Input). А вот ответ (output) никуда не уйдет, т.к. ответный пакет не попадет в output. Вообще. И промаркирован он не будет. И микротик не отправит его никуда.

Решить проблему можно по-разному.

1. prerouting вместо output

2. добавить маршруты по-умолчанию без указания таблиц маршрутизации

Например, как-то так:

/ip route
add distance=1 gateway=GW1 distance=10
add distance=1 gateway=GW2 distance=10

Или даже просто один из них:

/ip route add distance=1 gateway=GW1 distance=10

Не важно, будет этот маршрут доступен или нет, осноная таблица маршрутизации не будет пустой и микротик начнет искать замену этому маршруту. А если в основной таблице пусто - то и микротик делать ничего не будет и дело не дойдет до момента маркировки пакета в mangle -> output.

Читайте также: