Směrujte jednu podsíť pobočky přes internetový výstup SonicWall v centrále

Telefony pobočky by měly vycházet přes centrálu, zatímco notebooky pobočky dál používají místní WAN, a samotná zásada směrování to nezajistí. Trasa pobočky může vybrat tunel, ale zásada tunelu musí provoz přijmout, centrála jej musí předat a přeložit a odpověď se musí vrátit stejnou cestou. Vynechejte kteroukoli z těch tří věcí a příznakem bude podmnožina klientů, kteří ztratí internet právě tehdy, když je tunel aktivní.

Začněte selektorem, ne trasou

Zásada směrování se shoduje podle zdroje, takže zdroj musí být stabilní dřív než cokoli jiného. Zařaďte vybraná zařízení do skupiny adres, kterou udržuje správce, nebo lépe do vyhrazeného segmentu, jehož členství sleduje roli zařízení. Když běžná obměna DHCP může přesunout odpovídající adresu na jiný stroj, zásada tiše vybere špatného klienta a první hlášení se obvykle týká pomalého prohlížení, které je ve skutečnosti objížďkou.

Pojmenujte skupinu podle zásady, které slouží, ne podle patra nebo oddělení, protože pravidlo směrování přežije obojí. Zapište, která zařízení v ní jsou a kdo smí přidat další.

Přidejte zásadu pobočky a pak braňte její pořadí

Na SonicWall pobočky zásada trasy vybírá skupinu zdrojů, pojmenovává zamýšlené cíle a nastavuje rozhraní tunelu jako bránu, což je přesně to, proč existuje podporovaný návrh s rozhraním tunelu. Pravidla pro místní a soukromé cíle držte nad širokým internetovým pravidlem, protože první shoda vyhrává a soukromý prefix vtlačený do tunelu dorazí do centrály jen proto, aby byl zahozen. Zachovejte i vlastní trasu firewallu k jeho protějšku VPN, jinak přenos tunelu půjde podle zásady, na níž závisí. Nic z toho vás nenutí převádět každý existující tunel založený na zásadách; rozhraní tunelu je jedna podporovaná volba z několika.

Pořadí je ta část, která se mění omylem. Kdokoli přidává výjimku, musí ji vložit nad široké pravidlo, a kdokoli upravuje široké pravidlo, může jedním uložením obrátit celý návrh. Napište zamýšlené pořadí vedle zásady a po aktualizacích firmwaru jej znovu zkontrolujte, protože pojmenování rozhraní a vykreslování zásad se mezi verzemi skutečně mění.

Dokončete cestu v centrále

Zásada tunelu v centrále musí přijmout provoz, který nyní vybírá trasa pobočky. Mezikancelářský selektor omezený na soukromou LAN centrály není povolením přenášet libovolné veřejné cíle, takže zásada potřebuje zdroj pobočky a rozsah cílů, které skutečně zamýšlíte. Centrála pak tento příchozí provoz předá na svůj internetový uplink podle vlastních pravidel přístupu a příklad centrálního výstupu od SonicWall zahrnuje překlad zdroje pro vzdálenou síť na centrálním WAN. Bez tohoto překladu vidí vzdálená strana soukromou adresu pobočky a nemá k ní zpáteční trasu.

Odpovědi jsou druhá polovina smlouvy. Musí se vracet tunelem nebo překladem se stavem, který pro ně vznikl, a provoz soukromých lokalit může vyžadovat jiné zacházení NAT než veřejný výstup. Držte tato pravidla rozlišitelná, protože jedno široké pravidlo překladu, které skrývá každý interní zdroj, činí pozdější protokolování a řešení problémů mnohem obtížněji čitelnými.

Rozhodněte, co skupina dělá, když tunel spadne

Pokud je centrální výstup požadavkem, a ne preferencí, je návrat na místní WAN selháním shody, i když uživatelé zůstanou online. SonicOS dokumentuje trasu s odhozením rozhraní tunelu jako podporovaný způsob, jak zabránit vybranému provozu, aby se vydal nezamýšlenou alternativní cestou.

Slaďte rozsah a prioritu této trasy s nainstalovanou verzí a otestujte ji shozením tunelu místo spoléhání na označení. Skupina, která nikdy nesmí vycházet lokálně, by měla selhat zavřeně, zatímco skupina, kde je dostupnost důležitější, se může legitimně vrátit; obojí jsou rozhodnutí a ani jedno by se nemělo dít ve výchozím stavu.

Ověřte ze tří klientů a poté se čistě vraťte

Ping na centrální bránu testuje špatnou věc, protože vychází z firewallu, a ne z vybraného klienta. Testujte místo toho ze zařízení a otestujte tři z nich: vybrané zařízení, běžné zařízení, které má zůstat lokální, a jedno, které závisí na místních službách.

ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10

Porovnejte, kde veřejný požadavek skutečně vyplaval. Vybraný klient by se měl dostat na internet přes výstup centrály a běžný klient by měl na vzdálené straně stále představovat vlastní adresu pobočky; 203.0.113.10 je dokumentační adresa používaná jako zástupce cíle, na kterém vám záleží. Zahrňte DNS do stejného průchodu, protože klient, který se dotazuje překladače pobočky, může vytvořit dotaz pocházející z routeru s jiným zdrojem, a tedy jinou trasou.

Vrácení zpět je uložené pořadí zásad plus skupina adres. Obnovte předchozí pořadí, odeberte skupinu ze zásady a znovu otestujte obě třídy zařízení. Uchovávejte exportovanou konfiguraci spolu se záznamem změny, protože další inženýr potřebuje vědět, které pravidlo bylo to široké, než ho někdo upravil.