+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Получить публичный IP для dst-nat из локальной подсети.

Получить публичный IP для dst-nat из локальной подсети., RouterOS

brainchild

Guest

17.07.2007 02:39:00

Пожалуйста, обратитесь к прошлой статье под названием: http доступ к WAN IP с LAN. Проблема: когда у нас есть публичный IP-адрес, который переводится (с помощью правил dst-nat и переадресации портов) во внутренний приватный адрес, и клиент, находящийся в той же подсети, что и сервер, пытается получить доступ к серверу по публичному IP-адресу, это не работает. Доступ работает отлично, когда вы получаете доступ к публичному IP-адресу из любой другой сети, кроме локальной. Я пришел к выводу, что проблема в том, что роутер видит, что входящий запрос исходит от IP-адреса, находящегося в той же подсети, что и конечный сервер, поэтому он просто обходит маскировку IP-адреса пользователя и пересылает пакеты непосредственно на ПРИВАТНЫЙ IP-адрес внутреннего сервера. Другие предложили изменить DNS-записи на роутере, но это НЕ решение. Если дешевый Linksys или любой другой роутер может обрабатывать NAT для публичных IP-адресов должным образом, то и Mikrotik тоже должен, БЕЗ необходимости выполнять какие-либо специальные обходные пути. Нам НУЖНО, чтобы этот баг был исправлен. Когда правило dst-nat существует для локальной подсети, другие узлы в этой подсети должны иметь возможность получить доступ к этому серверу, используя Публичный IP-адрес. Эту проблему очень легко воспроизвести. Пожалуйста, Mikrotik, уделите несколько минут, чтобы взглянуть на эту проблему и реализовать решение. Если роутер Linksys может обрабатывать этот тип маршрутизации без проблем, то должна быть простая возможность сделать это на такой продвинутой системе, как RouterOS. Спасибо.

raymonvdm

Guest

08.08.2007 21:37:00

Хм, не уверен, что понимаю это решение, но у меня та же проблема. Но моя сеть немного "продвинутее", кажется.

История такова: у меня есть настольный ПК формата SFF с Dual Port, Quad Port и Single port NIC. Quad port подключен к моему провайдеру интернет-услуг. 4 x Ethernet → DSL модем. Для получения 4 IP-адресов с помощью DHCP-клиента на основе 4 разных MAC-адресов. 84.x.x.1 / 84.x.x.2 / 84.x.x.3 / 84.x.x.4

Dual Port карта подключена к DMZ 192.168.13.x/24 (Webserver Playground) и к WLAN-мосту 192.168.50.x/24 и 192.168.10.x/24 (Соседи).

Single port карта подключена к LAN. 192.168.100.x/24

Я настроил следующие правила для setup src-nat/dst-nat

0 ;;; Подключает DMZ Webserver хост к Интернету
chain=srcnat src-address=192.168.13.200 dst-address-list=!NO-SRC-NAT action=src-nat
to-addresses=84.x.x.2 to-ports=0-65535

1 ;;; DSL
chain=srcnat src-address=192.168.10.0/24 dst-address=!192.168.0.0/16 action=src-nat
to-addresses=84.x.x.3 to-ports=0-65535

2 chain=srcnat src-address=192.168.50.0/24 dst-address=!192.168.0.0/16 action=src-nat
to-addresses=84.x.x.3 to-ports=0-65535

3 X chain=srcnat src-address=192.168.100.202 dst-address=!192.168.0.0/16 action=src-nat
to-addresses=84.x.x.1 to-ports=0-65535

4 X chain=srcnat src-address=192.168.100.1 dst-address-type="" action=src-nat
to-addresses=84.x.x.2 to-ports=0-65535

5 chain=srcnat src-address=192.168.100.0/24 dst-address-type="" dst-address-list=!NO-SRC-NAT
action=src-nat to-addresses=84.x.x.4 to-ports=0-65535
84.x.x.4 — примеры. Но я получаю netblock из 4 адреса 84.x.x.x/24 хостов

6 ;;; SMTP Mailserver
chain=dstnat dst-address=84.x.x.4 protocol=tcp dst-port=25 action=dst-nat
to-addresses=192.168.100.200 to-ports=25

7 chain=dstnat dst-address=84.x.x.4 protocol=tcp dst-port=465 action=dst-nat
to-addresses=192.168.100.200 to-ports=465

