Ուղղորդել մասնաճյուղի ենթացանցը գլխամասային գրասենյակի SonicWall ինտերնետ ելքով

Մասնաճյուղի հեռախոսները պետք է դուրս գան գլխամասային գրասենյակով, մինչդեռ մասնաճյուղի նոթբուքերը շարունակում են օգտագործել տեղական WAN-ը, և միայն երթուղային քաղաքականությունը դա չի ապահովի։ Մասնաճյուղի ուղին կարող է ընտրել թունելը, բայց թունելի քաղաքականությունը պետք է ընդունի երթևեկությունը, գլխամասային գրասենյակը պետք է փոխանցի և թարգմանի այն, իսկ պատասխանը պետք է վերադառնա նույն ճանապարհով։ Բաց թողեք այս երեքից որևէ մեկը, և ախտանիշը կլինի հաճախորդների ենթաբազմություն, որոնք ինտերնետը կորցնում են հենց թունելի ակտիվ ժամանակ։

Սկսեք ընտրիչից, ոչ թե ուղուց

Երթուղային քաղաքականությունը համապատասխանում է աղբյուրի հիման վրա, ուստի աղբյուրը պետք է կայուն լինի ամեն ինչից առաջ։ Տեղադրեք ընտրված սարքերը ադմինիստրատորի կողմից պահպանվող հասցեների խմբում կամ, ավելի լավ, առանձին հատվածում, որի անդամակցությունը հետևում է սարքի դերին։ Երբ սովորական DHCP փոփոխությունը կարող է համապատասխան հասցեն տեղափոխել այլ մեքենա, քաղաքականությունը լուռ ընտրում է սխալ հաճախորդին, և առաջին բողոքը սովորաբար դանդաղ զննարկման մասին է, որն իրականում շրջանցում է։

Անվանեք խումբը այն քաղաքականության անունով, որին այն ծառայում է, ոչ թե հարկի կամ բաժնի անունով, քանի որ երթուղային կանոնը կապրի երկուսից էլ երկար։ Գրանցեք, թե որ սարքերն են դրա մեջ և ով կարող է ավելացնել մեկը։

Ավելացրեք մասնաճյուղի քաղաքականությունը, ապա պաշտպանեք դրա հերթականությունը

Մասնաճյուղի SonicWall-ում երթուղային քաղաքականությունը ընտրում է աղբյուրի խումբը, անվանում նպատակային ուղղությունները և սահմանում թունելի ինտերֆեյսը որպես դարպաս, ինչի համար էլ գոյություն ունի աջակցվող թունել-ինտերֆեյսի ձևավորումը։ Տեղական և մասնավոր ուղղությունների կանոնները պահեք լայն ինտերնետ կանոնից վեր, քանի որ առաջին համապատասխանությունը հաղթում է, և թունել մղված մասնավոր նախածանցը գլխամասային գրասենյակ հասնում է միայն նրա համար, որ դեն նետվի։ Պահպանեք նաև ֆայրվոլի սեփական ուղին դեպի իր VPN գործընկերը, այլապես թունելի տրանսպորտը կհետևի այն քաղաքականությանը, որից կախված է։ Այս ամենը ձեզ չի ստիպում փոխարկել յուրաքանչյուր գոյություն ունեցող քաղաքականության վրա հիմնված թունել, թունելի ինտերֆեյսը մի քանիսից մեկ աջակցվող ընտրություն է։

Հերթականությունը այն մասն է, որը փոխվում է պատահաբար։ Յուրաքանչյուր ոք, ով բացառություն է ավելացնում, պետք է այն տեղադրի լայն կանոնից վեր, իսկ ով խմբագրում է լայն կանոնը, կարող է ամբողջ ձևավորումը շրջել մեկ պահպանմամբ։ Գրեք նախատեսված հերթականությունը քաղաքականության կողքին և նորից ստուգեք այն որոնվածի թարմացումներից հետո, քանի որ ինտերֆեյսների անվանումը և քաղաքականությունների ցուցադրումը իսկապես փոխվում են տարբերակների միջև։

Ավարտեք ուղին գլխամասային գրասենյակում

