Փոխել պրովայդերին առանց կայքի VPN հասցեները վերահամարակալելու

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

Երկու հասցեային պլան, որոնք շարժվում են ինքնուրույն

Ներքին պլանը նկարագրում է մասնավոր հասցեները, որոնք օգտագործում են հավելվածները՝ մասնաճյուղի սերվերը 10.55.8.20 հասցեում, գլխամասի նախածանցը, որը երթուղավորում է դեպի այն, և վերադարձի ուղին: Արտաքին պլանը նկարագրում է, թե ինչպես են երկու դարպասներ հասնում միմյանց՝ զուգընկերի հասցեներ, լսող պորտեր և ուղին ինտերնետով:

Մատակարարի փոփոխությունը դիպչում է արտաքին պլանին: Այն ինքնին չի պահանջում ներքին պլանի փոփոխություն:

Երկու գույքագրերը առանձին պահելը գործնական պատճառն է overlay վարելու նույնիսկ այն դեպքում, երբ հավելվածն արդեն ինքն է գաղտնագրում իր թրաֆիկը: Overlay-ը ձեզ տալիս է կայուն ներքին տոպոլոգիա, որը դիմանում է արտաքին փոփոխություններին: Հավելվածը պահում է իր հասցեն, firewall-ի կանոնները և DNS գրառումները: Փոխվում են միայն տրանսպորտի գրառումները, և դա շատ ավելի փոքր վերանայում է:

Արտաքին թունելը տանում է ներքին զրույցը

Դարպաս-դարպաս թունելում արտաքին IP վերնագիրը հասցեավորում է երկու դարպասներին: Ներքին վերնագիրը դեռ նշում է հավելվածի իրական վերջնակետերը: RFC 7296-ի դարպաս-դարպաս նկարագրությունը սա դիտարկում է որպես սովորական երթուղավորում, որը թրաֆիկը հասցնում է թունելի վերջնակետերով:

Այդ պատճառով մասնաճյուղի սերվերը կարող է պահել 10.55.8.20-ը, մինչ դարպասի հանրային հասցեն փոխվում է: Ներքին փաթեթը բնավ չի պարունակում մատակարարի հասցեն:

Բաժանումը նախագծի հատկություն է, ոչ ավտոմատ երաշխիք: Եթե փոխարինող վերին կապը չի կարող կառուցել աջակցվող թունելը, կամ ներքին երթուղիները չեն վերատեղադրվում, հավելվածը կորցնում է իր ուղին, թեև հասցեն անփոփոխ է:

Մատակարարի տեղափոխումը դեռ ունի ստուգաթերթ

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

Դրանից հետո ստուգեք մասնաճյուղի նախածանցը, երկու ուղղությունների երթուղին, պաշտպանության քաղաքականությունը և մեկ իրական հավելվածային հոսք: Նոր հաստատված թունելը չի շտկում հին մասնավոր ենթացանցին ուղղված երթուղին:

Հասցեների համընկնումը մեկ այլ միացված կայքի հետ առանձին պլանավորման խնդիր է: Մատակարարի փոփոխությունը այն չի ստեղծում, բայց միգրացիան սովորաբար այն պահն է, երբ այն ի հայտ է գալիս:

Ինչ չի գոյատևում՝ հանրային աղբյուր և սեսիաներ

Կայուն մասնավոր սերվերի հասցեն կայուն հանրային աղբյուր չէ: Եթե զննարկումը դուրս է գալիս ուղղակիորեն նոր մատակարարի միջով, կայքերը տեսնում են նոր՝ մատակարարին ուղղված հասցեն:

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

Հաստատված սեսիաները նույնպես չեն գոյատևում ուղու փոփոխությունը: Թունելը կարող է վերականգնվել վայրկյանների ընթացքում և այնուամենայնիվ կտրել հին ուղուն ամրացված երկարաժամկետ կապերը: Պլանավորեք փոխարկումը մի պատուհանի համար, որտեղ վերամիացումները ընդունելի են: Մի պնդեք, որ միգրացիան անտեսանելի կլինի, եթե կոնկրետ հաճախորդները և նրանց ժամկետները չեն փորձարկվել:

Հաստատեք տեղափոխումը չորս ստուգումներով

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

Linux դարպասի վրա այս երեքը ծածկում են այդ ցանկի միջնամասը:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

Տրանսպորտի հասցեները պահեք մեկ գույքագրում, իսկ հավելվածի հասցեները՝ մյուսում: Թարմացրեք միայն այն գրառումները, որոնք իսկապես տեղափոխվել են: Ներքին կախվածությունների վերահամարակալումը թունելի արտաքին հասցեի փոփոխության պատճառով խուսափելի աշխատանք է: