Mikrotik.moscow [тема: Запрос на функцию: «Группа обслуживания»] http://mikrotik.moscow Новое в теме Запрос на функцию: «Группа обслуживания» форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Wed, 12 Aug 2026 18:21:16 -0400 Запрос на функцию: «Группа обслуживания» Запрос на функцию: «Группа обслуживания» RouterOS в форуме RouterOS.
Итак, JUMP используется, по сути, чтобы перехватывать определённые пакеты в нужный момент и ПЕРЕНАПРАВЛЯТЬ их на другое кастомное правило фаервола (или набор правил). Если пакет совпадает с кастомным правилом(ами), то выполняется действие и на этом всё, если пакет не совпадает — он возвращается к следующему правилу после цепочки JUMP (то есть к упорядоченному набору правил). По сути, цепочка JUMP — это как условие IF: ЕСЛИ это, то сделать вот это, иначе продолжать дальше…

++++++++++++++++++++++++++++++++++++++++++++++++++++++

Похожим на JUMP я теперь открыл для себя MANGLE. (Медленно, знаю.)

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

Сейчас я пытаюсь (безуспешно) использовать его, чтобы направить весь мой почтовый трафик с обеих LAN на WAN2, при том что WAN1 — основной (ближе, меньше пинг).

Стоит ли мне ставить IP адрес почтового сервера WAN2 в правило mangle (или просто указать порт и список LAN интерфейсов)? Надо ли ставить IP адрес только в правило IP маршрутизации или в оба места? (Использую mark route и новую маршрутизацию по меткам).

