Хабр Курсы для админов
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 33
Я сделал проще. У меня реверсивная схема. Всё идёт через VPN-туннель кроме IP RU сегмента.
Тоже думал про это дело но столкнулся с тем что к примеру у яндекс станции видимо для кинопоиска используется тоже CDN который нужно отловить. И получалось что у меня время от времени она говорила отсутсвует подключение к интернету
не совсем понятно что за CDN, который нужно отловить… Часть CDN яндекса находится в RU сегменте, какая то другая часть видимо находится в другом сегменте и работает через VPN - как это мешает станции? Можно пожалуйста поподробнее этот кейс расписать?
CDN cdn'у рознь. Для скорости, бывает так, что чтобы определить в какой регион нужно направить пользователя - смотрят откуда (из какой зоны) прилетел самый первый dns запрос. И если это dns какого-нибудь cloudflare , в который запрос прилетел с vps где-нибудь в Европе, то он вполне может вернуть европейский cdn.
Могу ошибаться
Пусть Яндекс Станция всегда бегает через провайдера, как вариант.
Так же разделяю весь трафик на русский и иностранный.
Тоже сталкивался с проблемой, когда Яндекс колонки отказываются работать.
Первое что я сделал, я их повесил на отдельную вай-фай сеть.
А второе, попросил нейросеть сделать администскую страничку где есть список устройств и на котором можно выбрать, будет ли устройство работать через обход или напрямую через байпас.
Выбрал Яндекс колонки и те устройства, которые нужны, чтобы напрямую ходили всегда.
Моя практика показала, что этого не достаточно: напрямую работает быстрее, например huggingface лучше гапрямую, но модели с него касаются напрямую не всегда, наш dns и забугорный расходятся: наши одни домены юлочат, ихние - другие.
Предложенный в статье метод выглядит панацеей, но думаю должен работать медленно. Пока все маршруты протестируются, мы будем получать отказы.
Может быть имеет смысл при попытке ресолвинга паралельно проверять разные dns, а потом опять же паралельно проверять доступность напрямую и через впн или несколько впн.
В идеальном мире, было бы интересно сделать версию для кинетик, заставить роутеры обмениваться накопленой информацией, создать механизм p2p-mesh-шаринга дуступа к впн для группы друзей, чтобы если какой-то маршрут не работает через твой впн, он мог бы стать доступным через роутер товарища.
Я просто обескуражен вашей идеей. Если люди мою задумку покатают то почему бы и не сделать меш сеть как вы и предложили.
Только вот в идеальном мире через роутер товарища в первую очередь потечет ЦП и клятвы верности исламскому государству. Обьяснять группе захвата, что ты всего лишь маршрутом поделился, будет, наверное, непросто.
То, что вы описали, уже изобрели. TOR называется.
Сейчас мне нужен отчёт что у кого ломается чтобы до ума доделать эту идею
Address list сильно затратное дело по cpu, ram возможно. Чистый роутинг гораздо легче
Во-первых, первый заход на неизвестное заблокированное направление всё равно должен сломаться. После истечения шестичасового TTL — снова.
Во-вторых, классификация идёт фактически по destination IP + protocol, а не по сайту. Если на одном Cloudflare/CDN-IP живёт 500 сайтов и один из них вызвал эвристику, TCP/443 на весь этот IP некоторое время поедет через РКН КВН. Это не ломает работу, но selective routing постепенно может становиться менее selective.
В-третьих, задержка/packet loss/дохлый сервер вполне могут выглядеть как блокировка. Момент тонкий, правда, лучше перебдеть и отправить в КВН.
И в-четвёртых, довольно забавна реализация: каждые 1–2 секунды RouterOS-скрипты ковыряют connection tracking (FAST 1s, DETECT 2s, JUDGE 1s). На мощном MikroTik и умеренном числе соединений это нормально, но я бы очень внимательно посмотрел на CPU при десятках тысяч conntrack entries, особенно, если роутер всё же не самый топовый.
Да и то, Cudy + OpenWRT сегодня для дома как-то самой бюджетной связкой выглядит - а на современном OpenWrt подобное же вполне реализуемо, причём даже архитектурно чище, чем на MikroTik: есть libnetfilter_conntrack/netlink API именно для работы с kernel conntrack, так что демон может слушать события, а небольшим таймером проверять только подозрительные незавершённые flows.
Да, первый заход на новый заблокированный IP действительно может не сработать — Susanin сначала должен понять, что с направлением что-то не так. После истечения записи он тоже может начать обучение заново. Это осознанный компромисс: я не хотел снова прийти к вечному списку IP, только уже автоматически собранному.
По CDN тоже всё верно. Сейчас логика в основном работает на уровне IP + протокол, поэтому если на одном IP сидит много сайтов, часть трафика может временно поехать через VPN шире, чем хотелось бы. TCP и UDP хотя бы разделены, но точности «по сайту» тут пока нет.
С false positive тоже согласен. Плохой канал, packet loss или просто дохлый сервер могут выглядеть как блокировка. Поэтому Susanin не отправляет адрес в VPN навсегда сразу: сначала пробует, потом смотрит, помогло ли это. Но идеальной классификации тут, конечно, нет — это эвристика.
И да, вопрос нагрузки на conntrack очень важный. На моём ARM64 MikroTik при домашней нагрузке всё нормально, но десятки тысяч соединений я пока не тестировал. Это как раз один из пунктов, который хочу отдельно проверить и замерить по CPU.
А по OpenWrt спорить вообще не буду — там такую штуку действительно можно сделать архитектурно красивее через netlink/conntrack events. Susanin появился именно потому, что у меня уже был MikroTik, и мне хотелось решить эту проблему внутри RouterOS, а не менять платформу.
Так что да — замечания по делу. Собственно, поэтому проект пока и называется pilot, а не production-ready.
А вот за это Вам и спасибо - во-первых, идея витала в воздухе, но одно дело "думать мыслю", другое - реализовать.
Во-вторых, хотя я нежно относился к Микротику многие годы, сейчас уже восторг поутих, и понимаю, что на его архитектуре не все пилится так уж легко, так что уложиться в прокрусово ложе ОС, которую пишет маленький коллектив, не ставящий целью делать немногое, но лучше всех - это, да, та еще задачка. Но и интересно же, наверное?
А с OWRT - тупо выходит дешевле. Не так много роутеров в магазине подходят, но Cudy имеет несколько устройств в линейке, и ЦП у них как на подбор - мощные, "ковыряйся - не хочу". Жаль, что флешки маловато, и не везде USB есть для расширения хранилища.
В любом случае, спасибо Вам!
ИМХО самое лучшее средство на данный момент это https://github.com/daniellavrushin/b4
Начиная от работы практически всего интернета без квн с детектом отказов до умного роутинга в туннели и т.д.
Настроил один раз через удобную веб панель списки сервисов и всё, они автоматически обновляются при необходимости
Это не то же самое что добавлять по одному сайту который не открылся в список роутера.
Кто захочет экспериментов базовые настройки тут
Проект активно развивается и это очень круто, у разработчика своя группа в телеге где есть что посмотреть)
Правильно ли я понимаб что в такой схеме, пользователь пытается обновить сайт, он не грузится, обновляет страницу и случается магия? Но если сайт зависит от других доменов, то обновлять страницу прийдётся несколько раз?
А не проверяли что с масштабируемостью такого подхода? Ну например, одно дело, какая нагрузка на железки если 2-3 юзера будут шерстить сеть (теоретически там проблем никаких не должно быть с этим), и совсем другое, если, например, 50?
К сожалению я такой возможностью не обладаю. Я поэтому и выпустил в пилот - чтобы у кого есть возможность рассказали как работает, да и как там по задержкам CPU нагрузке.
Так что если у вас получится я буду очень рад посмотреть результат
На реальном офисе вряд ли получится проверить (там экспериментировать нельзя, за такое ай-яй-яй). Но как вариант для тестов - попробовать это дело на симуляции: MikroTik CHR и какой-нибудь генератор трафика (или самому скриптами сделать нечто подобное). Получится такой подпроект, виртуальная лаба, так скажем
Установил на свой RB5009. Правда у меня иная схема маршрутизации - нет никаких интерфейсов VPN, а есть контейнер Mihomo, куда весь трафик и уходит. И сам принцип маршрутизации иной - адрес-листы LOCAL_CLIENTS, LOCAL_NETS (куда только напрямую) и DIRECT (хосты, попадающие в подсети LOCAL_CLIENTS, но которых надо пускать только напрямую), и два правила mangle, которые и рулят кого прямо, кого в Михомо. Поэтому в исходном виде Сусанин не подошел, но ИИ сделал мне форк под мои условия. Первое впечатление крайне положительное! Это именно то, чего мне не хватало. Теперь весь трафик не ломится через Михомо, нагрузка на поднятые в нем VPN упала. Ну и при высоких скоростях скачивания (у меня гигабитный тариф) Михомо нехило так жрал процессор, хоть и обрабатывал по правилу DIRECT. Сусанин распознает проблемы в целом корректно (например быстро и правильно оценил задушенный Youtube, в том числе и по QUIC), разве что немного “перестраховывается”. Например, пущенные им через VPN всяческие .yandex.ru (с чего бы?), .ksn.kaspersky-labs.com и прочее успешно обрабатываются в Михомо через DIRECT. Но такие случаи, можно сказать, единичные, и при моих условиях никакой роли не играют. Пока наблюдаю за работой. Было бы круто добавить в Сусанина редактируемый список типа “Всегда на VPN” для заблокированных с “той стороны” ресурсов, которые страницу успешно “отдают”, но пишут “вам недоступно” и т.п. Регулярный скан соединений конечно заметно нагружает процессор, но пока терпимо. На роутерах послабее не знаю как оно будет. У меня в пике ~30% бывает суммарно по роутеру. Сейчас ИИ борется с периодической ошибкой “script error: no such item (4)”, но пока что-то безуспешно. Буду внимательно следить за развитием проекта! Очень нужная штука в текущих условиях.
Спасибо вам огромное. Если можно выложите на гит чтобы я потом в мэйн ветку забрал изменения. В будущем в проекте много что планируется - просто пока не могу реализовать ввиду того что времени не хватает.
идея хорошая, спасибо!
желаю качественного развития
для себя пока подожду более стабильных версий
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сусанин: как я перестал кормить MikroTik списками доменов и научил искать рабочий маршрут самостоятельно