Как настроить Mikrotik так, чтобы выполнялись следующие требования?

Question

[ALLIGATOR]

Добрый день, есть такая схема сети:
                     --------------------------------------------------
                     |                    MIKROTIK                    |
PC1 192.168.3.2/24 - | ether1 192.168.3.1/24                          |
PC2 192.168.4.2/24 - | ether2 192.168.4.1/24    192.168.7.2/24 ether4 | - 192.168.7.1/24 PC4
PC3 192.168.5.2/24 - | ether3 192.168.5.1/24                          |
                     --------------------------------------------------

Необходимо чтобы для каждого из PC1, PC2, PC3 устройство PC4 было доступно как будто оно в одной локальной с ними сети. Чтобы сети .3 .4 .5 между собой не "соединялись".

Что было сделано:
настроен dst-nat:
In.Interface: ether1
Action: netmap
To Address: 192.168.7.1

Этот вариант работает для PC1, но приходится у PC1 указывать шлюзом адрес mikrotik'а - 192.168.3.1

ИСПРАВЛЕНИЕ!!!
Приходится у PC4 указывать шлюзом адрес mikrotik'а - 192.168.7.2
А PC1, PC2, PC3 - без шлюза
В принципе меня это устраивает и вопрос можно снимать, но появился другой вопрос - можно ли заставить работать эту схему вообще без использования шлюзов?
КОНЕЦ ИСПРАВЛЕНИЯ

А нужно чтобы без указания шлюза это работало

В маршрутизации не силен - если вопрос нубский прошу простить.

РЕШЕНИЕ (Найдено Andrey Barbolin):

/ip firewall nat
add action=dst-nat chain=dstnat in-interface=ether1 to-addresses=192.168.7.1
add action=masquerade chain=srcnat out-interface=ether1 src-address=192.168.7.1
add action=masquerade chain=srcnat dst-address=192.168.7.1 src-address=192.168.3.0/24

add action=dst-nat chain=dstnat in-interface=ether2 to-addresses=192.168.7.1
add action=masquerade chain=srcnat out-interface=ether2 src-address=192.168.7.1
add action=masquerade chain=srcnat dst-address=192.168.7.1 src-address=192.168.4.0/24

add action=dst-nat chain=dstnat in-interface=ether3 to-addresses=192.168.7.1
add action=masquerade chain=srcnat out-interface=ether3 src-address=192.168.7.1
add action=masquerade chain=srcnat dst-address=192.168.7.1 src-address=192.168.5.0/24

Comments

[Дмитрий]

А что, всё PC без настоеного шлюза по умолчанию?

[ALLIGATOR]

Дмитрий, Да
Нужно чтобы для PC4 для PC1 казался как будто в одной локальной сети с ним
Также и для:
PC4 - PC2
PC4 - PC3
Но, чтобы не было связи PC1-PC2, PC1-PC3, PC2-PC3 и т.д.

[Дмитрий]

ALLIGATOR, в одной локальной сети они не будут т.к. вы казали маску сети \24 и что бы им попадать в другую подсеть нужно или указывать адрес шлюза (по умолчанию или маршрут до сети 192.168.7.0\24 - не важно), или расширять маску сети на всех PC что бы их адресация пересекалась с 192.168.7.1. Дело в том что при запросе адреса не из своей сети трафик должен будет направлен согласно таблице маршрутизации на следующий шлюз или шлюз по умолчанию, если более точного маршрута не найдено. Но если нет даже шлюза по умолчанию вы получите сообщение Destination net unreachable и трафик не куда не уйдёт. Можно сделать dst-nat, но тогда надо будет связываться не с 7.1\24, а c N.1\24 (где N - адрес подсети со стороны PC1, PC2, PC3) В этом случае важно что бы у PC4 был обратный маршрут до сетей PC1, PC2, PC3 через 7.2\24

[ALLIGATOR]

Дмитрий, Да с dst-nat вопрос решается (посмотрите мои комментарии на ответ Andrey Barbolin), но мне теперь интересно как сделать чтобы заработала следующая схема:
PC1 192.168.3.2 --- (192.168.3.1 ether1 ether2 192.168.7.2) --- 192.168.7.1 PC2
PC1 GW - NULL
PC2 GW - NULL

