Данная статья сугубо технического характера, затрагивающая один из аспектов блокировки ресурсов по спискам РКН и имеет актуальность для сервисов, ориентированных (в том числе) на жителей РФ.
Краткий обзор способов блокировки
Для блокировки по спискам РКН обычно используют следующие техники:
- Блокировка путём анализа (копии) трафика и отправки фейкового tcp rst пакета, в результате чего происходит разрыв соединения. Весьма популярный способ среди операторов по разным причинам. Данная статья не применима к этому способу.
- Блокировка путём удаления (drop) трафика (опционально с редиректом/syn rst/прочим) на оборудовании DPI (или прозрачном прокси), который установлен в разрыв, при этом через DPI проходит весь трафик (ну или только tcp+dns или только нужные порты tcp). Этот способ тоже применяется операторами. Данная статья не применима к этому способу.
- Блокировка путём dns-спуфинга и "заруливанию" трафика на DPI/transparent proxy только для IP-адресов, которые есть в реестре (некоторые ещё добавляют путём резолвинга, но не суть). Этот способ тоже применяется операторами и именно про него речь и пойдёт в статье.
В реестре слишком много префиксов
Используя способ №3, оператору нужно проанонсировать в сеть огромное количество префиксов (маршрутов), в настоящий момент в реестре имеется около 2M префиксов (из которых бо?льшая часть /32) и если это сделать, то многие роутеры не справятся с такими количество записей в таблице маршрутизации. Типичный размер таблицы маршрутизации для используемых на сегодняшний день hw роутеров 1M-2M-4M (бывают и больше, но это уже из верхнего ценового диапазона). Если кто-то не знает, 2M маршрутов это больше, чем маршрутов во всём Интернет, в ipv4 и ipv6 пространствах вместе взятых.
Что делать с этими префиксами
Операторы, использующие вариант №3, не сильно хотят переходить на вариант №1 или №2 (обычно, они дороже, чем №3), поэтому производители решений, умеющих работать по схеме №3 применили следующий трюк: префиксы можно агрегировать до более крупных сетей, например в адресном пространстве ipv4 много соседних /32 схлопнуть до /24. Как это работает: все уникальные префиксы /32 округляются до /24 (применяется маска 0xffffff00 или 255.255.255.0 в более привычной нотации) и ведётся подсчёт количество уникальных префиксов среди всех округлённых до /24. Далее, вводится пороговое значение, по которому осуществляется анонсирование одной /24 вместо много /32. Например, при пороге 10 у вас будет примерно 380К вместо 2М, а это уже влезает даже в широко используемые и даже довольно старые модели роутеры. Если порог уменьшать, то префиксов будет ещё меньше.
И что в этом плохого?
Действительно, что же в этом плохого, ну пройдёт чуть больше трафика через DPI/прозрачный прокси, выглядит как проблема оператора, но на самом деле это не совсем так. Зачастую, это становится проблемой абонента и сервиса, у IP-адреса которого оказолось "много" соседей по сети /24 (или другой сети, смотря как агрегируют). Зачастую, эти железки перегружены у операторов в ЧНН (часы наибольшей нагрузки), вносят задержки, могут блокировать TLS-трафик с каким-то особенностями, случается, что они криво работают с http2, а следовательно, даже если IP-адреса вашего сервиса нет в списке РКН (и даже ни один домен не указывает на ваш IP-адрес), то это вовсе не означает, что трафик к вашему сервису не пойдёт через специальный фильтр (который ещё может быть установлен на другом конце страны если оператор крупный).
Какая польза от знания этого нюанса?
Польза для владельцев сервиса может быть такова — внезапно часть ваших пользователей (с плохо выраженными географическими особенностями и вообще непонятным общим признаком) стали жаловаться на медленную работу. Одной из возможных причин может быть то, что среди ваших соседей по IP-адресу "слишком много" (например, более 10) заблокированных IP-адресов в реестре РКН и поэтому некоторые операторы пустили трафик к вашему сервису DPI. А дальше уже решайте сами, насколько вам важны эти пользователи и жалобы от них, делать какое-то зеркало на другом IP, менять IP или что-то ещё. Ещё некоторые операторы в РФ дают IPv6 абонентам, возможно, ваш сервис ещё не умеет IPv6 и это может помочь решить описываемую проблему (ну и приобрести другие, как это обычно бывает).
Предупреждён — значит вооружён.
GennPen
Если работать с DNS по IPv6 то спуфинг не работает. Это особенность протокола или многие операторы не спуфят DNS по IPv6?
in_heb Автор
Тут всё по-разному. Оператором нужно, чтобы Ревизор генерировал хороший отчёт (с минимальным количеством пропусков). Ревизор следит и за ipv6, сторонние dns (насколько мне известно), Ревизор не тестирует. Многие операторы вообще не фильтруют трафик сторонних DNS, некоторые выдают специальные dns для Ревизора (вообще, РКН может покарать за помещение их коробочки в песочницу). Какой-то оператор может заворачивать весь трафик ipv4 dns на свой, а про ipv6 забыть или не иметь возможности (nat66 не все железки умеют).
В целом у меня нет статистики по операторам кто делает спуфинг по dns ipv4 и по dns ipv6. Кроме как «забыли» и нет возможности сделать «nat66»/не умеет DPI других вариантов не вижу. Сам по себе IPv6 никак не защищает от dns-спуфинга, так что у вас это какой-то побочный эффект.
GennPen
ДомРу, по IP блокирует(не знаю каким методом) по IPv4 и IPv6, в DNS подставляет IP заглушки только по IPv4.
PS C:\> nslookup telegram.org 8.8.8.8
TхЁтхЁ: dns.google
Address: 8.8.8.8
Не заслуживающий доверия ответ:
Lь : telegram.org
Addresses: 2a02:2698:a002:1::3:17
5.3.3.17
PS C:\> nslookup telegram.org 2001:4860:4860::8888
TхЁтхЁ: dns.google
Address: 2001:4860:4860::8888
Не заслуживающий доверия ответ:
Lь : telegram.org
Addresses: 2001:67c:4e8:1033:1:100:0:a
2001:67c:4e8:1033:2:100:0:a
2001:67c:4e8:1033:3:100:0:a
2001:67c:4e8:1033:4:100:0:a
2001:67c:4e8:1033:5:100:0:a
2001:67c:4e8:1033:6:100:0:a
149.154.167.99
nokimaro
Оператор может подменять ответы dns серверов в том числе 8.8.8.8 так как находится по середине и в обычном виде dns трафик не защищён от просмотра и подмены. Для борьбы с этим и существуют всякие DNScrypt или DNS over HTTPs (doh)