Хипервизор в домашната лаборатория е недостъпен през VPN: къде да търсим

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

Започнете със сегмента за управление

Потвърдете адреса за управление на хипервизора и услугата, която слуша на него, и потвърдете, че страницата се зарежда от друг хост в този сегмент, преди да диагностицирате нещо отдалечено. Локален тест, който се проваля, не е VPN проблем и е петминутна проверка, която спестява час.

После двата пътя. VPN клиентът се нуждае от маршрут до мрежата за управление, което обикновено означава, че AllowedIPs на клиента или изпратените маршрути включват тази подмрежа. Хипервизорът или шлюзът му по подразбиране се нуждае от обратен път до пула с адреси на клиентите, освен ако дизайнът умишлено не транслатира източника при влизане. Това са два отделни факта и липсата на всеки един дава същото изтичане по време. Проверете ги поотделно: ip route get 192.168.10.20 на клиента и прихващане на хоста на хипервизора, което показва дали пакетът изобщо е пристигнал.

Разрешете действителния отдалечен администратор

Оторизацията е отделен въпрос от достъпността. Използвайте политика на шлюза и хоста, ограничена до източниците и услугите, които се нуждаят от достъп за управление. Гост VPN акаунт, на който е нужно едно лабораторно приложение, не бива чрез това да достига до равнината за управление, а плоско правило, което допуска цялата тунелна подмрежа, е начинът, по който това се случва.

Пазете включени собствената автентикация на хипервизора и проверките на сертификата. Частният маршрут не е причина да кликнете през неочаквано предупреждение за самоличност.

Предупреждението заслужава да се третира като находка, а не като пречка. Ако сертификатът не съвпада с името, което сте използвали, или името е грешно, или услугата не е тази, за която мислите, и двата отговора имат по-голямо значение на интерфейс за управление, отколкото навсякъде другаде. Достигнете страницата по името, за което е издаден сертификатът, и оставете DNS да насочи това име към тунелния адрес. Частно име, което се резолвва непоследователно между LAN и тунела, е честа причина за оплаквания от сертификати, които изглеждат като VPN повреди.

Проверете вторичните връзки

Някои функции използват връзки, които уеб страницата не използва. Конзолна сесия, качване на ISO, VNC или SPICE прокси и канал за миграция могат да използват различен порт или различен адрес на хост. Когато страницата се зарежда и една функция се проваля, прочетете изискването на този продукт, вместо да отваряте всеки порт на хоста.

Отварянето на всичко е начинът, по който интерфейсът за управление става неуправляван. Всеки допълнителен порт е още един слушател, който трябва да се поддържа обновен, а хипервизорът и без това показва достатъчно от тях. Определете конкретната връзка, от която функцията се нуждае, потвърдете, че е достъпна през тунела, и оставете останалите затворени. Ако функцията настоява за директна връзка към адрес на хост, който не е маршрутизируем през вашия тунел, това е ограничение на дизайна, което да се заобиколи умишлено, а не причина да препращате диапазон.

Пазете път назад, преди да пипате мрежата

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

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

Тествайте отвън лабораторията, а не от LAN, и проверявайте отказите, както и разрешенията. Мрежа, която трябва да остане недостъпна от тунела, трябва да остане недостъпна и след промяната ви, и това е отделно твърдение от зареждането на страницата за управление. Запишете и двата резултата, защото вторият е този, който се пропуска и който има значение, когато лабораторията расте.

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

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