грубо говоря, сделать так, чтобы mikrotika как будто бы совсем и нет в сети, чтобы PC1 обращаясь на адрес 192.168.3.1 - попадал на PC2

Answer 1

[Valentin Barbolin]

Т.к. ПК в разных подсетях, то без GW не получится.

Хотите без GW - поместите все ПК в одну подсеть и напишите на МИК правила.

/ip firewall filter
add action=accept chain=forward src-address=192.168.3.2 dst-address=192.168.3.7
add action=accept chain=forward src-address=192.168.3.3 dst-address=192.168.3.7
add action=accept chain=forward src-address=192.168.3.4 dst-address=192.168.3.7
add action=drop chain=forward src-address=192.168.3.0/24 dst-address=192.168.3.0/24

Comments

[ALLIGATOR]

Хорошо, упростим схему до такой:

PC1 192.168.3.2 --- (192.168.3.1 ether1 ether2 192.168.7.2) --- 192.168.7.1 PC2

Неужели нельзя настроить в данном случае MIKROTIK так - чтобы для компьютеров его(mikrotik'а) как будто бы не было?
Чтобы PC1 обращаясь по адресу 192.168.3.1:80 на самом деле попадал на адрес 192.168.7.1:80

[Valentin Barbolin]

Можно, надо использовать DSTNAT

/ip firewall nat add action=dst-nat chain=dstnat protocol=tcp in-interface=ether1 to-addresses=192.168.7.1
/ip firewall nat add action=masquerade chain=srcnat out-interface=ether1
/ip firewall filter add action=accept chain=forward dst-address=192.168.7.1

[ALLIGATOR]

Andrey Barbolin, сделал как вы написали, три эти правила внёс в настройки микроитика, но ситуация осталась такой же:
PC1 192.168.3.2 --- (192.168.3.1 ether1 ether2 192.168.7.2) --- 192.168.7.1 PC2
со стороны PC1:
пинг, http(80) на адрес 192.168.3.1 - не работают

Но при этом в такой схеме:
PC1 192.168.3.2 --- (192.168.3.1 ether1 ether2 192.168.7.2) --- 192.168.7.1 PC2
PC1 GW - NULL
PC2 GW - 192.168.7.2
в этой схеме работает

в принципе меня это устраивает, изначально во время задания вопроса я или по запарке или по какой-то другой причине посчитал, что GW нужно настраивать со стороны PC1, такое решение меня бы не устроило, а со стороны PC2 - вполне

кстати, достаточно одного правила:
/ip firewall nat add action=dst-nat chain=dstnat protocol=tcp in-interface=ether1 to-addresses=192.168.7.1

с ним прекрасно все работает

[ALLIGATOR]

Andrey Barbolin,
ну и теперь ради интереса, можно ли запустить эту схему?

PC1 192.168.3.2 --- (192.168.3.1 ether1 ether2 192.168.7.2) --- 192.168.7.1 PC2
PC1 GW - NULL
PC2 GW - NULL

[Valentin Barbolin]

ALLIGATOR, Если все работает с одним правило, то скопируйте его 3 раза или укажите остальные интерфейсы.
Если вы не будете маскировать трафик (masquerade), то 3.2 (и остальные тоже) будет видеть, что ответ пришел от 7.1 и некоторым протоколам это может не понравиться (не будут работать).

/ip firewall nat 
add action=dst-nat chain=dstnat protocol=tcp in-interface=ether1 to-addresses=192.168.7.1
add action=dst-nat chain=dstnat protocol=tcp in-interface=ether2 to-addresses=192.168.7.1
add action=dst-nat chain=dstnat protocol=tcp in-interface=ether3 to-addresses=192.168.7.1


или
/ip firewall nat add action=dst-nat chain=dstnat protocol=tcp in-interface=ether1, ether2,ether3 to-addresses=192.168.7.1

[Дмитрий]

ALLIGATOR, тогда ещё надо делать src-nat(но не маскарадом), что бы подменялся и адрес отправителя и адрес получателя для того что бы 7.1 знал куда стать ответы.

[Valentin Barbolin]

7.1 все ответы шлет на GW, соответственно SRCNAT не нужен. Если бы не было GW, тогда нужен SRCNAT.

Если вы будете использовать SRCNAT в сторону 7.1, то все клиенты для него будет видны как 7.2, а это крайне не удобно для диагностики проблем.

[ALLIGATOR]

Да, спасибо, я понимаю что для трех ПК правило нужно раскопировать в соответствующем количестве
Про маскирование трафика тоже понял

Просто теперь вопрос в другом, эти правила работают, когда у правого ПК указан шлюзом микротик
при это у левого ПК шлюз как может быть задан, так может и отсутствовать

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

[ALLIGATOR]

В общем суть в том, что PC4 тут - это сервер точного времени NTP(с одним ethernet портом)
а PC1, PC2, PC3 - это я так обозначил различные ПК из трех различных подсетей

[ALLIGATOR]

Меняю схему! извинте )
PC1 192.168.3.2 --- / (192.168.3.1 ether1 ether2 192.168.7.2) --- 192.168.7.1 Server
PC2 192.168.3.3 ---|
PC1 GW - NULL
PC2 GW - NULL
PC3 GW - NULL
и чтобы всё работало )

