vlagilen Опубликовано 11 января, 2014 (изменено) Есть 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Барагоз Опубликовано 11 января, 2014 mark connection... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlagilen Опубликовано 11 января, 2014 mark connection... Не подскажите пример с маркировками? Прочитал много инфы по этому поводу, но так и не могу понять как все это дело работает через маркировку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlagilen Опубликовано 12 января, 2014 Не понятна логика данного маршрутизатора. До этого был DFL как ему объясняешь так он и делает. А микротик при активном подключении даже если приоритет у канала стоит меньше он же доступен со внехи и зайти на него можно, но он ни в какую не хочет принимать перенаправление портов на локальные железки до тех пор пока эти железки не будут пользовать этим же маршрутом. Печаль Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Барагоз Опубликовано 12 января, 2014 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 среди дилетантов вроде меня: обладая весьма общими представлениями о технологии, на МТ можно реализовать ее в несколько щелчков мыши и пользоваться через несколько минут, абсолютно не вникая в детали реализации на конкретной ОС или железке. Так что, если у вас что-то не получается - проблема не с логикой работы МТ, а с вашими представленимями ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlagilen Опубликовано 12 января, 2014 (изменено) Сделал как у вас, не работает. Немного разобрался почему не хочет работать. Суть в том что физически в маршрутик входиь только ОДИН кабель, на этом порту прописываем статику которую предоставляет провайдер и получаем доступ в просторы интернета с узким каналом и внутри провайдерскую сеть. Внутри этой сети поднимаю 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Барагоз Опубликовано 12 января, 2014 Сделал как у вас, не работает. Значит что-то недоосмыслили и сделали неправильно. Кусок конфига действующего роутера, на котором эта схема работает. Точно так же есть один интернет на порту и другой через впн, ходящий по этому же порту. Ничего, озарение придет со временем (я не иронизирую). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlagilen Опубликовано 12 января, 2014 В routing mark в таблице маршрутов вы указываете direct? Какие адреса содержатся в "tomsk" ? И почему вы указываете отрицательное значение? Единственное что в "src-address-list" я указал тот самый единственный локальный адрес. Интернет на локальный комп ,при указании маршрута с маркировкой, идет с vpn как и должно, но вот со статики на этот локальный так и не заходит. Железка нормально ведь отвечает со статики и порты работают ее родные (80, 8291), а в локалку ни в какую не перенаправляет. Бред. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Барагоз Опубликовано 12 января, 2014 (изменено) Единственное что в "src-address-list" я указал тот самый единственный локальный адрес. Ну и естественно работать не будет. В моем примере работает для всех подсетей, не относящихся к городским, то есть это список хостов/подсетей возможных инициаторов соединения. Ваш локальный адрес там ни при чем. В routing mark в таблице маршрутов вы указываете direct? Да, в маршрутах правило для direct через физический интерфейс и в route rule правило искать маршрут с роутингмарком direct в таблице direct. Изменено 12 января, 2014 пользователем Барагоз Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlagilen Опубликовано 13 января, 2014 (изменено) Ну и естественно работать не будет. В моем примере работает для всех подсетей, не относящихся к городским, то есть это список хостов/подсетей возможных инициаторов соединения. Ваш локальный адрес там ни при чем. Я 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Барагоз Опубликовано 13 января, 2014 Далее таблица маршрутов. Где 172.17.10.1 это шлюз vpn подключения(сервера). Тогда зачем вы роутинг-марк direct заворачиваете в впн, когда вам нужно ходить через физический интерфейс? В общем, нарисуйте для себя на бумажке, как должен идти пакет. Со всеми IP и номерами портов. И правильно ли я сделал Route rule? Оставьте direct - lookup - direct, всё остальное лишнее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlagilen Опубликовано 13 января, 2014 (изменено) Тогда зачем вы роутинг-марк 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlagilen Опубликовано 14 января, 2014 (изменено) Еще столкнулся с такой проблемой как отказоустойчивость. Если комп находится в сети и на него прописать все эти манглы и маршруты, то все работает. Потом через какое-то время маршрут route mark перестает работать, пока я не отключу в маршрутах route mark (или маршрут целиком) и заного не включу. Изменено 15 января, 2014 пользователем vlagilen Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
danila17 Опубликовано 18 ноября, 2015 Всем привет Что бы не создавать новое напишу тут Вот вопросик. есть 2 провайдера l2tp - wan1 pptp - wan2 пришли они в микротик. работают себе , но как допустим из 20-ти пользователей, 5-ыи дать wan1 15-ти wan2 Ну и что бы при откаже одного, всех на работающий, а потом обратно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...