Աստղ, թե լրիվ ցանց՝ ո՞ր VPN տոպոլոգիան է համապատասխանում ձեր տեղամասերին

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

Ամենից առաջ հաշվեք հավասարակիցների հարաբերությունները

N տեղամասերի դեպքում լրիվ ցանցին անհրաժեշտ է N անգամ N հանած մեկ, բաժանած երկուսի, թունել; աստղին՝ N։ Հինգ տեղամասում դա հինգի դիմաց տասն է, ինչը դեռ կառավարելի է թվում։ Տասնհինգում դա տասնհինգի դիմաց 105 է, և տարբերությունն արդեն ոչ թե թվաբանություն է, այլ անձնակազմ։

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

Թող որոշի տրաֆիկի խառնուրդը, ոչ թե նկարը

Եթե մասնաճյուղերի տրաֆիկը հիմնականում հարցումներ են կենտրոնական ERP-ին կամ ֆայլերի կլաստերին, աստղը փոխզիջում չէ, այն ճիշտ ձևն է՝ տրաֆիկն արդեն ուզում էր գնալ այնտեղ, և մեկ քաղաքականության կետն ավելի հեշտ է աուդիտ անել, քան զույգային կանոնների ցանցը։ Ցանցը արժանի է իր բարդությանը, երբ մասնաճյուղերը տվյալներ են փոխանակում միմյանց հետ՝ երկու գրասենյակների միջև կրկնօրինակում, տեղամասերի միջև ձայն, CAD-ի համօգտագործում, որը տասնյակ ինժեներներ ամբողջ օր բացում են։

Անհարմար դեպքերը մեջտեղում են, և դրանք մեծամասնությունն են։ Չափեք վիճելուց առաջ, փոխանակ կազմակերպության գծապատկերից գուշակեք։

Կարդացեք աղյուսակը որպես վճռող, ոչ որպես կանոն։ Չորս տողերից երեքը մեկ ուղղությամբ սովորաբար որոշում է նախագիծը՝ բաժանումը նշանակում է հիբրիդ, ինչին հասուն ցանցերի մեծ մասը ամեն դեպքում գալիս է։

Աստղին պետք է ասել, որ փոխանցի

Երկու աշխատող ճառագայթ-աստղ թունելներ չեն ստեղծում ճառագայթ-ճառագայթ հասանելիություն։ Աստղին անհրաժեշտ է միացված IP փոխանցում, երթուղի յուրաքանչյուր ճառագայթի ցանցին, հրային պատի կանոն, որը թույլ է տալիս տրանզիտը, և հաշվարկված վերադարձի ուղի՝ յուրաքանչյուր ճառագայթի անհրաժեշտ է երթուղի մյուս տեղամասի նախածանցերի համար։ Linux աստղի վրա դա net.ipv4.ip_forward=1 գումարած FORWARD շղթա է, որը լուռ չի գցում զույգը, և քաղաքականության վրա հիմնված IPsec-ում դրանք տրաֆիկի ընտրիչներ են, որոնք երկու ծայրերում թվարկում են հեռավոր ճառագայթի ենթացանցը։ strongSwan-ում փոխանցման նշումները ծածկում են միջուկի և հրային պատի կողմը, երբ հենց այդ շերտն է ձեզ պակասում։ Էժան փորձություն է տրաֆիկ ուղարկել մեկ ճառագայթից մյուսի ծառայությանը և դիտել աստղի հաշվիչները՝ կանոնը, որը երբեք չի ավելանում, նշանակում է, որ հերթականությունը սխալ է, ոչ թե երթուղին։

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

Զգուշացեք կիսատ տարբերակից՝ ճառագայթ A-ն աստղի միջով երթուղավորում է ճառագայթ B-ին, աստղը երթուղավորում է երկու ուղղությամբ, և աստղի հրային պատը թույլ է տալիս նոր միացումներ A-ից, բայց ոչ B-ից։ Առաջին ուղղությունը լավ է փորձարկվում, իսկ երկրորդը կախվում է, ինչը նման է երթուղավորման խափանման և այդպիսին չէ։

Նախ նախագծեք խափանումը, ապա՝ սովորական ուղին

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

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

Նախագծերից ոչ մեկը ինքնուրույն TCP սեանսը կենդանի չի պահում անցման ողջ ընթացքում։ Եթե հավելվածը չի կարող նորից միանալ, տոպոլոգիան ձեր խնդիրը չէ։

Ընտրեք փոփոխության արժեքով, ապա ստուգեք երթուղիները

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

Ապա ստուգեք երկու նկարը, ոչ թե մեկը։ Սովորական ուղու համար, traceroute յուրաքանչյուր տեղամասից յուրաքանչյուր ծառայության նախածանց և հաստատեք, որ թռիչքները համապատասխանում են գծապատկերին։ Խափանման ուղու համար անջատեք մեկ թունել և կրկնեք, որովհետև երթուղին, որն աշխատում է միայն այն ժամանակ, երբ ամեն ինչ միացված է, նախագծված չէ, միայն կարգավորված։

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