[Valentin Barbolin]

Повторимся
> 7.1 все ответы шлет на GW, соответственно SRCNAT не нужен. Если бы не было GW, тогда нужен SRCNAT.
Нам надо маскировать (masquerade,SRCNAT) трафик в обе стороны.

masquerade и SRCNAT это практически одно и тоже.

SRCNAT надо указывать адрес для маскарада
masquerade берет адрес интерфейса через который выходит пакет согласно таблице маршрутизации

/ip firewall nat

add action=masquerade  chain=srcnat  src-address=192.168.7.1 out-interface=ether1
add action=masquerade  chain=srcnat  src-address=192.168.7.1 out-interface=ether2
add action=masquerade  chain=srcnat  src-address=192.168.7.1 out-interface=ether3

add action=masquerade  chain=srcnat  dst-address=192.168.7.1 in-interface=ether1
add action=masquerade  chain=srcnat  dst-address=192.168.7.1 in-interface=ether2
add action=masquerade  chain=srcnat  dst-address=192.168.7.1 in-interface=ether3

[Valentin Barbolin]

/ip firewall nat
add action=dst-nat chain=dstnat protocol=tcp in-interface=ether1 to-addresses=192.168.7.1
add action=dst-nat chain=dstnat protocol=tcp in-interface=ether2 to-addresses=192.168.7.1
add action=dst-nat chain=dstnat protocol=tcp in-interface=ether3 to-addresses=192.168.7.1

add action=masquerade  chain=srcnat  src-address=192.168.7.1 out-interface=ether1
add action=masquerade  chain=srcnat  src-address=192.168.7.1 out-interface=ether2
add action=masquerade  chain=srcnat  src-address=192.168.7.1 out-interface=ether3

add action=masquerade  chain=srcnat  dst-address=192.168.7.1 in-interface=ether1
add action=masquerade  chain=srcnat  dst-address=192.168.7.1 in-interface=ether2
add action=masquerade  chain=srcnat  dst-address=192.168.7.1 in-interface=ether3

[ALLIGATOR]

Andrey Barbolin, сделал согласно вашим указаниям, только для одного интерфейса(чтобы проверить):

/ip firewall nat
add action=dst-nat chain=netmap in-interface=ether1 to-addresses=192.168.7.1
add action=masquerade  chain=srcnat  src-address=192.168.7.1 out-interface=ether1
add action=masquerade  chain=srcnat  dst-address=192.168.7.1 in-interface=ether1

PC1 192.168.3.2 --- (192.168.3.1 ether1 ether2 192.168.7.2) --- 192.168.7.1 PC2
PC1 GW - NULL
PC2 GW - NULL

