MikroTik. Резервирование канала и маршрутизация
 

Здравствуйте!
Имеется 2 роутера Микротик, один в головном офисе, другой в удалённом филиале. На первом поднят VPN сервер, второй является клиентом.
В нормальной работе связь между ними идёт по внутренней сети провайдера, если связи нет, то по 3G. На втором роутере заведено 2 подключения: VPN-LAN и VPN-3G. Tool Netwatch мониторит доступность VPN сервера по локалке провайдера, если пропадает, то выключает VPN-LAN и включает VPN-3G. На компьютере, подключенном ко второму роутеру программа постоянно передаёт данные по протоколу UDP на компьютер в локалке первого роутера. В фаерволе для srcnat прописан маскарадинг, а для dstnat - netmap на определённый порт этого компьютера. Всё работает нормально.

Вопрос в следующем.
При переключении канала с LAN на 3G, в программе пропадает связь на некоторое время. Я подозреваю, что таблица NAT (или ещё что-то в этом роде) не успевает обновиться и пакеты пытаются идти по старому маршруту. Как заставить пакеты идти по новому маршруту сразу после переключения?

MikroTik RouterOS 6.17

Вам нужно снифить пакеты на интерфейсах и смотреть кто и куда направляется в момент переключения. Возможно задержка во время поднятия 3G сессии или VPN сессии. Пока нет подключения - пакеты не идут.

К слову о какой задержке во времени идёт речь?

Можно держать подключенными сразу оба канала, но с разной метрикой (стоимостью). При падении одного будет переход на другой и т.д.

Это то понятно, что пока переключаются интерфейсы, пакеты не идут. Задержка от 3 до 15 минут. Т.е. пинг идёт, а UDP трафик нет.

Не очень удобно в моей конфигурации. Да и попытки подключения, к примеру, клиента VPN-LAN, при отсутствии связи по локалке, весь лог загадят. В общем, удобнее переключать.

А вот здесь поподробнее, пожалуйста. Как это сделать? И можно ли штатными средствами микротика?

Вот этот момент интересен как ни какой другой! Если идёт ICMP - то канал поднялся. Дальше уже стыки ПО. Возможно где-то соединения повисают и ПО ждёт ответа, а только после истечения времени считает соединение зависшим и переподключается.

Вы в праве отключить логирование любого процееса.

В МТ есть встроенная утилита Tools -> Packet Sniffer. Выбираете интерфейс и указываете фильтры. Если кратко, то система слушает и все пакеты сохраняет в отдельный файл. Далее можно воспользоваться утилитой Wireshark и в удобной форме просмотреть все пакеты и их заголовки. Советую почитать теорию (tcpdump, wireshark)

Вопрос с пропаданием связи при переключении отошёл на второй план, сейчас вылезла другая проблема.

Нет связи между двумя VPN клиентами.





Оборудование в Филиале 1 передаёт данные на компьютер в Центральный офис и в Филиал 2. Правила NAT прописаны. В Центральном офисе программа данные получает, а в Филиале 2 - нет, причём пинг есть.
Роутер 10.0.0.1 является VPN сервером. Если посмотреть ip firewall connections, то увидим, что сервер подменил своим IP-адресом адрес отправителя. Возможно, поэтому программа и не устанавливает соединение с оборудованием.




Есть ли какая-нибудь возможность построить VPN сеть, чтобы пакеты от одного VPN-клиента отправлялись на другой без подмены VPN-сервером IP адреса?

Всё, разобрался. Зачем-то поставил маскарадинг из сети 10.0.0.0/24, вот роутер и подставлял свой адрес. Убрал, теперь весь трафик между VPN клиентами идёт нормально.

BBKa, меня смутил один факт. У вас в трёх разных физических сегментах сети используется один и тот же логический сегмент (сеть 192.168.88.0/24)?
Для филиалов в качестве шлюза используется 192.168.88.1? И у вас на картинке есть два девайса с одним и тем же адресом 192.168.88.2? Или трафик из филиала в центр натится?

Да, LAN - это за NAT'ом роутеров.

NAT в VPN сети как мне кажется не нужен.

Как сделал я:
- у всех филиалов разные непересекающиеся сети 192.168.88.0/24, 192.168.77.0/24, 192.168.66.0/24,
- отдельная сеть для VPN клиентов и VPN сервера 192.168.22.0/24 (можно взять сеть меньше; /29 вам подойдёт)
- настроить подключение между VPN сервером и VPN клиентом
- прописать маршруты между сетями, через VPN интерфейсы.

Что получим в итоге:
- из любой точки сети можно подключиться в любую точку сети (в условиях работы NAT это в общем виде невозможно)
- ресурсы роутера расходуются оптимальнее т.к. маршрутизировать пакет проще чем натить
- схема логичнее.

Да, спасибо за замечание, так намного логичнее получается.
Сделал так, но возникла проблема. Компьютеры с Windows не пингуют и не пингуются.

Допустим, компьютер IP 192.168.100.1/24, шлюз 192.168.100.254. С него пингуем 192.168.200.1. Маршруты на роутерах прописаны.
Вывод команды ping:
При этом машина на Linux'е нормально пингует при такой схеме. Что я делаю не так?

Маршруты с роутеров покажите

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

Компьютер (192.168.110.1/24) --> Роутер (192.168.110.254/24)

Если на компьютере запустить пинг на 192.168.111.254, то на роутере в ip firewall connections должно появиться это соединение, а его там нет. И ответ "назначение недоступно" на команду пинг приходит не от роутера, а от интерфейса 192.168.110.1 компьютера.

Меня больше настораживают маршруты компьютера.

Сейчас скину вывод команды route

Всё, разобрался. На тестовом компьютере была неправильно настроена маршрутизация.

Зачем вам маршрутизация на компьютере?

Имел ввиду вывод команды route. Там из-за установленной виртуальной машины маршруты по умолчанию изменились и куда-то не туда отправляли.