VPN սերվերը նոր հանրային IP տեղափոխելը. ինչ ստուգել առաջինը
Տեղում փոխարինումը և զուգահեռ անցումը կոտրվում են տարբեր տեղերում. անցեք կարգավորումները, NAT-ը և վկայագրերը, ապա ստուգեք, թե ինչպես է յուրաքանչյուր հաճախորդ լուծում անունը։
Հասցեի վերանշանակումը տևում է մեկ րոպե. հաջորդ շաբաթն այն տեղն է, որտեղ տեղափոխումը կոտրվում է, և հազվադեպ այնտեղ, որտեղ հուշում է մատակարարի կոնսոլը։ Նոր հանրային IP-ն հիշատակվում է չորս տեղում՝ այն socket-ը, որի վրա լսում է դեմոնը, այն վստահության խարսխը, որը ստուգում են հաճախորդները, հին հասցեն անվանող յուրաքանչյուր կանոն, և այն DNS գրառումը, որը կապում է դրանք։ Երկու տեղափոխում կառավարման վահանակից նույն են երևում, բայց բոլորովին տարբեր են վարվում՝ հասցեն վերանշանակել ձեր կառավարած մեքենայի վրա, կամ երկրորդ endpoint կանգնեցնել և հաճախորդներին տեղափոխել դրա վրա։ Ստորև ստուգումները էժան ձախողումները դնում են առաջինը, և յուրաքանչյուր բաժին նշում է, թե որ տեղափոխմանն է վերաբերում։
Տեղում փոխարինումը և զուգահեռ անցումը տարբեր աշխատանքներ են
Տեղում փոխարինումը պահում է հոսթը, բանալիները, երթուղային աղյուսակը և օգտվողների ցանկը. փոխվում է միայն հասցեն։ Դա է անում լողացող IP-ի վերանշանակումը, և մի քանի մատակարարների մոտ հյուրը դա չի նկատում, որովհետև թարգմանությունը կատարվում է ինստանսի առջև։ Վերակառուցումը կամ մատակարարի վերանշանակումը ավելի կոպիտ է. հյուրը տեսնում է փոփոխությունը, և ամեն ինչ, որ հին արժեքը քեշ էր արել, իմանում է դրա մասին նույն պահին։
Զուգահեռ endpoint-ը երկրորդ հոսթն է, որը կատարում է նույն աշխատանքը։ Կառուցեք այն, փորձարկեք մեկ պրոֆիլով, և թողեք հինը պատասխանի, մինչև նորը իրեն ապացուցի իրական ուղու վրա։ Գինը վիճակն է։ Առանց ընդհանուր peer գրառումների, չեղարկումների և գրանցման՝ ունեք երկու ցանց, որոնք պատահաբար կիսում են անունը։
| Question | In-place swap | Parallel endpoint |
|---|---|---|
| Rollback in one step? | Only if you can get the old address back | Point DNS back; old host still up |
| Blast radius | Every client at once | Only the clients you moved |
| Best when | The address is yours to reassign | The old address is gone for good |
Գտեք բոլոր տեղերը, որտեղ գրված է հին հասցեն
Սկսեք տեքստային սկանավորմամբ, որովհետև կարգավորման ֆայլերը հեշտ կեսն են։ Փնտրեք դեմոնի կարգավորումում, ֆայրվոլի հատվածներում, մոնիտորինգի թիրախներում և սկավառակի վրա գեներացված ցանկացած հաճախորդային փաթեթում։ Ներառեք IPv6 հասցեն, եթե այդպիսին հրապարակում եք. միայն A գրառումը հետևող տեղափոխումը կրկնակի ստեկի հաճախորդներին թողնում է հին ուղու վրա։
OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpointsԱպա սկանավորեք միջուկը, որովհետև աշխատող համակարգը հասցեն պահում է այնպիսի տեղերում, որոնք ոչ մի ֆայլ չի հիշատակում։ Ստատիկ աղբյուրի NAT կանոնը, ipset գրառումը, bind հասցեն և conntrack գրառումը ապրում են ավելի երկար, քան դրանք հեռացրած կարգավորման խմբագրումը, և ոմանք վերապրում են նաև վերագործարկումը, որովհետև վերադարձել են պահված կանոնների հավաքածուից։ Մեկ շերտ վերևում մատակարարի անվտանգության խմբերը, բեռնվածքի հավասարակշռիչի թիրախները և մոնիտորինգի ստուգումները բոլորովին էլ ձեր ֆայլային համակարգում չեն։
Գրանցեք գույքագրումը նախքան որևէ բան փոխելը. այն նաև ծառայում է որպես հետադարձ սկրիպտ։
Հոսթանունով հաճախորդները վերականգնվում են. բառացի IP-ով հաճախորդները լռում են
Եթե հաճախորդները սերվերին հասնում են հոսթանունով, անցումը հիմնականում DNS խնդիր է, և երեկ դրած TTL-ը որոշում է, թե որքան վատ կլինի։ Լուծիչները քեշավորում են, stub լուծիչները նորից են քեշավորում, և շատ հաճախորդներ անունը փնտրում են միայն նոր միացման ժամանակ, այնպես որ հաստատված թունելը պահում է իր մեկնարկային հասցեն։
Եթե endpoint-ը բառացի հասցե է, ոչինչ նորից չի լուծվում և ոչինչ բողոք չի գրանցում։ WireGuard-ը պահում է լուծված socket հասցեն. Endpoint = vpn.example.net:51820-ը IP է դառնում այն պահին, երբ աշխատում է wg-quick up-ը, և մնում է այդ IP-ն, մինչև չփոխեք այն։ OpenVPN-ը ավելի ներողամիտ է. այն լուծում է remote հոսթանունը միացման պահին և resolv-retry infinite-ի հետ նորից փորձում DNS՝ վերամիացման ժամանակ։ Բառացի IP-ի դեպքում երկուսն էլ շարունակում են զանգահարել մի մեքենայի, որն այլևս չկա։
Մարդկանց մոլորեցնում է հայելային պատկերը։ Հաճախորդը, որն արդեն ուղղված է նոր հասցեին, մինչ հին լսողը դեռ պատասխանում է, անցնում է ձեր սեփական սեղանից արված բոլոր փորձարկումները։ Ինձ էլ են այդպես խաբել. նոր endpoint-ը հեռախոսում բարձրացավ առաջին փորձից, իսկ հին պրոֆիլով հաճախորդը հայտնվեց միայն այն ժամանակ, երբ հին լսողը շատ ավելի ուշ անջատվեց։
Վստահությունը հասցեի հետ չի տեղափոխվում
WireGuard-ը առանձնացնում է ինքնությունը հասանելիությունից, ինչը հասցեի տեղափոխումը գրեթե անվճար է դարձնում։ Peer-երը նույնացվում են հանրային բանալիով, և endpoint-ը միայն այն տեղն է, ուր փաթեթները հիմա գնում են. հոսթը թարմացնում է peer-ի endpoint-ը վերջին նույնականացված փաթեթի աղբյուրի հասցեից։ Անգործ peer-ին դեռ պետք է պատճառ՝ նոր տեղի հետ խոսելու համար, և նա հասցեն սովորում է միայն այն ժամանակ, երբ նրա սեսիան հնանում է, և handshake-ի կրկնափորձերը ձախողվում են տեսանելի տեղում։ WireGuard-ի արագ ուղեցույցը ընդգրկում է endpoint դաշտը։
TLS-ի վրա հիմնված սերվերները հակառակ դեպքն են։ Վկայագիրը կապված է անվան հետ, և հասցե հավաքող հաճախորդը համեմատում է հավաքածը սուբյեկտի այլընտրանքային անունների հետ։ Միացեք IP-ով վկայագրին, որը կրում է միայն DNS SAN, և ստուգումը ձախողվում է. հաճախորդի օգտագործած անունը վկայագրում չկա։ IP SAN-ով վերաթողարկումը ուղղում է այդ մեկ միացումը և վատացնում հաջորդ տեղափոխումը։ Պրոֆիլում հոսթանուն պահելը և verify-x509-name-ը տեղում թողնելը ստուգումը խիստ է պահում, մինչ ներքևի հասցեն փոխվում է։
Ապա ստուգեք, թե ինչին է կապված դեմոնը. հին հասցեին ամրացված socket-ը լուռ ձախողվում է։ local 203.0.113.10-ով սկսված OpenVPN սերվերը հրաժարվում է բարձրանալ, հենց որ այդ հասցեն անհետանում է, մինչ 0.0.0.0-ի վրա լսողը անվճար հետևում է փոփոխությանը։ NAT-ը նույն կերպ է բաժանվում. MASQUERADE-ը հետևում է, թե մեքենան հիմա ինչ հասցե ունի, իսկ ստատիկ SNAT --to-source 203.0.113.10-ը շարունակում է վերագրել մի հասցեի, որը դուք այլևս չեք տիրապետում, ուստի վերադարձի տրաֆիկը անհետանում է։ Եթե նոր հասցեն գալիս է այլ upstream դարպասով, ստուգեք rp_filter-ը. հակադարձ ուղու զտումը գցում է վերադարձի տրաֆիկը, որը հասնում է ինտերֆեյս, որը միջուկը չէր սպասում։
Անցման հերթականությունը և ապացույցը, որ այն աշխատեց
Մեկ օր առաջ իջեցրեք TTL-ը, կանգնեցրեք նոր լսողը և ապացուցեք այն պրոֆիլով, որը միայն դուք ունեք։ Նույն ցանցի ներսից արված փորձարկումը գրեթե ոչինչ չի ապացուցում, ուստի օգտագործեք բջջային ցանցի հեռախոս և փորձարկեք մի բան, որը թունելը պետք է տանի, այլ ոչ թե ping դեպի endpoint։
Ամբողջ պատուհանի ընթացքում հետևեք երկու հասցեներին։ wg show all latest-handshakes-ը նոր հոսթի վրա, կամ OpenVPN-ի կարգավիճակի ֆայլը, ասում է, թե իրականում քանի peer է տեղափոխվել։ Երբ նոր endpoint-ն ունի սպասված peer-երը, իսկ հինը՝ միայն հետ մնացածները, հանեք հին լսողը շահագործումից, հեռացրեք հնացած NAT կանոնը և հանեք հասցեն մատակարարի ֆայրվոլից։ Հին լսողի հեռացումը այն քայլն է, որը բաց է թողնվում, և այն փակում է այն ճեղքը, որտեղ հնացած պրոֆիլը դեռ հասնում է հին ցանց։
Նախքան սկսելը գրավոր սահմանեք հետադարձի ձգանը. եթե պայմանավորված պատուհանից հետո նոր endpoint-ը ոչ մի իրական հաճախորդից handshake չի ստանում, վերականգնեք հին հասցեն և դադարեցրեք պրոֆիլների բաշխումը։ Դրանից հետո նորից գործարկեք սկանավորումը և հաստատեք, որ ոչ մի լսող դեռ կապված չէ դուրս բերված հասցեին։ Երկու բան անցնում է հաջորդ տեղափոխմանը. հաճախորդի պրոֆիլում հոսթանուն, որպեսզի հաջորդ փոփոխությունը DNS խմբագրում լինի, և սերվերի վերականգնման նշումների կողքին պահված գույքագրումը։