Проблема решилась — я не указал исходный адрес. Я думал, что если оставить поле пустым, то это значит все возможные IP в LAN, но почему-то прописывание 0.0.0.0 в источник сработало. Хотя не понимаю почему.
14.03.2018 15:24:00, anav.]]> http://mikrotik.moscow/forum/forum57/83384-zapros-na-funktsiyu_-_gruppa-obsluzhivaniya/message376065 http://mikrotik.moscow/forum/forum57/83384-zapros-na-funktsiyu_-_gruppa-obsluzhivaniya/message376065 Wed, 14 Mar 2018 15:24:00 -0400 RouterOS Запрос на функцию: «Группа обслуживания» Запрос на функцию: «Группа обслуживания» RouterOS в форуме RouterOS.
Всё просто. Межсетевой экран использует цепочки правил, и пакеты проходят через них, пока не найдётся подходящее правило. Есть стандартные цепочки, например, «forward» или «input», но можно создавать и свои собственные. Маршрутизатор не будет учитывать их просто так, только потому что они существуют — нужно перейти к ним из стандартных цепочек. Когда это происходит, либо в кастомной цепочке находится подходящее правило (и обработка на этом заканчивается), либо, если такого нет, управление возвращается в исходную цепочку и продолжается там. И, к слову, приведённая конфигурация — это просто простой пример для forward, обычно ещё есть правила для input.
14.03.2018 03:50:00, Sob.]]> http://mikrotik.moscow/forum/forum57/83384-zapros-na-funktsiyu_-_gruppa-obsluzhivaniya/message376064 http://mikrotik.moscow/forum/forum57/83384-zapros-na-funktsiyu_-_gruppa-obsluzhivaniya/message376064 Wed, 14 Mar 2018 03:50:00 -0400 RouterOS Запрос на функцию: «Группа обслуживания» Запрос на функцию: «Группа обслуживания» RouterOS в форуме RouterOS.
Привет, Sob, мне понадобится время, чтобы врубиться, что ты тут делаешь. Совсем не шарю в JUMP, только начинаю разбираться с input и forward правилами (к маршрутизатору, через маршрутизатор). Любые быстрые объяснения будут очень кстати! Ещё меня запутало, как ты используешь FW правила без указания forward, input или output, но с = Service?? И, если говорить в общем, ты определяешь Chain=service как что-то вроде списка адресов для IP, но для сервисов? (ведь у них сами по себе нет IP, интерфейса или указания источника/назначения) В этом, конечно, есть смысл и это лучше, чем куча отдельных правил.
13.03.2018 18:07:00, anav.]]> http://mikrotik.moscow/forum/forum57/83384-zapros-na-funktsiyu_-_gruppa-obsluzhivaniya/message376063 http://mikrotik.moscow/forum/forum57/83384-zapros-na-funktsiyu_-_gruppa-obsluzhivaniya/message376063 Tue, 13 Mar 2018 18:07:00 -0400 RouterOS Запрос на функцию: «Группа обслуживания» Запрос на функцию: «Группа обслуживания» RouterOS в форуме RouterOS.
Если уж ничего другого, теперь у меня есть друг в Словакии, который хоть в одном отношении думает так же, ха-ха. Я собираюсь оставить сообщение в теме запросов встроенных функций, может быть, тогда это станет функцией…
13.03.2018 11:39:00, anav.]]> http://mikrotik.moscow/forum/forum57/83384-zapros-na-funktsiyu_-_gruppa-obsluzhivaniya/message376062 http://mikrotik.moscow/forum/forum57/83384-zapros-na-funktsiyu_-_gruppa-obsluzhivaniya/message376062 Tue, 13 Mar 2018 11:39:00 -0400 RouterOS Запрос на функцию: «Группа обслуживания» Запрос на функцию: «Группа обслуживания» RouterOS в форуме RouterOS.
Как видите, этот пост датируется ещё 2012 годом. С тех пор ничего не изменилось, что, конечно, огорчает. До сих пор невозможно задать какие-либо группы для протоколов, портов или сервисов в RouterOS.
13.03.2018 10:36:00, tomaskir.]]> http://mikrotik.moscow/forum/forum57/83384-zapros-na-funktsiyu_-_gruppa-obsluzhivaniya/message376061 http://mikrotik.moscow/forum/forum57/83384-zapros-na-funktsiyu_-_gruppa-obsluzhivaniya/message376061 Tue, 13 Mar 2018 10:36:00 -0400 RouterOS Запрос на функцию: «Группа обслуживания» Запрос на функцию: «Группа обслуживания» RouterOS в форуме RouterOS.
Какой статус у этого очевидного и логичного запроса — группировка портов/сервисов, похожая на подход с адресами для объектов, чтобы уменьшить путаницу в правилах файрвола и позволить изменять список без необходимости возиться с самими правилами. Кстати, такой же запрос по группировке портов/сервисов одинаково важен и для правил переадресации портов. Меня просто поражает, что чего-то подобного списку адресов (IP) для портов/сервисов до сих пор нет. Я пытаюсь перейти с роутера Zyxel и очень ценю логику и методы других проверенных производителей!
11.03.2018 18:40:00, anav.]]> http://mikrotik.moscow/forum/forum57/83384-zapros-na-funktsiyu_-_gruppa-obsluzhivaniya/message376060 http://mikrotik.moscow/forum/forum57/83384-zapros-na-funktsiyu_-_gruppa-obsluzhivaniya/message376060 Sun, 11 Mar 2018 18:40:00 -0400 RouterOS Запрос на функцию: «Группа обслуживания» Запрос на функцию: «Группа обслуживания» RouterOS в форуме RouterOS.
Спасибо за информацию, но даже в твоём примере у тебя всё равно остаётся 3 правила фаервола для одного сервиса, ведь по-другому это не сделаешь.

/ip firewall filter  
add chain="IPSec_VPN" protocol="UDP" dst-port="500" action="accept"  
add chain="IPSec_VPN" protocol="ipsec-esp" action="accept"  
add chain="IPSec_VPN" protocol="encap" action="accept"  
add chain="IPSec_VPN" action="jump" jump-target=SOME_OTHER_LIST_THAT_DENIES_ACCESS_TO_UNINITIATED_INC­OMING_TRAFFIC  

То есть нужно создавать 3 отдельные записи в фаерволе для одного сервиса (VPN).  

Если использовать Service Groups, то это была бы одна запись в фаерволе, где сервисы просто ссылаются на “Service group”, состоящую из нескольких сервисов. Прямо как с “Address Lists”, где в правилах фаервола можно указывать сразу несколько IP-адресов.  

Это никак не исправишь с помощью цепочек, потому что на самом деле ты просто кладёшь эти сервисы в другую цепочку. Хотя понимаю, что так фаервол становится чуть более организованным, но в итоге приходится гадать, куда и откуда прыгают эти правила (нужна логика цепей).  

