Гипервизор домашней лаборатории недоступен через VPN: куда смотреть

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

Начните с сегмента управления

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

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

Разрешите настоящего удалённого администратора

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

Оставьте включёнными собственную аутентификацию гипервизора и проверки сертификатов. Частный маршрут — не повод проходить через неожиданное предупреждение об идентичности.

Предупреждение стоит рассматривать как находку, а не как препятствие. Если сертификат не совпадает с использованным именем, либо имя неверно, либо служба не та, о которой вы думаете, и оба ответа важнее на интерфейсе управления, чем где-либо ещё. Дойдите до страницы по имени, для которого выдан сертификат, и позвольте DNS указывать это имя на адрес туннеля. Частное имя, которое между LAN и туннелем разрешается несогласованно, — частая причина жалоб на сертификаты, похожих на сбои VPN.

Проверьте вторичные соединения

Некоторые функции используют соединения, которых нет у веб-страницы. Сеанс консоли, загрузка ISO, прокси VNC или SPICE и канал миграции могут каждый использовать другой порт или другой адрес хоста. Когда страница загружается, а одна функция не работает, читайте требование этого продукта, а не открывайте каждый порт на хосте.

Открыть всё — это путь, которым интерфейс управления становится неуправляемым. Каждый дополнительный порт — ещё один слушатель, который нужно патчить, а гипервизор и так открывает их достаточно. Определите конкретное соединение, нужное функции, подтвердите, что оно достижимо через туннель, и оставьте остальное закрытым. Если функция настаивает на прямом соединении с адресом хоста, который не маршрутизируется через ваш туннель, это ограничение дизайна, которое нужно обходить намеренно, а не повод пересылать диапазон.

Сохраните путь назад, прежде чем трогать сеть

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

Это важнее всего в домашней лаборатории, потому что конечная точка VPN часто является виртуальной машиной на том самом гипервизоре, до которого вы пытаетесь добраться. Изменение виртуального коммутатора, моста или правила брандмауэра удалённо может убрать путь, которым вы пользуетесь, и сеанс может прожить достаточно долго, чтобы это увидеть.

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

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

Если страница всё ещё уходит в тайм-аут после всего этого, сделайте захват на гипервизоре и поищите пакет, прежде чем менять ещё одно правило. Пакет, который никогда не приходит, — вопрос маршрутизации или брандмауэра; пакет, который приходит и отклоняется, — вопрос службы или политики; пакет, который приходит и получает ответ, пока клиент ждёт, — вопрос обратного пути. Документация strongSwan о пересылке описывает, как шлюз Linux пересылает трафик туннеля внутреннему хосту. Три захвата лучше ещё одного предположения.