» MikroTik RouterOS (часть 3)

Цитата:

Задача ведь сделать резервный канал интернета, но только канал этот приходит на другую площадку, правильно?

faust72rus
да

исторически так сложилось
роутером был kerio winroute
потом появился L2 от провайдера
потом при лицензировании отказались от kerio - перешли на mikrotik
потом появился второй провайдер

а широковещательный домен по прежнему один.


Цитата:

Что то мешает разделить площадки на подсети и сделать между ними маршрутизацию?

даже не знаю инертность

к тому же связность офисов осуществляют коммутаторы провайдера - микротик тут будет еще одно звено - уменьшиться надежность (IMHO)

Dimsoft
Фактически из-за более правильного построения сети, разделения её на сегменты, создание живого резервирования канала по внешке (на случай падения провайдерского линка) надёжность только вырастет, как вырастет и управляемость и гибкость. Если всё таки этот вариант ну никак не подходит, то я пока не придумал как сделать работу двух каналов в твоей схеме. Может кто подскажет.

Сами прошли абсолютно точно такой же путь эволюции, от общей сети, через керио и фряху к микротику. Теперь каждая площадка в своём сегменте и всё смаршрутизированно с использованием OSPF и RIP. Аптаймы на некоторых маршрутизаторах более года.

faust72rus
так я понимаю, что разделить это более правильно
пока готовлюсь (морально) перевести контроллер домена в другую подсеть

при этом будет только по 1 контроллеру или как то надо думать как пробрасывать через микротик dhcp запросы

Цитата:

как пробрасывать через микротик dhcp запросы

DHCP Relay именно для этого предназначен

Chupaka
Dimsoft
Виндовый dhcp сервер не умеет передавать свои запросы через рэлей. (исключение составляет схема с использование dhcp-agent на isa сервере)

и как тогда поступить ?
сейчас через L2 объединены коммутаторы
на 2-х серверах (по 1 в каждом офисе) поднят DHCP на sbs2011 и standart 2003 90% адресов в резервировании, общий пул адресов поделен 80-20
по DHCP выдается два адреса DNS - контроллер в своем офисе и второй контроллер
профили и мои документы лежат в доменной DFS с репликами на обоих контроллерах.

при такой схеме оба офиса переживают смерть любого контролера (только exchange может умереть, тк он один)

как в данную схему вписать микротики и разные подсети ?

Добавлено:
пока просто сделал vrrp с главным в первом офисе - раздает обоим pppoe 8 мегабит
если во втором офисе падает канал до первого - второй офис начинает работать через свой микротик, первый сидит без интернета (пока второго провайдера нет)

Dimsoft
А в чём собстна проблема? Создаёшь подсети, разносишь в них контроллеры, в каждой по одному и по одному же dhcp серверу. На каждой площадке выдаёшь через dhcp оба dns сервера. (Никаких проблем не вижу)

Впихнуть в это дело микротик можно просто:

1. На девайсе включаешь в бридж два порта эзернет (LAN + 1)
В LAN включаешь локальную сеть
В "+1" включаешь канал до другой площадки
Таким образом получаешь трафик через маршрутизатор, но без изменения топологии.

2. Задаёшь адресацию, маршруты, уничтожаешь бридж.
Получаешь две независимые смаршрутизированные сети.

3. На одном девайсе шлюзом указываешь первый и нетвочем проверяешь шлюз провайдера (или что то такое), если этот узел не доступен, поднимаешь второй канал и переводишь на него основной шлюз (это очень краткий алгоритм реализации резервного канала)

faust72rus
а если у меня 1 контроллер упал ?
1 офис останеться без dhcp ?

Добавлено:
С vrrp я не лишаюсь резерва контроллеров (DHCP).
До контроллера и до второго достучится через шлюз только кто то должен раздать нужный dns

Dimsoft
Падение DHCP сервера никак не отразится на функционировании сети (в интервале от 0 до DHCP-release дней), но если так переживаешь, можно поднять дополнительный DHCP сервер на микротике, который будет включатся при недоступности виндового (там есть на это соответствующая опция).

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

