Hypervizor v domácí laboratoři nedostupný přes VPN: kde hledat

Tunel se naváže, webová stránka hypervizoru vyprší a klient říká, že je připojen. Tahle kombinace vylučuje překvapivě hodně: VPN handshake funguje, klient má adresu a koncový bod je dostupný. Zbývá krátký seznam otázek směrování a politiky a ty mají přirozené pořadí. Procházejte je od hypervizoru ven, ne od klienta dovnitř, protože vlastní stav hypervizoru se potvrzuje nejlevněji.

Začněte segmentem správy

Potvrďte adresu správy hypervizoru a službu, která na ní naslouchá, a potvrďte, že se stránka načte z jiného hostitele v tomto segmentu, než začnete cokoli diagnostikovat na dálku. Lokální test, který selže, není problém VPN a je to pětiminutová kontrola, která ušetří hodinu.

Pak dvě cesty. Klient VPN potřebuje trasu do sítě správy, což obvykle znamená, že AllowedIPs klienta nebo protlačené trasy zahrnují tuto podsíť. Hypervizor nebo jeho výchozí brána potřebuje zpětnou cestu k poolu adres klientů, pokud návrh záměrně nepřekládá zdroj na vstupu. To jsou dvě oddělené skutečnosti a chybění kterékoli z nich dává stejné vypršení. Ověřte je odděleně: ip route get 192.168.10.20 na klientovi a zachycení na hostiteli hypervizoru, které ukáže, zda paket vůbec dorazil.

Povolte skutečného vzdáleného správce

Autorizace je oddělená otázka od dostupnosti. Použijte politiku brány a hostitele omezenou na zdroje a služby, které potřebují přístup ke správě. Hostující účet VPN, který potřebuje jednu laboratorní aplikaci, by se tím neměl dostat do roviny správy, a ploché pravidlo, které propouští celou podsíť tunelu, je způsob, jak se to děje.

Nechte zapnuté vlastní ověřování hypervizoru a kontroly certifikátů. Soukromá trasa není důvod proklikat neočekávané varování identity.

Varování stojí za to brát jako zjištění, ne jako překážku. Pokud certifikát neodpovídá jménu, které jste použili, buď je jméno špatné, nebo služba není ta, kterou si myslíte, a obě odpovědi jsou na rozhraní správy důležitější než kdekoli jinde. Dostaňte se na stránku pod jménem, pro které byl certifikát vydán, a nechte DNS nasměrovat toto jméno na adresu tunelu. Soukromé jméno, které se mezi LAN a tunelem překládá nekonzistentně, je častou příčinou stížností na certifikáty, které vypadají jako poruchy VPN.

Zkontrolujte sekundární spojení

Některé funkce používají spojení, která webová stránka nepoužívá. Konzolová relace, nahrání ISO, proxy VNC nebo SPICE a migrační kanál mohou každý používat jiný port nebo jinou adresu hostitele. Když se stránka načte a jedna funkce selže, čtěte požadavek daného produktu, místo abyste otevírali každý port na hostiteli.

Otevřít všechno je způsob, jak se rozhraní správy stane nespravovaným. Každý další port je další posluchač, který je třeba udržovat záplatovaný, a hypervizor jich už vystavuje dost. Určete konkrétní spojení, které funkce potřebuje, potvrďte, že je přes tunel dostupné, a zbytek nechte zavřený. Pokud funkce trvá na přímém spojení s adresou hostitele, kterou přes váš tunel nesměrujete, je to návrhové omezení, které je třeba záměrně obejít, ne důvod přeposílat rozsah.

Než se dotknete sítě, ponechte si cestu zpět

Než změníte virtuální síť, která nese vaši vlastní VPN, potvrďte, že máte místní nebo nezávislou cestu zpět.

To je nejdůležitější v domácí laboratoři, protože koncový bod VPN je často virtuální stroj na právě tom hypervizoru, ke kterému se snažíte dostat. Změna virtuálního přepínače, bridge nebo pravidla firewallu na dálku může odstranit cestu, kterou používáte, a relace může přežít dost dlouho, abyste to viděli.

Testujte zvenčí laboratoře, ne z LAN, a ověřujte odmítnutí stejně jako povolení. Síť, která má zůstat z tunelu nedostupná, má zůstat nedostupná i po vaší změně, a to je samostatné tvrzení od načtení stránky správy. Zapište oba výsledky, protože druhý se přeskakuje a je to ten, na kterém záleží, když laboratoř roste.

Záznam, který si ponechat, je krátký: adresa a služba správy, trasa, kterou potřebuje každá strana, identity s povoleným přístupem a cesta obnovy. To stačí, aby další člověk reprodukoval funkční stav, aniž by ho znovu odvozoval.

Pokud stránka i po tom všem vyprší, zachyťte provoz na hypervizoru a hledejte paket, než změníte další pravidlo. Paket, který nikdy nedorazí, je otázka směrování nebo firewallu; paket, který dorazí a je odmítnut, je otázka služby nebo politiky; paket, který dorazí a je zodpovězen, zatímco klient čeká, je otázka zpětné cesty. Dokumentace strongSwan k přeposílání pokrývá, jak linuxová brána přeposílá provoz tunelu internímu hostiteli. Tři zachycení porazí jeden další odhad.