Например, гораздо чище фаервол выглядел бы так: (взято с одного из моих боевых конфигов, только подкорректировано для наглядности, как именно помогают Service Groups)  

/ip firewall filter  
# input цепочка  
add action=accept chain=input connection-state=established,related  
add action=drop chain=input connection-state=invalid  
add action=accept chain=input limit=5,5 service-group="ICMP WAN"  
add action=accept chain=input service-group="ROS Management WAN" in-interface=ether1-WAN  
add action=accept chain=input service-group="ROS Management LAN" in-interface=ether2-LAN  
add action=accept chain=input service-group="ROS VPN" src-address-list="VPN Partners"  
add action=drop chain=input  

# forward цепочка  
add action=accept chain=forward connection-state=established,related  
add action=drop chain=forward connection-state=invalid  
add action=accept chain=forward in-interface=ether2-LAN out-interface=ether1-WAN comment="Allow LAN -> WAN"  
add action=accept chain=forward dst-address=XXX.XXX.XXX.XXX service-group="HTTP"  
add action=accept chain=forward dst-address=XXX.XXX.XXX.XXY service-group="DNS"  
add action=accept chain=forward dst-address-list=Servers limit=2,2 service-group="ICMP Servers"  
add action=drop chain=forward  

Address Lists определяются так:  

Address List "Servers" содержит IP-адреса  
XXX.XXX.XXX.YYY  
XXX.XXX.XXX.ZZZ  

Address List "VPN Partners" содержит IP-адреса  
XXX.XX.X.YZ  
XXX.XX.XYZ.YZ  
XX.XYZ.XY.XY  

Service Groups определяются так:  

Service Group "ROS Management LAN" содержит  
dst-port=5678,20561 protocol=udp  
dst-port=22,8291 protocol=tcp  

Service Group "HTTP" содержит  
dst-port=80 protocol=tcp  
dst-port=443 protocol=tcp  

Service Group "DNS" содержит  
dst-port=53 protocol=tcp  
dst-port=53 protocol=udp  

Service Group "ICMP Servers" содержит  
icmp-options=0:0-255 protocol=icmp  
icmp-options=3:3 protocol=icmp  
icmp-options=3:4 protocol=icmp  
icmp-options=8:0-255 protocol=icmp  
icmp-options=11:0-255 protocol=icmp  

Service Group "ROS Management WAN" содержит  
dst-port=8291 protocol=tcp  

Service Group "ICMP WAN" содержит  
icmp-options=0:0-255 protocol=icmp  
icmp-options=3:3 protocol=icmp  
icmp-options=3:4 protocol=icmp  
icmp-options=8:0-255 protocol=icmp  
icmp-options=11:0-255 protocol=icmp  

Service Group "ROS VPN" содержит  
protocol=UDP dst-port=500  
protocol=ipsec-esp  
protocol=encap  
protocol=ipip  

С таким подходом фаервол получается простой и понятный, и не нужно рисовать никаких схем логики цепочек, при этом он работает точно так же.  

К тому же, если мне понадобится разрешить SSH с WAN к определённому ресурсу в сети, мне просто нужно добавить “dst-port=22 protocol=tcp” в нужную Service Group.
29.05.2012 13:12:00, tomaskir.]]> http://mikrotik.moscow/forum/forum57/83384-zapros-na-funktsiyu_-_gruppa-obsluzhivaniya/message376059 http://mikrotik.moscow/forum/forum57/83384-zapros-na-funktsiyu_-_gruppa-obsluzhivaniya/message376059 Tue, 29 May 2012 13:12:00 -0400 RouterOS Запрос на функцию: «Группа обслуживания» Запрос на функцию: «Группа обслуживания» RouterOS в форуме RouterOS.
Оборудование SonicWall тоже так работает. Группы упрощают управление (чем все, кстати, должны заниматься). Тем временем, я нашёл… ну, скажем так, обходной путь: использовать цепочки как «группы сервисов». Объясню на ваших примерах: создайте цепочку с именем «IPSec_VPN» с такими правилами:

/ip firewall filter add chain="IPSec_VPN" protocol="UDP" dst-port="500" action="accept"  
add chain="IPSec_VPN" protocol="ipsec-esp" action="accept"  
add chain="IPSec_VPN" protocol="encap" action="accept"  
add chain="IPSec_VPN" action="jump" jump-target=SOME_OTHER_LIST_THAT_DENIES_ACCESS_TO_UNINITIATED_INC­OMING_TRAFFIC

