074909
@074909
группа медленного нереагирования

Mikrotik: портмаппинг на внешнем интерфейсе и клиент из локальной сети не может подключиться, используя белый адрес роутера. Существует ли решение?

Здравствуйте!
Есть следующая конфигурация: роутер микротик (RouterOS 6.18), интернет PPoE (внешний адрес 69.69.69.69), несколько комп-ров в локальной сети. На одном из-комп-ров (192.168.0.2) некий сервис слушает tcp порт 128, в связи с чем был проброшен снаружи порт для внешних клиентов:
add action=dst-nat chain=dstnat dst-address=69.69.69.69 dst-port=128 protocol=tcp to-addresses=192.168.0.2 to-ports=128
Всё работает, как и ожидалось.

Далее возникает необходимость клиенту из локальной сети подключаться с сервису, используя как целевой не локальный адрес 192.168.0.2, а внешний 69.69.69.69; после чего выясняется, что для локальных клиентов успешно только пингование внешнего адреса роутера, а попытки подключения к любому из заведомо открытых портов (22, 80, 128) не приносят успеха.

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

Собственно, сам вопрос: что нужно сделать микротику, чтобы клиент 192.168.0.1 смог успешно соединится с 69.69.69.69:128 ? или это неисправимая особенность микротика?
  • Вопрос задан
  • 5005 просмотров
Решения вопроса 3
@Power
Скорее всего, не работает по следующей причине: инициатор соединения (клиент с адресом 192.168.0.*) посылает запрос на адрес 69.69.69.69. На роутере переписывается адрес назначения (на 192.168.0.2), но не переписывается адрес отправителя. Сервер (получатель) видит, что пакет отправлен с локального адреса (192.168.0.*) и ответ шлёт напрямую на этот адрес (в обход роутера). А клиент в результате получает ответ на свой запрос не с ожидаемого адреса 69.69.69.69, а с 192.168.0.2, так что считает такой пакет невалидным и игнорирует.
Для более точной диагностики нужны выводы следующих команд от имени root на роутере:
ifconfig -a
route -n
iptables-save
# если третья команда не работает, то вместо неё две:
iptables -nvL
iptables -t nat -nvL
Ответ написан
@blotlihome
Для решения твоей задачи нужно сделать так:
/ip firewall nat
add action=masquerade chain=srcnat comment="Map Lan to Lan" dst-address=\
192.168.24.18 dst-port=80 protocol=tcp src-address=192.168.22.0/16
add action=dst-nat chain=dstnat comment="Map Lan to Lan" dst-address=\
69.69.69.69 dst-port=80 protocol=tcp src-address=192.168.22.0/16 \
to-addresses=192.168.24.18
add action=dst-nat chain=dstnat comment=\
"Map 80" dst-address=69.69.69.69 dst-port=80 \
protocol=tcp to-addresses=192.168.24.18 to-ports=80
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
eapeap
@eapeap
Сисадмин, Беларусь
Скорее всего - особенность Микротика.
Была похожая задача - на Микротике на внешнем интерфейсе несколько внешних белых адресов, сделано несколько подсетей за НАТом, на разных внутренних портах. Проброшен порт RDP с одного внешнего адреса на вутренний 192,168,24,18. Снаружи работает, из своей сети 192.168.22.ХХХ - не работает. За разумные сроки не решили.
Ответ написан
edinorog
@edinorog
Троллей не кормить!
тупой вопрос. а зачем?)
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы