+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Проблема с резервированием L2TP при использовании VRRP.

Проблема с резервированием L2TP при использовании VRRP., RouterOS

maxkrok

Guest

04.10.2012 17:42:00

У нас есть два RB1100xAH2 – с vrrp между ними. Первый RB1100 имеет адрес x.x.x.203, второй RB1100 – x.x.x.204, виртуальный IP – x.x.x.202 vrrp. Все работает хорошо, и когда первый роутер выходит из строя, второй начинает работать. Проблема в том, что L2TP клиенты отправляют запрос на виртуальный адрес x.x.x.202, а получают ответ с "физического" адреса от роутера x.x.x.203 или x.x.x.204, и соединение не устанавливается.

iprob Guest	#2 0 24.10.2012 13:36:00 Прости, я новичок и тоже разбираюсь в этом. У меня та же проблема, и я не знаю, как составить правило для mangle. Можешь привести пример, пожалуйста?

mrz Guest	#3 0 24.10.2012 13:47:00 /ip firewall mangle add chain=output protocol=udp port=1701 action=mark-routing new-routing-mark=vrrp /ip firewall nat add chain=srcnat action=masquerade out-interface=vrrp /ip route add gateway= routing-mark=vrrp

iprob

Guest

24.10.2012 14:19:00

Кажется, я продвигаюсь вперед. Ранее в логах повторялись сообщения "first L2TP UDP packet received", а IPSec SA был только в одну сторону. Сейчас IPSec SA вижу с обеих сторон, но трафика по SA на выход нет. Стоит отметить, что на стороне "LAN" устройства ещё работает VRRP, но это, по идее, не должно влиять на установку туннеля. Пытался с указанием и без указания локального IP в PPP-соединении, но именно там кажется, что происходит сбой. Вот последнее, что я вижу в отладочном логе:
07:15:06 l2tp,debug,packet ppp: (M) Framing-Capabilities=0x1
07:15:06 l2tp,debug,packet ppp: (M) Bearer-Capabilities=0x0
07:15:06 l2tp,debug,packet ppp: Firmware-Revision=0x1
07:15:06 l2tp,debug,packet ppp: (M) Host-Name=“10100001-ipfw1”
07:15:06 l2tp,debug,packet ppp: Vendor-Name=“MikroTik”
07:15:06 l2tp,debug,packet ppp: (M) Assigned-Tunnel-ID=220
07:15:06 l2tp,debug,packet ppp: (M) Receive-Window-Size=4
07:15:06 ipsec,debug,packet ppp: KA: PUBLICVRRP[4500]->REMOTECLIENTIP[4500]
07:15:06 ipsec,debug,packet ppp: sockname PUBLICVRRP[4500]
07:15:06 ipsec,debug,packet ppp: send packet from PUBLICVRRP[4500]
07:15:06 ipsec,debug,packet ppp: send packet to REMOTECLIENTIP[4500]
07:15:06 ipsec,debug,packet ppp: src4 PUBLICVRRP[4500]
07:15:06 ipsec,debug,packet ppp: dst4 REMOTECLIENTIP[4500]
07:15:06 ipsec,debug,packet ppp: 1 times of 1 bytes message will be sent to REMOTECLIENTIP[4500]
07:15:06 ipsec,debug,packet ppp:

Есть ещё какие-нибудь предложения?

iprob

Guest

24.10.2012 21:46:00

Это не сработало. Я даже пытался обойти преобразование NAT и перенаправлять весь трафик на удаленное местоположение, на, как я полагаю, IP-адрес VRRP public interface? Не могу понять, как заставить как IPSec, так и L2TP использовать IP-адрес VRRP.

maxkrok

Guest

27.10.2012 08:54:00

Что ты имеешь в виду под "out-interface=vrrp" и "gateway="? Это разные интерфейсы или один и тот же...? Когда мы делаем такие настройки, получаем один и тот же результат: пакеты возвращаются не от VRRP, а от IP-адреса физического интерфейса...

iprob Guest	#7 0 27.10.2012 11:59:00 Получилось заставить это работать только на адресах, не использующих VRRP. Пришлось настроить DNS round-robin, чтобы обойти эту проблему. Похоже, не работает с VIP-адресами.

iprob

Guest

08.11.2012 15:08:00

