Hypervisor i hemmalabbet oåtkomlig via VPN: var du ska titta

Tunneln kommer upp, hypervisorns webbsida får tidsgräns och klienten säger att den är ansluten. Den kombinationen utesluter förvånansvärt mycket: VPN-handskakningen fungerar, klienten har en adress och slutpunkten är nåbar. Det som återstår är en kort lista med routing- och policyfrågor, och de har en naturlig ordning. Arbeta igenom dem från hypervisorn och utåt i stället för från klienten och inåt, eftersom hypervisorns eget tillstånd är det billigaste att bekräfta.

Börja med hanteringssegmentet

Bekräfta hypervisorns hanteringsadress och tjänsten som lyssnar på den, och bekräfta att sidan laddas från en annan värd i det segmentet innan du diagnostiserar något på distans. Ett lokalt test som misslyckas är inte ett VPN-problem, och det är en femminuterskontroll som sparar en timme.

Sedan de två vägarna. VPN-klienten behöver en rutt till hanteringsnätet, vilket oftast betyder att klientens AllowedIPs eller pushade rutter omfattar det subnätet. Hypervisorn, eller dess standardgateway, behöver en returväg till klientadresspoolen, om inte designen medvetet översätter källan vid ingången. Det är två separata fakta och saknas någon av dem blir tidsgränsen densamma. Kontrollera dem separat: ip route get 192.168.10.20 på klienten, och en avlyssning på hypervisorvärden som visar om paketet ens kom fram.

Tillåt den faktiska fjärradministratören

Auktorisering är en annan fråga än nåbarhet. Använd gateway- och värdpolicy begränsad till de källor och tjänster som behöver administratörsåtkomst. Ett gäst-VPN-konto som behöver en labbapplikation bör inte därigenom nå kontrollplanet, och en platt regel som släpper in hela tunnelsubnätet är hur det händer.

Håll hypervisorns egen autentisering och certifikatkontroller påslagna. En privat rutt är ingen anledning att klicka igenom en oväntad identitetsvarning.

Varningen är värd att behandla som ett fynd och inte som ett hinder. Om certifikatet inte matchar namnet du använde är antingen namnet fel eller så är tjänsten inte den du tror, och båda svaren väger tyngre i ett hanteringsgränssnitt än någon annanstans. Nå sidan under det namn certifikatet utfärdades för, och låt DNS peka det namnet mot tunneladressen. Ett privat namn som löses inkonsekvent mellan LAN och tunnel är en vanlig orsak till certifikatklagomål som ser ut som VPN-fel.

Kontrollera sekundära anslutningar

Vissa funktioner använder anslutningar som webbsidan inte använder. En konsolsession, en ISO-uppladdning, en VNC- eller SPICE-proxy och en migreringskanal kan var och en använda en annan port eller en annan värdadress. När sidan laddas och en funktion misslyckas, läs produktens krav i stället för att öppna varje port på värden.

Att öppna allt är hur ett hanteringsgränssnitt blir ett ohanterat sådant. Varje extra port är en lyssnare till som måste hållas uppdaterad, och en hypervisor exponerar redan tillräckligt många. Identifiera den specifika anslutning som funktionen behöver, bekräfta att den är nåbar genom tunneln och låt resten vara stängd. Om funktionen insisterar på en direkt anslutning till en värdadress som inte kan routas genom din tunnel är det en designbegränsning som måste kringgås medvetet, inte en anledning att vidarebefordra ett intervall.

Behåll en väg tillbaka innan du rör nätverket

Innan du ändrar det virtuella nätverk som bär din egen VPN, bekräfta att du har en lokal eller oberoende väg tillbaka.

Detta spelar störst roll i ett hemmalabb, eftersom VPN-slutpunkten ofta är en virtuell maskin på just den hypervisor du försöker nå. Att ändra en virtuell switch, en brygga eller en brandväggsregel på distans kan ta bort den väg du använder, och sessionen kan överleva tillräckligt länge för att se det hända.

Testa utifrån labbet i stället för från LAN, och verifiera avvisningarna lika väl som tillstånden. Ett nätverk som ska förbli onåbart från tunneln ska fortsätta vara det efter din ändring, och det är ett separat påstående från att hanteringssidan laddas. Skriv ned båda resultaten, eftersom det andra är det som hoppas över och det som spelar roll när labbet växer.

Posten som ska bevaras är kort: hanteringsadressen och -tjänsten, rutten varje sida behöver, identiteterna som får nå den och återställningsvägen. Det räcker för att nästa person ska kunna återskapa det fungerande tillståndet utan att härleda det igen.

Om sidan fortfarande får tidsgräns efter allt detta, fånga trafik på hypervisorn och leta efter paketet innan du ändrar ännu en regel. Ett paket som aldrig anländer är en routing- eller brandväggsfråga; ett paket som anländer och avvisas är en tjänste- eller policyfråga; ett paket som anländer och besvaras medan klienten väntar är en returvägsfråga. strongSwan-dokumentationen om vidarebefordran beskriver hur en Linux-gateway vidarebefordrar tunneltrafik till en intern värd. Tre avlyssningar slår en gissning till.