Вопрос по логике работы NAT

[M V]

Привет!
Не могу понять логику работы NAT на роутере. Две сети соединены через Wireguard. Один роутер на PFSense, второй - Keenetic. На PFSense все работает как требуется и в соответствии с настройками. Нарисовал просто для полноты картины. На кинетике не могу добиться такой же логики. Смысл проблемы в следующем:

Настроена статическая маршрутизация между сетями черех туннель. На keenetic выключен "ip nat Home" и прописаны статические правила NAT:

ip static Home L2TP0
ip static Wireguard0 L2TP0
ip static 192.168.1.0 255.255.255.0 L2TP0

Это нужно для того, чтобы девайсы из подсети А могли ходить на некоторые хосты в Интернете через туннель и кинетик. То же самое работает и в обратную сторону.

Проблема возникает как только я разрешаю NAT из A (ip static 192.168.1.0 255.255.255.0 L2TP0). После ввода этой команды, кинетик терминирует любые подключения из B в A на себя. Например, до ввода команды я могу с хоста 192.168.2.2 подключиться по ssh к хосту 192.168.1.2. После ввода, несмотря на то, что коннекчусь к 192.168.1.2, попадаю на кинетик. Трейсроут тоже меняется и показывает один хоп вместо трех.

Как мне сделать так, чтобы кинетик NATил траффик из A и B, но только при выходе пакетов через L2TP0? Во всех остальных случаях NAT'а быть не должно - используется обычная маршрутизация.

'ip nat loopback' на Home и Wireguard0 выключен. Разницы нет. Почему Кинетик вообще отвечает на запросы, адресованные в другую подсеть, которая даже не directly connected?

[gaaronk]

Попробуйте настроить в CLI

no isolate-private

interface Wireguard0
    security-level private

 

[M V]

Just now, gaaronk said:

Попробуйте настроить в CLI

no isolate-private

interface Wireguard0
    security-level private

 

Да, забыл написать.

И первое, и второе уже сделано. Все работает отлично и роутится как надо до того момента, как я разрешаю NAT из удаленной подсети (A)

[gaaronk]

надо посмотреть настройки iptables. или через entware или через self-test

[M V]

Думаю, что проблема в последней строке. Не пойму, зачем она там вообще нужна. Никаких правил DNAT я не создавал. Сейчас приложу релевантный конфиг.

 == Chain _NDM_STATIC_SNAT ==
src: 192.168.2.0/24, dst: 0.0.0.0/0, in: "*", out: "ppp0", proto: "any"; "ndmmark" match, value: 0x4/0x4, invert: 0x0; SNAT, address: {{WAN_IP}}
src: 10.0.0.0/24, dst: 0.0.0.0/0, in: "*", out: "ppp0", proto: "any"; "ndmmark" match, value: 0x4/0x4, invert: 0x0; SNAT, address: {{WAN_IP}}
src: 192.168.1.0/24, dst: 0.0.0.0/0, in: "*", out: "ppp0", proto: "any"; "ndmmark" match, value: 0x4/0x4, invert: 0x0; SNAT, address: {{WAN_IP}}
-> Chain default policy: RETURN
== Chain _NDM_STATIC_DNAT ==
src: 0.0.0.0/0, dst: 192.168.1.0/24, in: "*", out: "*", proto: "any"; DNAT, address: {{WAN_IP}}

[M V]

В файле конфиг. Убрал все, что не касается итерфейсов, фаервола и nat.

Как уже сказал, no isolate-private сделано, поэтому в конфиге его нет. В целом, настроек минимум. Только то, что нужно для роутинга и НАТа. Никаких доп фильтров, кроме телнета из локалки нет.

nat.txt

Изменено 3 марта, 2023 пользователем M V

[M V]

Но проблема очевидна теперь. При вводе "ip static 192.168.1.0 255.255.255.0 L2TP0" автоматом создается DNAT правило:

src: 0.0.0.0/0, dst: 192.168.1.0/24, in: "*", out: "*", proto: "any"; DNAT, address: {{WAN_IP}}

Соответственно, когда я пытаюсь подключиться откуда-либо к хосту в 192.168.1.0, меня DNATит на WAN_IP кинетика. Это правило не должно создаваться в принципе! Если мне нужен будет DNAT в 192.168.1.0 я сам создам правило для нужных мне хостов. А не тупо коннектить все к кинетику.

Если кто-то подскажет, как убрать эту строку - буду очень благодарен.

