Если необходимо мониторить трафик роутера, то это можно сделать достаточно простым способом. Для этого нам понадобится собственно сам Mikrotik и Linux сервер с поднятым веб сервером, php и sqlite3.

Сначала идем на наш Linux сервер и создаем новую директорию tc для нашего сайтика со статистикой:

mkdir /var/www/html/tc

Затем даем права на запись в созданную директорию:

chmod 0777 /var/www/html/tc

Теперь скачиваем скрипт с генерацией статистики отсюда.

Распаковываем содержимое в созданную ранее директорию на Linux сервере и открываем на редактирование файл init.php.

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

Все. С сервером закончили. Статистика будет доступна по адресу http://SERVER_IP/tc/

Теперь идем настраивать микрот. Команды буду писать терминальные, т. к. мне тупо лень делать скриншоты графического интерфейса управления и расписывать там каждый шаг. Кому нужно, тот сам поймет, куда нужно тыкать мышкой.

Создаем правила фаервола, чтобы считать проходящий трафик через нужные интерфейсы:

/ip firewall mangle add chain=forward in-interface=bridge out-interface=ether1 action=passthrough comment=local-wan-tx
/ip firewall mangle add chain=forward in-interface=ether1 out-interface=bridge action=passthrough comment=local-wan-rx

В данном примере ether1 — интернет, bridge — локальная сеть. Меняете эти параметры на те, что используются у вас. Ограничений по типу разделения — нет, можете использовать и конкретные интерфейсы, и списки, и IP адреса или что вам больше удобно. Главное соблюдать логику.

Теперь создадим скрипт, который и будет генерировать статистику на сайте:

/system script
add dont-require-permissions=no name=tc owner=admin policy=\
ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source="/\
:local srvip "192.168.1.2";\r\
\n:local wantx "local-wan-tx";\r\
\n:local wanrx "local-wan-rx";\r\
\n:local sysname [/system identity get value-name=name];\r\
\n:local txbytes [/ip firewall mangle get [/ip firewall mangle find comment="$wantx"] bytes];\r\
\n:local rxbytes [/ip firewall mangle get [/ip firewall mangle find comment="$wanrx"] bytes];\r\
\n/tool fetch url=("http://$srvip/tc/collector.php\?sn=$sysname&tx=$txbytes&rx=$rxbytes") mode=http keep-result=no;\r\
\n/ip firewall mangle reset-counters [/ip firewall mangle find comment="$wantx"];\r\
\n/ip firewall mangle reset-counters [/ip firewall mangle find comment="$wanrx"];\r\
\n"

В данном скрипте необходимо сменить srvip на адрес вашего Linux сервера.

Теперь добавим запуск скрипта по таймеру:

/system scheduler add name="tc" interval=1h on-event=tc

На этом все. Для проверки работоспособности всей конструкции, можете или подождать час, или запустить скрипт вручную и перейти на наш сайтик и обновить страницу. Если все сделано верно, то страница обновится и появится статистика, разделенная по устройствам.

Если мальчик — черт, то девочка тогда получается — чертила?
А в случае нежностей, мальчик — чертик, а девочка — черточка?

Сводная таблица совместимости оборудования и операционных систем.

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

Hyper-V, если у вас:

• Мало денег и мало времени.
• Мало знаний о виртуализации.
• Нет умения работать с чем-то, что сложнее «далее-далее-далее» мышкой.
• Обычное оборудование из соседнего Ашана.
• Низкие требования к системе виртуализации.
• Будут использоваться в основном системы на базе Windows, а Linux машин мало, да и те на базе лишь популярных дистрибутивов.

VMware, если у вас:

• Много денег и времени. Нет, не так.. Очень много денег.
• Вы специалист в области виртуализации.
• Вы разбираетесь в сложных комплексных системах и не боитесь читать документацию.
• Специально подобранное оборудование из энтерпрайз сегмента за много денег.
• Высокие требования к сложности виртуализации и ее возможностей.
• Будут использоваться различные системы, включая различные мало распространенные.

QEMU/KVM, если у вас:

• Нет денег, но очень много времени.
• Вы специалист в области виртуализации.
• Вы разбираетесь в сложных комплексных системах и не боитесь читать документацию.
• Прекрасно себя чувствуете в задачах с ручным редактированием конфигурационных файлов.
• Оборудование покупалось после прочтения спецификаций и требований.
• Высокие требования к сложности виртуализации и ее возможностей.
• Будут использоваться различные системы, включая совсем экзотику, а так же системы на базе других архитектур.

OVZ/XLC, если у вас:

• Нет денег, но много времени.
• Вы специалист в области виртуализации.
• Вы не боитесь читать документацию.
• Прекрасно себя чувствуете в задачах с ручным редактированием конфигурационных файлов.
• Обычное оборудование из соседнего Ашана.
• Низкие требования к системе виртуализации.
• Будут использоваться только системы на базе Linux и те в усеченном режиме.

Остальные платформы, вроде XCP, Citrix и прочих я не буду описывать, т. к. если вы читаете этот текст, то вам эти платформы точно не нужны.

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

Перед прочтением рекомендую ознакомиться с RFC6890 и RFC5735.

0.0.0.0/8
Диапазон описан в RFC1122, RFC3330 и RFC1700 как «этот хост в этой сети», хотя, учитывая варианты применения, правильнее было бы назвать его как «любой адрес». В частности, IP-адрес 0.0.0.0 используется для:

