Переброс запросов

Тема в разделе "Маршрутизация", создана пользователем deedee, 10 авг 2016.

  1. deedee

    deedee Участник

    Прошу помощи, так как своих познаний пока не хватает.
    Имеем 2 белых ip адреса. 1.1.1.1, 2.2.2.2.
    Нужно чтобы запросы приходящие на 1.1.1.1 порт 1111 переправлялись на 2.2.2.2 и порт 2222
    Там где IP 1.1.1.1 стоит оборудование mikrotik, локалки там нету он просто должен использоваться как шлюз для проброса.

    Заранее спасибо за любую помощь.
     
  2. Илья Князев

    Илья Князев Администратор Команда форума

    Последнее редактирование модератором: 23 янв 2019
  3. deedee

    deedee Участник

    Спасибо за ответ, но дело в том что это перечитанно не раз уже :) Мне не понятно что должно произойти с пакетом, обычный нет мап не помогает.
     
    Последнее редактирование модератором: 23 янв 2019
  4. deedee

    deedee Участник

    В общем получилось так:

    chain=dstnat action=netmap to-addresses=2.2.2.2 to-ports=2222
    protocol=tcp in-interface=ether1 dst-port=1111 log=yes log-prefix=""

    chain=srcnat action=masquerade out-interface=ether1 log=no log-prefix=""

    Нужно ещё что то добавлять ? Или этого достаточно ? В принципе всё заработало. Не работало без правила маскарадинга.
     
    Последнее редактирование модератором: 23 янв 2019
  5. Илья Князев

    Илья Князев Администратор Команда форума

    Достаточно
    И не должно было. 2.2.2.2 отправлял ответ на свой default gateway непосредственно отправителю пакета.
    Включением Masquerade вы поменяли адрес отправителя пакета на адрес первого маршрутизатора и теперь 2.2.2.2 отправляет пакет на 1.1.1.1
     
  6. deedee

    deedee Участник

    Спасибо вам огромное за просветление :)
     
  7. Roman Markov

    Roman Markov Участник

    А можно ли в обратную сторону для ВСЕХ пакетов из сети конечного сервера сделать правило, по которому он будет выходить в интернет через роутер-посредник.

    Пример - мы пробросили таким образом RDP до скрытого сервера, "засветив" только IP промежуточного посредника.

    Однако если на сервере пользователь запустит браузер и введёт запрос "Узнать свой IP" и пр. - он получит реальный адрес, через который тот выходит в интернет.

    А как сделать так, чтобы результатом был как раз тот самый промежуточный роутер? Возможно ли реализовать этим же методом, без построения тоннелей?
     
  8. Илья Князев

    Илья Князев Администратор Команда форума

    Вот не смог в голове схему представить, чего вы хотите получить :(
     
  9. Roman Markov

    Roman Markov Участник

    То, что мы получили в результате сабжа - это возможность предоставить кому-либо НЕ ТОТ IP, где реально располагается сервер, а промежуточный.
    То есть даём человеку адрес для стандартного RDP в виде: 2.2.2.2:3389
    А на самом деле этот RDP-сервер располагается вовсе не по этому IP-адресу, а где-то в другой точке мира.

    Таким образом по предоставленному IP-адресу можно приехать и найти там только промежуточный роутер, а не искомый сервер.

    Однако, если на этот сервер зайти и запустить tracert или тупо открыть сайт 2ip.ru и подобные - он сразу сообщит свой РЕАЛЬНЫЙ IP.

    А можно ли сделать так, чтобы весь трафик от этого сервера транслировался в обратном направлении и подобный запрос выдавал бы IP-адрес того самого посредника?

    Я имею в виду тот же метод, так как про тоннель знаю и сам.
     
    Последнее редактирование: 19 авг 2016
  10. Илья Князев

    Илья Князев Администратор Команда форума

    В принципе можно решить только первую часть идеи.
    /ip firewall nat
    add chain=dstnat protocol=tcp dst-port=3389 action=dst-nat to address=АДРЕС_ТС // Заворачиваем трафик на сервак.
    add chain=srcnat out-interface=WAN action=masquarade // И закрываем все своим адресом, чтобы сервак нам ответил сюда.

    А вот вторая часть задания без туннеля не решается. Потому что нам важно сохранить dst-address пакета, иначе он не будет доставлен куда надо.
     
  11. Roman Markov

    Roman Markov Участник

    Ничего не понял, если честно. Это же стандартный "проброс портов". Первая часто того, что я описывал решается одной вышеприведенной командой с netmap (когда есть промежуточный интернет-канал и он перебрасывает все запросы по конкретному порту на следующий внещний IP, где и работает приведенная вами конструкция.

    Это понятно.

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

    *********************

    А то я до этого я пытался городить огороды с dstnat и кучей маршрутов, а оказывается это решается одной командой netmap на промежуточном маршрутизаторе %о)))

    ОК, спасибо за ответ.
     
  12. Илья Князев

    Илья Князев Администратор Команда форума

    Netmap частный случай dst-nat или src-nat. Нужен для проброса СЕТЕЙ 1:1
    И в любом случае нужно 2 команды. Например
    1.1.1.1 - адрес клиента
    2.2.2.2 - адрес промежуточного роутера.
    3.3.3.3 адрес терминального сервера.
    Клиент шлет пакет
    1.1.1.1 -> 2.2.2.2
    На 2.2.2.2 срабатывает dst-nat
    1.1.1.1->3.3.3.3
    Если не сделать src-nat то 3.3.3.3 ответит клиенту напрямую со своего адреса. Клиент получив ответ с адреса на который ничего не отправлял будет удивлен. Поэтому добавляем src-nat
    2.2.2.2->3.3.3.3
     
  13. AlexShoroh

    AlexShoroh Участник

    Уважаемые коллеги. Доброго времени суток.
    Прошу помощи.
    Есть основная точка(router) потом вторая точка (роутер в режиме bridge)и после нее AP.
    Так вот, проброс порта 80 на АР идеть, а на роутер в режиме бриджа нет.
    IP на точках все статические. обращаюсь на внешнийIP:8084 и проброс на внутренний 80.
    Три точки завелись(АР), а вот эта нет. нахожусь за 380 км. от объекта (отпуск, купаюсь в Хопре, сотовой связи нет). ;-)
    Кофигурация проброса на router:
    Код:
    chain=dstnat action=netmap to-addresses=192.168.88.2 to-ports=80
      protocol=tcp in-interface=pppoe-out1 dst-port=8084 log=yes log-prefix=""
    На роутере в режиме бридж файрвола нет. www разрешен, CAP прекрасно работает. Терминал с роутера есть, но cli микротика не освоил.
    Как попасть на эту точку?
    З.Ы. Похоже до меня дошло. )))
    Пивка попью, попробую, отпишусь.
    Каюсь. Сам напортачил.
    На этой точке не было дефолного маршрута.
     
    Последнее редактирование: 21 авг 2016