Russian Users MikroTik | Форум пользователей MikroTik

Ну а вывод? Трассировка? Что в логах?
Фарйволы на компах отключены ?

Счётчик правила НАТ (которое Вы сейчас делали) = сработал?
Туда запросы попали?

pan4o писал(а): ↑25 фев 2019, 10:09

Vlad-2 писал(а): ↑25 фев 2019, 09:40

pan4o писал(а): ↑25 фев 2019, 09:27 Chain scrnat
Т.Е. scr Address 192.168.99.0/24
Dst. Address 192.168.1.0/24

Почти правильно, но не указали от какова адреса в итоге (на выходе) Натить.
Надо как-то так:

Код: Выделить всё

/ip firewall nat
add action=src-nat chain=srcnat dst-address=192.168.1.0/24 src-address=192.168.99.0/24 to-addresses=192.168.1.1

Увы, но не помогло.

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

Имеется HAS Lite, им было решено отгородить от заводской сети комплекс для плазменной резки. Но вот спецалистов по администрированию сетей ни на заводе ни у нас не хватило).

В микротик как внешняя сеть воткнута заводская 192.168.110.***, в ланы уже комплекс плазмагана 192.168.0.***

на внешний порт назначил 192.168.110.23 (завод), на lan 192.168.0.111(плазмаган). Из сети плазмагана видит сеть завода, пингует и т.п., а обратно из завода в комплекс не видит. Роутер режет входящий снаружи трафик, верно?

На компьютере технолога настроили микротик как шлюз (192.168.110.23) в настройках подключения, он увидел (пинг) лан интерфейс роутера (192.168.0.111), но за роутером ничего не видит.

(установили микротик как шлюз для чистоты эксперимента чтобы внутри завода маршруты не разруливать. а сначала хотя бы с микротиком разобраться).

Пробовал proxy-arp на лан интерфейсе, не пускает. Завтра попробую создать нат как описывали выше:

/ip firewall nat
add action=src-nat chain=srcnat dst-address=192.168.0.0/24 src-address=192.168.110.0/8 to-addresses=192.168.0.111

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

Вкратце, без всех этих прелюдий, вопрос звучит следующим образом:
Как увидеть сеть за микротиком, если он внутри другой подсети. Какое правило, или настройка?.

По умолчанию для LAN сети, находящейся за “натом”, доступ в внешнюю сеть есть, а из внешней сети в NAT-сеть попасть нельзя. За исключением случаев проброса портов (но как это сделать мы совместно с заводскими админами не знаем).

Вот и стоит вопрос, можно ли отключить NAT, или пробросить весь трафик между внешней заводской сеткой и плазма комплексом?

cynismus писал(а): ↑06 июл 2022, 14:55Вот и стоит вопрос, можно ли отключить NAT, или пробросить весь трафик между внешней заводской сеткой и плазма комплексом?

Можно.
Но тогда маршрутизатору основной сети нужен маршрут до сети, которая за микротиком.
А то микротик знает, что сетей две, а тот - нет.

Ну и на микротике firewall ещё нужно будет либо скорректировать под ситуацию, либо удалить совсем (нежелательно).

Прошу прощения за офф-топ

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

Вкратце, без всех этих прелюдий, вопрос звучит следующим образом:
Как увидеть сеть за микротиком, если он внутри другой подсети. Какое правило, или настройка?.

сам сейчас решаю "аналогично-похожую" задачу, она "висит" в FAQ и понял, что без понимания "как это работает", т.е. теории, самостоятельно решить возможно наверно только случайно :) На мой взгляд, в таких вопросах, самое главное, это понимание "Prerouting-Forward-Postrouting". Один из материалов, который изучаю:
https://temofeev.ru/info/articles/osnov ... -routeros/
и вообще, "Основы статической маршрутизации"
Понимание начинает приходить, постепенно не быстро,т.к. "переварить" сразу всё не получается сразу

REX писал(а): ↑07 июл 2022, 08:48На мой взгляд, в таких вопросах, самое главное, это понимание "Prerouting-Forward-Postrouting".

