Понимание технической стороны экономит время: становится ясно, почему одни советы бесполезны, а другие работают, и почему приложения ведут себя так странно — открываются, но наполовину. Разберём механизм без лишней сложности.
По какому признаку принимается решение
Каждый пакет, который уходит с вашего устройства, несёт адрес получателя. В обычном режиме сеть просто доставляет его дальше. В режиме белого списка на пути стоит проверка: входит ли адрес получателя в перечень разрешённых. Если да — пакет идёт дальше, если нет — отбрасывается.
Важно, что проверка происходит на раннем этапе и по внешнему признаку. Она не требует ни расшифровки, ни анализа содержимого, ни распознавания протокола — достаточно посмотреть на адрес.
Чем это отличается от DPI
DPI — глубокий анализ пакетов — заглядывает внутрь трафика и пытается понять, что это за протокол. Против него работает маскировка: если трафик выглядит как обычный HTTPS, зацепиться не за что. Фильтрация по адресу устроена проще и грубее, и именно поэтому маскировка против неё бессильна: содержимое никто не смотрит.
Почему приложение работает наполовину
Это самое сбивающее с толку наблюдение: банковское приложение открывается, баланс виден, а история операций не подгружается. Или карта запускается, но плитки не отрисовываются.
Объяснение простое: современное приложение обращается не к одному адресу, а к десяткам. Собственный API-сервер, сеть доставки контента для картинок, сервис аналитики, платёжный шлюз, сервис пуш-уведомлений — всё это разные адреса, часто принадлежащие разным компаниям.
В перечень разрешённых попадает не «приложение», а конкретные адреса. Те его части, что ходят к разрешённым адресам, работают. Те, что ходят к остальным, — нет. Отсюда и половинчатое поведение.
| Что делает приложение | Куда обращается | Работает ли |
|---|---|---|
| Вход и баланс | Собственный сервер банка | Обычно да |
| Логотипы и картинки | Сеть доставки контента | Часто нет |
| Карта отделений | Сторонний картографический сервис | Часто нет |
| Пуш-уведомления | Сервис доставки уведомлений | Обычно нет |
| Аналитика и метрики | Сторонние сервисы | Нет |
Почему VPN не подключается
Здесь всё следует из механизма. VPN-клиент отправляет пакет на адрес своего сервера. Этого адреса в перечне нет, поэтому пакет отбрасывается на сети оператора и до сервера не доходит. Сервер, в свою очередь, ничего не получает и ничего не отвечает.
Клиент видит только одно: ответа нет. Для него это неотличимо от «сервер недоступен», поэтому он показывает ошибку подключения или бесконечно повторяет попытки. Приложение при этом полностью исправно.
Из механизма следует и то, почему не помогают привычные решения:
- Смена протокола. Протокол определяет, как выглядит содержимое пакета. Содержимое здесь не проверяют.
- Смена порта. Порт тоже не является признаком, по которому принимается решение.
- Смена страны. Все адреса вне перечня одинаково недоступны, независимо от географии.
- Другой клиент. Клиент лишь отправляет пакеты; их судьбу решает сеть.
Работает единственное — точка входа на адресе, который сам входит в перечень разрешённых. Подробнее о том, что это значит на практике, — в статье что делать при белых списках.
Почему DNS иногда работает, а сайт нет
Ещё одно частое наблюдение: сайт «находится», но не открывается. Это происходит потому, что определение адреса по имени и собственно соединение — два разных шага, идущих к разным адресам.
Устройство сначала спрашивает у DNS-сервера, какой IP-адрес соответствует имени сайта. Если DNS-сервер входит в перечень разрешённых, ответ приходит. Затем устройство пытается соединиться с полученным адресом — и вот тут, если адрес не разрешён, соединение не устанавливается. Внешне это выглядит как «сайт есть, но не грузится».
Смена DNS не помогает
Популярный совет «пропиши публичный DNS» в этом режиме бесполезен по двум причинам: во-первых, сам публичный DNS-сервер может быть недоступен, во-вторых, даже успешный ответ не решает главную проблему — соединение к целевому адресу всё равно не пройдёт.
Почему у соседа работает, а у вас нет
Перечни формируются и применяются не единообразно. Отличия возникают на нескольких уровнях: между операторами (разная техническая реализация и разный состав перечня), между регионами (решения принимаются на региональном уровне) и между узлами сети внутри одного города.
Практическое следствие: чужой опыт не предсказывает вашу ситуацию. Отзыв «у меня работает» относится к конкретному оператору, конкретному району и конкретному моменту времени. Проверять всегда нужно на своей сети.
Если вы по другую сторону
Эту статью читают и те, кто держит собственный VPN-сервис: для них тот же механизм означает, что их ноды перестают быть достижимы, пока их адреса не входят в перечни. Задача решается на уровне инфраструктуры — whitelisted-входом перед нодой. Этим занимается Clearway, и один из входов BRAID построен именно на нём.
Коротко
Решение о судьбе пакета принимается по адресу получателя, без анализа содержимого. Отсюда всё остальное: половинчатая работа приложений, бесполезность маскировки и смены протокола, странное поведение DNS и различия между операторами. И отсюда же — единственное работающее решение: вход через адрес, который в перечне разрешённых есть.