Картина отказа: туннель поднят, счётчик пуст
В трекере Happ есть открытая заявка, описывающая Windows 11 и клиент версии 4.2.1. Она до сих пор без ответа разработчиков, и картина в ней настолько узнаваемая, что её стоит разобрать целиком.
Соединение устанавливается. Клиент показывает подключённое состояние, ошибок не выдаёт, сервер отвечает. При этом ни один сайт не открывается, счётчик переданных данных стоит на нуле. Если на той же машине переключиться в режим прокси и направить туда браузер, всё работает мгновенно. То есть сервер жив, ключ действителен, сеть в порядке, а трафик через туннель не идёт.
В журнале при этом появляется строка о неудачной попытке установить соединение с кодом ошибки, равным нулю. Нулевой код означает, что внятной причины отказа система назвать не смогла.
Маршрут до сервера уходит в сам туннель
В заявке разобрано, что происходит внутри. Процесс ядра не держит ни одного внешнего соединения. Не «мало», а ровно ноль: наружу он не ходит вообще.
Причина в таблице маршрутов. Когда включается режим TUN, система получает новый сетевой интерфейс и правило, по которому весь трафик идёт в него. Само по себе это и есть смысл режима. Но у клиента остаётся одно исключение, без которого схема не работает: маршрут до адреса VPN-сервера обязан идти мимо туннеля, напрямую через обычное подключение.
В описанном случае это исключение не срабатывает. Маршрут до сервера попадает под общее правило и уходит внутрь туннеля, который ещё не установлен. Получается замкнутый круг: чтобы туннель заработал, нужно достучаться до сервера, а путь до сервера ведёт в этот же туннель. Туда же попадает и разрешение доменных имён, о чём подробнее в материале про DNS внутри туннеля.
Почему перебор четырёх провайдеров не помогает
Первое, что делает человек в такой ситуации, это перебирает провайдеров туннеля. Их в Happ четыре, они устроены по-разному, и логика «попробую другой» выглядит разумной. Чем они отличаются, разобрано в материале про четыре провайдера TUN.
В заявке перебрали все четыре. Результат одинаковый на каждом.
Это и есть самое полезное наблюдение из всей истории. Провайдеры отличаются тем, как они поднимают туннель, но таблицу маршрутов системы все они используют общую. Если проблема в маршруте, а не в способе поднять интерфейс, смена провайдера не меняет ничего. Перебор в этом случае просто отнимает время.
Что известно и что пока не решено
Честный итог: рабочего решения у этого случая нет. Заявка открыта, разработчики на неё не ответили, обходного пути в документации не описано.
Что можно сделать реально. Убедиться, что это именно ваш случай: прокси на той же машине работает, счётчик туннеля стоит на нуле, перебор провайдеров ничего не меняет. Если хоть один пункт не сходится, у вас другая история, и её стоит искать в разборе ошибок подключения.
Пока случай не решён, режим прокси остаётся рабочим вариантом на этой машине. Он не покрывает весь трафик системы, но браузер и программы, которым можно указать адрес прокси, через него работают. Как это настроить, описано в материале про прокси в Happ.
Если туннель не поднялся, а прокси работает, восстановление фоновой службы этот случай не лечит: маршрут остаётся прежним.