Но, к сожалению, как только на PC2 я изменяю шлюз с 192.168.7.2 на NULL - связь от PC1 к PC2 пропадает (не идут пинги, не открывает веб интерфес:80)

[Valentin Barbolin]

Покажите вывод
/ip firewall export
/ip address export
/ip route export
/interface export

[ALLIGATOR]

Andrey Barbolin,

MMM      MMM       KKK                          TTTTTTTTTTT      KKK
  MMMM    MMMM       KKK                          TTTTTTTTTTT      KKK
  MMM MMMM MMM  III  KKK  KKK  RRRRRR     OOOOOO      TTT     III  KKK  KKK
  MMM  MM  MMM  III  KKKKK     RRR  RRR  OOO  OOO     TTT     III  KKKKK
  MMM      MMM  III  KKK KKK   RRRRRR    OOO  OOO     TTT     III  KKK KKK
  MMM      MMM  III  KKK  KKK  RRR  RRR   OOOOOO      TTT     III  KKK  KKK

  MikroTik RouterOS 6.45.9 (c) 1999-2020       http://www.mikrotik.com/

[?]             Gives the list of available commands
command [?]     Gives help on the command and list of arguments

[Tab]           Completes the command/word. If the input is ambiguous,
                a second [Tab] gives possible options

/               Move up to base level
..              Move up one level
/command        Use command at the base level
[admin@MikroTik] > /ip firewall export
# sep/04/2020 08:55:26 by RouterOS 6.45.9
# software id = 
#
#
#
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1 src-address=192.168.7.1
add action=masquerade chain=srcnat dst-address=192.168.7.1 out-interface=ether1
add action=netmap chain=dstnat in-interface=ether1 to-addresses=192.168.7.1
[admin@MikroTik] > /ip address export
# sep/04/2020 08:55:40 by RouterOS 6.45.9
# software id = 
#
#
#
/ip address
add address=192.168.3.1/24 interface=ether1 network=192.168.3.0
add address=192.168.4.1/24 interface=ether2 network=192.168.4.0
add address=192.168.5.1/24 interface=ether3 network=192.168.5.0
add address=192.168.7.2/24 interface=ether4 network=192.168.7.0
[admin@MikroTik] > /ip route export  
# sep/04/2020 08:55:50 by RouterOS 6.45.9
# software id = 
#
#
#
[admin@MikroTik] > /interface export
# sep/04/2020 08:55:59 by RouterOS 6.45.9
# software id = 
#
#
#
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
[admin@MikroTik] >

[Valentin Barbolin]

Ошибки.

add action=masquerade chain=srcnat dst-address=192.168.7.1 out-interface=ether1
должно быть
add action=masquerade chain=srcnat dst-address=192.168.7.1 in-interface=ether1

Пинг ходить не должен.

[ALLIGATOR]

Andrey Barbolin,
Couldn't change NAT Rule <192.168.7.1> - incoming interface matching not possible in output and postrouting chains(6)

[Valentin Barbolin]

Тогда поменять на

add action=masquerade chain=srcnat dst-address=192.168.7.1 src-address=192.168.3.0/24

[ALLIGATOR]

Andrey Barbolin, поменял:
[admin@MikroTik] > /ip firewall export
# sep/04/2020 09:22:53 by RouterOS 6.45.9
/ip firewall nat
add action=dst-nat chain=netmap in-interface=ether1 to-addresses=192.168.7.1
add action=masquerade chain=srcnat out-interface=ether1 src-address=192.168.7.1
add action=masquerade chain=srcnat dst-address=192.168.7.1 src-address=192.168.3.0/24

поведение такое:
1)
GW PC1 - NULL
GW PC2 - NULL
Запрос с компьютера PC1 по адресу 192.168.3.1:80 - не проходит

2)
GW PC1 - NULL
GW PC2 - 192.168.7.2
Запрос с компьютера PC1 по адресу 192.168.3.1:80 - не проходит

Теперь запрос не проходит и с указанием шлюза на PC2 и без указания шлюза

[ALLIGATOR]