Если вы хотите явно разрешить VPN-доступ к роутеру, нужно добавить переход (jump) на эту новую цепочку в вашей цепочке input. Пакеты, подходящие под это правило, будут прыгать в новую цепочку. По сути, вы даёте контекст цепочке IPSec_VPN, указывая, какие пакеты туда переходят. Вот как это выглядит:

/ip firewall filter add chain="input" dst-address=WAN_IP action="jump" jump-target="IPSec_VPN"

Если нужно, например, группу машин, которым предоставляется доступ, используйте address-list. Если всё ещё непонятно, вот кусок из моего рабочего конфига:

/ip firewall filter  
add action=jump chain=forward disabled=no dst-address-list=LAN jump-target=conn.in.est  

# ---  
# Используем address list, чтобы задать контекст для перехода в цепочку DMZ  
add action=jump chain=forward comment=DMZ disabled=no dst-address-list=DMZ jump-target=DMZ src-address-list=!LAN  
# --- ---  
# В этом контексте используем dst-address для более точного перехода в цепочку DMZ.WWW  
add action=jump chain=DMZ comment=DMZ.WWW disabled=no dst-address=XXX.XXX.XXX.XXX jump-target=DMZ.WWW  
# В цепочке DMZ.WWW разрешаем нужный трафик  
# Трафик, который не подходит под эту цепочку, остаётся в родительском контексте DMZ  
add action=accept chain=DMZ.WWW disabled=no dst-port=80 protocol=tcp  
add action=accept chain=DMZ.WWW disabled=no dst-port=443 protocol=tcp  
# Эта строка для моего лимитера SSH  
add action=jump chain=DMZ.WWW disabled=no dst-port=22 jump-target=limit_block protocol=tcp  
# --- ---  
# В этом контексте используем dst-address для более точного перехода в цепочку DMZ.DNS  
add action=jump chain=DMZ comment=DMZ.DNS disabled=no dst-address=XXX.XXX.XXX.XXX jump-target=DMZ.DNS  
# В цепочке DMZ.DNS разрешаем нужный трафик  
# Трафик, не подходящий под эту цепочку, остаётся в родительском контексте DMZ  
add action=accept chain=DMZ.DNS disabled=no dst-port=53 protocol=udp  
add action=accept chain=DMZ.DNS disabled=no dst-port=53 protocol=tcp  
# Эта строка для моего лимитера SSH. Возможно, можно было бы это как-то обобщить в цепочке DMZ, но не все хосты используют SSH. Зачем тогда давать доступ туда, где он не нужен?  
add action=jump chain=DMZ.DNS disabled=no dst-port=22 jump-target=limit_block protocol=tcp  
# ---  
# Эта часть относится ко всему, что прошло через контекст DMZ, включая WWW и DNS, так как цепочка продолжается вниз (напомню, порядок сверху вниз!)  
# Разрешаем пинг, переходя в цепочку ICMP  
add action=jump chain=DMZ disabled=no jump-target=ICMP protocol=icmp  
# Предоставляем контекст для всего остального трафика, чтобы он шел в цепочку conn.in.est (входящие установленные соединения)  
add action=jump chain=DMZ disabled=no jump-target=conn.in.est  

# Входящие установленные соединения  
add action=accept chain=conn.in.est comment=conn.in.est connection-state=established disabled=no  
add action=accept chain=conn.in.est connection-state=related disabled=no  
add action=drop chain=conn.in.est connection-state=invalid disabled=no  
# Все остальные прыгают в цепочку drop  
add action=jump chain=conn.in.est disabled=no jump-target=drop  

add action=drop chain=drop comment="Drop all" disabled=no  

