Ինչպես չափել հասցեային տարածությունը կայք-կայք VPN-ի համար

Հարցրեք, թե որքան մեծ պետք է լինի VPN-ի ենթացանցը, և անկեղծ պատասխանն այն է, որ հարցի մեջ կարող են թաքնված լինել չորս տարբեր ենթացանցեր։ Կայքի VPN-ը կարող է ներառել տրանսպորտի վերջնակետեր, համարակալված թունելային կապեր, պաշտպանված LAN-ի նախածանցեր և կառավարվող դարպասներում մատակարարի կողմից վերապահված ենթակառուցվածքային ենթացանց։ Տվյալ նախագծում դրանցից գոյություն ունեն միայն մեկը կամ երկուսը։ Դրանք գրասենյակային սարքերի քանակից չափելը այն ուղին է, որով ծրագիրը ավարտվում է ոչ մեկին չբավարարող /24-ով։

Անվանեք չորս դերերը, նախքան ինչ-որ բան հատկացնելը

Տրանսպորտի վերջնակետերը այն հասցեներն են, որոնք երկու դարպասներ օգտագործում են միմյանց հասնելու համար ինտերնետի կամ մասնավոր գծի միջոցով, և դրանց թիվը գալիս է դարպասի և ավելորդության մոդելից, ոչ թե LAN-ից։ Ներքին թունելային կապեր գոյություն ունեն միայն այնտեղ, որտեղ նախագիծը համարակալում է կետ-կետ ինտերֆեյս, ինչը քաղաքականության վրա հիմնված IPsec կազմաձևը սովորաբար չի անում։ Պաշտպանված նախածանցերը իրական գրասենյակային կամ VPC ցանցերն են, որոնք պետք է ուղղորդելի լինեն, իսկ մատակարարի վերապահված ենթացանցը պատկանում է կառավարվող ծառայությանը։

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

ip -br addr show
ip route show | head -40

Այդ երկու հրամանները տալիս են միացված ցանցերի և դրանցից այն կողմ ամեն ինչին հասնող ուղիների տեղական պատկերը։ Կրկնեք գույքագրումը յուրաքանչյուր կայքում, քանի որ մեկ կայքի ելքի վրա կառուցված ծրագիր կբախվի հաջորդի ելքի հետ։ Հավաքեք ելքերը նախքան մեկ բլոկ հատկացնելը։

Հաշվեք կապերն ու տոպոլոգիան, ոչ թե սարքերը

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

Մատակարարի սահմանափակումները գերազանցում են ընդհանուր պրակտիկային։ Փաստաթղթավորված ներքին թունելային տիրույթը կարող է պահանջել /30 նույնիսկ այնտեղ, որտեղ /31-ը աշխատում է ձեր երթուղիչներում, իսկ կառավարվող դարպասը կարող է պահանջել որոշակի դիմակ իր ենթացանցի համար։ Կարդացեք ծառայության պահանջը նախքան մեկ այլ հարթակից փոխառված կանոն կիրառելը։

Բազմակետ ծածկույթը նորից փոխում է թվաբանությունը․ մեկ հասցե յուրաքանչյուր դարպասի համար, և ծածկույթը հոգում է նրանց միջև հասանելիության մասին։ Որոշեք, թե իրականում որ տոպոլոգիան է օգտագործում ներդրումը, նախքան կայքերը բլոկի չափով բազմապատկելը։

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

Դարպասի ենթացանցը պահեք LAN-ի ավազանից դուրս

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

Նույնը վերաբերում է ամպային VPN միացումների թունելային տիրույթներին, որտեղ մատակարարը յուրաքանչյուր թունելի համար փոքր ներքին տիրույթ է հատկացնում իր իսկ օգտագործման համար։ Այդ տիրույթը այն տեղը չէ, որտեղ ապրում են ձեր մասնաճյուղի սերվերները, և այն ձերը չէ, որ բաժանեք։

aws ec2 describe-vpn-connections --query "VpnConnections[].{Id:VpnConnectionId,Tunnels:Tunnels[].OutsideIpAddress}" --output table

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

Գրանցեք դերը, սեփականատերը և աճը յուրաքանչյուր նախածանցի համար

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

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

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