[РЕШЕНО через костыль] Перестаёт работать dst-nat

[Sir_Prikol]

Доброго времени суток.
Имеем следующую конфигурацию:

Входящий RB3011, за ним стоит RB2011 (остальные в данной проблеме не важны и не участвуют)
Имеем WAN - 123.123.123.123
LAN 192.168.0.0/24
RB3011 - LAN - 192.168.0.1
RB2011 - 192.168.0.2

На RB2011 подняты sstp, l2tp,pptp серверы
На RB3011 подняты dst-nat на RB2011 по портам этих серверов и находятся в самом верху правил (без passrouth)

В фаерволе что на RB3011, что на RB2011 разрешены gre и даныые порты серверов и подняты на самый верх

Ситуация - связка работает, авторизация проходит на RB2011, но через некоторое время (иногда час иногда 3-е суток) dst-nat прекращает работать и, хоть счётчик пакетов увеличивается, пакеты до RB2011 не долетают.
В логах RB3011 - видно что правило отработало, в логах RB2011 девственная чистота.
После ребута RB3011 всё становится нормально, но опять до какого-то времени.

Часть настроек участвующих в данной реализации
RB3011

Код: Выделить всё

/ip firewall nat
add action=dst-nat chain=dstnat comment=PPtP dst-address=123.123.123.123 dst-port=1723 to-addresses=192.168.0.2 to-ports=1723 disabled=no
add action=dst-nat chain=dstnat comment=SStP dst-address=123.123.123.123 dst-port=12443 to-addresses=192.168.0.2 to-ports=12443 disabled=no
add action=dst-nat chain=dstnat comment=L2TP dst-address=123.123.123.123 dst-port=1701 to-addresses=192.168.0.2 to-ports=1701 disabled=no

RB2011

Код: Выделить всё

/ip firewall filter
add action=accept chain=input  disabled=no  dst-port=1723 protocol=tcp
add action=accept chain=input disabled=no  dst-port=12443 protocol=tcp
add action=accept chain=input  disabled=no  protocol=gre 

Эти головняки начались начиная с 6.42.6, как я и говорил, тенденция
Куда копать?

[Chupaka]

Доброго.

через некоторое время (иногда час иногда 3-е суток) dst-nat прекращает работать и, хоть счётчик пакетов увеличивается, пакеты до RB2011 не долетают.
В логах RB3011 - видно что правило отработало, в логах RB2011 девственная чистота.

Куда копать?

В первую очередь - понять, куда девается пакет. Например, добавив правило типа

Код: Выделить всё

/ip firewall filter add chain=forward dst-address=192.168.0.2 action=passthrough log=yes

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

Или Tools -> Torch подтвердить, что пакет действительно улетает с 3011 на 2011. Посмотреть, что он на 2011 не появляется тем же Torch'ем. Роутеры соединены патчкордом порт в порт?

[Sir_Prikol]

RB3011

RB2011


Но все сервера молчат
192.168.7.2=192.168.0.2

[Sir_Prikol]

UPD: на 2011 появились после ребута 2011. но sstp сервер молчит, и это будет продолжаться до ребута 3011

[Chupaka]

Кто появился?

Log для NAT не показывает out-interface, поэтому я и писал про filter forward. Но тут проблема может быть с обратным пакетом, раз до 2011 SYN'ы долетают. В общем, Torch и log=yes в помощь - смотреть полный путь пакета от клиента к 3011, 2011 и обратно. А вот где пакет пропадёт - там и смотреть, почему.

[Sir_Prikol]

Вот и я думаю что проблема именно с обраткой, но в моей маршрутизации такого наверчено, что без бутылки новую добавить - не совсем можно. Проще нетмапом сделать А ещё проще выдать белый ip на тот самый 2011 и забыть как страшный сон, но сам принцип...
В общем фигнёй страдает именно RB3011, так как с 3011 на 2011 спокойно проходит авторизация, а снаружи, через 3011, нифига. И с любого другого устройства внутри сети - работает

[Chupaka]

В общем фигнёй страдает именно RB3011, так как с 3011 на 2011 спокойно проходит авторизация, а снаружи, через 3011, нифига. И с любого другого устройства внутри сети - работает

Не факт, не факт. Тем более в свете упоминания навороченной маршрутизации Может и в 2011 причина быть. В общем, как я и сказал, надо отследить пакет - вдруг станет понятнее. На 3011 в forward'е, на 2011 - в output'е.

[Sir_Prikol]

