[mrrc]

Воскресного дня,
Что-то столкнулся с такой задачкой и не могу найти решения, которое при первом приближении находится на поверхности.
Есть маршрутизатор, одним интерфейсом смотрящим наружу в интернет (ether1) и внутренней пользовательской подсеткой (10.1.10.0/24). Также на маршрутизаторе поднят l2tp+ipsec впн-тоннель до удаленного офиса для связанности с одной удаленной подсетью (192.168.10.0/24), на которую поставлен маршрут через впн-тоннель, которая должна быть доступна здешним локальным пользователям наряду с доступом в интернет.

Если не включать nat для пользовательской подсетки (10.1.10.0/24), пакеты с удаленной подсетью (192.168.10.0/24) через впн-соединение ходят исправно.
Если же включить masquerade или src-nat для пользовательской подсетки (10.1.10.0/24) для возможности пользователям иметь доступ к интернет, утрачивается доступность удаленной подсети (192.168.10.0/24).

Дайте мысль, как обеспечить одновременный доступ в интернет и доступность уделенного сегмента подсети через впн-канал.
Исключение в правиле нат-а сетевого сегмента (192.168.10.0/24) в качестве dst-назначения или различные варианты построения данного правила с отрицанием не привело к успеху. Даже написание поста, как зачастую бывает, не придало варианта решения задачки.

[jffulcrum]

Конфиг выкладываем, потерев публичные IP адреса.

[mrrc]

@jffulcrum 

Казалось бы, проще некуда.

Включаю nat - у пользователей "локалки" утрачивается связанность с удаленной подсетью 192.168.77.0/24 по ту сторону впн-тоннеля.

 

# 2024-02-25 17:05:11 by RouterOS 7.13.5
#
# model = RB4011iGS+
/interface bridge
add name=bridge_lan
/interface ethernet
set [ find default-name=ether1 ] comment=WAN
set [ find default-name=ether2 ] comment=LAN
set [ find default-name=sfp-sfpplus1 ] disabled=yes
/interface list
add name=WAN_iface
/ip pool
add name=dhcp_lan ranges=192.168.130.1-192.168.130.253
/ip dhcp-server
add address-pool=dhcp_lan interface=bridge_lan lease-time=1d name=dhcp_lan
/port
set 0 name=serial0
set 1 name=serial1
/interface l2tp-client
add allow=mschap2 connect-to=xxx.xxx.xxx.8 disabled=no name=l2tp profile=\
    default use-ipsec=yes user=sig
/interface bridge port
add bridge=bridge_lan interface=ether2
add bridge=bridge_lan interface=ether3
add bridge=bridge_lan interface=ether4
add bridge=bridge_lan interface=ether5
add bridge=bridge_lan interface=ether6
add bridge=bridge_lan interface=ether7
add bridge=bridge_lan interface=ether8
add bridge=bridge_lan interface=ether9
add bridge=bridge_lan interface=ether10
/ip neighbor discovery-settings
set discover-interface-list=!WAN_iface
/ipv6 settings
set disable-ipv6=yes
/interface list member
add interface=ether1 list=WAN_iface
/ip address
add address=192.168.130.254/24 comment=Localnet interface=bridge_lan network=\
    192.168.130.0
add address=192.168.210.238/24 interface=ether1 network=192.168.210.0
/ip dhcp-client
add disabled=yes interface=ether1
/ip dhcp-server network
add address=192.168.130.0/24 dns-server=192.168.130.254 gateway=\
    192.168.130.254
/ip dns
set allow-remote-requests=yes servers=192.168.210.1
/ip firewall address-list
add address=192.168.77.0/24 list=Ask
/ip firewall filter
add action=drop chain=input comment="drop invalid connections" \
    connection-state=invalid disabled=yes in-interface=ether1
add action=accept chain=input comment="allow related connections" \
    connection-state=related disabled=yes in-interface=ether1
add action=accept chain=input comment="allow established connections" \
    connection-state=established disabled=yes in-interface=ether1
add action=drop chain=input comment="drop everything else" disabled=yes \
    in-interface=ether1
/ip firewall nat
add action=masquerade chain=srcnat src-address=192.168.130.0/24
/ip route
add comment="Route to Ask" disabled=no distance=1 dst-address=\
    192.168.77.0/24 gateway=192.168.33.1 pref-src="" routing-table=main \
    scope=30 suppress-hw-offload=no target-scope=10
add disabled=no dst-address=0.0.0.0/0 gateway=192.168.210.1 routing-table=\
    main suppress-hw-offload=no
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes
set api disabled=yes
set api-ssl disabled=yes
/system clock
set time-zone-name=Europe/Moscow
/system identity
set name=GW
/system note
set show-at-login=no
/system routerboard settings
set enter-setup-on=delete-key

 