Всё это дело хозяина сети. Т.е. твоё. Моё мнение = в твоём случае использование VRRP ненужно.

Цитата:

можно поднять дополнительный DHCP сервер на микротике, который будет включатся при недоступности виндового (там есть на это соответствующая опция).

faust72rus
можно про это по подробнее ?

Dimsoft
http://wiki.mikrotik.com/wiki/Manual:IP/DHCP_Server#Alerts
если сервера нет => включаем сервер

есть такая проблема, не проходит команда trcert с самого тика,
пинг идет нормально.... после отключения правила в Firewall:

Код: add action=drop chain=input comment="Drop everything else" disabled=no

faust72rus
не понял

/ip dhcp-server alert
on-alert (string; Default: )    Script to run, when an unknown DHCP server is detected.

это если есть, а как сделать если пропал ?

vlh
Команда блокирует всё что идёт на сам тик.
Исключение для трасерта можно сделать по протоколу icmp\igmp
Dimsoft
Вдруг пришло озарение и я решил, что проше создать нетвочь до твоего dhcp сервере, со скриптами включения и отключения локального dhcp

Цитата:

создать нетвочь до твоего dhcp сервер

faust72rus
точно - буду копать в этом направлении.

Цитата:

Команда блокирует всё что идёт на сам тик.  
Исключение для трасерта можно сделать по протоколу icmp\igmp

да, но почему пинг идет? он же то же по этому протоколу работает...


по поводу выполнения скрипта, скрипт выполняется и создается лог файл с:

Цитата:

Opening script file filter.auto.rsc
Script file loaded successfully
Script file loaded and executed successfully

я сделал export в файл, потом удалил одно правило, закачал файл по FTP,
скрипт сработал это видно из лога, но удаленное мною правило которое
точно есть в скрипте не добавилось...

vlh
Я вообще не уверен что инпут имеет отношение к исходящему трафику. Может адвансеты или Чупака меня поправят.

касательно DHCP - я бы смотрел в сторону параметра authoritative. если сервак завис и только пингуется, но не раздаёт адреса - это сработает гораздо лучше

chain=input - это пакеты, которые приходят на роутер. например, ответы на трассировку


Цитата:

да, но почему пинг идет? он же то же по этому протоколу работает

видимо, он где-то разрешён выше =) у меня отдельно стоящее такое правило блокирует даже пинг

я бы разрешил, например, icmp-options=11:0-255 - хотя лучше вообще icmp не запрещать

немного разобрался, но есть сомнения по поводу одного правила,
настраиваю firewal по схеме с wiki микротик - тут

Код: /ip firewall filter
add chain=input connection-state=invalid action=drop \
    comment="Drop Invalid connections"
add chain=input connection-state=established action=accept \
    comment="Allow Established connections"
add chain=input protocol=icmp action=accept \
    comment="Allow ICMP"
add chain=input src-address=192.168.0.0/24 action=accept \
    in-interface=!ether1
add chain=input action=drop comment="Drop everything else"

Цитата:

почему стоит !ether1? это же исключая этот интерфейс

угу. а по "туту" написано: "public (WAN) interface is ether1". т.е. даже если вражина заберётся чудом из Интернета с приватными адресами - фигу ему, доступ столько с других интерфейсов (т.е. LAN, etc.)

касательно трассировки, для не совсем понимающих и дабы быть уверенным, что "немного разобрался": работает правило
Цитата:

add chain=input connection-state=established action=accept \
comment="Allow Established connections"

при пинге пакет идёт от хоста A (наш роутер) к хосту Z (объект пинга). эта запись попадает в ConnectionTracking. ответ идёт от Z к A, и, поскольку такое соединение в ConnTrack уже есть, оно акцептится как established. далее, трассировка. пакет идёт от A к Z, а ответы приходят от промежуточных хостов (B, C, D, etc.), поэтому в established они ну никак не попадают. вот в этом и загвоздка.