Из того, что я понимаю - это то, что к PC2 пакеты прилетают с src.address вне подсети PC2, поэтому он без указания шлюза не работает, т.е. маскарадинг или нат не работают как требуется в этом случае, src.address должен был подмениться на 192.168.7.2 - адрес mikrotik'а для этой сети

даже скорее всего точный src.адрес в пакете 192.168.3.2 (или 192.168.3.1) )

[ALLIGATOR]

Так, запустил на PC2 WireShark
Вот что он выдаёт:
689 153.689157000 192.168.3.2 192.168.7.1 HTTP 353 [TCP Retransmission] GET / HTTP/1.1
т.е. адрес источника не изменяется

[ALLIGATOR]

Andrey Barbolin,
прошу прощения, в этой схеме, в моём ответе выше на самом деле связь проходит:

GW PC1 - NULL
GW PC2 - 192.168.7.2
Запрос с компьютера PC1 по адресу 192.168.3.1:80 - не проходит

[ALLIGATOR]

Andrey Barbolin,
Блин! Прошу прощения, всё работает без шлюзов! Я перезагрузил виртуалки PC1, Mikrotik, PC2 и всё заработало! Спасибо! Извините, что заводил в заблуждение последние 4 комментария назад )

[ALLIGATOR]

Итоговые правила такие:
/ip firewall nat
add action=dst-nat chain=dstnat in-interface=ether1 to-addresses=192.168.7.1
add action=masquerade chain=srcnat out-interface=ether1 src-address=192.168.7.1
add action=masquerade chain=srcnat dst-address=192.168.7.1 src-address=192.168.3.0/24

Для схемы:
PC1 192.168.3.2 --- (192.168.3.1 ether1 ether2 192.168.7.2) --- 192.168.7.1 PC2
PC1 GW - NULL
PC2 GW - NULL

[ALLIGATOR]

Поигрался с правилами и получается, что достаточно двух правил, по крайней мере с ними все работает:
/ip firewall nat
add action=dst-nat chain=dstnat in-interface=ether1 to-addresses=192.168.7.1
add action=masquerade chain=srcnat dst-address=192.168.7.1 src-address=192.168.3.0/24

[ALLIGATOR]

Andrey Barbolin,
Ещё поигрался с правилами и заметил, что и одного правила достаточно:
/ip firewall nat
add action=masquerade chain=srcnat dst-address=192.168.7.1 src-address=192.168.3.0/24

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

[Valentin Barbolin]

> И вот в случае с одним правилом - страница грузится медленнее и бывает не прогружаются картинки или не все, а с двумя правилами - все грузится моментально - как и положено в локальной сети

Как уже писал ранее, при одностороннем маскараде, PC1 обращается на 3.1, а ответы ему прилетают от 7.1 - конечно же возникают ошибки, т.к. он ждет ответ от 3.1. Ошибки это переотправка пакетов, что визуально выливается в медленную работу соединения.

[ALLIGATOR]

Andrey Barbolin, конечно может у вас уже нет времени или желания разжевывать такие вещи, но всё таки если найдется несколько минут, можете объяснить:
1) add action=dst-nat chain=dstnat in-interface=ether1 to-addresses=192.168.7.1
2) add action=masquerade chain=srcnat out-interface=ether1 src-address=192.168.7.1
3) add action=masquerade chain=srcnat dst-address=192.168.7.1 src-address=192.168.3.0/24

Действительно ли тут нужно правило под номером 2, если и без него все работает?

[Valentin Barbolin]

1) add action=dst-nat chain=dstnat in-interface=ether1 to-addresses=192.168.7.1
Это правило пробрасывает порт (если быть точнее, то пробрасывает весь TCP трафик), на 7.1 при этом 7.1 видит что пакет пришел с 3.2 и т.к. у него нет маршрута в сеть 3.0 (и GW тоже нет), то он не знает куда отправлять ответ. Дале мы решает эту проблему маскарадом, правило 3.

