Lokální most SoftEther versus SecureNAT: který zapnout

Otevřete SoftEther Manager a první skutečné rozhodnutí o hubu není zaškrtávací políčko, ale otázka topologie. Lokální most připojí hub k fyzickému adaptéru a nechá stávající segment dodávat adresování, kdežto SecureNAT dá hubu vlastní virtuální router, NAT a DHCP. Volba mezi nimi mění, odkud adresy pocházejí a které zařízení za ně odpovídá. Zapnout obojí a doufat, že jedno vyhraje, je způsob, jak se z funkční laboratoře stane žádost o podporu.

Začněte u hubu, který doopravdy upravujete

Manager zobrazuje strom serverů a hubů a snadno nastavíte výchozí hub, zatímco klienti se připojují k jinému s odlišným názvem. Klikněte na hub, přečtěte jeho název a potvrďte, že relace pod ním jsou klienti, kterým chcete sloužit. Tato jediná kontrola zabrání většině zmatku, který se pak přičítá protokolu.

Pak rozhodněte, co klient potřebuje od vzdáleného konce. Sdílené ethernetové chování s broadcastem a službami LAN ukazuje na most, směrovaný soukromý přístup k malému rozsahu adres ukazuje na SecureNAT a východ do internetu je rozhodnutí o směrování, které obě uspořádání mohou snést špatně.

Napište odpověď, než něco kliknete, protože obě nastavení nejsou zaměnitelná a vrácení zpět trvá déle než rozhodnutí. Dvě minuty psaní ušetří hodinu opětovného připojování.

Co dělá lokální most s adresováním

Lokální most připojuje hub k fyzickému adaptéru, takže se hub stává součástí onoho Ethernet segmentu. Klienti dostávají adresy od toho, co segmentu už slouží, a jejich bránou je router segmentu. Z pohledu klienta se připojil k firemní LAN, se vší dosažitelností a vší vystaveností, kterou to znamená.

To také znamená, že most potřebuje skutečný adaptér s odpovídající podporou ovladače a že správce musí být oprávněn ten segment rozšířit. Přihlášení VPN prokazuje autentizaci, ne právo umístit host do produkčního VLAN. Zkontrolujte, že název ovladače odpovídá zamýšlenému adaptéru, protože mostování špatného portu rychle shodí segment. Pokud je seznam adaptérů prázdný nebo most hlásí chybu, odpověď obvykle souvisí s ovladačem nebo oprávněními, nikoli s kryptografií.

Čtěte tabulku mostů z příkazové řádky, když je grafický strom nejednoznačný. Výstup pojmenuje adaptér, což strom ne vždy dělá.

vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionList

Prázdný seznam mostů s připojenými relacemi je užitečný obrázek: klienti jsou uvnitř virtuálního hubu a nic ho zatím nerozšiřuje na segment.

Co SecureNAT přidává a co skrývá

SecureNAT dává hubu virtuální router, funkci NAT a službu DHCP, vše uvnitř procesu SoftEther. Klienti dostávají adresy z virtuálního rozsahu DHCP, virtuální router odpovídá za výchozí bránu a provoz, který má odejít, se překládá. Fyzický adaptér do toho nevstupuje, a proto to funguje na hostu s jednou síťovou kartou a bez konfigurace přepínače.

Cena je, že virtuální adresy patří hubu a ničemu jinému. Stroj v kancelářské LAN nemůže bez pomoci směrovat na SecureNAT adresu klienta a vše, co zaznamenává zdrojové adresy, vidí přeloženou adresu hostu SoftEther. Pokud vaše přístupová pravidla nebo auditní stopa závisí na skutečné adrese klienta, je to změna návrhu, ne detail. To také rozhoduje, zda pravidlo zdrojové adresy klienta vůbec uvidí.

Je to také DHCP server. Provozování v segmentu, kde už jeden je, nebo současné mostování toho segmentu vytváří dva odpovídače a nepředvídatelné leases. Příručka chápe obě funkce jako samostatné volby právě z tohoto důvodu.

Prohlédněte si, čemu hub právě teď slouží, než zapnete cokoli dalšího. Každý příkaz vypisuje aktuální stav, ne zamýšlený.

vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGet

Zapnout jedno, aniž byste rozbili druhé

Vyberte uspořádání, zapněte ho a druhé nechte vypnuté. Hub s mostem i SecureNAT zároveň je hub se dvěma možnými odpověďmi na stejnou otázku a klient uvěří té, která dorazí první. Při přechodu z jednoho na druhé vypněte starou funkci a připojte klienta znovu, místo abyste předpokládali, že nové nastavení působí na existující relaci.

Seřaďte změnu tak, aby se klientský pool nepřekrýval s rozsahem LAN. Překrývající se podsítě jsou druhou nejčastější příčinou tunelu, který se připojí a pak se nikam nedostane, a jsou neviditelné, dokud oba plány adres neporovnáte vedle sebe.

Pak se z klienta znovu připojte a přečtěte, co dostal, protože pohled hubu na relaci není pohled klienta na jeho vlastní síť. Opětovné připojení je jediný spolehlivý způsob, jak vynutit nový lease.

Zkontrolujte bránu a resolver na klientovi

Úspěšná autentizace vám řekne, že přihlašovací údaje fungují a hub relaci přijal. Neříká nic o tom, zda se klient někam dostane, protože to závisí na adrese, masce, bráně a DNS serveru, které dostal. Přečtěte si tyto čtyři hodnoty na klientovi, než znovu sáhnete na nastavení serveru.

Ve Windows ukazuje detail adaptéru lease a resolver a směrovací tabulka ukazuje, zda je tunel skutečně výchozí cestou.

ipconfig /all
route print -4
nslookup intranet.corp.internal

U klienta Linux pocházejí stejné informace ze souborů adres, tras a resolveru. Výchozí trasa je hodnota, která rozhoduje, zda provoz vůbec vyjde tunelem. Pokud brána ukazuje na kancelářský router, zatímco tunel očekává, že ponese provoz, je topologie mostovaná podle názvu a v praxi rozbitá. Nejprve opravte zdroj adres, pak znovu otestujte aplikaci a teprve potom zvažujte změnu druhého režimu.