з.ы. теоретически, они должны попадать в related - но в данно примере почему-то нет правила "chain=input connection-state=related action=accept", хотя в официальной вики оно есть (почти?) везде

Цитата:

касательно DHCP - я бы смотрел в сторону параметра authoritative.

Chupaka
киньте примером, как поймать "вдруг" появившийся DHCP я понял, а как узнать что он "умер" ?

Dimsoft
Чупака говорит о параметре authoritative в свойствах DHCP сервера у микротика, этот параметр определяет время ожидания локального dhcp сервера ответа другого сервера, по истечению этого тайм аута он сам отвечает клиенту на его запрос. Т.е. если через X секунд твой виндовый сервак не даст клиенту адрес, за него это сделает микротик =)


Но это никак не отменяет использование нетвоч. Т.е. если пинга нет совсем то что то можно сделать, например отправить админу (*Тебе) письмо.

All
Уважаемые, если кто либо строил Wi-Fi сети с использованием Mesh напишите! Очень нужно.

Цитата:

если кто либо строил Wi-Fi сети с использованием Mesh

нужен именно mesh? зачем? или всё же роуминг?

Chupaka
Хм... Начинаем сначала.
Есть офисное здание, 4 этажа. Прекрытия плотные но не глухие. Поставил точки 17 штук (от 3 на самом маленьком, до 5 на самом большом этаже). Задал на них один SSID. Теперь возник вопрос как более правильно объединить их в одно облако wifi. У нас WPA2 EAP + Radius.

faust72rus
что такое "облако"? чтобы клиенты могли перемещаться по этажам? это и есть роуминг. надо каждую точку посадить на свою частоту (чтобы не мешали друг другу), а настройки SSID и всякие пароля сделать одинаковыми. тогда при потере одной точки клиент будет цепляться на другую

Chupaka
Так и сделано, но этого недостаточно, потому что клиент постоянно переключается от одной точки к другой. Я подумал что нужно сделать WDS, так как можно будет расширить зону покрытия в случае необходимости.

Цитата:

Chupaka
угу. а по "туту" написано: "public (WAN) interface is ether1". т.е. даже если вражина заберётся чудом из Интернета с приватными адресами - фигу ему, доступ столько с других интерфейсов (т.е. LAN, etc.)

ни чего не понял...
что разрешает это правило, оно же разрешает action=accept...?
проход пакетов с IP адресов 192.168.0.0/24 к самому тику, потому как
chain=input
или я опять что то пропустил, я прочитал это правило как -
разрешить проход пакетов к самому тику указанным адресам кроме
LAN интерфейса, то есть с других можно а вот с LAN нельзя....
как то так..

Цитата:

разрешить проход пакетов к самому тику указанным адресам кроме
LAN интерфейса

ещё раз повторяю:
Цитата:

"public (WAN) interface is ether1"

т.е. разрешить пакеты отовсюду, кроме WAN. а LAN в примере - это ether2,3,etc

Цитата:

Chupaka
т.е. разрешить пакеты отовсюду, кроме WAN. а LAN в примере - это ether2,3,etc

спасибо, теперь думаю что дошло
вся проблема в переводе, короче WAN интерфейс находится на ether1,
и правило разрешает все пакеты кроме WAN то бишь ether1...
тогда подскажи как будет правильнее, если например у меня на ether2
поднимается PPPoE, то мне нужно указывать в правиле !PPPoE или !ether2?
PPPoE это туннель между тиком и сервером провайдера, получается что тут
вроде нечего блокировать.... тогда скорее всего правильнее будет сделать
!ether2, так как он смотрит в сеть провайдера...

и все равно есть еще вопросы, если у меня несколько внешних интерфейсов, то
необходимо создавать такое правило для каждого.... наверное конечно да... но что то я
уже перегрелся с тиком
и опять о работе этого правила, то есть оно запрещает прохождение пакетов на интерфейсе
смотрящем в мир от IP 192.168.0.0/24 кроме интерфейса LAN смотрящего в локальную сеть?
тогда получается что пакеты например из сети 10.0.0.0.24 будут проходить?