Главное и, собственно, даже единственное, что надо в этой задаче понимать - это что когда настраивается маршрутизация между двумя маршрутизаторами, каждый со своими сетями, и без трансляции адресов (NAT), то маршруты до сетей другого маршрутизатора должны быть на обоих.
В данном конкретном случае, маршрут до сети другого маршрутизатора на микротике уже есть, потому что сам микротик является "клиентом" сети этого другого маршрутизатора. Но это лишь частный случай.

А вот "Prerouting-Forward-Postrouting" в частности, и firewall вцелом, к сути данной задачи (и к пониманию этой сути) не имеет вообще никакого отношения: да любое соединение чтобы быть успешно установленным должно быть так или иначе разрешено в firewall обоих маршрутизаторов, но это не вопрос маршрутизации между ними, это вопрос контроля доступа.

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

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

А вот "Prerouting-Forward-Postrouting" в частности, и firewall вцелом, к сути данной задачи (и к пониманию этой сути) не имеет вообще никакого отношения: да любое соединение чтобы быть успешно установленным должно быть так или иначе разрешено в firewall обоих маршрутизаторов, но это не вопрос маршрутизации между ними, это вопрос контроля доступа.

Это "Основы статической маршрутизации", где в таблице filter (применительно к fw например) содержатся цепочки, которые в свою очередь правила,а те уже критерии, действия и счётчики...
Пусть я даже ошибаюсь, озвучив цепочку "Prerouting-Forward-Postrouting" (думаю о своём вопросе), и пусть в авторской задаче работает другая цепочка, всё одно, без понимания того, "как это работает" остаётся надеяться только на "доброго дядю", который решит вопрос или разобраться самому
Мне сейчас вспомнился случай, когда с моей задачей один из гуру на англоязычном форуме "послал меня в сторону горизонта" , а аналогичные моему вопросы "висели" там на форуме с 2017 года нерешёнными. "Покурив" достаточно много лит-ры, я решил вопрос и теперь понимаю,что в состоянии решить и другие. Разумеется, с интересом знакомлюсь с опытом и практикой значительно более опытных людей(себя к таковым не отношу) и при необходимости уточняю некоторые моменты.
Вы хотите помочь автору действенно, исходя из своего опыта и знаний? напишите, что именно, где и как ему прописать, исходная информация вроде как есть. Я тоже хочу помочь, и тоже исхожу из своего понимания, что без знаний "основ статической маршрутизации" и после долгой переписки здесь, возможно и удастся решить вопрос, методом не понимаемого перебора вариантов.
Ещё раз прошу прощения за оффтоп

REX писал(а): ↑07 июл 2022, 13:39 а это всё и есть "основы статической маршрутизации"

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

А вот эти все схемы packet flow описывают движение пакетов внутри устройства, между разными блоками обработки этих пакетов. Оно про маршрутизацию вообще ничего не знает, тем более, статическая она там или динамическая.

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

Единственное, исключение, где firewall прямо вмешивается в маршрутизацию - это mangle action=mark-routing и action=route, но и там сам mangle все равно не имеет ни малейшего понятия о конкретных маршрутах.
Но к задаче этой темы оно никакого отношения не имеет.
И это именно mangle - то есть в буквальном смысле инструмент, созданный вмешиваться в "естественный" ход событий, а никак не что-то "базовое" (или "основное").

Всё понятно, маршрутизация к "основам маршрутизации" отношения не имеет
Странным образом получается, что всё, что Вы говорите, самым подробным образом описано именно в "основах статической маршрутизации" и как раз именно в PacketFlow показано, в каких местах принимается решение о маршрутизации пакетов.

Единственное, исключение, где firewall прямо вмешивается в маршрутизацию - это mangle action=mark-routing и action=route, но и там сам mangle все равно не имеет ни малейшего понятия о конкретных маршрутах.
Но к задаче этой темы оно никакого отношения не имеет.
И это именно mangle - то есть в буквальном смысле инструмент, созданный вмешиваться в "естественный" ход событий, а никак не что-то "базовое" (или "основное").

, о mangle я ничего и не говорил, это вообще не терминальное действие....но такая iptable есть...
ну думаю, что всё это как-то поможет ТС, т.к.по сути есть два варианта решения задачи: 1. это "добрый дядя" решит 2. решить самому, через некоторый объём теоретических знаний.