Jump to content
  • 0

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


M V

Question

Привет!
Не могу понять логику работы 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?

diagram.jpg

Link to comment
Share on other sites

21 answers to this question

Recommended Posts

  • 0
Just now, gaaronk said:

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

no isolate-private

interface Wireguard0
    security-level private

 

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

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

Link to comment
Share on other sites

  • 0

Думаю, что проблема в последней строке. Не пойму, зачем она там вообще нужна. Никаких правил 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}}
Link to comment
Share on other sites

  • 0

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

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

nat.txt

Edited by M V
Link to comment
Share on other sites

  • 0

Но проблема очевидна теперь. При вводе "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 я сам создам правило для нужных мне хостов. А не тупо коннектить все к кинетику.

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

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

Edited by M V
Link to comment
Share on other sites

  • 0

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

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

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

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

 

Link to comment
Share on other sites

  • 0

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

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

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

Link to comment
Share on other sites

  • 0

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

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

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

Link to comment
Share on other sites

  • 0
1 minute ago, gaaronk said:

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

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

Link to comment
Share on other sites

  • 0

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

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

Link to comment
Share on other sites

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

ip static 192.168.1.0 255.255.255.0 L2TP0

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

 

  • Thanks 1
Link to comment
Share on other sites

  • 0
Quote

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

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

Link to comment
Share on other sites

  • 0

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

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

  • Upvote 1
Link to comment
Share on other sites

  • 0

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

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

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

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

ip network-private <CIDR>

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

Edited by M V
Link to comment
Share on other sites

  • 0

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

Link to comment
Share on other sites

  • 0

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

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

  • Thanks 3
Link to comment
Share on other sites

  • 0

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

 

Edited by Werld
  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...