# Лимит ICMP, но разрешаем  
add action=accept chain=ICMP comment="0:0 and limit for 5pac/s" disabled=no icmp-options=0:0-255 limit=5,5 protocol=icmp  
add action=accept chain=ICMP comment="3:3 and limit for 5pac/s" disabled=no icmp-options=3:3 limit=5,5 protocol=icmp  
add action=accept chain=ICMP comment="3:4 and limit for 5pac/s" disabled=no icmp-options=3:4 limit=5,5 protocol=icmp  
add action=accept chain=ICMP comment="8:0 and limit for 5pac/s" disabled=no icmp-options=8:0-255 limit=5,5 protocol=icmp  
add action=accept chain=ICMP comment="11:0 and limit for 5pac/s" disabled=no icmp-options=11:0-255 limit=5,5 protocol=icmp  
add action=jump chain=ICMP comment="Drop everything else" disabled=no jump-target=drop  

# Общий тарпит, обычно применяю для SSH  
add action=accept chain=limit_block disabled=no src-address-list=limit_block_exempt  
add action=accept chain=limit_block connection-state=new disabled=no limit=3/1m,2  
add action=log chain=limit_block connection-state=new disabled=yes log-prefix=""  
add action=add-src-to-address-list address-list=limit_block address-list-timeout=1w chain=limit_block connection-state=new disabled=no  
add action=reject chain=limit_block disabled=no reject-with=icmp-host-unreachable src-address-list=limit_block

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

Дополнение: я подготовил визуальную «логическую цепочку», чтобы помочь вам. Смотрите: Пользователь добавил изображение

Надеюсь, это немного поможет.
27.05.2012 20:40:00, brotherdust.]]> http://mikrotik.moscow/forum/forum57/83384-zapros-na-funktsiyu_-_gruppa-obsluzhivaniya/message376058 http://mikrotik.moscow/forum/forum57/83384-zapros-na-funktsiyu_-_gruppa-obsluzhivaniya/message376058 Sun, 27 May 2012 20:40:00 -0400 RouterOS Запрос на функцию: «Группа обслуживания» Запрос на функцию: «Группа обслуживания» RouterOS в форуме RouterOS.
Было бы здорово добавить поддержку более продвинутых списков — это особенно помогло бы при большом количестве элементов. Но и решение с цепочками тоже неплохое:

/ip firewall filter  
# базовый файрвол  
add action=accept chain=forward comment="принять установленные и связанные" connection-state=established,related  
add action=drop chain=forward comment="отбросить недействительные" connection-state=invalid  
add action=accept chain=forward comment="worknet имеет неограниченный доступ" in-interface=work-lan  
add action=jump chain=forward comment="гости могут пользоваться только вебом" in-interface=guest-lan jump-target=service_web  
add action=accept chain=forward comment="разрешить dstnat-соединения" connection-nat-state=dstnat  
add action=jump chain=forward comment="соединения из интернета" in-interface=wan jump-target=incoming  
add action=reject chain=forward comment="блокировать всё остальное" reject-with=icmp-admin-prohibited  

# входящие соединения  
add action=jump chain=incoming comment="почтовый сервер" dst-address=1.2.3.4 jump-target=service_mail  
add action=jump chain=incoming comment="dns-сервер" dst-address=1.2.3.5 jump-target=service_dns  
add action=jump chain=incoming comment="отдельный веб-сервер" dst-address=1.2.3.6 jump-target=service_web  
add action=jump chain=incoming comment="другие веб-серверы из списка адресов" dst-address-list=web-cluster1 jump-target=service_web  
add action=jump chain=incoming comment="ещё одна группа веб-серверов" dst-address-list=web-cluster2 jump-target=service_web  
add action=jump chain=incoming comment="ipsec-соседи" jump-target=service_ipsec src-address-list=ipsec-peers  

