Suunake haru alamvõrk peakontori SonicWalli internetiväljundi kaudu
Valige haru lähtegrupp, võtke see tunnelipoliitikas vastu, tõlkige keskse WAN-i juures ja seejärel testige kolme klienti. Üksinda marsruut lüüsi ei loo.
Haru telefonid peaksid väljuma peakontori kaudu, samal ajal kui haru sülearvutid jätkavad kohaliku WAN-i kasutamist, ja marsruudipoliitika üksi ei anna seda. Haru marsruut saab tunneli valida, kuid tunnelipoliitika peab liikluse vastu võtma, peakontor peab selle edasi suunama ja tõlkima ning vastus peab tulema tagasi sama teed. Kui üks neist kolmest puudub, on sümptomiks hulk kliente, kes kaotavad interneti täpselt siis, kui tunnel on üleval.
Alustage valijast, mitte marsruudist
Marsruudipoliitika sobitub lähtekoha järgi, seega peab lähtekoht olema stabiilne enne kõike muud. Pange valitud seadmed administraatori hallatavasse aadressigruppi või veel parem, eraldi segmenti, mille liikmelisus järgib seadme rolli. Kui tavaline DHCP vahetus võib sobitatud aadressi teise masinasse liigutada, valib poliitika vaikselt vale kliendi, ja esimene raport on tavaliselt aeglasest sirvimisest, mis on tegelikult ümbersõit.
Nimetage grupp poliitika järgi, mida see teenindab, mitte korruse või osakonna järgi, sest marsruudireegel elab mõlemast kauem. Kirjutage üles, millised seadmed selles on ja kes tohib ühe lisada.
Lisage haru poliitika ja kaitske seejärel selle järjekorda
Haru SonicWallis valib marsruudipoliitika lähtegrupi, nimetab kavandatud sihtkohad ja seab tunneli liidese lüüsiks, milleks toetatud tunneliliidese disain täpselt mõeldud ongi. Hoidke kohalike ja privaatsete sihtkohtade reeglid laia internetireegli kohal, sest esimene sobivus võidab ja tunnelisse surutud privaatne eesliide jõuab peakontorisse vaid selleks, et ära visata. Säilitage ka tulemüüri enda marsruut tema VPN-vastaspoole suunas, muidu järgib tunneli transport poliitikat, millest see sõltub. Miski sellest ei sunni teid teisendama iga olemasolevat poliitikapõhist tunnelit; tunneliliides on üks toetatud valik mitme hulgas.
Järjekord on see osa, mis muutub kogemata. Iga erandi lisaja peab selle paigutama laia reegli kohale ja iga laia reegli muutja võib ühe salvestusega kogu disaini pöörata. Kirjutage kavandatud järjekord poliitika kõrvale ja kontrollige seda uuesti pärast püsivara uuendusi, sest liideste nimetamine ja poliitikate kuvamine muutuvad versioonide vahel tõesti.
Lõpetage tee peakontoris
Peakontori tunnelipoliitika peab vastu võtma liikluse, mille haru marsruut nüüd valib. Peakontori privaatse LAN-iga piiratud kontoritevaheline valija ei ole luba kanda suvalisi avalikke sihtkohti, seega vajab poliitika haru lähtekohta ja sihtvahemikku, mida te tegelikult kavatsete. Seejärel suunab peakontor selle saabuva liikluse oma interneti-ühendusse vastavalt oma juurdepääsureeglitele, ja SonicWallí keskse väljundi näide sisaldab lähtekoha tõlget kaugvõrgule keskses WAN-is. Ilma selle tõlketa näeb kaugpool haru privaatset aadressi ega oma sinna tagasiteed.
Vastused on lepingu teine pool. Need peavad naasma tunneli kaudu või nende jaoks loodud olekuga tõlke kaudu, ja privaatsete saitide liiklus võib vajada avalikust väljundist erinevat NAT-käsitlust. Hoidke need reeglid eristatavad, sest üks lai tõlkereegel, mis peidab iga sisemise lähtekoha, muudab hilisema logimise ja tõrkeotsingu palju raskemini loetavaks.
Otsustage, mida grupp teeb, kui tunnel langeb
Kui keskne väljund on nõue, mitte eelistus, on kohalikku WAN-i taganemine vastavusnõuete rikkumine isegi siis, kui kasutajad jäävad võrku. SonicOS dokumenteerib tunneliliidese mahaviskega marsruudi toetatud viisina takistada valitud liiklusel soovimatule alternatiivsele teele minekut.
Sobitage selle marsruudi ulatus ja prioriteet paigaldatud versiooniga ning testige seda tunnelit alla võttes, mitte silti usaldades. Grupp, mis ei tohi kunagi kohapeal väljuda, peaks ebaõnnestuma suletult, samas kui grupp, kus kättesaadavus on tähtsam, võib seaduslikult tagasi langeda; mõlemad on otsused ja kumbki ei tohiks toimuda vaikimisi.
Kontrollige kolmest kliendist ja seejärel taastage puhtalt
Ping kesksele lüüsile testib vale asja, sest see lähtub tulemüürist, mitte valitud kliendist. Testige hoopis seadmetest ja testige kolme neist: valitud seade, tavaline seade, mis peaks jääma kohalikuks, ja üks, mis sõltub kohalikest teenustest.
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
Võrrelge, kus avalik päring tegelikult pinnale tuli. Valitud klient peaks internetti jõudma peakontori väljundi kaudu ja tavaline klient peaks kaugpoolel endiselt esitama haru enda aadressi; 203.0.113.10 on dokumentatsiooniaadress, mida kasutatakse teile olulise sihtkoha asendajana. Kaasake DNS samasse käiku, sest haru resolverit päritav klient võib tekitada ruuterist lähtuva päringu teistsuguse lähtekohaga ja seega teistsuguse marsruudiga.
Tagasipööramine on salvestatud poliitikajärjekord pluss aadressigrupp. Taastage eelmine järjekord, eemaldage grupp poliitikast ja testige uuesti mõlemat seadmeklassi. Hoidke eksporditud konfiguratsioon muudatuse kirjega koos, sest järgmine insener peab teadma, milline reegel oli lai enne, kui keegi seda muutis.