Comments 25
а не проще было делать локальную подмену MAC на ПК, получая "нужный" IP на основе MAC по DHCP?
В моём случае - нет. Использую кучку USB-LAN адаптеров и WiFi подключение на ноуте, мне проще ориентироваться по адресам устройств, чем заморачиваться с их MAC. Можно реализовать получение списка всех адресов локальной сети из DHCP и сделать удобный список выбора, но это не тот функционал, который меня интересует в первую очередь, интересней добиться быстрого переключения маршрутов, но что-то постоянно держит сессии, как их не отстреливай - это больше сейчас меня занимает )
Предположим у меня сотня VPN подключений на микротике и 1 сервер за этим микротиком, который должен в зависимости от адрес листа выходить в мир(на любые адреса) через то или иное VPN подключение. Вопрос, есть ли возможность что-то прописать в domains чтоб весь трафик шел через VPN? может запись default это как раз оно?
Default - применить основной маршрут вашего роутера, снять с адреса или домена принадлежность к списку адресов на файрволле. Вам надо создать правила mangle на файрволле, как я описал - в зависимости от принадлежности локального адреса к списку пускать его на адрес шлюза за VPN подключением (локальный адрес роутера/хоста за VPN маршрут к которому должен быть прописан в списке маршрутов через имеющееся подключение, на другой стороне так же должен быть маршрут в вашу сеть, либо примените masquerade на это VPN подключение). И помещать адрес сервера в один из таких списков, весь его трафик, кроме немаршрутизируемых адресов в отдельном списке not-routed (он нужен обязательно, без него начнутся коллизии), пойдёт через указанный шлюз.
ппц замарочился ето статью можно был назввать как NOC обходит блолкировки)
Хорошо заморочились :) У меня похожая схема (несколько "точек выхода" в разных странах, маршрутизация через ту или иную по GeoIP, AS, подсети, IP или домену), но списки для маршрутизации централизованно на одном сервере формируются, а он уже всем микротикам и не только раздаёт их в виде отдельного community на каждую группу адресов по BGP.
Понравилась Ваша идея про адресацию на основе локального адреса клиента. Пока у меня просто отдельные группы пользователей в VPN (из локальных сетей получаешь набор маршрутов, дефолтный для данной локации, хочешь другой набор - подключайся к VPN под нужным юзером), что дико неудобно. Но надо хорошо подумать, как это изящнее реализовать, если один и тот же клиент может подключиться через 5 разных роутеров или VPN.
А вопрос - насколько такой простой логики хватает (добавляем в список IP / домен основного сайта, который в адресной строке)? Часто ли получается, что сайт подтягивает кучу ресурсов с совершенно других серверов (или, того хуже, CDN), у которых либо свои ограничения по доступу, либо просто всё ломается от разных маршрутов, - и в итоге добавление одного IP не спасает?
Когда сайт стабильно сидит на нескольких ip, в пределах 10, то его можно смело добавлять в списки по этим адресам. На Микротике наглядно видно при добавлении доменного имени, что с ним происходит - оно либо стабильно сидит на одних и тех же адресах, либо устраивает чехарду в списке из постоянно обновляющихся адресов за этим именем. Проверка входящего ip на сайте обычно происходит один раз при первом обращении, тот же intel.com позволяет зайти под иностранным адресом, потом можно переключиться на свой не обновляя страницу и продолжить с ней работать. Что-то более сложное делать со стороны админов иностранных ресурсов - не вижу смысла, чем усложнять логику на сайте, проще забанить нас на уровне доступа к своим пулам адресов.
Ну когда как у Интела - это понятно. Но бывает просто блок по GeoIP и получаем или заглушку access denied (родную или от Cloudflare со товарищи), или вообще никак не отвечающий сайт. И этот блок может быть установлен не только на домене, отдающем главную страницу. Ну и внереестровые блокировки РКН сюда же. И вечно меняющие IP сайты без собственной AS (классический пример, который меня бесит, - турецкий маркетплейс hepsiburada.com; размещён на Akamai, адреса постоянно разные, по GeoIP не турецкие, но при этом с нетурецких адресов тупо не открывается).
Для таких случаев, теоретически, должно помочь: (а) собирать все доменные имена, с которых страница тянет ресурсы (но тут могут быть конфликты, какие-нибудь Google Fonts таким макаром окажутся во всех списках одновременно, надо вести и список исключений, получается) и (б) один раз внесённые в список доменные имена периодически в фоне заново ресолвить, чтобы отлавливать смену IP. Но это уже совсем нетривиально получается... Пункт "б" у меня, в принципе, реализован, но тоже не без проблем (я этот ресолвинг делаю централизованно на одном сервере, но клиентам в разных странах могут отдаваться разные IP). По ходу, без интеграции со своим DNS-ресолвером (отправляем все запросы к оному на фоновую проверку по спискам доменов, при совпадении добавляем маршрут в нужный список) нормально никак не сделать.
Проблему производительности для себя закрыл переходом на x86 - теперь я в упираюсь в возможности системы, например, есть ограничение на общий размер всех переменных окружения и у меня не получилось объявить массив в миллион строк, но зато список файрволла спокойно заполняю доменными именами, система сама поддерживает актуальный список адресов не вызывая ощутимой нагрузки. Но мне не так много надо куда ходить и ещё просто не сталкивался, с тем, чтобы сайт упорно меня не пускал при добавлении его доменов в мой список.
Понятно. Я пытаюсь решить более общую задачу - чтобы меня отовсюда пускало везде, даже если мне туда не надо и я вообще в жизни никогда не узнаю про существование такого сайта :) И тут уже сотни тысяч маршрутов, с которыми адекватно работать получается только через BGP.
Я думал об автоматике построения базы доступности доменов с разных регионов ip, тут нужен бот заходящий на страницы с разных адресов и сравнивающий их содержимое, если сайт не выдаёт нам ошибку при обращении и не блочит. Реализовать не сложно, но пока не хочется жертвовать своими адресами в базу спам-ботов :) поэтому остановился на плагине, который всегда под рукой.
Может кому интересно будет, поделюсь своим решением использования региональных баз адресов https://forum.mikrotik.com/viewtopic.php?t=40507#p1050902
Очень интересный инструмент, а под линукс браузеры что нить подобное можно создать?
Расширение работает в Линукс версии Chrome, должно работать в Mac версии. Кто скачал ранее, в файле popup.css удалите строку width: 200px; в разделе body - это фиксированная ширина плагина, нужна пока делаешь вёрстку, чтоб легче было ровнять объекты. Но она под шрифты по умолчанию Windows, в других ОС другие шрифты и вёрстка поедет с такой шириной плагина. Удалите строку или сделайте значение ширины больше, на свой вкус.
как тренировка написания расширения — отлично, интересно и все понятно, а если для работы, то имхо универсальнее сделать через механизм add src to address list и скрипта, анализирующего итоговые списки
на маршрутизаторе создаем статические dns адреса вида: isp1, isp2 и пр (в человекопонятном виде), подготавливаем списки, ну и делаем скрипт, который проверяет списки и при нахождении адреса переносит этот адрес в список, соответствующий нужному шлюзу/провайдеру/правилу и тд.
для переключения, с нужного устройстве пингуем соответствующиее dns имя и все.
да, будет лаг на время периодичности запуска скрипта, но в остальном - нет привязки к браузеру, платформе и прочее
Попробовал использовать ваше расширение, и есть небольшой баг репорт/фидбэк если можно так сказать:
1) если расширение не может достучаться до ваших внешних ресурсов(например впн через который шел трафик - упал) - оно не позволяет внести изменение в адрес лист
2) если микротик в другой сети - расширение не может к нему подключиться
3) использование ваших личных внешних ресурсов, в целях определения ip адреса и может чего еще - немного сомнительная практика, лучше бы использовать популярные общедоступные сервисы или дать возможность эту функцию отключить вовсе
Извиняюсь за позднюю реакцию, давно не посещал ресурс. Не удалось воспроизвести 1-й случай, при падении канала у меня маршруты идущие через него идут на дефолтные и поведение такое же, как при выборе дефолтного маршрута для своего компа или для сайта, переключение работает. Во время такого поведения есть сверху сообщение об ошибке красным цветом? 2-й случай надо проверить, работает ли API Микротика из другой сети вообще, в браузере с компа другой сети перейти по адресу: http://192.168.88.1/rest/system/resource и если появится предложение ввести учётные данные, значит API доступно и надо искать проблему в приложении. На ROS 7 у меня работает управление роутерами в других сетях.
По поводу внешнего API приму к сведению, подумаю какие варианты можно сделать. Как будет время и желание, допишу чего-нибудь. Свой API развиваю, между прочим, он и появился от недостатка функционала имеющихся общедоступных сервисов. Можно заменить API частично скриптами Микротика, в эту сторону надо подумать.
В первом случае у меня машина теряет доступ в интернет полностью, к микротику тоже - т.е. полностью изолируется, однако у машины есть второй сетевой интерфейс через который есть доступ к микротику через другую подсеть(только к микротику, к интернету - нет), и вот мы переходим ко второму случаю, я думаю приложение не может получить доступ к вашим API(интернета то нет), и это каким-то образом не дает ему корректно отработать и поменять маршрут
del
Проект выложил на GitHub, описание обновления и ссылка в конце статьи.
Расширение браузера для управления маршрутами на Микротике