NAT и дополнительный хоп

Обсуждение ПО и его настройки
centner
Сообщения: 14
Зарегистрирован: 07 фев 2018, 17:22

Всем привет!

Сразу прошу прощения, если объясняю сумбурно, но постараюсь :)

Имеем: два маршрутизатора RB2011, назовем их условно R1 и R2. Версия софта - 6.40.3.На них поднят VRRP. Топология примерно такая( изображаю интересующую нас часть, есть в топологии еще устройства, поэтому не надо спрашивать, почему все так, а лучше сделать по-другому. По-другому сделать невозможно. ):

Интернет
|
R1(VRRP Priority=200)---------Сеть партнера
|
клиент---VRRP
|
R2(VRRP Priority=100)---------Сеть партнера(альтернатива)

Для клиента основным шлюзом является IP адрес vrrp. Как видно из приоритетов, основным шлюзом для клиента является R1.

Далее, на R2 настроен dst-nat на ip адрес клиента. Вот тут то вся петрушка. Соединение инициируется от хоста в сети партнера именно через альтернативный канал к нашему клиенту и натится на R2.
Т.е. пакет идет так:
ТУДА: Из сети партнера через R2 сразу к клиенту
ОБРАТНО: От клиента на R1, далее на R2 и в сеть партнера.

При всем при этом на R2 в коннектах файрвола видим, что пакеты принимаются, однако обратно ничего не отправляется.
Bytes: 2439 B/0 B
Packets: 14/0
Со стороны партнера так же говорят, что не видят от нас ответов.

Однако, если соединение инициировать от нашего клиента в сеть партнера - то все отлично(для проверки этого создавали отдельное правило для src-nat).

Я подозреваю, что причиной тому - работа NAT плюс дополнительный хоп на обратном пути. Т.е. если поменять приоритеты VRRP и основным шлюзом насильно сделать R2 - то все начинает бегать как надо.

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


enzain
Сообщения: 291
Зарегистрирован: 26 дек 2017, 22:30

centner писал(а):Далее, на R2 настроен dst-nat на ip адрес клиента. Вот тут то вся петрушка. Соединение инициируется от хоста в сети партнера именно через альтернативный канал к нашему клиенту и натится на R2.
Т.е. пакет идет так:
ТУДА: Из сети партнера через R2 сразу к клиенту
ОБРАТНО: От клиента на R1, далее на R2 и в сеть партнера.


Добавте следом SRC-NAT - на адрес внутренний маршрутизатора R2
И схема поменяется на:
ТУДА: Из сети партнера через R2 сразу к клиенту
ОБРАТНО: От клиента на R2 и в сеть партнера.


centner
Сообщения: 14
Зарегистрирован: 07 фев 2018, 17:22

Спасибо за ответ! Тока что-то не особо догнал, что во что натить? Src адрес хоста в сети партнера во внутренний адрес R2?


enzain
Сообщения: 291
Зарегистрирован: 26 дек 2017, 22:30

centner писал(а):Спасибо за ответ! Тока что-то не особо догнал, что во что натить? Src адрес хоста в сети партнера во внутренний адрес R2?


Да.

если у вас маршрутизации нет в ту сеть (а раз вы натите DST то ее видимо нет) - то так проще всего сделать будет


centner
Сообщения: 14
Зарегистрирован: 07 фев 2018, 17:22

Не, не прокатывает фокус...
Все равно в connections ответы - по нулям...


centner
Сообщения: 14
Зарегистрирован: 07 фев 2018, 17:22

А, вру, видимо старое соединение осталось. Удалил, новое соединение поперло уже с правилом src-nat. Спасибо за интересное решение!

А есть еще способы исправить? Может в прошивке дело? Или еще в чем?


enzain
Сообщения: 291
Зарегистрирован: 26 дек 2017, 22:30

centner писал(а):А, вру, видимо старое соединение осталось. Удалил, новое соединение поперло уже с правилом src-nat. Спасибо за интересное решение!