Более тщательное тестирование показало, что DNS round robin тоже не работает. Проблема в том, что если подключаешься через L2TP к роутеру, который не является VRRP master, трафик не проходит во внутреннюю сеть. Подозриваю, что это связано с mangle, который заставляет outbound NAT использовать IP-адрес VRRP data. У кого-нибудь есть работающая L2TP с VRRP для публичного IP-адреса подключения? Есть какие-нибудь идеи, почему это может не работать?

mrz Guest	#9 0 08.11.2012 15:11:00 Конечно, это не сработает. Нужно разрешить пользователям подключаться только к VRRP-адресу, остальное заблокировать в файрволе.

iprob Guest	#10 0 08.11.2012 15:39:00 Связь по VRRP-адресу не работает, что посоветуете? Правила, которые были предоставлены ранее в посте, проблему не решили. Так что говорить использовать VRRP-адрес, который не работает, не помогает.

iprob

Guest

#11

08.11.2012 16:46:00

Вот еще информация, полученная при перехвате пакетов: сценарий с не-VRRP публичным IP (VRRP работает, маршрутизатор является мастером): IPSec установлен, а L2TP пакеты обмениваются с использованием публичного IP интерфейса, А НЕ VRRP адресом. Я вижу пакеты с целевыми портами 1701, устанавливающими L2TP туннель. Соединение устанавливается успешно, пока маршрутизатор является мастером. Используемый интерфейс — ether1. Это, в принципе, не должно работать, потому что у меня есть правило NAT, которое предписывает использовать мое src-nat правило для назначения исходящего IP адреса VRRP адресом для всего трафика с исходящим интерфейсом ether1. Так почему бы тогда не использовать IP адрес, назначенный ether1? Правило src-nat находится в позиции 0 в списке NAT брандмауэра в Winbox. Сценарий с VRRP IP: IPSec установлен, и L2TP пакеты принимаются из удаленного местоположения. Нет ОТВЕТОВ от маршрутизатора MikroTik на какой-либо входящий трафик на порту 1701 (L2TP). IPSec пакеты показывают исходящий IP как VRRP адрес, что соответствует правилу src-nat. Похоже, что L2TP сервер не слушает VRRP адрес. Я также не понимаю, почему сценарий без VRRP работает, но, если честно, мне все равно, если получится заставить его работать с VRRP адресом. Не уверен, есть ли инструмент netstat в MikroTik, так что как проверить, слушает ли L2TP на VRRP адресе?

iprob

Guest

#12

08.11.2012 17:56:00

Я прочистил все соединения и перезагрузил роутеры. Теперь я получаю ответы, используя сценарий с VRRP. Проблема в том, что ответы отправляют публичный IP интерфейса ether1, а НЕ IP VRRP. Это напрямую нарушает правило NAT, которое я настроил на роутере, согласно которому весь трафик, выходящий через интерфейс ether1, должен использовать src-nat и присваивать IP VRRP. L2TP обходит правила NAT? Если да, то почему?

iprob

Guest

#13

09.11.2012 15:39:00

Есть какие-нибудь предположения, почему оно не использует правило NAT? Публичный IP, который возвращается в пакетах L2TP, определённо не VRRP-адрес, определённый в правиле NAT, что и создаёт проблему. Я также открыт к любым возможным обходным путям для решения этой проблемы. Сейчас кажется, что L2TP сломался с VRRP.

stormcloud

Guest

#14

31.03.2014 23:03:00

Кто-нибудь уже нашёл способ обойти это? Я могу установить соединение, используя физический IP на L2TP сервере, но если я попытаюсь использовать VRRP IP, клиент просто пишет "соединяется". Все остальное без изменений – я могу подключиться с помощью L2TP клиента с физическим WAN IP, но не с VRRP IP.

iprob Guest	#15 0 01.04.2014 12:45:00 Мы отказываемся от VRRP. Проблема с его корректной работой в связке с outbound NAT, L2TP, STS IPSec туннелями и другими возникшими проблемами сделала его скорее проблемой, чем решением. Мы будем создавать избыточность через KVM-уровень, а пока будем полагаться на резервные копии, которые можно восстановить менее чем за 5 минут. Наше оборудование очень устойчиво (RAID и т.д.) и находится под мониторингом, а также у нас есть горящие резервные устройства. VRRP в основной маршрутизации на MikroTik 1100 пока не вызывал проблем, поэтому мы оставляем его там. Только в тех местах, где мы используем MikroTik в качестве файрвола. Знаю, это не то, что вы хотели услышать.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры