Привет! Я пока ещё осваиваю основы, всё настроено для домашней конфигурации, но есть одна проблема, которую я сам решить не могу. У меня RB751G-2HnD, подключение к интернету настроено через PPTP-клиента на самом роутере. Внешний IP динамически назначается интерфейсу PPTP. У меня есть скрипт dyndns, который отлично и корректно обновляет моё доменное имя третьего уровня dyndns. Порт 80 перенаправлен на внутренний веб-сервер, всё работает нормально, если я получаю доступ к нему из интернета (пробовал веб-прокси и Tor для проверки). Теперь я хочу, чтобы запросы к внешнему IP из локальной сети маршрутизировались обратно к моему веб-серверу, как будто они пришли из интернета. Как это: HTTP-запрос приходит из локальной сети (bridge-local), а целевой IP-адрес назначен внешнему интерфейсу роутера. Я хочу, чтобы этот пакет был передан на IP, расположенный внутри локальной сети. Внешний IP (целевой) динамический, поэтому я не могу использовать его в каких-либо правилах брандмауэра. Я понимаю, что могу просто добавить локальный IP веб-сервера в статические DNS-хосты и получить доступ к нему по доменному имени, но я хотел бы использовать внешний IP (для единообразия).
Маршрутизация запросов из локальной сети обратно в локальную сеть.
Маршрутизация запросов из локальной сети обратно в локальную сеть., RouterOS
04.08.2012 07:35:00
|
|
|
|
06.08.2012 07:54:00
Привет, думаю, если ты используешь dst-nat для доступа твоих локальных клиентов к твоему WAN IP-адресу, твоя проблема решится. Проверь это..
|
|
|
|
06.08.2012 15:59:00
Пришли схему своей сети и напиши, что именно тебе нужно, тогда я смогу помочь тебе лучше.
|
|
|
|
07.08.2012 21:36:00
Отличный вопрос. Обычно для навигации по серверу используют локальное имя или локальный IP-адрес сервера + порт. И если нужно просто проверить соединение (без логина), то использование внешнего прокси, TOR или VPN вполне нормально. Но в вашем случае установленное вами правило заставит Mikrotik OS разрешить dyndns IP… Для решения читайте и используйте небольшой скрипт с:
|
|
|
|
08.08.2012 17:04:00
@Andys Следуй этому примеру:
|
|
|
|
02.10.2012 09:42:00
Статью написал пользователь “Fewi”, и раз я не знаю другого способа отметить его вклад, сделаю это здесь! Fewi, отличная и очень полезная статья!! Спасибо
|
|
|
|
02.07.2017 21:40:00
Всем привет, искренне извиняюсь за то, что поднимаю старую тему, но я АБСОЛЮТНО в такой же ситуации, и ни один из скриптов, которые я пробовал, для меня не работает. Вот моя текущая ситуация. Мой модем работает по pppoe и настроен как bridge. MT роутер правильно настроен для подключения по pppoe. (Интернет работает). Мне удалось настроить правила брандмауэра для моего NAS и я смог получить к нему доступ через DDNS из Интернета (поначалу). Я поискал больше информации и наткнулся на эту тему и с помощью предоставленных здесь советов смог настроить маршрутизацию с LAN обратно в LAN, и теперь я МОГУ получить доступ к моему NAS через DDNS из LAN. Далее была задача обновить публичный IP, так как в Firewall-NAT dst-Address — это мой публичный динамический IP, и я хочу убедиться, что если он изменится, DDNS будет продолжать работать правильно. Вот тут я застрял и потратил 3-4 часа, чтобы запустить скрипт и добиться желаемого результата. Согласно этой теме, я следовал туториалу, написанному на
a. Шаг один :: /ip firewall address-list add address=0.0.0.0 comment=sam9s.synology.me list=host_synology — это добавляет запись под firewall->adress list. b. Шаг два :: /ip firewall filter add chain=ouput dst-address-list=host_synology action=accept — это добавляет запись под firewall->filter. Теперь, когда я запускаю скрипт, который там размещен… НИЧЕГО не происходит… адрес под Firewall->Address Lists все еще просто 0.0.0.0. Исправьте меня, если я не прав, но когда скрипт запускается, 0.0.0.0 должно измениться на мой публичный IP, верно? Но этого не происходит. Я пробовал другие скрипты, но ничего не работает, может быть, я что-то упускаю. Могу ли я попросить "гуру" ПОМОЧЬ мне здесь? Я уже несколько часов кручусь на месте без успеха. С уважением, Sammy |
|
|
|
03.07.2017 11:57:00
Привет! А есть какая-то конкретная причина использовать hairpin NAT? Лично у меня в локальных DNS-серверах есть записи, чтобы разрешать соответствующие FQDN в их LAN-адреса.
|
|
|
|
04.07.2017 00:03:00
Я перечитал это снова и немного запутался в скрипте разрешения домена. То, что я предложил, заменяло бы только эту часть. На самом деле, DNS-разрешение вам вообще не нужно (ну, возможно, смотрите ниже). У вас есть два варианта:
а) Используйте hairpin NAT. Пример предполагает, что ваша локальная сеть — 192.168.88.0/24, роутер — 192.168.88.1, внутренний сервер — 192.168.88.100, и вы хотите перенаправить TCP-порт 80. Замените это на свои цифры. Сначала добавьте правило dstnat: `/ip firewall nat` `add action=dst-nat chain=dstnat dst-address-type=local dst-address=!192.168.88.1 dst-port=80 protocol=tcp to-addresses=192.168.88.100` Оно будет соответствовать соединениям к порту 80 и любому адресу, принадлежащему роутеру, за исключением его внутреннего (так что вы все равно сможете получить доступ к WebFig по адресу `add action=masquerade chain=srcnat dst-address=192.168.88.0/24 out-interface=<LAN> src-address=192.168.88.0/24` Это универсальное правило, которое будет работать со всеми перенаправленными портами. И, наконец, разрешите перенаправленные порты через файрвол роутера: `/ip firewall filter` `add action=accept chain=forward connection-nat-state=dstnat` б) Используйте DNS, как предлагает w177f: `/ip dns static` `add address=192.168.88.100 name=sam9s.synology.me` Вашим устройствам в локальной сети нужно использовать роутер в качестве DNS-разрешателя, и благодаря этому, при переходе по адресу У каждого способа есть свои преимущества и недостатки: использование статического DNS кажется проще на первый взгляд. Оно также лучше для производительности, потому что пакеты не нужно отправлять на роутер и обратно, они идут напрямую к серверу. Но есть некоторые ограничения, например, подключите устройство со статически настроенным DNS-разрешателем к чему-то, отличному от вашего роутера, и оно не будет работать. Если вы укажете больше доменных имен, потребуется статическая запись для каждого. И вам придется следить за изменениями (если вы добавите или удалите доменные имена). Но, вероятно, можно с уверенностью предположить, что это не будет проблемой в вашем случае. Оно также не позволяет подключения к числовому адресу, потому что вы не можете перенаправить его с помощью DNS. Hairpin NAT — это "настрой и забудь", оно будет автоматически работать с любым доменным именем, указанным на ваш текущий WAN-адрес. Но оно менее эффективно, как упоминалось ранее. Но это проблема только при большом объеме трафика. |
|
|
|
Читают тему