Содержание
- Mikrotik current operator error
- Re: LTE operator problem?
- Re: LTE operator problem?
- Re: LTE operator problem?
- Re: LTE operator problem?
- Re: LTE operator problem?
- Re: LTE operator problem?
- Re: LTE operator problem?
- Re: LTE operator problem?
- Re: LTE operator problem?
- Re: LTE operator problem?
- Re: LTE operator problem?
- Распространенные проблемы MikroTik
- Распространенные проблемы MikroTik
- Ресурсы
- Firewall
- Другие способы анализа трафика
- Wireless
- Ping, Traceroute
- Заключение
Mikrotik current operator error
Sun Feb 21, 2021 3:15 am
Goodnight! I require your help as soon as possible
It turns out that I have problems with the LTE band, the parameters are perfect, the internet is going very well, even from one moment to another it changes the name of the mobile operator for a series of numbers and after this the internet starts to fail and it doesn’t even give me nor 1mb of download speed .
It seems strange to me because the connection parameters do not change (according to the tab), but the moment I observe that the name of the operator is changed by a series of numbers, the internet becomes terrible
I have a router: LHG LTE6 kit (ROW)
PD: I want to highlight that I have made the firmware change to the latest version and the problem continues
Re: LTE operator problem?
Wed Feb 24, 2021 9:51 pm
150 RouterBoards in EMEA
Knowledge Base about LTE by SiB | Buy me a caffe | Telegram : http://t.me/SiB_PL
Re: LTE operator problem?
Thu Feb 25, 2021 10:25 am
I have the latest version for a few weeks, but this did not solve anything!
Also, I have noticed an incredible loss of speed even though I do a band blocking, the speed decreases from one moment to another and I have to restart the modem from the system to have a high download speed! How can i fix this?
Re: LTE operator problem?
Fri Feb 26, 2021 9:12 am
I have tried band blocking and it works for a few hours but then the problem returns . I have also used some guides to «improve» this situation with the script
/interface lte at-chat lte1 input=»AT*Cell=2,3,,37900,118″
Although in the console I have specified which cell to use, in the «Cellular» tab a different one appears
I have also tried some answers in other posts, and they have not served me at all =/
PD: What I have been able to notice is the change in the frequencies of the signal . there is a change in cells and the EARFCN is reversed, that is, they are exchanged, if before the EARFCN 38100 used cell # 118, from one moment to another the EARFCN moves to cell # 127
this is an antenna software problem??
Re: LTE operator problem?
Fri Feb 26, 2021 4:23 pm
This is strange and looks as some bug.
In my Poland networks I can connect only to that cell what I define in Cell Lock.
You discover in Cell Monitor that cells what are detected via direction & signals and. that bands what are active at lte module but they can be only 2 at ones. Means, CellMonitor is suitable when you use one band. I do in my scripts action like «set band=1,2; cell-comonitor lte1;» and after that change bands to next one like «set band=3,7; cell-comonitor lte1;» and at every 2bands I scan air.
150 RouterBoards in EMEA
Knowledge Base about LTE by SiB | Buy me a caffe | Telegram : http://t.me/SiB_PL
Re: LTE operator problem?
Fri Feb 26, 2021 11:46 pm
This is strange and looks as some bug.
In my Poland networks I can connect only to that cell what I define in Cell Lock.
You discover in Cell Monitor that cells what are detected via direction & signals and. that bands what are active at lte module but they can be only 2 at ones. Means, CellMonitor is suitable when you use one band. I do in my scripts action like «set band=1,2; cell-comonitor lte1;» and after that change bands to next one like «set band=3,7; cell-comonitor lte1;» and at every 2bands I scan air.
This is what I can see in the lte log with the bands locked to only one (using the command /interface lte at-chat lte1 input=»AT*Cell=2,3,,37900,118″)
Another problem I have with the winbox is that I have never been able to download the .log file correctly, whenever I want to see the log on my desktop to be able to see it with the notes blog, the file does not have any content written inside (it is in White)
I understand that having control of the blocked bands I can only connect to that band and that is what I want, since a single frequency in a certain physical cell is the one that gives me the desired speed, but that cell changes from one moment to another from EARFCN and it leaves me without internet or it puts me in a terrible state where I can not even download at 100kbs, although it is the same antenna, since it comes from the same physical cell and has the same RSRQ and SINR parameters, so I have to disable the band lock command (cell + EARFCN) and then reactivate it but with the new EARFCN .
PD: I’m going to disable the lock command and in a few hours I’ll be back with the .log results.
Re: LTE operator problem?
Sat Feb 27, 2021 9:23 pm
I have deactivated the band blocking and this was the result during the connection, although it seems it was made to the same cell that I made the blocking, so I don’t think that there is a different reference in the log
what if it has happened is the same as always, when restarting the connection the internet returns to a high speed, I have been using your script to cancel the inactivity and apparently this has not served at all
and now as you can see in the image below you will notice that the EARFCN of cell # 118 has been changed (which is the one I use for cell lock), this is a constant problem that got me sick
Before (Yesterday)
Later (Today)
Is this really possible? that an internet provider company can rotate the frequencies and cells?
Re: LTE operator problem?
Tue Mar 02, 2021 6:46 am
I am very tired of having to restart the mikrotik from time to time to get my internet speed back to high, otherwise it is limited to a download speed of no more than 50kbs and restarting it is the only thing that «solves» the problem but it’s only for a short period of time, then I have to restart the mikrotik again . I’m really giving up and now I’m feeling like the mikrotik antennas are useless
Re: LTE operator problem?
Tue Mar 02, 2021 9:54 pm
Unfortunately it’s hard to judge whether it is a single-piece hardware fault of your LTE modem or a firmware bug. The fact that the operator name changes into a 6-digit number means something is terribly wrong, because the number would have to be a 5-digit one if it was just a minor issue of not translating the MNC (in the ccc-oo format where ccc is country code and oo is operator (network) code) into a network name properly. Also the fact that the mapping between frequency and sector ID changes indicates a problem with RAM or with software.
So I’d definitely recommend to raise a warranty claim with whoever has sold the LHG-R to you. What you experience is not normal.
Re: LTE operator problem?
Tue Mar 02, 2021 10:37 pm
@sindy: There’s nothing going ‘terribly wrong’, it’s just a translation error. Some countries use a 3-digit MNC (mobile network code) and MCC-MNC 732-716 matches DirecTV Colombia.
@JotaOS: What is happening with the changing EARFCN is weird. An EARFCN of 38100 indicates a center frequency of 2605MHz (2.605GHz). An EARFCN of 37900 indicates a center frequency of 2585MHz (2.585GHz). In most countries, government allows a telecom operator to acquire a license for a specific frequency for a duration of 5-10 years. This frequency definitely should not change every 10 minutes.
Re: LTE operator problem?
Wed Mar 03, 2021 7:47 am
Unfortunately it’s hard to judge whether it is a single-piece hardware fault of your LTE modem or a firmware bug. The fact that the operator name changes into a 6-digit number means something is terribly wrong, because the number would have to be a 5-digit one if it was just a minor issue of not translating the MNC (in the ccc-oo format where ccc is country code and oo is operator (network) code) into a network name properly. Also the fact that the mapping between frequency and sector ID changes indicates a problem with RAM or with software.
So I’d definitely recommend to raise a warranty claim with whoever has sold the LHG-R to you. What you experience is not normal.
How can I know the health of my lte antenna? because the command / system health print or / system health set (they do not work for my LHG LTE6 kit-MIPSBE)
Although I have started to notice since I update the firmware of the equipment that my router restarts every few hours (more or less every 11 hours), but the problem of the decrease in my internet speed has always been the same, from the first day who applied my sim card, tried with infinite script to maintain a false activity in my router but nothing, also tried to update the 3 types of firmware (lte, OS, winbox) possible from mikrotik and they did not serve me at all!
Re: LTE operator problem?
Wed Mar 03, 2021 10:24 am
This command only reports temperature, power supply voltage etc. on higher grade models, which support measurement of these values in hardware. It says nothing about hardware failures (like memory issues) even on those models.
So what do the following commands output currently?
/system resource print
/system routerboard print
/system check-installation
/interface lte firmware-upgrade [find] upgrade=no
The LTE modem is a plugin module and is quite autonomous; RouterOS retrieves the values displayed using /interface lte info from it using AT commands. So also the translation of the MCC+MNC value to text is done by the LTE modem itself:
[me@myTik] > /interface lte at-chat [find] input=»AT+COPS?»
output: +COPS: (0,0,»operator-name»,7,0),(0,0,»operator-name»,7,0)
Hence it is most likely that the issue is in the modem module itself; whether it is a manufacturing fault (hardware issue of that single piece) or a software one is hard to say and it cannot be determined having just a single device to test with.
The hardware design of the Routerboard allows to script a brutal workaround of your issue: whenever it appears (which in your case seems to be indicated by the change of the current-operator value from to DIRECTVCO to 732716), you can power-cycle the LTE modem. I have to do this with various types of non-Mikrotik 3G and LTE modems that hang occasionally and no firmware upgrade can be expected for them.
The command is /system routerboard usb power-reset bus= N duration=10s. You have to find the correct N value by trying, I couldn’t find how to determine the bus number using any information provided by RouterOS, and it depends on the RB model and PCIe slot where the modem is located.
So the script would look something like
You would schedule this script to run every minute. But as said, it is a workaround, not a solution.
Источник
Распространенные проблемы MikroTik
Распространенные проблемы MikroTik
Самая распространенная проблема MikroTik (точнее жалоба) — «у меня ничего не работает», причем чаще всего это неправда. Если у босса не открывается вложение в письме с темой «вы выиграли миллион», потому что его заблокировал антивирус, то настраивать роутер в этот день вряд ли придется.
Поэтому один из важных навыков админа — это умение вести диалог с пользователем и выяснять, что именно и как не работает. Увы, эта статья не будет посвящена данному вопросу, так что переходим сразу к технической части.
Ресурсы
Первое, на что обращает внимание любой системный администратор, — потребление ресурсов. Благо WinBox выводит эти данные прямо в главном окне. А если еще не выводит — сейчас же добавляй их туда. Это сэкономит много времени в будущем. Тебе нужно меню Dashboard → Add. И кстати, зеленый квадратик в правой верхней части — это не загрузка процессора. Не обращай на него внимания.
Если процессор постоянно загружен больше 80% (в зависимости от условий это значение может меняться, но в среднем давай примем такое число), то что‑то неладно. В первую очередь смотрим на местный «диспетчер задач», меню Tools → Profile. Тут мы увидим, что именно нагружает CPU, и поймем, как действовать дальше.
Длительную статистику по нагрузке CPU, трафику на интерфейсах и другим параметрам можно увидеть в Tools → Graphing.
Объяснение полей вы найдете в вики. Наиболее часто встречаются DNS, Encrypting и Firewall.
- Encrypting — роутер тратит много ресурсов на шифрование. Скорее всего, у вас много туннелей VPN и нет аппаратного чипа шифрования. Нужно поменять на железку со специальным чипом или выбрать более слабые алгоритмы.
- Firewall — прямое указание, что вы не читали мои предыдущие статьи.
- DNS — а вот тут вас ждет кое‑что интересное.
Сам по себе DNS-сервер почти не нагружает роутер в небольших и средних сетях (до нескольких тысяч хостов). А использовать RouterOS в качестве DNS-сервера в больших сетях не лучшая идея. Так откуда нагрузка? Давай разбираться. Если есть нагрузка, значит что‑то ее создает. Вероятно, серверу DNS приходится отвечать на большое количество запросов. Проверим, так ли это. Создадим в файрволе правило.
И теперь смотрим в лог. Если наши предположения верны, то заметим много сообщений с префиксом 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.
С его помощью можно увидеть параметры трафика и даже содержимое пакета.
Но иногда требуется более детальный анализ — например, чтобы убедиться, что TCP handshake успешно прошел и данные передаются. В таком случае в передаваемых пакетах должен присутствовать флаг ACK. Но искать пакеты в скудном интерфейсе «Винбокса» неудобно.
И тут на помощь приходит всеми любимый Wireshark — мощнейший инструмент для анализа сетевого трафика. В Filter указываем нужные параметры, чтобы не снифать все подряд, в General выбираем Filename, жмем Apply и Start. Теперь в Files на роутере можно найти наш дамп, перекинуть его на компьютер и открыть «Шарком». О нем написано много статей, поэтому даже не буду пытаться писать тут, как с ним работать.
Но это лишь начало. Можно в реальном времени наблюдать за трафиком из Wireshark. И без всяких операций с файлами! Открываем «Шарк», в фильтре пишем udp . wbr / > port wbr / > == wbr / > 37008 , на сниффере RouterOS во вкладке Streaming ставим галочку Streaming wbr / > 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 wbr / > too wbr / > large — MTU в канале ниже заданного нами значения пакета. Уменьшаем его и проверяем снова. Таким образом выявляем максимальный пакет, который проходит через сеть без фрагментации.
Ping
По умолчанию пакет отправляется с роутера с src address того интерфейса, в который он вылетает. Бывает, что нужно его поменять. Например, при диагностике маршрутизации внутри VPN или корректности работы файрвола. Для этого нужно заполнить поле src address. Не забывай, что адрес должен быть существующим, чтобы ответный пакет вернулся.
При сложной маршрутизации необходимо выбрать нужную Routing Table. Впрочем, те, кто пользуется несколькими таблицами маршрутизации, и так это знают.
Заключение
Невозможно в одной статье и даже в нескольких книгах описать все возможные проблемы и методы их диагностики и решения. Для эффективного дебага нужно понимать, как работает сеть на каждом уровне, ее особенности в конкретной реализации — ведь не бывает двух одинаковых сетей: рецепты, работающие в одной инфраструктуре, будут бесполезными для другой.
Для дебага необходимо понимать, как пакет проходит внутри RouterOS, а в особо сложных случаях — и знать особенности вендора. И это относится не только к MikroTik. Лучший инструмент дебага — знания и опыт!
Источник
Хорошо настроить роутер — важное дело, но иногда этого бывает недостаточно и приходится решать проблемы уже во время эксплуатации. О проблемах Mikrotik и как с ними справиться, если вы или ваш клиент использует роутер MikroTik, мы и поговорим в данной статье.
Содержание
- Распространенные проблемы MikroTik
- Ресурсы
- Firewall
- Другие способы анализа трафика
- Wireless
- Ping, Traceroute
- Заключение
Самая распространенная проблема MikroTik (точнее жалоба) — «у меня ничего не работает», причем чаще всего это неправда. Если у босса не открывается вложение в письме с темой «вы выиграли миллион», потому что его заблокировал антивирус, то настраивать роутер в этот день вряд ли придется.
Еще на тему Микротик:
- Настройка безопасности MikroTik
- Настройка файрвола на примере Микротика
- Блокировка сайтов в MikroTik без Layer7 Protocols
Поэтому один из важных навыков админа — это умение вести диалог с пользователем и выяснять, что именно и как не работает. Увы, эта статья не будет посвящена данному вопросу, так что переходим сразу к технической части.
Ресурсы
Первое, на что обращает внимание любой системный администратор, — потребление ресурсов. Благо WinBox выводит эти данные прямо в главном окне. А если еще не выводит — сейчас же добавляй их туда. Это сэкономит много времени в будущем. Тебе нужно меню Dashboard → Add. И кстати, зеленый квадратик в правой верхней части — это не загрузка процессора. Не обращай на него внимания.
Если процессор постоянно загружен больше 80% (в зависимости от условий это значение может меняться, но в среднем давай примем такое число), то что‑то неладно. В первую очередь смотрим на местный «диспетчер задач», меню Tools → Profile. Тут мы увидим, что именно нагружает CPU, и поймем, как действовать дальше.
Длительную статистику по нагрузке CPU, трафику на интерфейсах и другим параметрам можно увидеть в Tools → Graphing.
Объяснение полей вы найдете в вики. Наиболее часто встречаются DNS, Encrypting и Firewall.
- Encrypting — роутер тратит много ресурсов на шифрование. Скорее всего, у вас много туннелей VPN и нет аппаратного чипа шифрования. Нужно поменять на железку со специальным чипом или выбрать более слабые алгоритмы.
- Firewall — прямое указание, что вы не читали мои предыдущие статьи.
- DNS — а вот тут вас ждет кое‑что интересное.
Сам по себе DNS-сервер почти не нагружает роутер в небольших и средних сетях (до нескольких тысяч хостов). А использовать RouterOS в качестве DNS-сервера в больших сетях не лучшая идея. Так откуда нагрузка? Давай разбираться. Если есть нагрузка, значит что‑то ее создает. Вероятно, серверу DNS приходится отвечать на большое количество запросов. Проверим, так ли это. Создадим в файрволе правило.
/ip firewall filter add action=accept chain=input dst—port=53 log=yes log—prefix=DNS protocol=udp |
И теперь смотрим в лог. Если наши предположения верны, то заметим много сообщений с префиксом DNS. Увидим, с каких адресов и на какие интерфейсы летят запросы. Скорее всего, это будет интерфейс WAN. Но мы не хотим обрабатывать DNS-запросы, пришедшие к нам из интернета. Закроем UDP-порт 53 на интерфейсе WAN, поместим правило в нужном месте — и наслаждаемся снизившейся нагрузкой. Поздравляю! Мы только что обнаружили, что были частью ботнета, закрыли эту дыру и сделали интернет чуточку чище. Подобные атаки часто проводятся с применением протоколов, работающих над UDP.
Firewall
Вообще, умение работать с файрволом несет в себе огромную силу. Правильно построенное правило укажет, как проходит пакет через систему, в какой интерфейс попадает, из какого уходит дальше и получает ли ответный пакет. По одним только счетчикам можно многое узнать о своей сети.
В столбцах Bytes и Packets отображаются количество байтов и пакетов, обработанных правилом. Кнопки Reset Counters сбрасывают эти счетчики. Теперь можно наблюдать, попадает ли трафик в нужное правило или нет.
Полезной часто оказывается вкладка Connections файрвола. Тут видно все потоки, проходящие через роутер: их состояние, количество прошедших байтов, флаги потока (для получения подсказки достаточно навести на значение в столбце). Для большей наглядности нужно добавить поля Reply Dst. Address и Reply Src. Address. В этих полях видно, в какой и из какого адреса был проведен NAT.
Файрвол со всеми его фичами позволяет детально дебажить весь трафик, проходящий через роутер. Чтобы лучше понимать, что происходит во всех этих вкладках, нужно изучить, как пакеты проходят через роутер. На картинке упрощенная версия схемы. Более подробная есть в документации.
Другие способы анализа трафика
Увидеть состояние потока, его адреса, байты и прочее — хорошо. Но файрвол не позволяет удобно и из единого места убедиться, что маршрутизация корректна. Чтобы узнать, в какой интерфейс вылетает пакет, достаточно воспользоваться инструментом Torch.
Torch можно воспринимать как некое подобие tcpdump. Здесь можно увидеть VLAN ID, source/destination address/port, DSCP, битовую и пакетную скорость. Есть удобные фильтры, которые позволяют делать точные выборки. Если данные в окне меняются слишком быстро, увеличивай значение Entry Timeout. К сожалению, в одном окне он может показывать только трафик на одном интерфейсе, но никто не мешает нажать New Window и наблюдать за несколькими интерфейсами. Если Torch не показывает нужного трафика на нужном интерфейсе — налицо проблемы с маршрутизацией.
Torch позволяет наблюдать за потоками трафика в реальном времени. Но в некоторых случаях нужны более детальные данные о трафике. Их позволяет получить инструмент IP Sniffer.
С его помощью можно увидеть параметры трафика и даже содержимое пакета.
Но иногда требуется более детальный анализ — например, чтобы убедиться, что TCP handshake успешно прошел и данные передаются. В таком случае в передаваемых пакетах должен присутствовать флаг ACK. Но искать пакеты в скудном интерфейсе «Винбокса» неудобно.
И тут на помощь приходит всеми любимый Wireshark — мощнейший инструмент для анализа сетевого трафика. В Filter указываем нужные параметры, чтобы не снифать все подряд, в General выбираем Filename, жмем Apply и Start. Теперь в Files на роутере можно найти наш дамп, перекинуть его на компьютер и открыть «Шарком». О нем написано много статей, поэтому даже не буду пытаться писать тут, как с ним работать.
Но это лишь начало. Можно в реальном времени наблюдать за трафиком из Wireshark. И без всяких операций с файлами! Открываем «Шарк», в фильтре пишем
udp.<wbr />port <wbr />== <wbr />37008, на сниффере RouterOS во вкладке Streaming ставим галочку
Streaming <wbr />Enabled и вписываем IP-адрес компьютера с запущенным «Шарком». Можно поставить галочку Filter stream, чтобы лить в «Шарк» не весь трафик, а только выбранный.
Лить трафик в сниффер можно и из файрвола. За это отвечает действие sniff-TZSP в таблице Mangle. Работает это по аналогии со Sniffer Streaming, но в файрволе можно сделать более точную выборку пакетов для сниффера.
Wireless
Самая сложная часть диагностики — это Wi-Fi. Он и сам по себе очень сложная технология, к тому же среда передачи данных общая и все соседские роутеры мешают работать твоему, так же как и он им. О работе 802.11 написана не одна книга, пересказывать их я не буду. Посмотрим только на инструменты, которые могут помочь при диагностике.
В RouterOS их немного. Самый главный — вкладка Registration в Wireless. Здесь видно всю информацию о подключенных клиентах: MAC, уровень сигнала, качество сигнала.
Самые важные поля:
- CCQ — Client Connection Quality. Чем ближе к 100%, тем лучше. Ниже 60% означает плохую связь;
- TX/RX Signal Strength — уровень сигнала. Отличное значение — от 0 до –45, приемлемое — от –55 до –75. Все, что между, — хорошо. Ниже –75 можно считать отсутствием связи. По крайней мере, я ориентируюсь на такие цифры.
- Signal to Noise — отношение сигнал/шум. Чем выше — тем лучше.
Второй инструмент — логи. Собственно, этот инструмент должен активно использоваться не только при диагностике Wi-Fi. Если стандартных логов недостаточно — просто включи расширенные.
Ping, Traceroute
Первым инструментом диагностики у сисадмина всегда был пинг. Но далеко не все знают, сколько возможностей он в себе скрывает.
Многие сталкивались с тем, что текст на сайте отображается, а картинки нет. Или скрипты не загрузились, и сайт «поехал». Это первые признаки несогласованности MTU. С помощью пинга можно проверить этот вариант. Ставим галочку Don’t fragment, выставляем нужный нам размер пакета и смотрим на результат. Если видим
packet <wbr />too <wbr />large — MTU в канале ниже заданного нами значения пакета. Уменьшаем его и проверяем снова. Таким образом выявляем максимальный пакет, который проходит через сеть без фрагментации.
По умолчанию пакет отправляется с роутера с src address того интерфейса, в который он вылетает. Бывает, что нужно его поменять. Например, при диагностике маршрутизации внутри VPN или корректности работы файрвола. Для этого нужно заполнить поле src address. Не забывай, что адрес должен быть существующим, чтобы ответный пакет вернулся.
При сложной маршрутизации необходимо выбрать нужную Routing Table. Впрочем, те, кто пользуется несколькими таблицами маршрутизации, и так это знают.
Заключение
Невозможно в одной статье и даже в нескольких книгах описать все возможные проблемы и методы их диагностики и решения. Для эффективного дебага нужно понимать, как работает сеть на каждом уровне, ее особенности в конкретной реализации — ведь не бывает двух одинаковых сетей: рецепты, работающие в одной инфраструктуре, будут бесполезными для другой.
РЕКОМЕНДУЕМ:
Как защититься от руткитов в Linux
Для дебага необходимо понимать, как пакет проходит внутри RouterOS, а в особо сложных случаях — и знать особенности вендора. И это относится не только к MikroTik. Лучший инструмент дебага — знания и опыт!
Загрузка…
srv8.vpn.zaborona.help
Оперативки он почти не занимает. Так и сделал. Скрипт создал список подсетей. Потом уже сам добавил правило маркировки трафика который идет к подсетям из етого списка, а затем в маршрутах весь маркированый трафик направил в тунель все заработало. Ну VK OK Yandex mail.ru так точно )))) Спасибо.
Может кому пригодится:
Создаем шедулер для обновления маршрутов раз в 3 дня.
/system scheduler
add interval=3d name=sync_uablacklist on-event="/system/script/run sync_uablacklist" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-date=dec/06/2021 start-time=05:00:00
Создем таблицу маршрутизации
/routing table
add fib name=zaborona
Правило маркировки трафика к IP адресам из списка.
/ip firewall mangle
add action=mark-routing chain=prerouting comment="Mark to zaborona" dst-address-list=uablacklist new-routing-mark=zaborona passthrough=yes
Маршрут маркированного трафика в интерфейс забороны.
/ip route
add comment="Route to zaborona" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=zaborona pref-src="" routing-table=zaborona scope=30 suppress-hw-offload=yes target-scope=10
Ну и сам скрипт добавляем и сразу запускаем.
/system script
add dont-require-permissions=no name=sync_uablacklist owner=admin policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source=":local apiPrefix "https://uablacklist.
net/subnets_mikrotik_"r
n:local tempFile "uablacklist.txt"r
n:local listName "uablacklist"r
nr
n/log info "removing existing '$listName'..."r
n:put "removing existing '$listName'..."r
n/ip firewall address-list remove [/ip firewall address-list find list=$listName]r
nr
n:local i 0r
n:local isEnd falser
n:do {r
n :local apiPath "$apiPrefix$i.txt"r
n /log info "fetching UA blacklist registry piece ($apiPath)..."r
n :put "fetching UA blacklist registry piece ($apiPath)..."r
n :local contentLen 0r
n :local content ""r
n :do {r
n /tool fetch url=$apiPath dst-path=$tempFiler
n :set content [/file get [/file find name=$tempFile] contents]r
n :set contentLen [:len $content]r
n } on-error={r
n /log info "no more pieces"; r
n :put "no more pieces"r
n :set isEnd truer
n }r
n :local lineEnd 0r
n :local line ""r
n :local lastEnd 0r
n :local company ""r
n :while ($lastEnd < $contentLen) do {r
n :set lineEnd [:find $content "\n" $lastEnd ]r
n :set line [:pick $content $lastEnd $lineEnd]r
n :set lastEnd ($lineEnd+1)r
n :local entry [:pick $line 0 ($lineEnd-1)]r
n :if ([:pick $line 0 1] != "#") do={r
n :if ([:len $entry ] > 0) do={r
n /log info "add '$entry' subnet of '$company' to list '$listName'...";r
n :put "add '$entry' subnet of '$company' to list '$listName'...";r
n :do {r
n /ip firewall address-list add list=$listName address=$entry comment=$companyr
n } on-error={r
n /log info "failed to add '$entry' subnet of '$company' to list '$listName', probably, it's duplication error."; r
n :put "failed to add '$entry' subnet of '$company' to list '$listName', probably, it's duplication error."r
n }r
n }r
n } else={r
n :set company [:pick $line 2 ($lineEnd) ]r
n }r
n }r
n :set i (i+1)r
n} while (!$isEnd)"
/system/script/run sync_uablacklist
P.S. Совсем забыл. У кого в фаерволе есть правило «fasttrac connection» его придется отключить, чтоб ето нормально работало. Так как fasttrac konnection позволяет трафику миновать большую часть фаервола, то маркировка трафика будет работать не корректно, заблокированные сайты будут открываться, но медленнее. Если же «fasttrac connection» все же нужен, тогда выход пока один, прописывать маршруты прямо в /ip routes к каждой подсети из списка забороны.
I don’t know if this can be of any help:
15:24:35 dhcp,debug,packet Subnet-Mask = 255.255.255.0
15:24:35 dhcp,debug,packet Broadcast-Address = 192.168.4.255
15:24:35 dhcp,debug,packet Domain-Server = 192.168.4.1
15:24:35 dhcp,debug,packet Router = 192.168.4.1
15:24:35 dhcp,debug,state dhcp-client on ether5 entering <error> state
15:24:36 dhcp,debug,packet dhcp-client on wlan1 sending discover with id xxxxx413 to 255.255.255.255
15:24:36 dhcp,debug,packet secs = 52
15:24:36 dhcp,debug,packet ciaddr = 0.0.0.0
15:24:36 dhcp,debug,packet chaddr = xx:xx:xx:xx:xx:x8
15:24:36 dhcp,debug,packet Msg-Type = discover
15:24:36 dhcp,debug,packet Parameter-List = Subnet-Mask,Classless-Route,Router,Static-Route,Domain-Server,NTP-Server,CAPWAP-Server,Vendor-Specific
15:24:36 dhcp,debug,packet dhcp-client on wlan1 received offer with id xxxxx5413 from 192.168.1.1
15:24:36 dhcp,debug,packet secs = 49
15:24:36 dhcp,debug,packet ciaddr = 0.0.0.0
15:24:36 dhcp,debug,packet yiaddr = 192.168.1.11
15:24:36 dhcp,debug,packet siaddr = 192.168.1.1
15:24:36 dhcp,debug,packet chaddr = xx:xx:xx:xx:xx:x8
15:24:36 dhcp,debug,packet Msg-Type = offer
15:24:36 dhcp,debug,packet Server-Id = 192.168.1.1
15:24:36 dhcp,debug,packet Address-Time = 3600
15:24:36 dhcp,debug,packet Renewal-Time = 1800
15:24:36 dhcp,debug,packet Rebinding-Time = 3150
15:24:36 dhcp,debug,packet Subnet-Mask = 255.255.255.0
15:24:36 dhcp,debug,packet Router = 192.168.1.1
15:24:36 dhcp,debug,packet Domain-Server = 192.168.1.1
15:24:36 dhcp,debug,packet NTP-Server = 192.168.1.1
15:24:36 dhcp,debug,state dhcp-client on wlan1 entering <requesting...> state
15:24:36 dhcp,debug,packet dhcp-client on wlan1 sending request with id xxxxx5413 to 255.255.255.255
15:24:36 dhcp,debug,packet secs = 52
15:24:36 dhcp,debug,packet ciaddr = 0.0.0.0
15:24:36 dhcp,debug,packet chaddr = xx:xx:xx:xx:xx:x8
15:24:36 dhcp,debug,packet Msg-Type = request
15:24:36 dhcp,debug,packet Server-Id = 192.168.1.1
15:24:36 dhcp,debug,packet Address-Request = 192.168.1.11
15:24:36 dhcp,debug,packet Parameter-List = Subnet-Mask,Classless-Route,Router,Static-Route,Domain-Server,NTP-Server,CAPWAP-Server,Vendor-Specific
15:24:37 dhcp,debug,packet dhcp-client on wlan1 received ack with id xxxxxx5413 from 192.168.1.1
15:24:37 dhcp,debug,packet secs = 52
15:24:37 dhcp,debug,packet ciaddr = 0.0.0.0
15:24:37 dhcp,debug,packet yiaddr = 192.168.1.11
15:24:37 dhcp,debug,packet siaddr = 192.168.1.1
15:24:37 dhcp,debug,packet chaddr = xx:xx:xx:xx:xx:x8
15:24:37 dhcp,debug,packet Msg-Type = ack
15:24:37 dhcp,debug,packet Server-Id = 192.168.1.1
15:24:37 dhcp,debug,packet Address-Time = 3600
15:24:37 dhcp,debug,packet Renewal-Time = 1800
15:24:37 dhcp,debug,packet Rebinding-Time = 3150
15:24:37 dhcp,debug,packet Subnet-Mask = 255.255.255.0
15:24:37 dhcp,debug,packet Router = 192.168.1.1
15:24:37 dhcp,debug,packet Domain-Server = 192.168.1.1
15:24:37 dhcp,debug,packet NTP-Server = 192.168.1.1
15:24:37 dhcp,debug,state dhcp-client on wlan1 entering <error> state
15:24:40 system,info sntp change time Mar/27/2021 15:24:37 => Mar/27/
Thanks