[vlagilen]

Есть Mikrotik и два провайдера.

1) Первый провайдер имеет статический адрес, но узкий канал 1мб.

2) У второго все хорошо со скоростью, но из вне адреса у него нет.

Необходимо чтобы пользователь сети (предположим что он единственный и на нем крутится web сервер) выходил в просторы интернета через широкий канал, а на него можно было зайти из вне, через узкий канал по 80 порту.

 

Если я сажу пользователя на узкий канал, то проблем нет, он выходит и на него можно без проблем зайти, но вот если прописать маршруты так чтобы второй канал(узкий) был резервный, то из вне не могу до него достучаться, это и логичн т.к. маршрут со статический адресом становится не активным, до тех пор пока не отвалится первый канал. Пробовал и через маркировку, все равно привязка идет к маршруту.

 

192.168.0.14 адрес того самого единственного клиента

[admin@MikroTik] /ip firewall mangle> print
Flags: X - disabled, I - invalid, D - dynamic 
0   chain=prerouting action=mark-routing new-routing-mark=mark_wan 
    passthrough=yes protocol=tcp src-address=192.168.0.14

 

172.17.0.2 - первый провайдер со статмческий ip. Вся переадресация (port mapping) идет с этого адреса на локальный компьютер (192.168.0.14).

172.17.0.1 - второй провайдер с широким каналом и без возможности зайти на него из вне. Используется по умолчанию и если он падает, то второй провайдер поднимается и можно зайти на 192.168.0.14 локальный 80-й порт компьютера.

#      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
0 A S  0.0.0.0/0                          172.17.0.1             1
1 A S  0.0.0.0/0                          172.17.0.2             2

Изменено 11 января, 2014 пользователем vlagilen

[Барагоз]

mark connection...

[vlagilen]

mark connection...

 

Не подскажите пример с маркировками? Прочитал много инфы по этому поводу, но так и не могу понять как все это дело работает через маркировку.

[vlagilen]

Не понятна логика данного маршрутизатора. До этого был DFL как ему объясняешь так он и делает. А микротик при активном подключении даже если приоритет у канала стоит меньше он же доступен со внехи и зайти на него можно, но он ни в какую не хочет принимать перенаправление портов на локальные железки до тех пор пока эти железки не будут пользовать этим же маршрутом. Печаль

[Барагоз]

ip firewall mangle

 

 2   ;;; mark connection rdp from out of tomsk
    chain=prerouting action=mark-connection new-connection-mark=rdp passthrough=yes protocol=tcp dst-address=х.х.х.х 
    src-address-list=!tomsk dst-port=3389 

4   ;;; mark routing for rdp from out of tomsk
    chain=prerouting action=mark-routing new-routing-mark=direct passthrough=yes src-address=192.168.0.2 connection-mark=rdp

 

ip firewall nat

 

 2   ;;; rdp-server
    chain=dstnat action=dst-nat to-addresses=192.168.0.2 to-ports=3389 protocol=tcp dst-address=x.x.x.x src-address-list=admin-list 
    in-interface=tomtel dst-port=3389 

 

ну и в маршрутах соответствующий роутинг-марк.

 

Не понятна логика данного маршрутизатора

Логика данного маршрутизатора совпадает, на мой взгляд, с логикой IP-технологий как таковых. Именно этим объясняется бешеная популярность RouterOS среди дилетантов вроде меня: обладая весьма общими представлениями о технологии, на МТ можно реализовать ее в несколько щелчков мыши и пользоваться через несколько минут, абсолютно не вникая в детали реализации на конкретной ОС или железке. Так что, если у вас что-то не получается - проблема не с логикой работы МТ, а с вашими представленимями ;)

[vlagilen]

Сделал как у вас, не работает.

 

Немного разобрался почему не хочет работать.

Суть в том что физически в маршрутик входиь только ОДИН кабель, на этом порту прописываем статику которую предоставляет провайдер и получаем доступ в просторы интернета с узким каналом и внутри провайдерскую сеть. Внутри этой сети поднимаю vpn (так называемый ранее широкий канал). Следовательно что шлюз у статики и vpn разный. Доступ из вне необходимо имень через "узкую" статику". Если маршруты прописаны со статики то все работает, но вот если прописать маршрут с vpn, до доступа на статику нет потому что маршрут будет резервным.

 

Если физически два кабеля будут заходить в железку, то проблем нет(проверял).

Так все таботает.

#      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
1 A S  0.0.0.0/0                          127.0.0.1             1

 

pptp_connect "Routing mark: mark_ip" в этом случае сам маршрутизатор доступен, но перенаправлять порты отказывается на локальный компьютер

#      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
0 A S  0.0.0.0/0                          pptp_connect              1
1 A S  0.0.0.0/0                          127.0.0.1             1

Изменено 12 января, 2014 пользователем vlagilen

[Барагоз]

Сделал как у вас, не работает.

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

[vlagilen]

 

В routing mark в таблице маршрутов вы указываете direct?

Какие адреса содержатся в "tomsk" ? И почему вы указываете отрицательное значение?

Единственное что в "src-address-list" я указал тот самый единственный локальный адрес.

 