[mrrc]

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

 

/ip firewall nat
add action=masquerade chain=srcnat dst-address=!192.168.77.0/24 src-address=\
    192.168.130.0/24

 

[Saab95]

Может вместо !192.168.77.00/24 написать !192.168.0.0/16?

[jffulcrum]

16 часов назад, mrrc сказал:

/ip route
add comment="Route to Ask" disabled=no distance=1 dst-address=\
    192.168.77.0/24 gateway=192.168.33.1 pref-src="" routing-table=main \
    scope=30 suppress-hw-offload=no target-scope=10
add disabled=no dst-address=0.0.0.0/0 gateway=192.168.210.1 routing-table=\
    main suppress-hw-offload=no

Плохая практика не указывать distance для маршрута по-умолчанию. Он у вас будет 1, и оба этих маршрута окажутся равнозначными. Да, роутер примет во внимание более узкую подсеть, но если у вас внешний интерфейс в той же подсети по class - а это как раз ваш случай - возможны всякие эффекты. Distance указывайте побольше, 20,30, чтобы это действительно был маршрут of last resort.

 

16 часов назад, mrrc сказал:

/ip firewall nat
add action=masquerade chain=srcnat src-address=192.168.130.0/24

Если у вас статический внешний IP - не пользуйтесь masquerade как action, пользуйтесь src-nat. Masquerade - это привет из далекого прошлого, автоматика для хомячковых роутеров, он может работать непредсказуемо в сети сложнее двух портов. И указывайте out интерфейс в Интернет в правиле, чтобы дополнительно от фильтровать трафик LAN/WAN

 

16 часов назад, mrrc сказал:

/ip dns
set allow-remote-requests=yes servers=192.168.210.1

Вы вот это делаете, а в firewall не поставили запрет на dns запросы снаружи на ether1. В вашем случае снаружи серая сеть и это не так критично, но выставьте такой конфиг в интернет - и быстро окажетесь участником DDOS-атаки на кого-нибудь ещё.

 

12 часов назад, mrrc сказал:

/ip firewall nat
add action=masquerade chain=srcnat dst-address=!192.168.77.0/24 src-address=\
    192.168.130.0/24

 Это более правильно.

[mrrc]

43 минуты назад, jffulcrum сказал:

Плохая практика не указывать distance для маршрута по-умолчанию. Он у вас будет 1, и оба этих маршрута окажутся равнозначными. Да, роутер примет во внимание более узкую подсеть, но если у вас внешний интерфейс в той же подсети по class - а это как раз ваш случай - возможны всякие эффекты. Distance указывайте побольше, 20,30, чтобы это действительно был маршрут of last resort.

Добро, какова best practices тогда в данном конкретном случае?

Большую distance ставим на маршрут по умолчанию, верно?

 

51 минуту назад, jffulcrum сказал:

Если у вас статический внешний IP - не пользуйтесь masquerade как action, пользуйтесь src-nat. Masquerade - это привет из далекого прошлого, автоматика для хомячковых роутеров, он может работать непредсказуемо в сети сложнее двух портов. И указывайте out интерфейс в Интернет в правиле, чтобы дополнительно от фильтровать трафик LAN/WAN

Да, я знаю. При src-nat частенько возникали сложности с внутренней маршрутизацией между подсетями, полагаю это связаного как раз с nat-ом без задания исключений и distance по абзацу выше. Нужно будет поработать в этом ключе для выхода на best practices.

 

53 минуты назад, jffulcrum сказал:

Вы вот это делаете, а в firewall не поставили запрет на dns запросы снаружи на ether1. В вашем случае снаружи серая сеть и это не так критично, но выставьте такой конфиг в интернет - и быстро окажетесь участником DDOS-атаки на кого-нибудь ещё.

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

 

55 минут назад, jffulcrum сказал:

Это более правильно.

Иначе и не поднялось, ну или как выше в обсуждении говорилось сращу на всю !192.168.0.0/16 целиком.

[himikrzn]

/ip firewall nat
add action=masquerade chain=srcnat out-interface-list=WAN

 

в этом случае будет натить только в WAN list int, а все что пойдет в тунель пойдет без ната

Изменено 26 февраля пользователем himikrzn

[mrrc]

@himikrzn применительно к вопросу в теме if-листы с внешним ифейсом разумеется опробовались (как и прямое единичное указание ether1 собственно), но задача не решалась, иначе бы не было созданной темы. Только указание с отрицанием dst-address=!192.168.77.0/24 или dst-address=!192.168.0.0/16 возымело желаемый эффект.

[himikrzn]

у меня так работает, что все идет наружу натится, тунели нет, настраиваю удаленные обьекты именно так, срс нат не юзаю, вы по сути исключили трафик между сетями из ната

