Sophos RED-ի ո՞ր ռեժիմն է հարմար ձեր մասնաճյուղի ցանցին։
RED-ը հեռավոր տեղամասի դեր է, ոչ թե արձանագրություն։ Ընտրեք Standard/Unified, Standard/Split կամ Transparent/Split՝ կախված նրանից, թե ում է պատկանում մասնաճյուղի դարպասը և DHCP-ն։
Sophos RED-ը հեռավոր տեղամասի դեր է, ոչ թե VPN արձանագրություն, և այդ պատճառով այն IPsec-ի կամ OpenVPN-ի հետ համեմատելը պատասխանում է սխալ հարցին։ Սարքը կենտրոնական հրապատի վերահսկողությունը տարածում է մասնաճյուղի վրա, և ձեր ընտրած ռեժիմը որոշում է, թե ով է ապահովում մասնաճյուղի դարպասը, ով է բաշխում հասցեները և որ երթևեկությունն է անցնում թունելով։ Այս երեք պատասխանները ավելի կարևոր են, քան ռեժիմների անունները։ Դրանք նախապես գրառելը արտադրանքի ընտրությունը վերածում է ձևավորման որոշման։
RED-ը դեր է, ոչ թե արձանագրություն
RED սարքը մասնաճյուղը միացնում է կենտրոնական Sophos Firewall-ին, և հրապատի կոնֆիգուրացիան է որոշում, թե ինչի է վերածվում մասնաճյուղը։ Թունելը այդ միացման իրականացման մանրամասն է, ոչ թե ընդհանուր նպատակի VPN վերջնակետ, որը կարելի է ուղղել ցանկացած զուգընկերոջ։
Այս ձևակերպումը կարևոր է, որովհետև RED-ը փոխարինելի չէ կամայական IPsec զուգընկերոջ հետ։ Այն ակնկալում է, որ կենտրոնական հրապատը կկառավարի այն, և աջակցվող ռեժիմները նկարագրում են, թե մասնաճյուղի որ մասն է այն վերցնում։ Այն որպես սովորական թունելի վերջնակետ դիտարկելը ստեղծում է ակնկալիքներ, որոնք արտադրանքը երբեք չի խոստացել։ Այն որպես դեր դիտարկելը ծնում է այն հարցերը, որոնք իսկապես որոշում են ձևավորումը։
Ստորև բերված երեք պայմանները փոխում են պատասխանը, և բոլորն էլ սեփականության մասին են, ոչ թե գաղտնագրման։
Երեք պայման, որոնք ընտրում են ռեժիմը
Հարցրեք, թե ում է պատկանում մասնաճյուղի դարպասը, ով է վարում DHCP-ն և DNS-ը մասնաճյուղի հաճախորդների համար, և արդյոք տեղական ինտերնետ ելքը պետք է վերապրի թունելի խափանումը։
Standard/Unified-ը երեքին էլ նույն կերպ է պատասխանում՝ կենտրոնական հրապատն ունի մասնաճյուղի տեղական ցանցը, ներառյալ դարպասի և DHCP-ի պարտականությունները, և երթևեկությունն անցնում է թունելով։ Standard/Split-ը պահպանում է կենտրոնական կառավարումը և թունելով ուղարկում միայն կարգավորված ցանցերը։ Transparent/Split-ը թողնում է գոյություն ունեցող մասնաճյուղի ցանցին կառավարել իր դարպասը և հասցեները, և թունել է ուղղում միայն ընտրված երթևեկությունը։ Երեք ռեժիմ, երեք տարբեր սեփականատեր։
| Mode | Branch gateway and DHCP | Traffic through the tunnel |
|---|---|---|
| Standard/Unified | Central firewall owns both | All branch traffic |
| Standard/Split | Central firewall owns both | Only the configured networks |
| Transparent/Split | The existing branch router keeps both | Only the selected flows |
Նախ կարդացեք միջին սյունակը, որովհետև այն է որոշում, թե մասնաճյուղի որ մասն է դեռ աշխատում, երբ թունելը բացակայում է։
Ում են պատկանում մասնաճյուղի դարպասը և DHCP-ն
Միասնական դասավորության մեջ մասնաճյուղը ինքնուրույն դարպաս չունի, ինչը պարզեցնում է կոնֆիգուրացիան և կենտրոնացնում խափանումը։ Այդ կենտրոնացումը լավ է, երբ մասնաճյուղը փոքր է, իսկ կենտրոնական հրապատը՝ բարձր հասանելիության։
Թափանցիկ տեղակայման դեպքում մասնաճյուղը պահում է իր երթուղիչը, իսկ RED-ը տեղադրվում է ուղու մեջ՝ ընտրված երթևեկությունը վերահասցեավորելու համար։ Դա պահպանում է տեղական վերահսկողությունը և ավելացնում սարք, որի դիրքը ուղու մեջ այժմ կարևոր է յուրաքանչյուր վերահասցեավորված հոսքի համար։ Փաստագրեք, թե որտեղ է այն նստում, որովհետև մասնաճյուղի երթուղիչի հետագա փոփոխությունը կարող է լուռ շրջանցել այն։ Դասավորություններից ոչ մեկը ընդհանուր առմամբ չի հաղթում. նրանք տարբեր կերպ են բաշխում պատասխանատվությունը։
Հասցեների սեփականությունը այն մասն է, որ պետք է գրառել, որովհետև մեկ սեգմենտում երկու DHCP սերվեր առաջացնում են ընդհատվող խափանումներ, որոնք հաղորդվում են որպես VPN խնդիրներ։
Ինչ է պատահում, երբ թունելն ընկնում է
Split ռեժիմի աշխատանքը հաճախ ընթերցվում է որպես խոստում, որ տեղական ինտերնետը շարունակում է աշխատել թունելի խափանման ընթացքում, և այդ ընթերցումը անվտանգ չէ։ Ճշգրիտ վարքը կախված է ընտրված ռեժիմից, որոնվածից և սարքից, ուստի դրա տեղը ընդունման չափանիշներում է, ոչ թե ենթադրության մեջ։
Որոշեք, թե մասնաճյուղը թունելից առանց դեռ ինչ պետք է անի՝ հասնի տեղական տպիչներին, լուծի անունները, ընդունի վճարումներ, թե ոչինչ։ Ապա այդ վիճակը դիտավորյալ փորձարկեք՝ արգելափակելով թունելը և դիտելով մասնաճյուղը։ Մասնաճյուղը, որը լուռ կորցնում է DNS-ը, ավելի վատ է, քան այն, որը բարձրաձայն ձախողվում է, որովհետև աջակցության զանգը գալիս է ժամեր անց։ Գրանցեք դիտարկված արդյունքը ձևավորման արձանագրության մեջ։
Կենտրոնական կախվածությունը նույնն է բոլոր ռեժիմներում՝ ինչ-որ մեկը պետք է տիրապետի հենց սարքի վերականգնման ուղուն։
Գրեք մասնաճյուղի պայմանագիրը տեղակայումից առաջ
Մասնաճյուղի պայմանագիրը տեղավորվում է մեկ էջում՝ սեփականատերեր, հասցեների աղբյուրներ, թունելով անցնող նախածանցեր, ելքի քաղաքականություն և ձեր ընդունած խափանման վարքը։
Ապա ստուգեք տեղակայված արդյունքը, ոչ թե նախատեսվածը։ Ստուգեք մասնաճյուղի հաճախորդի հասցեն, նրա լռելյայն դարպասը, թե որ նախածանցերն են լուծվում թունելով և ինչն է դեռ պատասխանում, երբ թունելը արգելափակված է։ Համատեղելիությունը, հասանելիությունը և լիցենզավորումը բոլորը պետք է ստուգվեն մատակարարի ընթացիկ փաստաթղթերի դեմ՝ ճշգրիտ մոդելի համար, որովհետև արտադրանքի անունը չի երաշխավորում ռեժիմ։ Պահեք այդ էջը սարքի գրառման հետ, որպեսզի հաջորդ ինժեները ժառանգի որոշումները, ոչ թե սխեման։
ip -br addr
ip route
traceroute -n 10.80.4.10
dig +short intranet.corp.exampleԿրկնեք այդ բլոկը արգելափակված թունելով, և երկու գործարկումների տարբերությունը հենց այն խափանման վարքն է, որ դուք իրականում գնել եք։