Интернет на локальный комп ,при указании маршрута с маркировкой, идет с vpn как и должно, но вот со статики на этот локальный так и не заходит. Железка нормально ведь отвечает со статики и порты работают ее родные (80, 8291), а в локалку ни в какую не перенаправляет. Бред.

[Барагоз]

Единственное что в "src-address-list" я указал тот самый единственный локальный адрес.

Ну и естественно работать не будет. В моем примере работает для всех подсетей, не относящихся к городским, то есть это список хостов/подсетей возможных инициаторов соединения. Ваш локальный адрес там ни при чем.

 

В routing mark в таблице маршрутов вы указываете direct?

Да, в маршрутах правило для direct через физический интерфейс и в route rule правило искать маршрут с роутингмарком direct в таблице direct.

Изменено 12 января, 2014 пользователем Барагоз

[vlagilen]

Ну и естественно работать не будет. В моем примере работает для всех подсетей, не относящихся к городским, то есть это список хостов/подсетей возможных инициаторов соединения. Ваш локальный адрес там ни при чем.

Я list оставляю пустым. У меня статический адрес так же является и локальным для провайдера, нет распределения на локальный и внешний.

 

Сделал все как вы описали(вроде):

[admin@MikroTik] /ip firewall mangle> print

# x.x.x.x - статический внешний ip через который необходимо попадать из вне
0   chain=prerouting action=mark-connection new-connection-mark=uni 
    passthrough=yes protocol=tcp dst-address=x.x.x.x dst-port=8443 

1   chain=prerouting action=mark-routing new-routing-mark=direct 
    passthrough=yes src-address=192.168.7.5 connection-mark=uni

 

[admin@MikroTik] /ip firewall nat> print
Flags: X - disabled, I - invalid, D - dynamic 

# pptp-connect - vpn подключение через которое необходимо ходить
# ether1 - статический канал от провайдера
0   chain=srcnat action=masquerade out-interface=pptp-connect 

1   chain=srcnat action=masquerade out-interface=ether1 

2   chain=dstnat action=dst-nat to-addresses=192.168.7.5 protocol=tcp 
    dst-address=x.x.x.x dst-port=8443 

 

Далее таблица маршрутов. Где 172.17.10.1 это шлюз vpn подключения(сервера).

При поднятии VPN я не получаю внешнего адреса как такогого, а только локальный который выдает сервер "172.17.10.5". Собственно поэтому со внехи через шлюз vpn доступа нет т.к. нет адреса, он плавающий(адрес) и крутится со стороны сервера.

Необходимо чтобы локальный компьютер "192.168.7.5" использовал для выхода в интернет VPN шлюз, а доступ из вне был через ether1. Зайти на железку используя внешний адрес ether1 на порты 80, 8291 получается без проблем, но вот на порт 8443 локального устройста(192.168.7.5) нет.

 

И правильно ли я сделал Route rule?

 

Что не так?

Изменено 13 января, 2014 пользователем vlagilen

[Барагоз]

Далее таблица маршрутов. Где 172.17.10.1 это шлюз vpn подключения(сервера).

Тогда зачем вы роутинг-марк direct заворачиваете в впн, когда вам нужно ходить через физический интерфейс?

В общем, нарисуйте для себя на бумажке, как должен идти пакет. Со всеми IP и номерами портов.

 

И правильно ли я сделал Route rule?

Оставьте direct - lookup - direct, всё остальное лишнее.

[vlagilen]

Тогда зачем вы роутинг-марк direct заворачиваете в впн, когда вам нужно ходить через физический интерфейс?

Нужно выходить через VPN клиенту MT, а попадать на клиента MT нужно через физический интерфейс (по схеме 1.1.1.1)

 

VPN туннель поднимается посредством внешний адресов выданным провайдером №1 (1.1.1.1 <-VPN-> 2.2.2.2). Так же со стороны сервера 2.2.2.2 приходит второй провайдер 3.3.3.3 и наш микротик посредством VPN канала получает со своей стороны выход через 3.3.3.3, а следовательно клиент микротика тоже ходит через 3.3.3.3, собственно что нам и нужно было. Если клиент MT будет ходить через 1.1.1.1, то проблем с перенаправлением портов нет.

 

---- - выход клиента MT в интернет

---- - доступ на клиента MT на порт 8443

 

------------------------------

 

В итоге вроде все получилось. direct указал на основном канале, статическом. В mark connection убрал dst.port и убрал правило mangle rule (за что оно отвечает ?) и с ними и без них все завелось. Если мне нужны не только TCP ? Если я создам еще mark connection + mark route, но уже для UDP соединений и пропишу все это еще одним маршрутом, будет работать?

Огромное Спасибо!

Изменено 14 января, 2014 пользователем vlagilen

[vlagilen]

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

Изменено 15 января, 2014 пользователем vlagilen

[danila17]

Всем привет

Что бы не создавать новое напишу тут

Вот вопросик.

есть 2 провайдера

l2tp - wan1

pptp - wan2

пришли они в микротик. работают себе , но как допустим из 20-ти пользователей, 5-ыи дать wan1 15-ти wan2 Ну и что бы при откаже одного, всех на работающий, а потом обратно