Otvorte SoftEther Manager a prvé skutočné rozhodnutie o hube nie je zaškrtávacie políčko, ale otázka topológie. Lokálny most pripojí hub k fyzickému adaptéru a nechá existujúci segment dodávať adresovanie, kým SecureNAT dá hube vlastný virtuálny router, NAT a DHCP. Voľba medzi nimi mení, odkiaľ adresy pochádzajú a ktoré zariadenie za ne odpovedá. Zapnúť oboje a dúfať, že jedno vyhrá, je spôsob, akým sa z fungujúceho laboratória stane žiadosť o podporu.

Začnite pri hube, ktorý naozaj upravujete

Manager zobrazuje strom serverov a hubov a ľahko nastavíte predvolený hub, kým klienti sa pripájajú k inému s odlišným názvom. Kliknite na hub, prečítajte jeho názov a potvrďte, že relácie pod ním sú klienti, ktorým chcete slúžiť. Táto jediná kontrola zabráni väčšine zmätku, ktorý sa potom pripisuje protokolu.

Potom rozhodnite, čo klient potrebuje od vzdialeného konca. Zdieľané ethernetové správanie s broadcastom a službami LAN ukazuje na most, smerovaný súkromný prístup k malému rozsahu adries ukazuje na SecureNAT a výstup do internetu je rozhodnutie o smerovaní, ktoré obe usporiadania môžu zniesť zle.

Napíšte odpoveď, skôr než na čokoľvek kliknete, pretože obe nastavenia nie sú zameniteľné a vrátenie späť trvá dlhšie ako rozhodnutie. Dve minúty písania ušetria hodinu opätovného pripájania.

Čo robí lokálny most s adresovaním

Lokálny most pripája hub k fyzickému adaptéru, takže hub sa stáva súčasťou tohto Ethernet segmentu. Klienti dostávajú adresy od toho, čo segmentu už slúži, a ich bránou je router segmentu. Z pohľadu klienta sa pripojil k firemnej LAN, s celou dosiahnuteľnosťou a celým vystavením, ktoré to prináša.

To tiež znamená, že most potrebuje skutočný adaptér s príslušnou podporou ovládača a že správca musí byť oprávnený ten segment rozšíriť. Prihlásenie cez VPN dokazuje autentifikáciu, nie právo umiestniť host do produkčného VLAN. Skontrolujte, či názov ovládača zodpovedá zamýšľanému adaptéru, pretože mostovanie nesprávneho portu rýchlo zhodí segment. Ak je zoznam adaptérov prázdny alebo most hlási chybu, odpoveď zvyčajne súvisí s ovládačom alebo oprávneniami, nie s kryptografiou.

Čítajte tabuľku mostov z príkazového riadka, keď je grafický strom nejednoznačný. Výstup pomenuje adaptér, čo strom nie vždy robí.

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

Prázdny zoznam mostov s pripojenými reláciami je užitočný obraz: klienti sú vnútri virtuálneho hubu a nič ho zatiaľ nerozširuje na segment.

Čo SecureNAT pridáva a čo skrýva

SecureNAT dáva hubu virtuálny router, funkciu NAT a službu DHCP, všetko v procese SoftEther. Klienti dostávajú adresy z virtuálneho rozsahu DHCP, virtuálny router odpovedá za predvolenú bránu a prevádzka, ktorá musí odísť, sa prekladá. Fyzický adaptér do toho nevstupuje, a preto to funguje na hoste s jednou sieťovou kartou a bez konfigurácie prepínača.

Cena je, že virtuálne adresy patria hubu a ničomu inému. Stroj v kancelárskej LAN nemôže bez pomoci smerovať na adresu SecureNAT klienta a všetko, čo zaznamenáva zdrojové adresy, vidí preloženú adresu hostu SoftEther. Ak vaše pravidlá prístupu alebo auditná stopa závisia od skutočnej adresy klienta, je to zmena návrhu, nie detail. To tiež rozhoduje, či pravidlo zdrojovej adresy klienta vôbec niekedy uvidí.

Je to aj server DHCP. Prevádzka v segmente, kde už jeden je, alebo mostovanie toho segmentu súčasne vytvára dvoch odpovedajúcich a nepredvídateľné prenájmy. Príručka chápe obe funkcie ako samostatné voľby práve z tohto dôvodu.

Preskúmajte, čomu hub práve teraz slúži, skôr než zapnete čokoľvek iné. Každý príkaz vypisuje aktuálny stav, nie zamýšľaný.

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

Zapnúť jedno bez pokazenia druhého

Vyberte usporiadanie, zapnite ho a druhé nechajte vypnuté. Hub s mostom aj so SecureNAT zároveň je hub s dvoma možnými odpoveďami na tú istú otázku a klient uverí tej, ktorá príde prvá. Pri prechode z jedného na druhé vypnite starú funkciu a pripojte klienta znova, namiesto toho, aby ste predpokladali, že nové nastavenie pôsobí na existujúcu reláciu.

Zoraďte zmenu tak, aby sa klientsky fond neprekrýval s rozsahom LAN. Prekrývajúce sa podsiete sú druhou najčastejšou príčinou tunela, ktorý sa pripojí a potom sa nikam nedostane, a sú neviditeľné, kým oba plány adries neporovnáte vedľa seba.

Potom sa z klienta znova pripojte a prečítajte, čo dostal, pretože pohľad hubu na reláciu nie je pohľadom klienta na jeho vlastnú sieť. Opätovné pripojenie je jediný spoľahlivý spôsob, ako vynútiť nový prenájom.

Skontrolujte bránu a resolver na klientovi

Úspešná autentifikácia vám povie, že prihlasovacie údaje fungujú a hub reláciu prijal. Nehovorí nič o tom, či sa klient niekam dostane, pretože to závisí od adresy, masky, brány a DNS servera, ktoré dostal. Prečítajte si tieto štyri hodnoty na klientovi, skôr než znova siahnete na nastavenie servera.

V systéme Windows detail adaptéra zobrazuje prenájom a resolver a smerovacia tabuľka ukazuje, či je tunel skutočne predvolenou cestou.

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

Na klientovi Linux pochádzajú rovnaké informácie zo súborov adries, trás a resolvera. Predvolená trasa je hodnota, ktorá rozhoduje, či prevádzka vôbec vyjde tunelom. Ak brána ukazuje na kancelársky router, kým tunel očakáva, že ponesie prevádzku, topológia je mostovaná podľa názvu a v praxi rozbitá. Najprv opravte zdroj adries, potom znova otestujte aplikáciu a až potom zvažujte zmenu druhého režimu.

Súvisiace články