SoftEther kaskáda: vědomě propojte dva virtuální huby

Dva huby SoftEther propojené kaskádou sdílejí jednu broadcastovou doménu, takže smyčka nebo druhý server DHCP přestává být místní chybou a stává se chybou sdílenou. To je celý model rizika. Kaskáda sama je nakonfigurovaný klientský vztah: místní virtuální hub se připojuje k hubu vzdáleného serveru pod identitou, kterou tento server autorizuje. Je to stavební prvek větší virtuální sítě, nikdy výstup do internetu.

1. Rozhodněte, co má spojení nést

Začněte od požadavku, ne od funkce. Kaskáda přenáší rámce druhé vrstvy mezi huby, což je to, co chcete, když mají dvě lokality vypadat jako jeden Ethernetový segment. Pokud je potřeba jen směrovaný přístup k několika podsítím, směrovaná cesta je jednodušší a selhává způsoby, které jsou lépe vidět. Volba kaskády vás zavazuje ke sdílenému broadcastu, sdílenému objevování a jedné topologii smyčky.

Napište požadavek na jeden řádek, než se dotknete serveru: které systémy musí vypadat, že jsou na stejném drátě, a které potřebují jen cestu. Vše, co odpovídá „cesta“, patří mimo kaskádu. Tato jediná věta zabrání většině návrhů, které končí duplicitními adresními službami.

2. Vymezte identitu, která to autorizuje

Přihlašovací údaje, kterými se spravuje server, a identita, kterou kaskáda používá k připojení, jsou různá tajemství a jejich míchání je častá zkratka s dlouhým ocasem. Vzdálený hub potřebuje záznam uživatele nebo zásady, který této kaskádě umožní připojení. Tento záznam je autorizace; úspěšné přihlášení nic neříká o tom, co stojí za vzdáleným hubem.

Zaznamenejte, který hub iniciuje, ke kterému vzdálenému hubu se připojuje a co může vzdálená identita dosáhnout. Než se zavážete, porovnejte obě architektury:

Udržujte údaje a pokyny k obnově na obou koncích aktuální. Změna hesla nebo úprava zásady na vzdáleném hubu přeruší kaskádu, aniž by se dotkla místních uživatelů, a porucha se obvykle projeví jako spojení, které je nahoru, ale prázdné.

3. Prohlédněte, co hub už nese

Hub je zřídka izolovaný. Může už přemosťovat fyzický adaptér, směrovat přes virtuální router nebo kaskádovat jinam, a každé z těchto připojení se přenáší do nového vztahu. Proto se „připojili jsme jen dva huby“ tak často mění v „proč jsou tyto dvě lokality teď jeden segment?“.

Dva huby přemostěné do stejného fyzického segmentu a poté kaskádované jeden k druhému tvoří smyčku. Přidejte spanning tree, nebo to nestavějte. Stejný test platí pro hub, který už dosahuje cíle přes jinou kaskádu: druhé spojení nepřidává kapacitu, přidává cestu.

Nepřidávejte spojení proto, že chybí jedna cesta; opravte cestu. Nejprve nakreslete topologii na papír, včetně každého mostu a kaskády, protože diagram trvá dvě minuty a zachytí většinu smyček dřív, než vzniknou.

4. Vyřešte adresování před připojením

Spojené segmenty přinášejí duplicitní podsítě a duplicitní servery DHCP jsou klasickým příznakem: klienti berou pronájem od serveru, který odpoví první, takže chování vypadá náhodně a mezi restarty se přesouvá. Předem rozhodněte, která strana vlastní přidělování adres, a dejte vzdálenému segmentu rozsah, který se s ničím místním nepřekrývá. Vypněte druhou službu DHCP dřív, než kaskáda vyjde online, ne až po první stížnosti.

DNS je samostatná otázka. Kaskáda přenáší rámce; nenastavuje překladače a jméno, které se překládá na místní straně, se nemusí přeložit přes spojení. Testujte dotaz odděleně od cesty IP, protože fungující ping dokazuje jen jedno ze dvou.

5. Dokažte to skutečným zdrojem

Vyberte povolenou službu v zamýšleném vzdáleném segmentu a potvrďte, že odpověď se vrací přes kaskádu. Potom totéž zopakujte pro překlad jmen. Pokud cíl spoléhá na objevování broadcastem, očekávejte jiné chování přes přemostěné spojení než na jediném drátě, a naplánujte to, místo abyste to hlásili jako vadu.

Nakonec zapište topologii: který hub kam kaskáduje, která identita to autorizuje, které segmenty jsou přemostěné a kdo na každém vlastní přidělování adres. Ta poznámka umožní dalšímu člověku změnit zásadu, aniž by shodil segment, o kterém nevěděl, že existuje.