fix(proxy): LAN-режим отклонял настоящие адреса Telegram (#42) (#43)

@alexsagaidak: с компьютера прокси работает, с телефона — нет. Адрес машины
вписан верно, порт верный, брандмауэр выключен, порт добавлен в исключения.

Причина нашлась в проверке «это Telegram?». Она сравнивала два первых октета:

    (149, 154) => Some(...)
    (91, 108)  => Some(...)

То есть «телеграмом» считались целиком четыре /16 — десятки тысяч чужих
адресов, — а IPv6 не распознавался вообще ни один. Telegram владеет
149.154.160.0/20, шестью /22 в 91.108, 91.105.192.0/23, 185.76.151.0/24 и пятью
блоками IPv6.

Ошибка в обе стороны, и на loopback она не видна. Там allow_direct включён, и
неопознанный адрес всё равно релеится напрямую — соединение просто работает.
На сетевом слушателе allow_direct выключен, и тот же адрес получает SOCKS5
0x02. Отсюда ровно то, что описал репортёр: на компьютере работает, с телефона
нет. Заодно чужие адреса внутри этих /16 уходили в MTProto-туннель и умирали
там.

Список сетей теперь опубликованный самим Telegram
(core.telegram.org/resources/cidr.txt), проверка по маске префикса, IPv4 и
IPv6, с тестами на края блоков и на соседей за границей.

Отдельно разрешены имена веб-инфраструктуры: telegram.org, t.me, telegram.me,
telesco.pe, cdn-telegram.org. Это не MTProto, а обычный HTTPS — клиент ходит
туда за конфигурацией, превью и файлами CDN, и на телефоне эти запросы идут
через тот же прокси. Заворачивать их в туннель нельзя, поэтому они идут прямым
релеем. Совпадение по границе метки, так что telegram.org.example.com —
посторонний домен. В ограниченном режиме имя разрешается заранее и адреса
внутри локальной сети отбрасываются: назначение выбирает чужое устройство, и
DNS-ответ не должен открывать доступ к 192.168.х этой машины.

И главное для разбора следующего такого случая: отказ перестал быть
молчаливым. Появился счётчик «Отклонено» в диагностике и в строке статуса CLI,
отклонённый адрес один раз называется в журнале, и отдельно отмечается первое
подключение с каждого сетевого адреса. Без этого «с телефона не работает»
неразличимо распадалось на два случая: телефон не дошёл до машины — и дошёл,
но попросил адрес, который мы не пускаем. Теперь первый виден как ноль
соединений и ноль отказов, второй — как соединения есть, отказы растут.

Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>

ui/main.ts

@@ -11,6 +11,8 @@ type Status = {
   route: string;
   failures: number;
   routeFailures: number;
+  /// Отклонено политикой «в LAN-режиме только Telegram».
+  blocked: number;
   uptimeSeconds: number;
   port: number;
   /// Адрес для других устройств. Приходит только в LAN-режиме.
@@ -41,6 +43,7 @@ let status: Status = {
   route: "Маршрут ещё не выбран",
   failures: 0,
   routeFailures: 0,
+  blocked: 0,
   uptimeSeconds: 0,
   port: 1080,
   shareAddress: null,
@@ -283,6 +286,10 @@ function renderDiagnostics(): void {
           <span>Падений маршрутов</span>
           <strong>${status.routeFailures}</strong>
         </article>
+        <article class="metric-card">
+          <span>Отклонено</span>
+          <strong>${status.blocked}</strong>
+        </article>
       </div>
 
       <p class="field-hint">
@@ -291,6 +298,13 @@ function renderDiagnostics(): void {
         Число в багрепорте помогает понять, что именно перебиралось.
       </p>
 
+      <p class="field-hint">
+        «Отклонено» — запросы, которые LAN-режим не пропустил: он ходит только
+        по адресам Telegram. Если с телефона ничего не работает, а здесь ноль и
+        соединений тоже ноль, значит телефон до этого компьютера не дошёл —
+        дело в сети или брандмауэре. Какие именно адреса отклонены, видно ниже.
+      </p>
+
       <div class="log-panel">
         <div class="log-heading">
           <span>Последние события</span>