Сегодня поразмышляю про КВН, маршрутизацию и давай запихнём туда весь Интернет
Периодически меня спрашивают, откуда я беру списки доменов и IP-адресов для маршрутизации через КВН.
Есть замечательные готовые проекты, которые мне прислали, которые я изучил, вроде Antifilter.Download или V2Fly Domain List Community или keneetic-antifilter и ещё 100500 других которых на гитхабе полно.
Сразу скажу 〰️ я ничего не имею против самих проектов. Более того, это огромная работа, и тот же V2Fly прямо пишет, что его база не определяет, какой домен нужно блокировать или отправлять через прокси. Это набор данных, из которого предполагается строить собственные правила.
Проблема начинается тогда, когда подобный список скачивают целиком и говорят 📢
Ну всё. Вот это отправляем через КВН.
И тут у меня как у человека, который хоть немного дружит с сетями, начинает дёргаться глаз. 😨
В таких community-базах могут быть огромные категории сервисов, компаний, CDN, инфраструктурных доменов, подсетей и зависимостей. Например, одна только категория category-companies у V2Fly включает Apple, Amazon, Adobe, Cisco, Microsoft, NVIDIA, Oracle, Sony, Yahoo, Яндекс, МТС, Ростелеком, Selectel и ещё десятки компаний. 🤪
А дальше одна категория включает другую, та 〰️ третью, появляются domain, full, keyword, regexp, целые географические группы… 🙈
И в какой-то момент возникает закономерный вопрос ❓
А мы РКН обходим или строим альтернативный маршрут для половины Интернета? 😁
С IP-сетями история ещё веселее. Community-версия Antifilter на момент написания этого поста сама сообщает, что её список префиксов покрывает 884 541 IP-адрес.
И вот этого подхода я для себя принципиально не хочу.
Мне не нужен КВН для всего Интернета.
Мне нужно, чтобы через КВН работали конкретные ресурсы, которыми пользуюсь я, моя семья, родственники, друзья и коллеги. Всё остальное должно идти обычным маршрутом.
Поэтому мой принцип очень простой ❗️
не добавить всё, а потом разбираться, а добавить только то, необходимость чего я увидел сам.
И это немного сложнее.
Допустим, нужен какой-нибудь сервис. Добавил его основной домен 〰️ не заработало.
Почему ❓
Потому что современное приложение практически никогда не ходит только например, на google.com. У него могут быть API, авторизация, CDN, WebSocket, телеметрия, отдельные backend-сервисы, облачные хранилища и ещё пачка зависимостей.
И вот тут начинается самое интересное 〰️ смотреть сеть. 👀
Совсем недавно я таким способом разбирался с Google и его сервисами.
Вместо того чтобы взять очередной список ВСЕ ДОМЕНЫ GOOGLE!!!111 и отправить через КВН половину Google Cloud, я запускал приложение и смотрел РЕАЛЬНЫЙ ТРАФИК.
Обычный tcpdump довольно быстро показал обращения к нужным *.googleapis.com, *.run.app, ssl.gstatic.com и другим зависимостям.
Добавил необходимое ➡️ проверил.
Не работает ➡️ снова посмотрел трафик.
Нашёл следующий запрос ➡️ понял, зачем он нужен ➡️ добавил.
Перезапустил ➡️ проверил ещё раз.
Да, это ДОЛГО 〰️ то самое страшное слово, которое так не любят в компаниях PM, CEO и прочие уважаемые люди, когда нужно быстро, прямо сейчас, а желательно ещё вчера. 😁
Это дольше, чем просто скачать чей-нибудь domains.txt.
Зато в конце я хотя бы понимаю, почему каждая запись находится в моём списке маршрутизации.
И это правильный траблшутинг ❗️
На macOS для этого мне ещё очень нравится Little Snitch от Objective Development.
Это вообще прекрасная штука для тех, кому интересно, что на самом деле происходит у него на компе.
Little Snitch показывает, какой процесс к какому серверу подключается, домен, адрес сервера, протоколы, порты и историю соединений. Можно открыть нужное приложение и буквально наблюдать, куда оно пытается сходить.
И очень быстро выясняется, что условное app.google.com
на самом деле превращается в
auth.google.com
api.google.com
ssl.gstatic.com
oauth2.googleapis.com
backend.run.app
и ещё несколько совершенно неочевидных адресов.
Вот эти адреса я и предпочитаю находить самостоятельно. 😎
Есть ещё tcpdump, dig, nslookup, traceroute, curl, просмотр DNS-запросов 〰️ старые добрые инструменты, которые почему-то всё ещё прекрасно работают. 😁
Иногда, глядя на некоторые публичные списки, создаётся ощущение, что сегодня главное 〰️ побыстрее собрать очередной универсальный обход блокировок, выложить его, получить звёздочки и подписчиков, а вопрос что конкретно мы сейчас маршрутизируем и почему? оставить на потом. Всё равно никто не спрашивает если заработало то что нужно. 😁
А потом появляются списки, где можно встретить совершенно неожиданные вещи, вплоть до локальных/служебных адресов и категорий, которые конкретному пользователю вообще никогда не понадобятся.
Мой подход скучнее ❓ Да ❗️
нужен ресурс ➡️ смотрим его трафик ➡️ находим зависимости ➡️ проверяем ➡️ добавляем ➡️ документируем.
И да-да-да 〰️ документация. 😁
Та самая штука, которую никто не любит писать, потому что и так всё понятно.
А потом проходит полгода, ты открываешь список из сотни доменов и IP-адресов, видишь там какой-нибудь ssl.gstatic.com и задаёшь себе главный инженерный вопрос
А нафига я это сюда добавил?
И вот именно в этот момент та самая скучная документация, на которую когда-то пожалел -цать минут, внезапно становится очень нужна.
Поэтому добавил домен или подсеть 〰️ напиши хотя бы одной строкой в Obsidian или текстовичок для какого сервиса, зачем и при каких условиях это понадобилось.
Поверьте, через полгода будущий Вы скажет нынешнему Вам спасибо. 😁
И всё ❗️
В результате список получается намного меньше, понятнее и, главное, мой.
Я знаю, зачем там находится каждый крупный домен или подсеть. Я могу удалить правило и понимаю, что перестанет работать. А обычный российский трафик, банковские приложения, локальные сервисы, CDN и всё, чему КВН совершенно не нужен, не отправляются путешествовать через полмира только потому, что кто-то когда-то добавил соответствующую сеть в огромный community-list.
Наверное, это профессиональная деформация.
Но я всё-таки за принцип
КВН должен маршрутизировать столько, сколько необходимо.
А не столько, сколько удалось найти в интернете. 😉
#КВН #маршрутизация #сети #Keenetic #LittleSnitch #tcpdump #DNS #DevOps
Периодически меня спрашивают, откуда я беру списки доменов и IP-адресов для маршрутизации через КВН.
Есть замечательные готовые проекты, которые мне прислали, которые я изучил, вроде Antifilter.Download или V2Fly Domain List Community или keneetic-antifilter и ещё 100500 других которых на гитхабе полно.
Сразу скажу 〰️ я ничего не имею против самих проектов. Более того, это огромная работа, и тот же V2Fly прямо пишет, что его база не определяет, какой домен нужно блокировать или отправлять через прокси. Это набор данных, из которого предполагается строить собственные правила.
Проблема начинается тогда, когда подобный список скачивают целиком и говорят 📢
Ну всё. Вот это отправляем через КВН.
И тут у меня как у человека, который хоть немного дружит с сетями, начинает дёргаться глаз. 😨
В таких community-базах могут быть огромные категории сервисов, компаний, CDN, инфраструктурных доменов, подсетей и зависимостей. Например, одна только категория category-companies у V2Fly включает Apple, Amazon, Adobe, Cisco, Microsoft, NVIDIA, Oracle, Sony, Yahoo, Яндекс, МТС, Ростелеком, Selectel и ещё десятки компаний. 🤪
А дальше одна категория включает другую, та 〰️ третью, появляются domain, full, keyword, regexp, целые географические группы… 🙈
И в какой-то момент возникает закономерный вопрос ❓
А мы РКН обходим или строим альтернативный маршрут для половины Интернета? 😁
С IP-сетями история ещё веселее. Community-версия Antifilter на момент написания этого поста сама сообщает, что её список префиксов покрывает 884 541 IP-адрес.
И вот этого подхода я для себя принципиально не хочу.
Шурик, это же не наш метод!
Мне не нужен КВН для всего Интернета.
Мне нужно, чтобы через КВН работали конкретные ресурсы, которыми пользуюсь я, моя семья, родственники, друзья и коллеги. Всё остальное должно идти обычным маршрутом.
Поэтому мой принцип очень простой ❗️
не добавить всё, а потом разбираться, а добавить только то, необходимость чего я увидел сам.
И это немного сложнее.
Допустим, нужен какой-нибудь сервис. Добавил его основной домен 〰️ не заработало.
Почему ❓
Потому что современное приложение практически никогда не ходит только например, на google.com. У него могут быть API, авторизация, CDN, WebSocket, телеметрия, отдельные backend-сервисы, облачные хранилища и ещё пачка зависимостей.
И вот тут начинается самое интересное 〰️ смотреть сеть. 👀
Совсем недавно я таким способом разбирался с Google и его сервисами.
Вместо того чтобы взять очередной список ВСЕ ДОМЕНЫ GOOGLE!!!111 и отправить через КВН половину Google Cloud, я запускал приложение и смотрел РЕАЛЬНЫЙ ТРАФИК.
Обычный tcpdump довольно быстро показал обращения к нужным *.googleapis.com, *.run.app, ssl.gstatic.com и другим зависимостям.
Добавил необходимое ➡️ проверил.
Не работает ➡️ снова посмотрел трафик.
Нашёл следующий запрос ➡️ понял, зачем он нужен ➡️ добавил.
Перезапустил ➡️ проверил ещё раз.
Да, это ДОЛГО 〰️ то самое страшное слово, которое так не любят в компаниях PM, CEO и прочие уважаемые люди, когда нужно быстро, прямо сейчас, а желательно ещё вчера. 😁
Это дольше, чем просто скачать чей-нибудь domains.txt.
Зато в конце я хотя бы понимаю, почему каждая запись находится в моём списке маршрутизации.
И это правильный траблшутинг ❗️
На macOS для этого мне ещё очень нравится Little Snitch от Objective Development.
Это вообще прекрасная штука для тех, кому интересно, что на самом деле происходит у него на компе.
Little Snitch показывает, какой процесс к какому серверу подключается, домен, адрес сервера, протоколы, порты и историю соединений. Можно открыть нужное приложение и буквально наблюдать, куда оно пытается сходить.
И очень быстро выясняется, что условное app.google.com
на самом деле превращается в
auth.google.com
api.google.com
ssl.gstatic.com
oauth2.googleapis.com
backend.run.app
и ещё несколько совершенно неочевидных адресов.
Вот эти адреса я и предпочитаю находить самостоятельно. 😎
Есть ещё tcpdump, dig, nslookup, traceroute, curl, просмотр DNS-запросов 〰️ старые добрые инструменты, которые почему-то всё ещё прекрасно работают. 😁
Иногда, глядя на некоторые публичные списки, создаётся ощущение, что сегодня главное 〰️ побыстрее собрать очередной универсальный обход блокировок, выложить его, получить звёздочки и подписчиков, а вопрос что конкретно мы сейчас маршрутизируем и почему? оставить на потом. Всё равно никто не спрашивает если заработало то что нужно. 😁
А потом появляются списки, где можно встретить совершенно неожиданные вещи, вплоть до локальных/служебных адресов и категорий, которые конкретному пользователю вообще никогда не понадобятся.
Мой подход скучнее ❓ Да ❗️
нужен ресурс ➡️ смотрим его трафик ➡️ находим зависимости ➡️ проверяем ➡️ добавляем ➡️ документируем.
И да-да-да 〰️ документация. 😁
Та самая штука, которую никто не любит писать, потому что и так всё понятно.
А потом проходит полгода, ты открываешь список из сотни доменов и IP-адресов, видишь там какой-нибудь ssl.gstatic.com и задаёшь себе главный инженерный вопрос
А нафига я это сюда добавил?
И вот именно в этот момент та самая скучная документация, на которую когда-то пожалел -цать минут, внезапно становится очень нужна.
Поэтому добавил домен или подсеть 〰️ напиши хотя бы одной строкой в Obsidian или текстовичок для какого сервиса, зачем и при каких условиях это понадобилось.
Поверьте, через полгода будущий Вы скажет нынешнему Вам спасибо. 😁
И всё ❗️
В результате список получается намного меньше, понятнее и, главное, мой.
Я знаю, зачем там находится каждый крупный домен или подсеть. Я могу удалить правило и понимаю, что перестанет работать. А обычный российский трафик, банковские приложения, локальные сервисы, CDN и всё, чему КВН совершенно не нужен, не отправляются путешествовать через полмира только потому, что кто-то когда-то добавил соответствующую сеть в огромный community-list.
Наверное, это профессиональная деформация.
Но я всё-таки за принцип
КВН должен маршрутизировать столько, сколько необходимо.
А не столько, сколько удалось найти в интернете. 😉
#КВН #маршрутизация #сети #Keenetic #LittleSnitch #tcpdump #DNS #DevOps