Пакет отслежен, он теряется в OSPF. А вот тут засада. Сам по себе OSPF начинает мозг компосировать, если я ему прописываю /24 маршрутизацию, а по sstp выдаю /30, меняю в OSPFна /30, маршрутизация ложится вообще. Сегодня донапишу отказ от OSPF. Перелопачу полную маршрутизацию руками. Проще рутинг марками сделать, нежели на автомат полагаться.

UPD: Вся эта хрень начинает корректно работать на дефолтных маршрутах, вот осталось заставить понимать пакет, чтоб он уходил туда-же откуда пришёл. Или, как вариант, всё-таки выделить отдельный IP и отдельный канал для этих соединений, что реально, так как три канала аплинка, один отдать под sstp,l2tp,pptp и будет счастье

[Chupaka]

Вообще ничего не понял

Что значит "теряется в OSPF"? OSPF строит таблицу маршрутизации, он ничего с пакетами сам не делает.

Что значит "на дефолтных маршрутах"? "чтоб он уходил туда-же откуда пришёл" - это Policy Routing в помощь.

[Sir_Prikol]

Вот как раз PBR и глючит на 3011, на нём единственном, идентичная конфа на 1100 - работает на ура, на 1009 то-же. Очередной косяк именно с RB3011, это уже не первый раз когда на этом маршрутизаторе выявляются косяки не свойственные для другой модели. Есть желание увидеть как там и что - могу дать доступ Но на этом маршрутизаторе уже побывало 5 человек, с серификатами ибез, и ответ один - всё должно работать А оно отрубается

[Sir_Prikol]

Как я и предупреждал, не отрабатывает arp на RB3011, в связи с этим шлюз кажется доступным, а пакеты теряются Решил эту проблему по другому, через cname и /ip cloud

Так как у меня везде белая сеть, то через CNAME просто привязал ddns микротика на свой поддомен, и коннектится можно по имени, а не по ip

Сделал простейший скрипт, который обновляет в /ip cloud нужный мне аплинк и дальше простым нетмапом.

Кому интересен скрипт -

Код: Выделить всё

#variable to store the IP address of the Primary gateway you wish to use to update the MikrotikCloud DDNS
:local PrimaryGW "<Primary Gateway IP>"
 
#variable to store the IP address of the Secondary gateway you wish to use to update the CloudIP DDNS
:local SecondaryGW "<Secondary Gateway IP>"
 
#The url of the Mikrotik Cloud DDNS (for ipv4) if need ipv6 use cloud2.mikrotik.com
:local cloudIPDDNS "cloud.mikrotik.com"
 
#resolve the ip address
:resolve $cloudIPDDNS
 
#Delete any routes that already exist with distance 30 and 31
/ip route remove [find distance="30"]
/ip route remove [find distance="31"]
 
#Add the new default routes to the Mikrotik Cloud DDNS
:foreach aRecord in=[/ip dns cache all find where (name=$cloudIPDDNS && type=”A”)] do={
/ip route add dst-address=[/ip dns cache all get $aRecord data] gateway=$PrimaryGW distance=”30″;
}
 
:foreach aRecord in=[/ip dns cache all find where (name=$cloudIPDDNS && type=”A”)] do={
/ip route add dst-address=[/ip dns cache all get $aRecord data] gateway=$SecondaryGW distance=31;
}

Далее простой нетмап на нужный ip тоже скриптом
Вот как-то так

З.Ы. Странность с маршрутами была ещё следующая, чек маршрутов через пинг и арп были сделаны по разному (признаю, мой косяк) арп был сделан на pppoe клиентов (2шт) а пинг был сделан на физический интерфейс. Может из-за этого глючило, не знаю, сейчас RB3011 был в ребуте, соответственно всё поднялось, когда отрубится - буду искать дальше.
В принципе, у меня задача стоит выделить для sstp один единственный канал, остальные это выход в мир. Сделано это из-за того, чтобы можно было закконектится в любом случае, даже при падении промежуточных каналов связи. Аплинк для sstp,l2tp,pptp - магистральный, у него аптайм гарантирован, всместе со скоростью

[Chupaka]

Ну, вроде бы логично, что arp-проверка работать на pppoe-интерфейсе не будет - не тот тип интерфейса

[Sir_Prikol]

Я то эту логику понимаю, но.... У одного прова juniper по кривому настроен На пинг реакции нет, только на arp, причём arp через pppoe. Ну это пошла дибильная политика компании, оттуда ушло много толковых ребят, остались пионеры, вот и ловлю глюки на их аплинках, плюс, ко всему прочему, juniper мало того что криво настроен, так они ещё что-то настроили так, что 2-е суток выдавало серую сеть вместо белой, я уже ручками ip адреса прописывал, пока не восстановили