• обозначения в конфигурационных файлах серверов и выводе netstat информации о том, что определенный сервис «слушает» запросы на всех IP-адресах данного сервера;
• конфигурации маршрута по умолчанию на активном сетевом оборудовании;
• использования в качестве src address в запросах на получение IP-адреса (DHCPDISCOVER);
• обозначения IP-адреса в суммаризованных событиях безопасности IDS/IPS/WAF/etc (например, TCP Host Sweep — обозначение dst host в случае инициации коннектов к большому количеству IP-адресов).

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Три вышеописанных диапазона не маршрутизируются в Интернет, поскольку зарезервированы под организацию локальных сетей ИТ инфраструктуры компаний. Описаны изначально в RFC1918. При этом любая организация вправе использовать любой из вышеописанных диапазонов для IP-адресного плана либо все вместе на свое усмотрение. Для взаимодействия с внешними ресурсами и партнерами во избежание пересечения адресного пространства должен использоваться NAT.

100.64.0.0/10
В соответствии с RFC6598, используется как транслируемый блок адресов для межпровайдерных взаимодействий и Carrier Grade NAT. Особенно полезен как общее свободное адресное IPv4-пространство RFC1918, необходимое для интеграции ресурсов провайдеров, а также для выделения немаршрутизируемых адресов абонентам. Конечно, в последнем случае никто не мешает использовать RFC1918 — на откуп сетевым архитекторам.

127.0.0.0/8
В случае, если сервису необходим для работы функционирующий сетевой стек, который не будет давать сбоев при отключении от сети, используются loopback-адреса. Выделение 127.0.0.0/8 под внутренние loopback-адреса определено в RFC1122. В отличие от адресов RFC1918 и RFC6598, адреса для loopback не должны присутствовать и обрабатываться ни в одной сети, только во внутренней таблице маршрутизации хоста.

169.254.0.0/16
В соответствии с RFC3927, определен как Link-Local для автоматической конфигурации. Думаю, каждый человек хоть раз в жизни, но успел столкнуться с ситуацией, когда ПК, не получив IP-адрес от DHCP-сервера, присваивает сам себе непонятный и нигде не прописанный ранее IP, начинающийся на 169.254... Это и есть реализация рекомендаций из RFC3927.

192.0.0.0/24
Блок не встречается в повседневной жизни, поскольку зарезервирован под IANA для нужд IETF в соответствии с RFC6890.

192.0.2.0/24
198.51.100.0/24
203.0.113.0/24
Эти три подсети, в соответствии с RFC5737, зарезервированы для описания в документах. Многие, думаю, сталкивались с ситуацией, когда для статьи в журнале либо презентации на конференции нужно показать некоторое адресное пространство, которое, с одной стороны, не должно ассоциироваться с локальными RFC1918 адресами и как бы показывать Интернет, но, в то же время, и не принадлежать никому, чтобы не было лишних вопросов со стороны владельца адресов. Для этого и были выделены три подсети /24 по принципу «дарю, пользуйтесь».

192.88.99.0/24
Частный случай из подсети 192.0.0.0/24, описанной выше, но заслуживает отдельного описания из технологического интереса. В связи с необходимостью взаимодействия новых IPv6-облаков между собой в преобладающем IPv4-транзите необходим NAT 6to4. При этом некоторые межконтинентальные сервисы, наиболее критичные из которых — корневые сервера DNS, используют технологию anycast. Наверное, это тема для отдельной заметки, но вкратце: подсеть, выделенная под anycast, может терминироваться в любой автономной системе для обеспечения отказоустойчивости. В RFC3068 был выделен пул адресов 192.88.99.0/24 для NAT 6to4 сервисов, использующих anycast. Как видим, выделен был этот пул еще в 2001 году, после чего, нахлебавшись проблем на практике, в 2015 году издается RFC7526, отменяющий RFC3068, но при этом подсеть 192.88.99.0/24 остается зарезервированной под нужды IETF.

198.18.0.0/15
Диапазон выделен под лаборатории нагрузочного тестирования (Benchmarking) в соответствии с RFC2544 и уточнением в RFC6815, что данный диапазон не должен быть доступен в Интернет во избежание конфликтов. Опять же, никто при этом не отменяет использование RFC1918, но для больших сетей с крупными лабораториями лишний блок /15 явно не помешает.

224.0.0.0/4
Этот диапазон в исторической классификации еще называется как Class D. Выделен под Multicast, уточнение специфики работы которого тоже вроде как отдельная заметка. В RFC5771 подробно расписано использование подсетей внутри блока, но суть остается той же: эти адреса не закреплены ни за каким провайдером, и, соответственно, через Интернет не должны светиться.

240.0.0.0/4
В соответствии с RFC1122, данный диапазон IP-адресов, исторически также известный как Class E, зарезервирован под использование в будущем. Юмор ситуации в том, что RFC1122издавался еще в августе 1989 года, сейчас 2016 год, IPv4-адреса закончились, но для IETF будущее еще не наступило, потому что из всей большой подсети /4 до сих пор используется только один адрес. Но, наверное, если посчитать статистику по всем подсетям всех организаций мира, этот адрес окажется в лидерах, потому что сервисы, использующие broadcast, обращаются к адресу 255.255.255.255, который и принадлежит описанному диапазону.