8 chain=dstnat dst-address=84.x.x.4 protocol=tcp dst-port=993 action=dst-nat
to-addresses=192.168.100.200 to-ports=993

15 ;;; Sun Cobalt Raq 4i
chain=dstnat dst-address=84.x.x.2 protocol=tcp dst-port=21 action=dst-nat
to-addresses=192.168.13.200 to-ports=21

16 chain=dstnat dst-address=84.x.x.2 protocol=tcp dst-port=25 action=dst-nat
to-addresses=192.168.13.200 to-ports=25

17 chain=dstnat dst-address=84.x.x.2 protocol=tcp dst-port=80 action=dst-nat
to-addresses=192.168.13.200 to-ports=80

18 chain=dstnat dst-address=84.x.x.2 protocol=tcp dst-port=444 action=dst-nat
to-addresses=192.168.13.200 to-ports=444

19 chain=dstnat dst-address=84.x.x.2 protocol=tcp dst-port=81 action=dst-nat
to-addresses=192.168.13.200 to-ports=81

No-SRC-NAT Adres list
# LIST ADDRESS
0 NO-SRC-NAT 172.19.3.0/24 *
1 NO-SRC-NAT 192.168.0.0/16
Замечание: Эта сеть используется для удаленного управления моим DSL модемом. Ее IP-адрес привязан к одному из моих DSL-интерфейсов. Как добиться подключения наружу от 192.168.100.1 к 84.x.x.2? Внешний доступ. Когда я сканирую открытые порты изнутри 192.168.100.1 к 84.x.x.2, он находит открытые порты MT ftp/ssh/

airstream

Guest

09.08.2007 00:52:00

Наша система работает с DSTNAT только если LAN-сервер находится в другом подсегменте. То есть, если ваши LAN-клиенты 192.168.1.0/24, то вам нужно, чтобы сервер находился в другой сети LAN2 192.168.2.0/24, и обе сети были назначены вашему LAN-интерфейсу в MT, а DSTNAT указывал на ваш сервер по адресу 192.168.2.xxx. Таким образом, любой входящий вызов на порт X вашего WAN-IP с вашей LAN будет перенаправляться на порт X в LAN2.

Borage

Guest

09.08.2007 09:19:00

Это мне подходит, и мой сервер находится в той же подсети. / ip firewall nat
add chain=dstnat dst-address=<Public_IP_address> protocol=tcp dst-port=80 action=dst-nat to-addresses=<Web_Server_IP_address> \
to-ports=0-65535 comment="" disabled=no / ip firewall nat
add chain=srcnat dst-address=<Web_Server_IP_address> protocol=tcp dst-port=80 action=src-nat to-addresses=<Router_Internal_IP_address> \
to-ports=0-65535 comment="" disabled=no

lbenzo

Guest

24.10.2007 18:15:00

Пытаюсь это сделать, но пока безрезультатно. У меня работает dst-nat из public_ip:80 в local_ip:80, но если я пытаюсь получить доступ к public_ip:80 с другого local_ip в локальной подсети, то не работает. Есть какие-нибудь идеи, как это реализовать? Спасибо!

Chupaka Guest	#6 0 25.10.2007 14:40:00 используй src-nat с dst-nat

brainchild

Guest

27.10.2007 16:29:00

Эти команды у меня тоже не работают. Mikrotik: надеюсь, вы понимаете, что это функциональность, которую нужно реализовать в RouterOS. В любом Cisco (или любом потребительском роутере вроде Linksys или Netgear), если я настраиваю переадресацию порта для публичного IP-адреса, чтобы он шёл на внутренний сервер, он будет переадресовывать Internal src трафик так же, как и с интернета. Спасибо.

brainchild Guest	#8 0 27.10.2007 17:12:00 Да, заработало, спасибо, Borage!! Оказывается, во время тестов у меня был ещё один NAT-команд, который всё отменял.

klambrev

Guest

12.11.2007 07:29:00

Помогите, пожалуйста, я попробовал вот это: /ip firewall filter add chain=forward in-interface=wlan1 out-interface=ether1 action=accept dst-address=88. . .4 add chain=forward in-interface=ether1 out-interface=wlan1 action=accept src-address=88. . .4 затем set ip 88. . .4 на моем ноутбуке, set gw (88. . .3)публичный IP моего MT роутера. В чём проблема?

pekr

Guest

#10

12.11.2007 08:33:00

