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

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

Почніть із сегмента керування

Підтвердьте адресу керування гіпервізора та службу, що слухає на ній, а також те, що сторінка завантажується з іншого хоста в цьому сегменті, перш ніж щось діагностувати віддалено. Невдалий локальний тест не є проблемою VPN, і це п'ятихвилинна перевірка, що економить годину.

Далі два шляхи. Клієнту VPN потрібен маршрут до мережі керування, що зазвичай означає, що AllowedIPs клієнта або просунуті маршрути включають цю підмережу. Гіпервізору або його шлюзу за замовчуванням потрібен зворотний шлях до пулу адрес клієнтів, якщо тільки дизайн навмисно не транслює джерело на вході. Це два окремі факти, і відсутність будь-якого з них дає той самий тайм-аут. Перевірте їх окремо: ip route get 192.168.10.20 на клієнті та захоплення на хості гіпервізора, яке показує, чи пакет узагалі прибув.

Дозвольте справжнього віддаленого адміністратора

Авторизація — окреме питання від доступності. Використовуйте політику шлюзу й хоста, обмежену джерелами та службами, яким потрібен доступ до керування. Гостьовий обліковий запис VPN, якому потрібен один лабораторний застосунок, не повинен через це потрапляти на площину керування, а пласке правило, що пропускає всю підмережу тунелю, — це те, як так виходить.

Залиште ввімкненими власну автентифікацію гіпервізора та перевірки сертифікатів. Приватний маршрут не є приводом проходити крізь неочікуване попередження про ідентичність.

Попередження варто сприймати як знахідку, а не як перешкоду. Якщо сертифікат не збігається з використаним ім'ям, або ім'я хибне, або служба не та, про яку ви думаєте, і обидві відповіді важливіші на інтерфейсі керування, ніж будь-де інде. Дійдіть до сторінки за іменем, для якого видано сертифікат, і дозвольте DNS указувати це ім'я на адресу тунелю. Приватне ім'я, яке між LAN і тунелем розв'язується неузгоджено, — часта причина скарг на сертифікати, схожих на збої VPN.

Перевірте вторинні з'єднання

Деякі функції використовують з'єднання, яких немає у вебсторінки. Сеанс консолі, завантаження ISO, проксі VNC або SPICE і канал міграції можуть кожен використовувати інший порт або іншу адресу хоста. Коли сторінка завантажується, а одна функція не працює, читайте вимогу цього продукту, а не відкривайте кожен порт на хості.

Відкрити все — це шлях, яким інтерфейс керування стає некерованим. Кожен додатковий порт — ще один слухач, який треба патчити, а гіпервізор і так відкриває їх достатньо. Визначте конкретне з'єднання, потрібне функції, підтвердьте, що воно доступне через тунель, і залиште решту закритою. Якщо функція наполягає на прямому з'єднанні з адресою хоста, яка не маршрутизується через ваш тунель, це обмеження дизайну, яке треба обходити навмисно, а не привід пересилати діапазон.

Збережіть шлях назад, перш ніж торкатися мережі

Перш ніж змінювати віртуальну мережу, що несе ваш власний VPN, підтвердьте, що у вас є локальний або незалежний шлях назад.

Це найважливіше в домашній лабораторії, бо кінцева точка VPN часто є віртуальною машиною на тому самому гіпервізорі, до якого ви намагаєтеся дістатися. Зміна віртуального комутатора, мосту або правила брандмауера віддалено може прибрати шлях, яким ви користуєтеся, і сеанс може прожити достатньо довго, щоб це побачити.

Перевіряйте ззовні лабораторії, а не з LAN, і перевіряйте відмови так само, як дозволи. Мережа, яка має залишатися недосяжною з тунелю, має залишатися такою і після вашої зміни, і це окреме твердження від завантаження сторінки керування. Запишіть обидва результати, бо другий якраз пропускають, і саме він важливий, коли лабораторія зростає.

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

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