# повторно используемые цепочки для сервисов  
add action=accept chain=service_web dst-port=80,443 protocol=tcp  
add action=accept chain=service_mail dst-port=25,110,143,465,587,993,995 protocol=tcp  
add action=accept chain=service_ipsec dst-port=500,4500 protocol=udp  
add action=accept chain=service_ipsec protocol=ipsec-esp  
add action=accept chain=service_ipsec protocol=ipsec-ah  
add action=accept chain=service_dns dst-port=53 protocol=tcp  
add action=accept chain=service_dns dst-port=53 protocol=udp
13.03.2018 16:15:00, Sob.]]> http://mikrotik.moscow/forum/forum57/83384-zapros-na-funktsiyu_-_gruppa-obsluzhivaniya/message376057 http://mikrotik.moscow/forum/forum57/83384-zapros-na-funktsiyu_-_gruppa-obsluzhivaniya/message376057 Tue, 13 Mar 2018 16:15:00 -0400 RouterOS Запрос на функцию: «Группа обслуживания» Запрос на функцию: «Группа обслуживания» RouterOS в форуме RouterOS.
Ребята, я видел, что несколько человек спрашивали про возможность разрешать TCP и UDP в одном правиле для firewall/nat/mangle, но почему бы не зайти чуть дальше? Мне очень хотелось бы иметь опцию, похожую на Address Lists, но для разных протоколов/портов. Например: я создаю «Service Group» под названием «IPSec_VPN». В эту группу сервисов вошли бы: протокол UDP, порт назначения 500; протокол IPSec-ESP; протокол IP-Encap. Тогда я мог бы создать правило firewall/NAT/Mangle, использующее эту «Service Group» с такой же функциональностью, как мы используем Address Lists для адресов. Одно правило, которое срабатывает на множество условий, определённых в «Service Group».

Пример конфигурации firewall:

/ip firewall filter  
# цепочка input  
add action=accept chain=input connection-state=established,related  
add action=drop chain=input connection-state=invalid  
add action=accept chain=input limit=5,5 service-group="ICMP WAN"  
add action=accept chain=input service-group="ROS Management WAN" in-interface=ether1-WAN  
add action=accept chain=input service-group="ROS Management LAN" in-interface=ether2-LAN  
add action=accept chain=input service-group="ROS VPN" src-address-list="VPN Partners"  
add action=drop chain=input  

# цепочка forward  
add action=accept chain=forward connection-state=established,related  
add action=drop chain=forward connection-state=invalid  
add action=accept chain=forward in-interface=ether2-LAN out-interface=ether1-WAN comment="Allow LAN -> WAN"  
add action=accept chain=forward dst-address=XXX.XXX.XXX.XXX service-group="HTTP"  
add action=accept chain=forward dst-address=XXX.XXX.XXX.XXY service-group="DNS"  
add action=accept chain=forward dst-address-list=Servers limit=2,2 service-group="ICMP Servers"  
add action=drop chain=forward  

Address Lists будут определены так:  
Address List «Servers» содержит IP:  
XXX.XXX.XXX.YYY  
XXX.XXX.XXX.ZZZ  

Address List «VPN Partners» содержит IP:  
XXX.XX.X.YZ  
XXX.XX.XYZ.YZ  
XX.XYZ.XY.XY  

А Service Groups определены так:  
Service Group «ROS Management LAN» содержит:  
dst-port=5678,20561 protocol=udp  
dst-port=22,8291 protocol=tcp  

Service Group «HTTP» содержит:  
dst-port=80 protocol=tcp  
dst-port=443 protocol=tcp  

Service Group «DNS» содержит:  
dst-port=53 protocol=tcp  
dst-port=53 protocol=udp  

Service Group «ICMP Servers» содержит:  
icmp-options=0:0-255 protocol=icmp  
icmp-options=3:3 protocol=icmp  
icmp-options=3:4 protocol=icmp  
icmp-options=8:0-255 protocol=icmp  
icmp-options=11:0-255 protocol=icmp  

Service Group «ROS Management WAN» содержит:  
dst-port=8291 protocol=tcp  

Service Group «ICMP WAN» содержит:  
icmp-options=0:0-255 protocol=icmp  
icmp-options=3:3 protocol=icmp  
icmp-options=3:4 protocol=icmp  
icmp-options=8:0-255 protocol=icmp  
icmp-options=11:0-255 protocol=icmp  

Service Group «ROS VPN» содержит:  
protocol=UDP dst-port=500  
protocol=ipsec-esp  
protocol=encap  
protocol=ipip  

Это всего лишь примеры. Лично для меня это реально очистило бы цепочки firewall и таблицу NAT. Буду рад любой дискуссии на эту тему! Спасибо, tom
04.05.2012 10:38:00, tomaskir.]]> http://mikrotik.moscow/forum/forum57/83384-zapros-na-funktsiyu_-_gruppa-obsluzhivaniya/message376056 http://mikrotik.moscow/forum/forum57/83384-zapros-na-funktsiyu_-_gruppa-obsluzhivaniya/message376056 Fri, 04 May 2012 10:38:00 -0400 RouterOS