По-моему, есть несколько решений. И, по-моему, это ни в коем случае не ошибка в Mikrotik OS. На самом деле, я думаю, что дешевое оборудование предоставляет тебе кое-какие "помощники". Есть несколько решений, в зависимости от ситуации. Добавь статические записи DNS для твоего публичного адреса и домена — почему бы тебе не рассмотреть это как решение? Это работает, да. Используй dst-nat, когда это необходимо. Когда у тебя есть xy узлов в твоей сети, и они натаются, и, например, содержат идентичные сети (например, 10.0.0.x/24), тебе нужно использовать src-nat в дополнение. Это типичная проблема, когда твоя сеть растёт — мы начали с ADSL, потом подключили узлы, и выяснили, что каждый из них содержит идентичную сеть. Если ты не будешь делать src-nat, запрос дойдёт до твоего сервера, но роутер попытается ответить в своём сегменте 10.0.0.x/24, что приведет к неудаче. Используй маршрутизацию в сочетании с 1! Назначь своему серверу какой-нибудь адрес, например, 10.10.10.10, и добавь только одну статическую запись в DNS.

chriswoodall

Guest

#11

29.11.2007 15:24:00

Для меня dst-nat и src-nat работают отлично, но вот загвоздка... могу ли я реализовать балансировку нагрузки? Стоит только попробовать настроить балансировку, как мои правила src-nat и dst-nat перестают работать. Есть какие-нибудь идеи?

airstream Guest	#12 0 29.11.2007 19:23:00 Ты используешь отметки соединения/пакета с помощью mangle для балансировки нагрузки?

GWISA Guest	#13 0 29.11.2007 21:35:00 Точно-точно… Я бы обиделся, если бы работал в MT и кто-то настоял на внедрении функции, которая есть у Linksys и Netgear, просто чтобы кому-то облегчить жизнь, не понимая, что он делает!

martinkaplan Guest	#14 0 23.08.2016 17:07:00 Я думаю, это лучшее решение! Добавьте статические записи DNS для вашего публичного адреса и домена – почему бы вам не рассмотреть это как решение? Это оно, работает.

alli

Guest

#15

24.01.2017 15:53:00

У меня была та же проблема с доступом к нашим сетевым камерам из локальной сети. Я добавил статический адрес для облачного домена, указывающий на локальный IP-адрес роутера, и настроил NAT (маскировку) для локальной сети, и теперь всё работает нормально!

arnaldo Guest	#16 0 08.05.2018 00:04:00 Я пытаюсь разобраться в этом, особенно учитывая, что все "базовые" роутеры вроде бы делают это без какой-либо специальной настройки. Так как есть какие-то "решения", но без объяснения процесса, я смотрел на те, что заявляют, что работают, и смею утверждать, что проблема возникает из-за следующей цепочки пакетов: Предположим, хост-A и сервер-B находятся в одной внутренней сети. Пакет приходит на "внутренний" интерфейс, а назначением является внешний IP-адрес роутера. Источник: хост-A во внутренней сети, назначение: роутер (внешний IP) на этапе пре-маршрутизации, DST-NAT меняет назначение (и порт) на IP-адрес (и порт) внутреннего сервера. Источник: хост-A во внутренней сети, назначение: сервер-B во внутренней сети Пакет покидает роутер в направлении сервера-B, при этом источник по-прежнему установлен на хост-A. Сервер-B примет соединение и ответит хосту-A напрямую. Хост-A не имеет соединения с сервером-B, а скорее с роутером. Поэтому это не сработает (TCP/UDP-соединение). Вот почему решения, использующие SRC-NAT для изменения источника всех пакетов, предназначенных для внутреннего сервера, работают. Это правильно установит источник пакета как исходящий от роутера, так что сервер-B будет отвечать роутеру, который в свою очередь перешлет пакет реальному источнику (хост-A). Одной из сложностей при использовании SRC-NAT является динамический внешний IP-адрес. Не проблема, для этого и существует "masquerade". Я использую следующее правило, своего рода "single rule catch it all": add action=masquerade chain=srcnat comment="Allow internal access to servers using router's external IP addresses" \ dst-address=<внутренняя сеть> src-address=<внутренняя сеть> Таким образом, masquerade на внутренних интерфейсах, если назначение находится во внутренней сети. Это охватит ЛЮБУЮ службу в ЛЮБОЙ сети, которую можно указать с использованием CIDR-нотации. Кроме того, {src,dst}-address-list также можно использовать для уточнения правила.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры