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...