А вообще, я бы назвал это багом. Не вижу вообще причины, по какой это правило может создаваться.

Изменено 3 марта, 2023 пользователем M V

[gaaronk]

Да. Я вспомнил что есть у кинетика такое поведение. Даже обсуждал это тут на форуме. Сейчас с телефона и не найду уже. 

Типа тут так принято.

На пфсенс надо все что не идет в сторону 192.168/16 делать snat/masquerade в адрес на wg интерфейсе.

А с кинетика эту строку убрать  

 

[gaaronk]

Это потому что кинетик смотрит принадлежит ли src интерфейс или сеть уровню private. А ваша сеть 192.168.1.0/24 не соответствует адресации ни на одном приватном интерфейсе. Значит она public. 
 

А раз public - делаем DNAT. А указать уровень для сети, не интерфейса - нельзя. Такая логика. 
 

SOHO железка же. Без всей этой сложной маршрутизации и т.д.

[M V]

Ну да, так-то оно будет работать. Но это какой-то адский костыль. Это ж ломает возможность потом фильтровать траффик из A в B каким-либо образом, кроме полного allow или deny.. 🤦‍♂️

А вот правило "src: 0.0.0.0/0, dst: 192.168.1.0/24, in: "*", out: "*", proto: "any"; DNAT, address: {{WAN_IP}}" не имеет абсолютно никакого смысла. Зачем кинетику вдруг принимать на себя подключения, которые даже не существуют на нем?.. Мягко говоря, странная имплементация. Попробую баг-репорт написать.

Спасибо за ответы!

[M V]

1 minute ago, gaaronk said:

А раз public - делаем DNAT. А указать уровень для сети, не интерфейса - нельзя. Такая логика.

Точнее ее отсутстывие.. DNAT вникуда ведь все равно..

[gaaronk]

NAT а кинетике всегда был кривой как турецкая сабля. Причем это сделано специально. Что бы у обычного домашнего пользователя не было проблем с утечкой серых адресов или что где то забыли маршрут прописать. 
 

Ну вот такое оно. 

[r13]

1 час назад, M V сказал:

ip static 192.168.1.0 255.255.255.0 L2TP0

Такой конфиг вроде так и не работает

 

[gaaronk]

Шесть лет прошло, а проблемы все те жи…

[M V]

Quote

При этом еще и включается проброс портов с сетей 192.168.0.0/255.255.252.0 на адрес интерфейса ISP, что противоречит логике.

But why??? 🤦‍♂️
Зачем он включается, если об этом никто не просит? Какая-то кривая реализация, честно..
Посмотрим, что ответят.. Если ответят.

[gaaronk]

На pfsense сделайте что то воде - если выходим через wg туннель и назначение НЕ РАВНО 192.168.0.0/16 - маскарад. 
 

будет и интернет и контроль доступа А в Б

[gaaronk]

Было бы хорошо иметь костыль в виде команды

ip network-private <CIDR>

[M V]

На pfsense сделайте что то воде - если выходим через wg туннель и назначение НЕ РАВНО 192.168.0.0/16 - маскарад. 

На pfsense сделайте что то воде - если выходим через wg туннель и назначение НЕ РАВНО 192.168.0.0/16 - маскарад. 

Отличная идея!

Было бы хорошо иметь костыль в виде команды

ip network-private <CIDR>

Я бы все же предпочел тупо убрать DNAT правило. Ведь все равно нужно создавать отдельные вручную, чтобы что-то куда-то форвардить. А это дефолтное правило абсолютно не имеет смысла и ломает роутинг.

Изменено 3 марта, 2023 пользователем M V

[gaaronk]

Это врядли уберут. На эту логику с уровнями много что завязано. 

[M V]

Пока прописал SNAT на PFSense для всего, что не в 192.168/16 в адрес WG. Работает как надо.
Gaaronk, еще раз спасибо за ответы! Вы мне очень помогли!

[Le ecureuil]

Это все родовая травма команды ip static, которая одновременно и nat настраивает, и проброс портов. Аргумент интерфейс во второй позиции интерпретируется как интерфейс локальной сети в случае если он PRIVATE/PROTECTED, и тогда включается SNAT, или как входной WAN в случае PUBLIC, и тогда включается DNAT.

Возможно это будет улучшено, но пока ничего нового.

[Werld]

Пару лет назад уже создавал тему в развитии. Предлагаю всем заинтересованным голосовать. 

 

Изменено 4 марта, 2023 пользователем Werld