A home lab hypervisor nem érhető el VPN-en: hol keresse

Az alagút feláll, a hypervisor weboldala időtúllépésbe fut, és az ügyfél azt mondja, hogy csatlakozott. Ez a kombináció meglepően sokat kizár: a VPN-kézfogás működik, az ügyfélnek van címe, és a végpont elérhető. Ami marad, az az útválasztási és házirend-kérdések rövid listája, és ezeknek természetes sorrendjük van. Kívülről befelé haladjon a hypervisortól, ne az ügyféltől, mert a hypervisor saját állapotát a legolcsóbb megerősíteni.

Kezdje a felügyeleti szegmenssel

Erősítse meg a hypervisor felügyeleti címét és a rajta figyelő szolgáltatást, és még a távoli diagnózis előtt erősítse meg, hogy az oldal betöltődik ugyanazon szegmens egy másik gazdagépéről. A helyben elbukó teszt nem VPN-probléma, és ez egy ötperces ellenőrzés, amely egy órát spórol.

Aztán a két útvonal. A VPN-ügyfélnek útvonalra van szüksége a felügyeleti hálózat felé, ami általában azt jelenti, hogy az ügyfél AllowedIPs vagy a tolt útvonalak tartalmazzák azt az alhálózatot. A hypervisornak vagy az alapértelmezett átjárójának visszaútra van szüksége az ügyfélcím-készlethez, kivéve ha a tervezés szándékosan lefordítja a forrást a belépésnél. Ez két külön tény, és bármelyik hiánya ugyanazt az időtúllépést eredményezi. Ellenőrizze őket külön: ip route get 192.168.10.20 az ügyfélen, és egy rögzítés a hypervisor gazdagépén, amely megmutatja, hogy a csomag egyáltalán megérkezett-e.

Engedje a tényleges távoli rendszergazdát

Az engedélyezés külön kérdés az elérhetőségtől. Átjáró- és gazdagép-házirendet használjon, amely csak azokra a forrásokra és szolgáltatásokra korlátozódik, amelyeknek felügyeleti hozzáférés kell. Az egyetlen laboralkalmazást igénylő vendég VPN-fiók nem juthat el ezen keresztül a felügyeleti síkhoz, és a lapos szabály, amely a teljes alagút-alhálózatot beengedi, az az út, amelyen ez megtörténik.

Tartsa bekapcsolva a hypervisor saját hitelesítését és a tanúsítvány-ellenőrzéseket. A magánútvonal nem ok arra, hogy átkattintson egy váratlan identitásfigyelmeztetésen.

Érdemes a figyelmeztetést leletként kezelni, nem akadályként. Ha a tanúsítvány nem egyezik a használt névvel, vagy a név rossz, vagy a szolgáltatás nem az, amire gondol, és mindkét válasz többet számít egy felügyeleti felületen, mint bárhol máshol. Érje el az oldalt azon a néven, amelyre a tanúsítványt kiállították, és hagyja, hogy a DNS ezt a nevet az alagút címére irányítsa. A LAN és az alagút között következetlenül feloldódó magánnév gyakori oka a VPN-hibáknak látszó tanúsítványpanaszoknak.

Ellenőrizze a másodlagos kapcsolatokat

Egyes funkciók olyan kapcsolatokat használnak, amelyeket a weboldal nem. Egy konzolmunkamenet, egy ISO-feltöltés, egy VNC- vagy SPICE-proxy és egy migrációs csatorna külön portot vagy külön gazdagép-címet használhat. Ha az oldal betöltődik és egy funkció meghibásodik, olvassa el az adott termék követelményét, ahelyett hogy minden portot megnyitna a gazdagépen.

Minden megnyitása az az út, amelyen egy felügyeleti felület felügyeletlenné válik. Minden további port egy újabb figyelő, amelyet foltozva kell tartani, és a hypervisor már így is eleget tesz közzé. Azonosítsa azt a konkrét kapcsolatot, amelyre a funkciónak szüksége van, erősítse meg, hogy az alagúton keresztül elérhető, és hagyja a többit zárva. Ha a funkció ragaszkodik egy közvetlen kapcsolathoz olyan gazdagép-címhez, amely az alagúton nem irányítható, az olyan tervezési korlát, amelyet szándékosan meg kell kerülni, nem ok egy tartomány továbbítására.

Tartson visszautat, mielőtt a hálózathoz nyúl

Mielőtt megváltoztatja a saját VPN-jét hordozó virtuális hálózatot, erősítse meg, hogy van helyi vagy független visszaútja.

Ez a home labban számít a legtöbbet, mert a VPN-végpont gyakran éppen annak a hypervisornak a virtuális gépe, amelyet el próbál érni. Egy virtuális kapcsoló, egy híd vagy egy tűzfal-szabály távoli módosítása eltávolíthatja a használt útvonalat, és a munkamenet elég sokáig élhet ahhoz, hogy ezt lássa.

A laboron kívülről teszteljen, ne a LAN-ból, és az elutasításokat éppúgy ellenőrizze, mint az engedélyeket. A hálózatnak, amelynek az alagútból elérhetetlennek kell maradnia, a változtatás után is elérhetetlennek kell maradnia, és ez külön állítás a felügyeleti oldal betöltésétől. Írja le mindkét eredményt, mert a másodikat hagyják ki, és ez számít, amikor a labor nő.

A megtartandó feljegyzés rövid: a felügyeleti cím és szolgáltatás, az útvonal, amelyre mindkét oldalnak szüksége van, az engedélyezett identitások és a helyreállítási útvonal. Ez elég ahhoz, hogy a következő ember újra előállítsa a működő állapotot anélkül, hogy újra levezesse.

Ha az oldal mindezek után is időtúllépésbe fut, rögzítsen a hypervisoron, és keresse a csomagot, mielőtt újabb szabályt változtat. A soha meg nem érkező csomag útválasztási vagy tűzfal-kérdés; a megérkező és elutasított csomag szolgáltatási vagy házirend-kérdés; a megérkező és megválaszolt csomag, miközben az ügyfél vár, visszaút-kérdés. A strongSwan továbbítási dokumentációja leírja, hogyan továbbít egy Linux-átjáró alagútforgalmat egy belső gazdagéphez. Három rögzítés jobb, mint még egy találgatás.