Nukreipkite filialo potinklį per pagrindinės būstinės SonicWall interneto išėjimą

Filialo telefonai turėtų išeiti per pagrindinę būstinę, o filialo nešiojamieji kompiuteriai toliau naudoja vietinį WAN, ir vien maršrutizavimo politika to neužtikrins. Filialo maršrutas gali pasirinkti tunelį, bet tunelio politika turi priimti srautą, būstinė turi jį persiųsti ir išversti, o atsakymas turi grįžti tuo pačiu keliu. Jei praleisite bent vieną iš šių trijų, simptomas bus klientų pogrupis, kurie netenka interneto būtent tada, kai tunelis veikia.

Pradėkite nuo selektoriaus, o ne nuo maršruto

Maršrutizavimo politika suderinama pagal šaltinį, todėl šaltinis turi būti stabilus prieš viską kita. Įdėkite pasirinktus įrenginius į adresų grupę, kurią prižiūri administratorius, arba dar geriau į atskirą segmentą, kurio narystė seka įrenginio vaidmenį. Kai įprastas DHCP pokytis gali perkelti atitinkantį adresą į kitą mašiną, politika tyliai pasirenka netinkamą klientą, o pirmasis pranešimas paprastai būna apie lėtą naršymą, kuris iš tikrųjų yra apylanka.

Pavadinkite grupę pagal politiką, kuriai ji tarnauja, o ne pagal aukštą ar skyrių, nes maršrutizavimo taisyklė pergyvens abu. Užrašykite, kurie įrenginiai joje yra ir kas gali pridėti vieną.

Pridėkite filialo politiką, o tada ginkite jos tvarką

Filialo SonicWall maršruto politika pasirenka šaltinio grupę, įvardija numatomas paskirties vietas ir nustato tunelio sąsają kaip tinklo vartus, o palaikomas tunelio sąsajos dizainas egzistuoja būtent tam. Laikykite vietinių ir privačių paskirties vietų taisykles aukščiau bendros interneto taisyklės, nes laimi pirmas atitikimas, o į tunelį įstumtas privatus priešdėlis pasiekia būstinę tik tam, kad būtų išmestas. Išsaugokite ir pačios užkardos maršrutą į savo VPN partnerį, kitaip tunelio transportas seks politiką, nuo kurios priklauso. Niekas iš to nevers jūsų konvertuoti kiekvieno esamo politikos pagrindu veikiančio tunelio; tunelio sąsaja yra vienas palaikomas pasirinkimas tarp kelių.

Tvarka yra ta dalis, kuri pasikeičia netyčia. Kiekvienas, kuris prideda išimtį, turi įterpti ją aukščiau bendros taisyklės, o kiekvienas, kuris redaguoja bendrą taisyklę, gali apversti visą dizainą vienu išsaugojimu. Užrašykite numatytą tvarką šalia politikos ir po programinės įrangos atnaujinimų patikrinkite ją dar kartą, nes sąsajų pavadinimai ir politikų atvaizdavimas tikrai keičiasi tarp versijų.

Užbaikite kelią būstinėje

Būstinės tunelio politika turi priimti srautą, kurį dabar pasirenka filialo maršrutas. Tarpofficinis selektorius, apribotas būstinės privačiu LAN, nėra leidimas perduoti savavališkas viešas paskirties vietas, todėl politikai reikia filialo šaltinio ir paskirties vietų diapazono, kurį iš tikrųjų numatote. Tada būstinė persiunčia tą gaunamą srautą į savo interneto uplinką pagal savo prieigos taisykles, o SonicWall centrinio išėjimo pavyzdys apima šaltinio vertimą nuotoliniam tinklui centriniame WAN. Be to vertimo tolimoji pusė mato privatų filialo adresą ir neturi maršruto atgal į jį.

Atsakymai yra kita sutarties pusė. Jie turi grįžti per tunelį arba per jiems sukurtą būsenos vertimą, o privačių svetainių srautas gali reikalauti kitokio NAT apdorojimo nei viešas išėjimas. Laikykite tas taisykles atskiriamas, nes viena plati vertimo taisyklė, slepianti kiekvieną vidinį šaltinį, vėlesnį registravimą ir trikčių šalinimą padaro daug sunkiau įskaitomą.

Nuspręskite, ką grupė daro, kai tunelis nukrenta

Jei centrinis išėjimas yra reikalavimas, o ne pageidavimas, grįžimas prie vietinio WAN yra atitikties pažeidimas, net jei vartotojai lieka prisijungę. SonicOS dokumentuoja maršrutą su tunelio sąsajos atmetimu kaip palaikomą būdą neleisti pasirinktam srautui pasukti nenumatytu alternatyviu keliu.

Suderinkite to maršruto apimtį ir prioritetą su įdiegta versija ir išbandykite jį nuleisdami tunelį, o ne pasitikėdami etikete. Grupė, kuri niekada neturėtų išeiti vietiškai, turėtų nepavykti uždarai, o grupė, kurioje prieinamumas svarbesnis, gali teisėtai grįžti; abu yra sprendimai, ir nė vienas neturėtų įvykti pagal nutylėjimą.

Patikrinkite iš trijų klientų, tada švariai atsukite atgal

Ping į centrinius tinklo vartus tikrina ne tai, nes jis kyla iš užkardos, o ne iš pasirinkto kliento. Bandykite iš įrenginių ir išbandykite tris iš jų: pasirinktą įrenginį, įprastą įrenginį, kuris turėtų likti vietinis, ir vieną, kuris priklauso nuo vietinių paslaugų.

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

Palyginkite, kur viešoji užklausa iš tikrųjų pasirodė. Pasirinktas klientas turėtų pasiekti internetą per būstinės išėjimą, o įprastas klientas tolimojoje pusėje vis dar turėtų rodyti savo filialo adresą; 203.0.113.10 yra dokumentacijos adresas, naudojamas kaip jums svarbios paskirties vietos pakaitalas. Įtraukite DNS į tą patį etapą, nes klientas, klausiantis filialo resolverio, gali sukurti maršrutizatoriaus kilmės užklausą su kitu šaltiniu ir todėl kitu maršrutu.

Atšaukimas yra išsaugota politikų tvarka ir adresų grupė. Atkurkite ankstesnę tvarką, pašalinkite grupę iš politikos ir iš naujo išbandykite abi įrenginių klases. Išsaugokite eksportuotą konfigūraciją su pakeitimų įrašu, nes kitam inžinieriui reikia žinoti, kuri taisyklė buvo plati prieš kam nors ją redaguojant.