Устранение сетевых проблем WSL + VPN/TUN

Устранение сетевых проблем WSL + VPN/TUN

Tags: Google Antigravity, WSL 2, VPN, TUN, MTU, sing-tun

Google Antigravity — это агентная платформа разработки, реализующая парадигму Agent-First IDE. Архитектура платформы предполагает высокую степень связности между локальными агентами исполнения (в среде WSL) и облачными сервисами оркестрации. При использовании L3-туннелей (sing-tun, Hiddify) и виртуализации WSL возникают специфические проблемы инкапсуляции и маршрутизации трафика.

Вы спросите: "При чём тут Google Antigravity?"
Отвечу: "Потому что при использовании его с территории РФ, можно поймать проблемы с сетевым подключением."

Данное руководство описывает методологию локализации и устранения сетевых сбоев на основе анализа дампов и конфигураций интерфейсов.

1. Сбор и анализ первичных диагностических данных

Для идентификации сетевых проблем следует использовать встроенный инструмент сбора логов. В палитре команд IDE выполните:
Antigravity: Download Antigravity Diagnostics

Важное примечание: Процесс сбора данных и формирования отчета может занимать значительное время (до нескольких минут). По завершении операции IDE инициирует системный диалог сохранения файла (Save As) с предложенным по умолчанию именем Antigravity-diagnostics.txt.

Критические индикаторы в файле Antigravity-diagnostics.txt:

  • TLS handshake timeout: Ошибка на этапе согласования параметров шифрования. Указывает на потерю пакетов данных (Certificate) из-за проблем с фрагментацией.
  • Connection reset by peer (ECONNRESET): Принудительный разрыв TCP-сессии промежуточным узлом или сетевым экраном хоста.
  • Model not found (HTTP 404/500 для ресурсов 1008/1018): Невозможность загрузки конфигурационных манифестов мультимодальных моделей вследствие блокировки эндпоинтов antigravity-unleash.goog.
  • Timed out while waiting for response: Превышение лимита времени ожидания ответа от gRPC-интерфейсов облачного бэкенда.

2. Верификация сетевой связности в среде WSL

Поскольку управляющие процессы (Language Server, PID 700) функционируют внутри WSL, диагностику необходимо проводить в контексте данной подсистемы.

Тестирование TLS-рукопожатия

Эмуляция запроса регистрации агента с расширенным выводом:

curl -k -v https://antigravity-unleash.goog/api/client/register

Интерпретация: Остановка процесса после получения Server hello (2) свидетельствует о невозможности приема пакетов, размер которых превышает текущий Path MTU.

Аудит параметров MTU (Maximum Transmission Unit)

Расхождение размеров MTU на виртуальных и физических интерфейсах — наиболее вероятная причина потерь данных при инкапсуляции.

Хост (Windows PowerShell):
netsh interface ipv4 show subinterfaces

Пример вывода с аномалией (Jumbo Frames на туннеле):

       MTU  MediaSenseState      Получено байт     Отправлено байт  Интерфейс
----------  ---------------  ------------  ------------  -------------
      9000                1      25519176      20676185  tun0
      1500                1    1052027165     317349294  Ethernet 3

Особое внимание: наличие MTU 9000 на виртуальных адаптерах TUN при физическом лимите 1500.

Гостевая система (WSL Bash):
ip addr | grep mtu

Пример вывода:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
8: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000

3. Регламент устранения неисправностей

Этап 1: Нормализация MTU в WSL

Для предотвращения отбрасывания пакетов в VPN-туннеле необходимо принудительно ограничить MTU интерфейса WSL до безопасного значения, учитывающего оверхед туннельных протоколов.

# Установка лимита в 1400 байт для интерфейса eth3 (или соответствующего дефолтного)
sudo ip link set dev eth3 mtu 1400

Этап 2: Конфигурация маршрутизации и метрик

В WSL 2 часто возникает ситуация «конфликта маршрутов по умолчанию» (default gateway race), когда трафик хаотично распределяется между физическим интерфейсом (eth0) и виртуальным интерфейсом туннеля (eth3). Для обеспечения стабильной работы агентов необходимо явно приоритезировать туннельный маршрут.

Технические манипуляции с таблицей маршрутизации:

  1. Удаление неопределенного маршрута: Часто туннели создают маршрут без явной метрики, что делает поведение сетевого стека непредсказуемым.

    bash sudo ip route del default dev eth3

  2. Добавление приоритетного маршрута: Установка параметра metric позволяет жестко задать приоритет. Чем ниже значение метрики, тем выше приоритет маршрута.

    bash sudo ip route add default dev eth3 metric 10

    Примечание: Если физический шлюз имеет метрику 25 или выше, установка значения 10 гарантирует, что gRPC-трафик Antigravity пойдет через VPN.
    3. Верификация итоговой таблицы:
    Команда ip route должна показывать туннельный интерфейс как основной (default) с наименьшим значением метрики.

Этап 3: Оптимизация сетевого режима WSL

В ряде случаев для прозрачного взаимодействия с системными прокси Windows рекомендуется переключение в режим зеркалирования интерфейсов в файле %USERPROFILE%\.wslconfig:

[wsl2]
networkingMode=mirrored
dnsTunneling=true

Важно: При возникновении ошибки инициализации экземпляра (0x8007054f), указывающей на конфликт драйверов TUN, следует вернуться к режиму NAT.

4. Особенности интерпретации результатов

В конфигурациях с использованием проксирования на базе sing-box (Hiddify) следует учитывать:

  1. ICMP Filtering: Команды tracepath или mtr могут возвращать no reply из-за фильтрации ICMP-трафика туннелем. Это не является признаком отсутствия связи для TCP/gRPC трафика Antigravity.
  2. DNS Hijacking: Рекомендуется проверка /etc/resolv.conf на предмет использования внутреннего DNS-резолвера туннеля (например, 172.19.0.2).

Заключение

Стабильность платформы Google Antigravity напрямую коррелирует с целостностью канала передачи данных. Приведение сетевой топологии к единому MTU и обеспечение приоритетности маршрутов позволяют агентам беспрепятственно синхронизировать контекст разработки с облачными вычислительными ресурсами.