2) add action=masquerade chain=srcnat out-interface=ether1 src-address=192.168.7.1
На 3.2 ответ прилетит от 7.1, от чего он конечно будет в ШОКЕ, т.к. запрос от отправил на 3.1. Мы решаем эту проблему этим правилом, маскирует пакет от 7.1 в сторону 3.2.

3) add action=masquerade chain=srcnat dst-address=192.168.7.1 src-address=192.168.3.0/24
Это правило маскирует пакет от 3.2 в сторону 7.1.

[ALLIGATOR]

Отлично, проверил для полной изначальной схемы решение с двумя правилами - всё работает как я изначально и хотел.
Т.е. для каждой связи PCn - PC4(server, NTP) нужно добавить два этих правила

Но все же буду использовать три правила

Спасибо, Andrey Barbolin

[Valentin Barbolin]

Если отойти в сторону, то вся эта схема - полная дичь, с точки зрения маршрутизации. Может привести к нестабильной работе протокола который вы собираетесь так маршрутизировать. То что так можно сделать - не говорит о том, что это правильно.

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

На данный момент - это жесткий КОСТЫЛЬ!

[ALLIGATOR]

Andrey Barbolin, задача такая - есть NTP сервер точно времени с одним ethernet портом, от него должны синхронизироваться несколько серверов, встраиваемые системы, в разных локальных сетях. И рядом есть mikrotik со свободными портами - поэтому появилась мысль сделать такую маршрутизацию, маскарадинг.
Протокол - NTP
Опрос будет инициироваться всегда с "другой стороны" от NTP-сервера

Изменить NTP сервер на другой нет возможности, поставить несколько NTP-серверов тоже нельзя - все системы должны быть синхронизированы от единого источника точного времени

[Valentin Barbolin]

Поднимите на микротике NTP сервер, а он в свою очередь, пусть синхрониться с 7.1.

[ALLIGATOR]

Andrey Barbolin, Хммм, и почему я сам об этом не подумал ) Спасибо
Проверить, правда, теперь смогу только через неделю - "стенд" сейчас недоступен

[ALLIGATOR]

Всё, удалось проверить, настроил NTP Client и NTP Server - всё работает

Answer 2

[Роман]

В принципе меня это устраивает и вопрос можно снимать, но появился другой вопрос - можно ли заставить работать эту схему вообще без использования шлюзов?

Без шлюза устройства не будут слать пакеты на маршрутизатор, а будут вещать в свою сеть (подходит только если у вас простой свитч), а вот если вы зададите маску сети не ограничивающуюся последним октетом, например вместо ip/24 указать в вашем случае ip/22 (если предпоследний октет подразумевает более чем от 0 до 3, то маску стоит понижать, на вики есть табличка), а на микротике настроить routes, то вполне себе будет работать как одна сеть, которую можно разграничить правилами средствами самого микротика используя маркировку пакетов

Comments

[ALLIGATOR]

Прошу прощения, но дело не в шлюзах и не масках в данном случае я уверен, что здесь можно сделать без задания адресов шлюза, ну просто если себя представить шлюзом и попробовать разрулить ip пакеты, вся загвоздка в том что я не имею опыта работы с инструментами mikrotik'а, iptables и т.п. и всеми этими сопутствующими аббреиватурами типа masquerade, src-nat, dst-nat и т.п.

Да и в общем-то... я не шлю пакеты в не свою сеть - каждый ПК отсылает пакет в свою подсеть
задача шлюза - подменить IP адреса источника и назначения на свой и запомнить это где-то у себя

[Роман]

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

[ALLIGATOR]

Роман, запрос производится на адрес НЕ в другой подсети, а в своей
всё, что вы говорите - верно, но не относится к решаемой задаче

Решение уже найдено, посмотрите ветку комментариев с Andrey Barbolin

[Роман]

ALLIGATOR, я и не ищу решения, я ответил на вопрос в исправлении о том, что в вашем случае нельзя обойтись без указания шлюза на устройствах

[ALLIGATOR]

Роман, Роман, решение без указания шлюзов уже найдено и отмечено отметкой "Отмечено решением"
То, что вы посчитали невозможным - на самом деле возможно