Co vlastně virtuální hub SoftEther propojuje

Virtuální hub SoftEther je hranice členství uvnitř jednoho serveru, nikoli umístění. Relace, které se k hubu připojí, se dostanou k tomu, k čemu je hub připojen, a relace na jiném hubu nikoli, i když se obě ověřují na stejném serveru. Proto úspěšné přihlášení může klienta stále umístit do nesprávné sítě. Čtení hubu jako virtuálního přepínače objasňuje, co dělá a co nechává mostům, směrování a konfiguraci kaskády.

Hub je hranice členství

Jeden server může hostovat několik hubů, každý s vlastními uživateli, relacemi a politikou. Ověření určuje, kdo relace je, zatímco hub rozhoduje, do které virtuální sítě se tato relace připojí. Dva huby na jednom hostiteli se proto chovají jako dva oddělené přepínače, které náhodou sdílejí hardware. Nic na úspěšném přihlášení neznamená, že relace přistála tam, kam jste zamýšleli.

Použijte název hubu zdokumentovaný provozovatelem, ne název zapamatovaný ze snímku obrazovky. Klient, který se připojí k nesprávnému hubu, se s platnými přihlašovacími údaji dostane do jiné sítě, což je zjištění o konfiguraci, nikoli bezpečnostní incident. Uchovávejte název hubu a jeho účel v poznámkách profilu připojení.

Správa je vymezena stejně. Správce hubu spravuje tento hub, zatímco správce serveru spravuje proces, posluchače a každý hub na hostiteli.

Připojení rozhodují, co je za nimi

Hub sám o sobě propojuje relace navzájem. Dostat se k čemukoli jinému závisí na tom, jak je hub připojen: lokální most k fyzickému rozhraní, virtuální router nebo kaskáda k jinému serveru. Každé připojení nese vlastní pravidla předávání a vlastní způsoby selhání. Předpoklad, že hub poskytuje přístup k internetu, je nejčastější chyba týkající se produktu.

SecureNAT je vestavěná možnost, realizovaná virtuálním routerem a virtuální službou DHCP uvnitř serveru. Je vhodná pro laboratoř a nevhodná pro cokoli, co potřebuje předvídatelné adresování nebo politiku. Lokální most staví hub na skutečný segment, který dědí přepínání, DHCP a chování vysílání tohoto segmentu.

Kaskáda propojuje dva servery, takže relace na jednom hubu se mohou objevit na druhém. Je to vztah hub k hubu, takže oba konce potřebují kompatibilní politiku a funkční cestu mezi sebou.

Čtěte relace a politiku odděleně

Pohledy na relace, adresy MAC a adresy IP popisují, jak virtuální síť právě vypadá. Jsou to pozorování, ne oprávnění. Relace viditelná v seznamu tím není oprávněna ke každé službě, ke které se hub dostane, a platí to i obráceně.

Porovnejte seznam relací s politikou, která se na něj má vztahovat. Zařízení s adresou mimo zamýšlený rozsah obvykle znamená DHCP odjinud nebo ručně nakonfigurovaného klienta. Adresa MAC, která se pohybuje mezi relacemi, znamená přenesené zařízení nebo dvě zařízení sdílející identitu. Obě stojí za pohled a ani jedno se neprokazuje samotnou tabulkou.

Na serveru vpncmd ukazuje stejný obraz z pohledu hostitele. Porovnejte tento výstup s vlastním pohledem klienta, kdykoli se oba rozcházejí.

vpncmd localhost /SERVER /CMD SessionList
vpncmd localhost /SERVER /CMD HubList

Berte správu hubu jako vlastní roli, ne jako oprávnění klienta. Delegování jednoho hubu by nemělo předat posluchače ani proces, který hostuje každý další hub.

Po připojení zkontrolujte klienta

Ze strany klienta navázaná relace dokazuje jen to, že ověření a název hubu byly přijaty. Potvrďte adresu, trasu a překlad názvů odděleně, protože každé z nich může selhat poté, co hub relaci přijal.

ip -brief address show
ip route get 10.20.30.41
resolvectl query host.internal

Seznam adres ukazuje, zda adaptér dostal pronájem od zamýšleného zdroje. Dotaz na trasu ukazuje, které rozhraní by neslo soukromé cíle, a dotaz na překladač ukazuje, zda DNS následovalo relaci. Hub, který předává pakety, zatímco DNS stále ukazuje na místní síť, vytváří klasické napůl funkční spojení.

Testujte aplikaci, ne spojení. Načtená stránka intranetu je silnější důkaz než adaptér s věrohodnou adresou.