А есть еще способы исправить? Может в прошивке дело? Или еще в чем?


Так а зачем?

Если надо посмотреть другое решение - нужны конфиги.

И сети из которых к вам бегут пакетики ...


centner
Сообщения: 14
Зарегистрирован: 07 фев 2018, 17:22

Ну как зачем, чтобы понять причину такого поведения(именно с Mikrotik столкнулся совсем недавно). Я же правильно понял, что причина - это логика работы dst-nat? Наверняка из-за дополнительного хопа R2 не понимает, что обратно пришел пакет именно этой сессии. Вот я как раз про то, возможно есть какие-то исправления в работе dst-nat в других версиях софта.

P.S. Конфиги предоставить мне никто не разрешит конечно :)...


enzain
Сообщения: 291
Зарегистрирован: 26 дек 2017, 22:30

centner писал(а):Ну как зачем, чтобы понять причину такого поведения(именно с Mikrotik столкнулся совсем недавно). Я же правильно понял, что причина - это логика работы dst-nat? Наверняка из-за дополнительного хопа R2 не понимает, что обратно пришел пакет именно этой сессии. Вот я как раз про то, возможно есть какие-то исправления в работе dst-nat в других версиях софта.

P.S. Конфиги предоставить мне никто не разрешит конечно :)...


Количество хопов - в принципе фиолетово для IP, туда пакет может идти по одному маршруту, обратно - по другому. Это нормальная ситуация в сетях в принципе (не относится к микротику, вообще, хоть циска, хоть микротик, хоть длинк)
НО - на R1 вы можете увеличить TTL именно этих пакетов на единицу, и проверить свою теорию, никто не запрещает этого делать.

Если конфиги недоступны, будет сложно ... :)

Для начала - зачем вы вообще делаете DST-NAT? У вас нет маршрутизации в сеть из которой приходят пакеты?

Нарисуйте хотя бы схему с адресацией тогда, чтобы хоть что-то понять

По идее если у вас на R1 прописан маршрут в ту сеть, откуда идет запрос то этот роутер не учавствует в маршрутизации совсем, он должен отправлять icmp redirect на внутренний адрес R2 (в настройках надо выставить что он может отправлять этот редирект)


centner
Сообщения: 14
Зарегистрирован: 07 фев 2018, 17:22

Вот и я за то, что дополнительный хоп на обратном пути не должен никак влиять на ситуацию.
Зачем мы делаем dst-nat. Партнер может маршрутизировать только определенное количество адресов в нашу сторону. Чтобы все делать без ната - нам количества адресов не хватает, поэтому изворачиваться путем dst-nat.

Давайте примерно попробую изобразить схему с адресами.


(192.168.1.1/24)R1(VRRP Priority=200)(172.30.50.2/30)---------(172.30.50.1/30)Сеть партнера----Хост(10.20.1.21)
|
клиент(192.168.1.21/24)---VRRP(192.168.1.3/24)
|
(192.168.1.2/24)R2(VRRP Priority=100)(172.30.50.6/30)---------(172.30.50.5/30)Сеть партнера(альтернатива)----Хост(10.30.1.21)

И партнер нам говорит, что в нашу сторону может маршрутизировать только подсеть 10.10.1.0/29. Для того, чтобы из сети партнера наши хосты были доступны, приходится их натить, т.к. количество хостов, которые должно быть доступно с нашей стороны - равно 6, и адресов из смашрутизированной со стороны партнера в нашу сторону сети не хватает даже, чтобы прописать ну хотя бы на vrrp.
Таким образом, Хост 10.30.1.21 должен достучаться до нашего клиента по адресу 10.10.1.2 по альтернативному каналу. Маршруты на подсети партнера есть на обоих маршрутизаторах. Т.е. на R1 в сеть 10.30.1.0/24 - через R2, На R2 в сеть 10.30.1.0/24 - через 172.30.50.5. На партнерской стороны маршрут на сеть 10.10.1.0/29 через 172.30.50.6.


Ответить