Обсуждение законности обратного прокси в домашней сети

Обсуждение возможных проблем с законностью при использовании обратного прокси в домашнем интернете и способы их решения

Контекст

Около 90 дней назад я столкнулся с проблемой невозможности подключения к IPv6 от провайдера China Telecom в провинции Хубэй. После длительного наблюдения и анализа, сейчас подвожу следующие итоги.

Анализ проблемы

Первоначально подозревались две возможные причины:

  1. Обнаружение использования PCDN

    • Хотя PCDN не использовался активно
    • Было лишь небольшое количество загрузок через BT
    • Был установлен лимит на скорость загрузки, но проблема сохранялась
  2. Домашний сервер в качестве источника блога

    • Правила обратного прокси через Cloudflare указывали порт
    • Возможно, оператор расценил это как “коммерческую деятельность”

После трех месяцев проверки, проблема, скорее всего, вызвана открытием портов HTTP/HTTPS для публичного доступа.

Конкретные проявления

  1. Аномальное состояние IPv6:

    • Можно получить префикс /56
    • Устройства могут получать глобальный IPv6-адрес
    • Но не могут получить доступ к внешней сети
    • Только маршрутизатор в режиме моста может нормально использовать IPv6
  2. Аномальное подключение Tailscale:

    • На сервере-источнике показывает прямое подключение, но аномальная задержка (около 400 мс)
    • Другие устройства подключаются через ретранслятор, но задержка ниже (около 80 мс)

Анализ политики оператора

В некоторых регионах операторы China Telecom принимают меры по снижению качества обслуживания для частых входящих HTTP/HTTPS-соединений:

  1. Снижение качества IPv6-сервиса

    • Нормальное распределение адресов
    • Отсутствующая таблица маршрутизации
    • Фактически, нет доступа к сети
  2. Ограничение P2P-соединений

    • Tailscale показывает прямое подключение
    • Фактически высокая задержка
    • Ограниченная пропускная способность

Решения

  1. Отключение сервиса обратного прокси:

    • Отключить обратный прокси Cloudflare/Alibaba Cloud ESA
    • После нескольких перезагрузок маршрутизатора можно восстановить нормальную работу
  2. Защита от сканирования доменов: Избегайте использования следующих распространенных поддоменов:

    - home.example.com
    - ddns.example.com
    - dev.example.com
    - test.example.com
    
  3. Лучшие практики:

    • Использовать GUID для генерации случайных поддоменов
    • Избегать использования регулярных или распространенных имен поддоменов
    • Регулярно менять домены для снижения риска сканирования