Smerujte jednu podsieť pobočky cez internetový výstup SonicWall v centrále

Telefóny pobočky by mali vychádzať cez centrálu, zatiaľ čo notebooky pobočky ďalej používajú miestny WAN, a samotná politika smerovania to nezabezpečí. Trasa pobočky môže vybrať tunel, ale politika tunela musí prevádzku prijať, centrála ju musí poslať ďalej a preložiť a odpoveď sa musí vrátiť tou istou cestou. Vynechajte ktorúkoľvek z tých troch vecí a príznakom bude podmnožina klientov, ktorí strácajú internet práve vtedy, keď je tunel aktívny.

Začnite selektorom, nie trasou

Politika smerovania sa zhoduje podľa zdroja, takže zdroj musí byť stabilný skôr než čokoľvek iné. Zaradenie vybraných zariadení do skupiny adries, ktorú udržiava správca, alebo lepšie do vyhradeného segmentu, ktorého členstvo sleduje rolu zariadenia. Keď bežná obmena DHCP môže presunúť zodpovedajúcu adresu na iný stroj, politika ticho vyberie nesprávneho klienta a prvé hlásenie sa zvyčajne týka pomalého prehliadania, ktoré je v skutočnosti obchádzkou.

Pomenujte skupinu podľa politiky, ktorej slúži, nie podľa poschodia alebo oddelenia, pretože pravidlo smerovania prežije oboje. Zapíšte, ktoré zariadenia v nej sú a kto smie pridať ďalšie.

Pridajte politiku pobočky a potom bráňte jej poradie

Na SonicWall pobočky politika trasy vyberá skupinu zdrojov, pomenúva zamýšľané ciele a nastavuje rozhranie tunela ako bránu, a práve na to existuje podporovaný návrh s rozhraním tunela. Pravidlá pre miestne a súkromné ciele držte nad širokým internetovým pravidlom, pretože prvá zhoda vyhráva a súkromný prefix vtlačený do tunela dorazí do centrály len preto, aby bol zahodený. Zachovajte aj vlastnú trasu firewallu k jeho partnerovi VPN, inak prenos tunela pôjde podľa politiky, na ktorej závisí. Nič z toho vás nenúti previesť každý existujúci tunel založený na politike; rozhranie tunela je jedna podporovaná voľba z viacerých.

Poradie je tá časť, ktorá sa mení omylom. Ktokoľvek pridáva výnimku, musí ju vložiť nad široké pravidlo, a ktokoľvek upravuje široké pravidlo, môže jediným uložením obrátiť celý návrh. Napíšte zamýšľané poradie vedľa politiky a po aktualizáciách firmvéru ho znova skontrolujte, pretože pomenovanie rozhraní a vykresľovanie politík sa medzi verziami skutočne menia.

Dokončite cestu v centrále

Politika tunela v centrále musí prijať prevádzku, ktorú teraz vyberá trasa pobočky. Medzikancelárska voľba obmedzená na súkromnú LAN centrály nie je povolenie prenášať ľubovoľné verejné ciele, takže politika potrebuje zdroj pobočky a rozsah cieľov, ktoré skutočne zamýšľate. Centrála potom túto prichádzajúcu prevádzku odošle na svoj internetový uplink podľa vlastných pravidiel prístupu a príklad centrálneho výstupu od SonicWall zahŕňa preklad zdroja pre vzdialenú sieť na centrálnom WAN. Bez tohto prekladu vidí vzdialená strana súkromnú adresu pobočky a nemá k nej spiatočnú trasu.

Odpovede sú druhá polovica zmluvy. Musia sa vracať tunelom alebo prekladom so stavom, ktorý pre ne vznikol, a prevádzka k súkromným lokalitám môže vyžadovať iné zaobchádzanie NAT ako verejný výstup. Držte tieto pravidlá rozlíšiteľné, pretože jedno široké pravidlo prekladu, ktoré skrýva každý interný zdroj, robí neskoršie protokolovanie a riešenie problémov oveľa ťažšie čitateľnými.

Rozhodnite, čo skupina robí, keď tunel spadne

Ak je centrálny výstup požiadavkou a nie preferenciou, návrat na miestny WAN je zlyhaním zhody, aj keď používatelia zostanú online. SonicOS dokumentuje trasu s odhodením rozhrania tunela ako podporovaný spôsob, ako zabrániť vybranej prevádzke, aby sa vydala neúmyslnou alternatívnou cestou.

Zosúlaďte rozsah a prioritu tejto trasy s nainštalovanou verziou a otestujte ju zhozením tunela namiesto spoliehania sa na označenie. Skupina, ktorá nikdy nesmie vychádzať lokálne, by mala zlyhať zavretá, zatiaľ čo skupina, kde je dostupnosť dôležitejšia, sa môže legitímne vrátiť; oboje sú rozhodnutia a ani jedno by sa nemalo diať v predvolenom stave.

Overte z troch klientov a potom sa čisto vráťte

Ping na centrálnu bránu testuje nesprávnu vec, pretože vychádza z firewallu, a nie z vybraného klienta. Testujte zo zariadení a otestujte tri z nich: vybrané zariadenie, bežné zariadenie, ktoré má zostať lokálne, a jedno, ktoré závisí od miestnych služieb.

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

Porovnajte, kde verejná požiadavka skutočne vyplávala. Vybraný klient by sa mal dostať na internet cez výstup centrály a bežný klient by mal na vzdialenej strane stále predstavovať vlastnú adresu pobočky; 203.0.113.10 je dokumentačná adresa používaná ako zástupca cieľa, na ktorom vám záleží. Zahrňte DNS do rovnakého prechodu, pretože klient, ktorý sa pýta prekladača pobočky, môže vytvoriť dopyt pochádzajúci z routera s iným zdrojom, a teda inou trasou.

Vrátenie späť je uložené poradie politík plus skupina adries. Obnovte predchádzajúce poradie, odoberte skupinu z politiky a znova otestujte obe triedy zariadení. Uchovávajte exportovanú konfiguráciu spolu so záznamom zmeny, pretože ďalší inžinier potrebuje vedieť, ktoré pravidlo bolo to široké, než ho niekto upravil.