[Chupaka]

А что-нибудь такого типа не поможет? https://wiki.mikrotik.com/wiki/Advanced ... _Scripting

Ну и... А разве может быть такое, что pppoe поднялся и не отваливается, а шлюз недоступен? О_о

[Sir_Prikol]

У нас может быть всё, так как ставят шляпные свитчи. Вот и получается, выставляешь таймаут в 30 сек, вроде pppoe поднят, вроде в норме, потом отвал шлюза - сессия ещё пытается что-то проверить, и начинается, глючит свитч по дороге (частенько порты по скоростям падают) соединение есть - шлюз виден через раз. Это всё экономия В личку кинул свою конфу, так как лениво IP переделывать, слишком много

[Sir_Prikol]

Блин, тупость какая-то, пытаюсь уменьшить количество правил в NAT, вместо входящего ip выставляю список интерфейсов аплинка, тут-же перестаёт работать доступ внутри сети по внешним адресам. Имеется ввиду следующее:
ip сайта - 192.168.0.178
внешний ip - 123.123.123.123
изнутри с компа 192.168.0.10 лезу по имени blablabla.bla (ip 123.123.123.123) при использовании в dstnat листа интерфейсов - не работает, при явном прописанном ip работает.
Не, умом я понимаю, что оно не должно работать, так как не понятно по какому ip лезть и куда выстраивать маршрут, но так не должно быть, надо предусмотреть возможность использования и ip и листа в одном правиле Единственное я вижу, это использование не Interface list, а address-list, но сегодня уже делать не буду, как-нить позже проверю

[Sir_Prikol]

Ааааааа, дурдом какой-то.
В общем добился следующего.
dst-nat отрабатывает, клиент цепляется, но.... в один прекрасный момент он может и не зацепится вообще, до какого момента не выяснено, в то-же время с другого ip всё в норме проходит и всё работает.

Как пример, чтоб понятней было

Тестовые 3 mikrotik клиента
1- законнектился, 2 законнектился, 3 - законнектился
Через какое-то время (или действо) 2-ой переподключаю - шиш, подключения нет, при этом переподключения 1 и 3 спокойно работают
Такое ощущение, что где-то ловлю бан или по маку или по ip, но перелопатил весь микроб, ни где не светится ip и mac. Ни в соединениях ни в адреслистах, ни в инвалидных пакетах.

В общем мозг сломан, глаза в кучу.... Такая проблема была на 6.10, но там решалась простым энкрипшеном в профиле, тут вообще что-то не понятное. Не хочется откат делать на 6.42.7, где всё это работало.

[Sir_Prikol]

Ихаааа, папочка рулит

Проброс портов на железных Микротиках иногда требует специального описания маскарада для ответных пакетов.
Признаком такой ситуации как раз является состояние соединения "syn sent". Для решения требуется создать еще одно правило маскарада:
add action=masquerade chain=srcnat dst-address=xxx.xxx.xxx.xxx dst-port=xxx protocol=tcp

Фисё, как только это правило появилось - заработали все клиенты

[Chupaka]

Ух, сколько всего

вместо входящего ip выставляю список интерфейсов аплинка, тут-же перестаёт работать доступ внутри сети по внешним адресам

Логично: пакеты изнутри сети приходят не с аплинка Можно попробовать dst-address-type=local - тогда будут ловиться пакеты на любой адрес роутера (включая внутренние)

Проброс портов на железных Микротиках иногда требует специального описания маскарада для ответных пакетов

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

[Sir_Prikol]

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

Согласен, но маскарад реально спасает, особенно когда особо нет времени на выяснение причины и простаивает система, а это потеря денег Поэтому решения с маскарадом такие популярные, идеального нет в этом ничего, в последствии, естественно, будет найдено решение без маскарада

Логично: пакеты изнутри сети приходят не с аплинка Можно попробовать dst-address-type=local - тогда будут ловиться пакеты на любой адрес роутера (включая внутренние)

Это решилось путём создания wan-list в adress-list с ip wan интерфейсов, так что предположение было верным

[Chupaka]

в последствии, естественно, будет найдено решение без маскарада

Минутка троллинга суровой реальностью: спорим, не будет xD

[Sir_Prikol]

Ну как сказать Я ещё тот "ботаник", я-же найду