Изменено 26 февраля пользователем himikrzn

[mrrc]

@himikrzn да я ранее также придерживался аналогичной практики, а в данном конкретном случае вылезло то, что вылезло, поставив в тупик.

[Saab95]

9 часов назад, himikrzn сказал:

/ip firewall nat
add action=masquerade chain=srcnat out-interface-list=WAN

 

в этом случае будет натить только в WAN list int, а все что пойдет в тунель пойдет без ната

А если туннель идет через интернет, данные разве не через WAN интерфейс пойдут?

 

12 часов назад, jffulcrum сказал:

И указывайте out интерфейс в Интернет в правиле, чтобы дополнительно от фильтровать трафик LAN/WAN

Правильно работать только с IP адресами, а не интерфейсами. Т.к. могут быть разного рода странности.

 

11 часов назад, mrrc сказал:

Да, я знаю. При src-nat частенько возникали сложности с внутренней маршрутизацией между подсетями, полагаю это связаного как раз с nat-ом без задания исключений и distance по абзацу выше. Нужно будет поработать в этом ключе для выхода на best practices.

Тут, скорее всего, проблема была в таблицах маршрутизации, т.к. удаленные роутеры не знали где другие клиенты (за каким роутером находятся), и когда работал нат, удаленные роутеры общались с IP роутера и все работало.

[himikrzn]

>>А если туннель идет через интернет, данные разве не через WAN интерфейс пойдут?

 

чет цитирование не работает...

 

 

под тунелем я имел ввиду, sstp\pptp\l2tp они создают отдельные интерфесы которые в wan list не включаются автоматом, а вот с ipsec тунелем уже надо исключать из ната.

Изменено 27 февраля пользователем himikrzn

[mrrc]

11 часов назад, Saab95 сказал:

Тут, скорее всего, проблема была в таблицах маршрутизации, т.к. удаленные роутеры не знали где другие клиенты (за каким роутером находятся), и когда работал нат, удаленные роутеры общались с IP роутера и все работало.

Сейчас с точностью сценарий не вспомню, но удаленные маршрутизаторы в схеме не присутствовали, маршрутизация vlan-подсетей велась внутри самого маршрутизатора.

 

4 минуты назад, himikrzn сказал:

а вот с ipsec тунелем уже надо исключать из ната.

Как раз по теме имела место быть базовая схема l2tp+ipsec тоннеля до удаленной стороны.

Никакие обвязки в if_list-ы как выше упоминал не проканали, а тоннель как раз прокладывался через интернет-соединение через единый для всего wan-интерфейс.

[himikrzn]

l2tp с ipsec с шифрованием как раз отдельный инт создает, а вот чистый ipsec тунель нет, и трафик в него с ната уходит

[DeLL]

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

[mrrc]

3 минуты назад, DeLL сказал:

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

Например?

3 минуты назад, DeLL сказал:

Так с одним правилом конечно не будет работать

Работает, как выше приводилось.

3 минуты назад, DeLL сказал:

надо же не просто копипастить, а понимать для чего правило и что оно делает

Это вы о чем?

[DeLL]

Например: 

/ip firewall nat add action=masquerade chain=srcnat src-address=192.168.130.0/24 out-interface-list=WAN_iface

О чем говорит это правило? Маскарадить трафик из подсети 192.168.130.0/24 только в том случае, если трафик выходит через интерфейсы в интерфейс-листе WAN_iface. То есть в интернет. Думаю тут не сложно

Значит у пользователей будет интернет, так как для него есть нат, и будет работать доступ к\из впн тунеля, так в этом случае нат не сработает и будет чистая маршрутизация. 

В вашем случае с общим правилом маскарада микрот делает нат ДЛЯ ВСЕГО трафика из этой подсети. Поэтому работает интернет, но не работает трафик в\из впн или наоборот. Вот это надо понимать, чтобы не возникало вот таких вопросов:

Цитата

Если не включать nat для пользовательской подсетки (10.1.10.0/24), пакеты с удаленной подсетью (192.168.10.0/24) через впн-соединение ходят исправно.
Если же включить masquerade или src-nat для пользовательской подсетки (10.1.10.0/24) для возможности пользователям иметь доступ к интернет, утрачивается доступность удаленной подсети (192.168.10.0/24).

 

[mrrc]

3 минуты назад, DeLL сказал:

Вот это надо понимать, чтобы не возникало вот таких вопросов

Вы подключились к участию поназидать, я не пойму?) Или невнимательно читали все обсуждение выше)

Контрпродуктивно.

 

 

[DeLL]

В первых двух сообщениях описана проблема, остальное не читал. зачем?)

Проблема не совпадает с конфигом по айпишникам, ну то ладно.

Если что-то не так, тогда просто зашел посозидать)

Изменено 1 марта пользователем DeLL