mikrotik редирект внешнего адреса на внутренний
Перенаправление запросов (проброс портов) на Mikrotik
Инструкция описывает процесс настройки перенаправления сетевых запросов с внешнего подключения на компьютеры в локальной сети.
Настройка проброса
Далее настройка выполняется в зависимости от того, какой сервис нужно опубликовать.
Примеры пробросов
RDP (удаленный рабочий стол)
* если данная настройка не сработает, меняем протокол на tcp и задаем порт RDP — по умолчанию, 3389.
WWW (80 или веб-сервер или http)
HTTPS
Настройка та же, что для 80 порта, но в место 80 пишем 443.
Видеонаблюдение
Системы видеонаблюдения могут работать на различных портах, поэтому первым делом обращаемся к инструкции системы, с которой необходимо работать.
В данном примере рассмотрим проброс RTSP.
* RTSP работает по протоколам TCP и UDP. В данном примере правило настроено для последнего.
Почтовая система Zimbra
Для нормальной работы почтовой системы необходимо пробросить следующие порты:
Важно отметить, что не все перечисленные порты понадобятся именно вам. Если мы не планируем использовать POP3, то и соответствующие порты для него пробрасывать не нужно.
Сама настройка на микротике будет такой:
Перенаправление трафика в MikroTik
Исходные данные:
Локальная сеть (src-address): 172.16.66.0/24
Задача:
Надо перенаправить с url: routerpwn.com/info.html на 172.16.66.200:80
Делаю так:
(1) у сайта routerpwn.com ip адрес: 74.208.139.97
я вначале отбираю все пакеты у которого dst-address == 74.208.139.97
ip firewall mangle add action=jump jump-target=registry chain=prerouting dst-address=74.208.139.97 dst-port=80 protocol=tcp src-address=172.16.66.0/24
(2) создаю правило в L7 для url: routerpwn.com/info.html
ip firewall layer7-protocol add name=routerpwn regexp=»^.*(\/info\.html).*(routerpwn\.com).*$»
(3) маркирую пакеты по L7
ip firewall mangle add action=mark-packet chain=registry dst-port=80 layer7-protocol=routerpwn new-packet-mark=registry passthrough=no protocol=tcp src-address=172.16.66.0/24
(4) а в NAT перенаправляю:
ip firewall nat add action=dst-nat chain=dstnat dst-port=80 packet-mark=registry protocol=tcp src-address=172.16.66.0/24 to-addresses=172.16.66.200 to-ports=80
Что получается: 1-3 проходит как и хотел, а вот (4) не срабатывает… пробовал в (4) перенаправлять, когда dst-address = 74.208.139.97 получается, так же получается если в (1) промаркировать пакеты с dst-address == 74.208.139.97 тоже вышло, а вот после (3) пункта и маркировки пакета по L7 не получается.
UDP:
если на шаге (3) убрать L7, то все получается. L7 правило создано верно, проверял через ip filter — дропаются пакетики
Mikrotik, переадресация ip адреса?
Добрый день!
Имеется внешний микротик с внешним ip адресом, локальной сетью 10.12.0.0/24 + сервис (пусть будет web- сервер на 4856 порту).
Есть клиент клиенты, работающие через интернет.
Сделан проброс порта.
Но в логах сервера подключения идут от микротика. Но нужно сделать так чтобы были видны в логах реальные адреса клиентов.
Если же микротик заменить на зуксел, то в логах идут реальные адреса клиентов.
Andrey Makarenko, Покажи правила для проброса порта.
/ip firewall export
/ip firewall filter
add action=accept chain=input dst-port=1723 protocol=tcp
add action=accept chain=input protocol=gre
add action=drop chain=input disabled=yes protocol=icmp
/ip firewall nat
add action=masquerade chain=srcnat
add action=dst-nat chain=dstnat dst-address-type=local dst-port=4856 \
protocol=tcp to-addresses=10.12.0.250 to-ports=4856
add action=masquerade chain=srcnat out-interface=ether1
Делаем (или правим) NAT для IP которые будут работать в обход, исключаем белые ip «white_ip»
/ip firewall nat add action=masquerade chain=srcnat src-address-list=!white_ip disabled=no out-interface=ether3
Далее список NetMap адресов которым «привязываем» белые
/ip firewall nat add chain=srcnat src-address=10.0.40.67 action=netmap to-addresses=1.1.1.1
/ip firewall nat add chain=dstnat dst-address=1.1.1.1 action=netmap to-addresses=10.0.40.67
И заключительная часть, добавляем в white_ip наши VIP адреса:
/ip firewall address-list add list=»white_ip» address=10.0.40.67
Как зайти по внешнему IP-адресу из локальной сети для MikroTik
Допустим у нас есть:
У нас уже есть настроенное правило проброса порта 8080:
Но оно не будет срабатывать при обращении из локалки, так как настройки ориентированы на пакеты из внешней сети, через WAN-порт. Поэтому нам нужно прописать дополнительно еще 2 правила.
Настройка доступа из локальной сети по внешнему IP-адресу
1. Создаем правило для перенаправления обращений по внешнему IP из локальной сети.
Теперь на компьютер 192.168.88.229 можно зайти из локальной сети по внешнему IP-адресу 1.1.1.1.
Но при попытке какого-то взаимодействия с ним ничего не получится. Почему? Посмотрим, что происходит.
Поэтому нам нужно еще одно правило, которое будет подменять локальный адрес источника при отправке пакета на внешний IP.
2. Подменяем локальный адрес компьютера на внешний IP-адрес.
На вкладке Action выставляем маскарадинг (masquerade), т. е. подмену адреса источника на локальный адрес маршрутизатора.
На вкладке General прописываем правила, при которых он будет применяться:
Теперь, получив пакет из локальной сети, адресованный на внешний IP 1.1.1.1, маршрутизатор не только перенаправит его на 192.168.88.229 (по первому правилу), но и заменит в пакете адрес источника (192.168.88.110) на свой локальный адрес.
Ответ от сервера поэтому отправится не напрямую в локальную сеть, а на маршрутизатор, который, в свою очередь направит его источнику.
Второй способ Hairpin NAT MikroTik: 2 правила вместо 3
Можно сделать еще проще, заменив правило проброса портов первым правилом Hairpin NAT. В этом случае в настройках не нужно указывать In. Interface и Src Address, но нужно прописать адрес назначения.
Доступ на внешний IP адрес вашего сервера или компьютера с приложением будет открыт как для обращений извне, так и из локальной сети, с любых адресов, но только для пакетов с адресом назначения 1.1.1.1:80.
Теперь добавляете описанное выше правило srcnat, и все. Можно добавить дополнительную фильтрацию, прописав в out-interface тот интерфейс, с которого будут осуществляться отправки пакетов, если есть такая необходимость.
Недостатком Hairpin NAT является только то, что нагрузка на роутер возрастает, ведь те обращения, что раньше проходили через локальную сеть непосредственно между компьютерами, теперь будут идти через маршрутизатор.
Второй способ проще, но, в зависимости от конфигурации вашей сети, может использоваться и первый.
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Проброс портов и Hairpin NAT в роутерах Mikrotik
Проброс портов
Давайте рассмотрим небольшую схему, которая поможет понять принцип действия проброса портов.
Допустим, некий удаленный ПК хочет обратиться к нашему веб-серверу, который находится за маршрутизатором в локальной сети. Но обратиться он может только по внешнему адресу маршрутизатора (в нашем примере 192.168.3.113), на который мы пробросили порт 80 веб-сервера. Поэтому он формирует пакет, в котором адресом назначения выступает маршрутизатор и отправляет его получателю, в качестве адреса источника он указывает собственный адрес.
Маршрутизатор, получив такой пакет выполняет замену адреса назначения с собственного, на адрес веб-сервера, также, при необходимости, он может изменить и порт назначения. После чего пакет отправляется в локальную сеть и достигает веб-сервера. Данные о преобразовании заносятся в специальную таблицу трансляции NAT.
Нужно ли менять адрес отправителя? Нет, если маршрутизатор выступает основным шлюзом сети, а в подавляющем большинстве случаев это так. Веб-север обработает запрос, а так как он ничего не знает о сети получателя, то обратный пакет будет направлен шлюзу по умолчанию, т.е. назад нашему маршрутизатору.
Маршрутизатор на основании данных таблицы трансляции выполнит обратное преобразование, заменив на этот раз адрес источника с внутреннего адреса веб-сервера, на свой внешний адрес и отправит пакет запросившему его узлу.
Мы не даром заостряем на этом особое внимание, так как непонимание процесса прохождения пакета по цепочкам сетевого фильтра способно привести к значительным затруднениям, когда вроде-бы все правила составлены верно, но ничего не работает.
Так для пакета от клиента к веб-серверу и обратно порядок прохождения цепочек будет следующим:
Обратите внимание, что пакет не попадает в цепочки INPUT и OUTPUT, которые используются для собственных пакетов маршрутизатора.
Либо выполните в терминале:
Но это еще не все, после PREROUTING пакет попадет в цепочку FORWARD, в которой, если вы настраивали роутер по нашей инструкции, запрещены любые внешние пакеты, кроме инициированных из локальной сети соединений.
Располагаться данное правило должно выше правила, запрещающего транзитный трафик из внешней сети во внутреннюю.
Обратите внимание, что если вы пробрасываете порт с изменением номера, скажем внутренний 3389 (RDP) на внешний 3390, то в правиле брандмауэра вы всегда должны указывать внутренний порт, т.е. 3389, так как пакет уже прошел цепочку PREROUTING и данные о получателе в нем уже изменены на адрес и порт внутреннего сервера.
Из терминала это можно сделать командами:
Осталось только проверить работу наших правил, попробуем получить доступ к веб-серверу со внешнего узла:
Как видим, все прекрасно работает.
Hairpin NAT
Почему так происходит? Давайте рассмотрим еще одну схему:
Первая ее часть нам уже знакома, узел отправляет запрос на внешний адрес маршрутизатора, он заменяет адрес назначения адресом внутреннего сервера и отправляет пакет к нему, адрес отправителя остается неизменным. А вот дальше начинается самое интересное, веб-сервер видит, что отправитель находится в ним в одной сети и отправляет ответ ему напрямую. Но отправитель направлял запрос на внешний адрес сервера и ждет ответа именно от него, поэтому ответный пакет, отправителем которого указан внутренний адрес веб-сервера будет отброшен и связь установить не удастся.
Что же делать? Очевидно, что нужно каким-то образом заставить веб-сервер отвечать не напрямую клиенту, а пересылать пакет обратно маршрутизатору. Здесь нам на помощь придет действие src-nat (SNAT), которое позволяет изменить адрес отправителя, находящееся в цепочке POSTROUTING. В терминах Mikrotik данная настройка носит наименование Hairpin NAT.
Чтобы понять, как это работает мы подготовили следующую схему:
Теперь наш маршрутизатор не только изменяет адрес назначения, но и адрес источника, указывая в его качестве собственный внутренний IP. Обработав такой пакет веб-сервер отправит его обратно к маршрутизатору, который выполнит обратные преобразования (согласно таблице трансляции) и оправит его получателю. А так как отвечать будет именно тот узел, к которому был отправлен запрос, то в данном случае все будет работать.
Обратите внимание, что в качестве адреса и порта назначения мы указываем внутренние адрес и порт, так как пакет уже прошел цепочку PREROUTING, где данные получателя были изменены. К сожалению, не все это понимают, во многих инструкциях в сети в данном правиле фигурирует внешний адрес, стоит ли говорить, что такое правило работать не будет.
Через терминал данное правило можно создать следующим образом:
В нашем случае все адреса статические, поэтому использование src-nat здесь будет более уместно.
Правило создано, проверим его работу:
Подводя итог, можем сказать, что в пробросе портов нет ничего сложного, но только в том случае, если вы представляете в каком порядке и как обрабатываются пакеты, в противном случае даже такая элементарная задача способна превратиться в длительные мучения на ровном месте. Поэтому мы надеемся, что данный материал пригодится вам не только в практическом плане, но и позволит повысить собственный уровень знаний.
Дополнительные материалы:
Mikrotik
The Dude
Помогла статья? Поддержи автора и новые статьи будут выходить чаще: