Два клиента работают одновременно, каждый уверен, что владеет маршрутом по умолчанию, и симптом проявляется как нечто странное: одно приложение гостя работает, другое разрешается не туда. VPN внутри гостя и VPN на хосте могут сосуществовать, но только когда внешний путь и внутренняя политика согласны в том, кто что несёт. Запуск обоих сам по себе не создаёт цепочку. Сначала запишите подключение, затем меняйте по одной вещи за раз.

Сначала запишите подключение гостя

Гость достигает своего VPN-сервера тем путём, который дал ему гипервизор: NAT за хостом, мост в физический сегмент или сеть только для хоста с добавленной сверху маршрутизацией. Каждое подключение меняет то, что гость видит и что хост может сделать с его трафиком. Под NAT пакеты гостя выглядят приходящими от хоста, поэтому собственный туннель хоста может нести их так, что гость об этом ничего не знает. Под мостом у гостя есть собственное присутствие в сегменте и собственный шлюз по умолчанию.

Запишите подключение, прежде чем трогать любую конфигурацию, вместе с тем, какой клиент должен нести какое приложение. Эта фраза решает большинство таких случаев, потому что два клиента обычно построены на разных допущениях. Гость, от которого ожидается использование туннеля хоста, не должен иметь и собственного конкурирующего маршрута по умолчанию.

Проследите конечную точку гостя наружу

VPN гостя нужен пригодный путь к своему серверу, прежде чем что-либо ещё заработает. Когда туннель хоста поднят, а гость находится за NAT, рукопожатие гостя выходит через туннель хоста, что является либо замыслом, либо аварией, которую никто не задокументировал. Когда туннель хоста падает, а гость зависел от него, гость теряет связность без единого изменения на своей стороне. Прослеживание конечной точки наружу показывает, какой из этих двух случаев у вас на самом деле.

Широкий маршрут в любом из контекстов захватывает трафик, которого ожидал другой клиент. Маршрут 0.0.0.0/0 внутри гостя и клиент хоста с полным туннелем оба претендуют на всё, и побеждает тот, что применяется последним. Пересечения между виртуальными сетями гостя, локальной LAN и удалёнными сетями дают тот же эффект для частных префиксов, а сбои напоминают проблемы аутентификации; поведение трансляции адресов то же, что описано для сетей контейнеров.

Сравните запись до и после

Снимите базовую линию с выключенным туннелем хоста или в любом контролируемом состоянии, которое допускает ваша политика, и запишите маршрут и резолвер гостя. Затем примените объединённую конфигурацию и сравните две записи, сохранив требования приватности. Если прямая базовая линия неприемлема, запишите это ограничение в запись вместо того, чтобы пропустить сравнение.

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

Запрос маршрута называет интерфейс и адрес источника, которые понесли бы конкретное назначение, и это самая полезная строка в этом расследовании. Список правил показывает, отправляет ли маршрутизация по политике некоторые назначения через вторую таблицу. Вывод резолвера показывает, последовал ли DNS за туннелем гостя или остался на пути хоста. Выполните те же три команды до и после изменения, и разница назовёт виновника.

Держите владение ясным между перезапусками

Ограничение локального доступа клиента хоста может блокировать трафик к виртуальному NAT или мосту, и это ограничение регулярно путают с проблемой учётных данных гостя. Читайте документированное поведение клиента, а не отключайте ограничение, чтобы тест прошёл. После поддерживаемого исправления повторите проверку приложения гостя и требуемой вами политики отказа. Хост, который успешно переподключается, ничего не доказывает о маршруте или резолвере гостя.

Решите, какая сторона владеет маршрутом по умолчанию, и запишите это в руководство по эксплуатации. Перезапуск гостя или смена сети на хосте, которая тихо переворачивает владение, порождает отчёт об ошибке про VPN, который никогда не был виноват. Устройство должно пережить перезагрузку так, чтобы никто не помнил, почему оно работало.

Похожие статьи