Hiperwizor w domowym laboratorium nieosiągalny przez VPN: gdzie zajrzeć

Tunel się podnosi, strona internetowa hiperwizora kończy się przekroczeniem czasu, a klient twierdzi, że jest połączony. Ta kombinacja wyklucza zaskakująco wiele: uzgadnianie VPN działa, klient ma adres, a punkt końcowy jest osiągalny. Zostaje krótka lista pytań o routing i politykę, a one mają naturalną kolejność. Przechodź je od hiperwizora na zewnątrz, a nie od klienta do środka, bo własny stan hiperwizora najtaniej potwierdzić.

Zacznij od segmentu zarządzania

Potwierdź adres zarządzania hiperwizora i usługę, która na nim nasłuchuje, oraz to, że strona ładuje się z innego hosta w tym segmencie, zanim zaczniesz cokolwiek diagnozować zdalnie. Nieudany test lokalny nie jest problemem VPN i jest pięciominutową kontrolą, która oszczędza godzinę.

Potem dwie ścieżki. Klient VPN potrzebuje trasy do sieci zarządzania, co zwykle oznacza, że AllowedIPs klienta lub wypchnięte trasy obejmują tę podsieć. Hiperwizor lub jego brama domyślna potrzebuje drogi powrotnej do puli adresów klientów, chyba że projekt celowo tłumaczy źródło na wejściu. To dwa odrębne fakty i brak któregokolwiek daje ten sam limit czasu. Sprawdź je osobno: ip route get 192.168.10.20 na kliencie i przechwycenie na hoście hiperwizora pokazujące, czy pakiet w ogóle dotarł.

Zezwól rzeczywistemu administratorowi zdalnemu

Autoryzacja to osobne pytanie od osiągalności. Używaj polityki bramy i hosta ograniczonej do źródeł i usług, które potrzebują dostępu administracyjnego. Konto gościa VPN, któremu potrzebna jest jedna aplikacja laboratoryjna, nie powinno przez to docierać do płaszczyzny zarządzania, a płaska reguła wpuszczająca całą podsieć tunelu jest sposobem, w jaki to się dzieje.

Zostaw włączone uwierzytelnianie samego hiperwizora i kontrole certyfikatów. Prywatna trasa nie jest powodem, by klikać przez nieoczekiwane ostrzeżenie o tożsamości.

Ostrzeżenie warto potraktować jako ustalenie, a nie przeszkodę. Jeśli certyfikat nie pasuje do użytej nazwy, albo nazwa jest błędna, albo usługa nie jest tą, którą myślisz, i obie odpowiedzi znaczą więcej w interfejsie zarządzania niż gdziekolwiek indziej. Dotrzyj do strony pod nazwą, dla której wydano certyfikat, i pozwól DNS wskazać tę nazwę na adres tunelu. Prywatna nazwa, która rozwiązuje się niespójnie między LAN a tunelem to częsta przyczyna skarg na certyfikaty wyglądających jak awarie VPN.

Sprawdź połączenia wtórne

Niektóre funkcje używają połączeń, których strona nie używa. Sesja konsoli, wysyłanie ISO, proxy VNC lub SPICE i kanał migracji mogą każde używać innego portu lub innego adresu hosta. Gdy strona się ładuje, a jedna funkcja zawodzi, przeczytaj wymaganie tego produktu zamiast otwierać każdy port na hoście.

Otwarcie wszystkiego to sposób, w jaki interfejs zarządzania staje się niezarządzany. Każdy dodatkowy port to kolejny nasłuch, który trzeba łatać, a hiperwizor i tak wystawia ich dość. Zidentyfikuj konkretne połączenie potrzebne funkcji, potwierdź, że jest osiągalne przez tunel, a resztę zostaw zamkniętą. Jeśli funkcja upiera się przy bezpośrednim połączeniu z adresem hosta, którego nie da się routować przez twój tunel, to ograniczenie projektu, które trzeba świadomie obejść, a nie powód do przekazywania zakresu.

Zachowaj drogę powrotną, zanim dotkniesz sieci

Zanim zmienisz sieć wirtualną, która przenosi twoją własną VPN, potwierdź, że masz lokalną lub niezależną drogę powrotną.

To ma największe znaczenie w domowym laboratorium, bo punkt końcowy VPN jest często maszyną wirtualną na tym samym hiperwizorze, do którego próbujesz dotrzeć. Zmiana przełącznika wirtualnego, mostka lub reguły firewalla zdalnie może usunąć ścieżkę, której używasz, a sesja może przetrwać dość długo, by to zobaczyć.

Testuj z zewnątrz laboratorium, a nie z LAN, i weryfikuj odmowy tak samo jak zezwolenia. Sieć, która ma pozostać nieosiągalna z tunelu, powinna pozostać taka po twojej zmianie, i to jest osobne twierdzenie od ładowania strony zarządzania. Zapisz oba wyniki, bo drugi jest tym, który się pomija, i tym, który ma znaczenie, gdy laboratorium rośnie.

Zapis, który warto zachować, jest krótki: adres i usługa zarządzania, trasa potrzebna każdej stronie, tożsamości dopuszczone do dotarcia i ścieżka odzyskiwania. To wystarcza, by następna osoba odtworzyła działający stan bez wyprowadzania go ponownie.

Jeśli strona nadal kończy się przekroczeniem czasu po tym wszystkim, przechwyć ruch na hiperwizorze i poszukaj pakietu, zanim zmienisz kolejną regułę. Pakiet, który nigdy nie dociera, to pytanie o routing lub firewalla; pakiet, który dociera i jest odrzucany, to pytanie o usługę lub politykę; pakiet, który dociera i otrzymuje odpowiedź, gdy klient czeka, to pytanie o drogę powrotną. Dokumentacja strongSwan dotycząca przekazywania opisuje, jak brama Linux przekazuje ruch tunelu do hosta wewnętrznego. Trzy przechwycenia biją jeszcze jedno przypuszczenie.