Գլխամասային գրասենյակի թունելի քաղաքականությունը պետք է ընդունի այն երթևեկությունը, որն այժմ ընտրում է մասնաճյուղի ուղին։ Գլխամասային գրասենյակի մասնավոր LAN-ով սահմանափակված միջգրասենյակային ընտրիչը կամայական հանրային ուղղություններ կրելու թույլտվություն չէ, ուստի քաղաքականությանը պետք են մասնաճյուղի աղբյուրը և այն ուղղությունների շրջանակը, որը դուք իրականում նկատի ունեք։ Այնուհետև գլխամասային գրասենյակը փոխանցում է այդ ներգնա երթևեկությունը իր ինտերնետ uplink-ին իր սեփական մուտքի կանոններով, և SonicWall-ի կենտրոնական ելքի օրինակը ներառում է աղբյուրի թարգմանություն հեռավոր ցանցի համար կենտրոնական WAN-ում։ Առանց այդ թարգմանության հեռավոր կողմը տեսնում է մասնավոր մասնաճյուղի հասցե և դեպի այն վերադառնալու ուղի չունի։

Պատասխանները պայմանագրի մյուս կեսն են։ Նրանք պետք է վերադառնան թունելով կամ իրենց համար ստեղծված վիճակային թարգմանությամբ, և մասնավոր կայքերի երթևեկությունը կարող է տարբեր NAT մշակում պահանջել, քան հանրային ելքը։ Այդ կանոնները պահեք տարբերելի, քանի որ յուրաքանչյուր ներքին աղբյուր թաքցնող մեկ լայն թարգմանության կանոնը հետագա գրանցումն ու խնդիրների լուծումը շատ ավելի դժվար է դարձնում կարդալ։

Որոշեք, թե ինչ է անում խումբը, երբ թունելն ընկնում է

Եթե կենտրոնական ելքը պահանջ է և ոչ նախընտրություն, տեղական WAN-ին վերադառնալը համապատասխանության ձախողում է, նույնիսկ եթե օգտատերերը մնում են առցանց։ SonicOS-ը փաստագրում է թունելի ինտերֆեյսի գցմամբ ուղին որպես աջակցվող եղանակ՝ ընտրված երթևեկությանը չթույլատրելու անցանկալի այլընտրանքային ուղի վերցնել։

Համապատասխանեցրեք այդ ուղու շրջանակը և առաջնահերթությունը տեղադրված տարբերակին, և ստուգեք այն՝ իջեցնելով թունելը, այլ ոչ թե վստահելով պիտակին։ Խումբը, որը երբեք չպետք է տեղական դուրս գա, պետք է փակ ձախողվի, մինչդեռ խումբը, որտեղ հասանելիությունն ավելի կարևոր է, կարող է օրինականորեն հետ գնալ, երկուսն էլ որոշումներ են, և ոչ մեկը չպետք է տեղի ունենա լռելյայն։

Ստուգեք երեք հաճախորդից, ապա մաքուր հետ վերադարձեք

Կենտրոնական դարպասին ping-ը ստուգում է սխալ բանը, որովհետև այն սկիզբ է առնում ֆայրվոլից, ոչ թե ընտրված հաճախորդից։ Փորձարկեք սարքերից փոխարենը, և փորձարկեք դրանցից երեքը՝ ընտրված սարք, սովորական սարք, որը պետք է մնա տեղական, և մեկը, որը կախված է տեղական ծառայություններից։

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

Համեմատեք, թե որտեղ է հանրային հարցումն իրականում ի հայտ եկել։ Ընտրված հաճախորդը պետք է ինտերնետին հասնի գլխամասային գրասենյակի ելքով, իսկ սովորական հաճախորդը հեռավոր կողմում պետք է դեռ ներկայացնի մասնաճյուղի սեփական հասցեն, 203.0.113.10-ը փաստաթղթային հասցե է, որն օգտագործվում է ձեզ համար կարևոր ուղղության փոխարինող։ Ներառեք DNS-ը նույն անցումում, քանի որ մասնաճյուղի լուծիչին հարցնող հաճախորդը կարող է առաջացնել երթուղիչից սկիզբ առնող որոնում այլ աղբյուրով և հետևաբար այլ ուղիով։

Հետ վերադարձը պահպանված քաղաքականության հերթականությունն է գումարած հասցեների խումբը։ Վերականգնեք նախորդ հերթականությունը, հեռացրեք խումբը քաղաքականությունից և կրկին փորձարկեք սարքերի երկու դասերը։ Պահեք արտահանված կոնֆիգուրացիան փոփոխության գրառման հետ, քանի որ հաջորդ ինժեները պետք է իմանա, թե որ կանոնն էր լայնը նախքան ինչ-որ մեկը խմբագրել է այն։