Երկրորդ WAN VPN մուտքը ձախողվում է, մինչ առաջնայինը շարունակում է աշխատել

Առաջնային թունելը մնում է բարձրացված, օգտատերերը շարունակում են աշխատել, և երկրորդ ISP շղթան անգործ մնում է, ինչ էլ փոխեք։ Դուք հրապարակել եք հասցե պահուստային շղթայի համար, անուն եք ուղղել դրան, գուցե պահուստային գրառում ավելացրել հաճախորդին, և հաճախորդը կամ երբեք չի փորձում այն, կամ նույնականացվում է և հետո մեռնում։ Իմ հետևած դեպքերում failover-ի ֆունկցիան սովորաբար կարգին էր. պակասում էր այն հինգ բաներից մեկը, որոնք գրառումը դարձնում են օգտագործելի։ Անունը կարող է լուծվել պահուստային հասցեի, մինչ այդ ինտերֆեյսում ոչինչ չի լսում, և լսողը կարող է ընդունել կապակցում, մինչ պատասխանը դուրս է գալիս առաջնայինով։ Վերաբերվեք յուրաքանչյուր WAN-ին որպես առանձին գրառում՝ իր պայմանագրով, և խափանումը դադարում է հաճախորդի սխալ թվալ։

Յուրաքանչյուր WAN ունի իր մուտքի պայմանագիրը

Գրանցեք հինգ դաշտ յուրաքանչյուր WAN-ի համար՝ հանրային անունը և հասցեն, տրանսպորտը և պորտը, այն ինտերֆեյսը կամ կոնտեքստը, որը վերջացնում է այն, գործընկերոջ ինքնությունը, որը պետք է ներկայացնի, և որտեղից է դուրս գալիս պատասխանը։ Երկու շղթա նշանակում է երկու ամբողջական հավաքածու։ Եթե երկրորդ հավաքածուն չունի վերջացնող ինտերֆեյս կամ վերադարձի ուղի, դուք պահուստային գրառում չունեք. ունեք DNS գրառում, որը նկարագրում է մտադրություն։

Սարքը և դրա տարբերակը նույնպես պետք է աջակցեն այս դասավորությանը։ DNS գրառումը չի կարող ծառայություն բացել մեկ այլ ինտերֆեյսում, և շատ պլատֆորմներում լսողը կարգավորվում է ըստ հասցեի, ոչ ըստ սարքի։ ASA-ում ինտերֆեյսի վրա հիմնված IPsec-ը կապում է կրիպտոքարտեզները և թունելային խմբերը արտաքին ինտերֆեյսին, ուստի երկրորդ uplink-ին անհրաժեշտ է քաղաքականություն այնտեղ, որտեղ այդ փաթեթները իրոք հասնում են։ Երթուղու վրա հիմնված ձևավորումները այլ կերպ են վարվում. լսողը կարող է կապվել յուրաքանչյուր հասցեի կամ մեկ անվանված հասցեի, և այդ ընտրությունը որոշում է՝ ISP B-ն ընդհանրապես կարո՞ղ է պատասխանել։

Ստուգեք, որ երկրորդ WAN-ը իսկապես պատասխանում է

Փորձարկեք երկու շղթաների դրսից, ոչ դարպասի հետևի մեքենայից, և փորձարկեք հենց այն անունը, որն օգտագործում է հաճախորդի պրոֆիլը։ TLS լսողի համար արագ ստուգումը openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts է՝ գործարկված ձեր ցանցից դուրս գտնվող հոսթից։ Դուք ուզում եք ավարտված ձեռքսեղմում, որի շղթան համապատասխանում է պրոֆիլի անվանը, ոչ թե պարզապես TCP պորտ, որն ընդունում է կապակցում։

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

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

Հետևեք պատասխանին, ոչ միայն հարցումին

Երկրորդ WAN-ը սովորաբար կոտրվում է վերադարձի ճանապարհին։ Հարցումը գալիս է ISP B-ով, սարքը պատասխանում է, և պատասխանը դուրս է գալիս ISP A-ի լռելյայն երթուղով՝ աղբյուրի այնպիսի հասցեով, որը հաճախորդը երբեք չի խնդրել։ Վիճակով թարգմանությունը վատացնում է այն. եթե քարտեզագրումը կառուցվել է առաջնային ինտերֆեյսի համար, վերադարձող փաթեթը բաց է թողնում թարգմանությունը կամ կրում է աղբյուր, որը հաճախորդի հրապատը գցում է։ Մատակարարները նույնպես գցում են աղբյուրի հասցեներ, որոնք չեն պատկանում իրենց տված շղթային, դրա համար էլ սա միակողմանի սև խոռոչ է թվում, ոչ թե մաքուր արձանագրային սխալ։

Ստուգեք երթուղային որոշումը երկրորդ գրառումից սկիզբ առնող երթևեկության համար։ Պատասխանը պետք է դուրս գա այն ինտերֆեյսից, որով եկել է հարցումը, կամ գոնե կրի հասցե, որը հեռավոր կողմն ընդունում է որպես այդ ուղուն պատկանող։ Քաղաքականությամբ երթուղավորման պլատֆորմներում դա նշանակում է մուտքային ինտերֆեյսին կամ թարգմանված աղբյուրին կապված կանոն, գումարած յուրաքանչյուր արտաքին ինտերֆեյսին կապված թարգմանության հայտարարություն։ Գրանցեք միաժամանակ երկու ինտերֆեյսում, մինչ հաճախորդը միանում է. ISP B-ով եկող SYN-ը և ISP A-ով դուրս եկող SYN-ACK-ը մեկ վազքով լուծում են հարցը։

Տվեք հաճախորդին երկրորդ գրառումն իմանալու միջոց

Failover-ը հաճախորդի կողմի որոշում է, և յուրաքանչյուր հաճախորդային ընտանիք այլ կերպ է իմանում այլընտրանքների մասին։ ASA-ում պահուստային սերվերների ցանկը տրամադրվում է խմբային քաղաքականության webvpn ատրիբուտներով, մինչ այլ հաճախորդներ սպասում են պրոֆիլի ներսում ցանկի կամ օգտատիրոջ ընտրած ձեռքով երկրորդ պրոֆիլի։ Cisco-ի կապի քաղաքականության ուղեցույցը նկարագրում է և՛ հաճախորդում կարգավորված, և՛ դարպասի տրամադրած պահուստային տեղեկատվությունը, և այդ արձանագրային մանրամասները չպետք է ընդհանրացվեն յուրաքանչյուր հաճախորդի կամ թունելի ռեժիմի վրա։ Հաստատեք, թե տեղակայված հաճախորդն ինչ մեխանիզմ է իրականացնում, նախքան երկրորդ գրառումը սխալի շուրջ կառուցելը։

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

Մեկ հասցե երկու մատակարարի մոտ այլ ապրանք է

Մեկ հանրային հասցեն երկու շղթաներով հասանելի պահելը երթուղավորման ծառայություն է, ոչ թե VPN-ի նշատուփ։ Այն պահանջում է հասցեային տարածք, որը երկու մատակարարներն էլ պատրաստ են կրելու, հայտարարված այնպես, որ նրանց ցանցերն ընդունեն, և դա է տալիս մատակարարից անկախ տարածքով և BGP-ով բազմակի միացումը։ ISP A-ի հասցեն ISP B-ի ինտերֆեյսին նշանակելը այնտեղ չի հասցնում. փաթեթը հասնում է ցանց, որը երբեք չի հայտարարել նախածանցը, և վերևում գցվում է։

Երկու գրառում հրապարակելու համար ձեզ այս ոչ մեկը պետք չէ։ Եթե հաճախորդը կարող է պահել երկու անուն և անցում կատարել նրանց միջև, երկու անկախ գրառումը բավական է, և դուք խուսափում եք AS համարից, peering պայմանավորվածությունից և ամենուր ընդունելի նախածանցից։ Դիտարկեք տեղափոխվող հասցեի տարբերակը միայն այն դեպքում, երբ իսկապես պետք է մեկ կայուն մուտքի կետ, որը հնարավոր չէ փոխարինել հաճախորդներին վերակարգավորելով, կամ երբ DNS-ի վրա հիմնված failover-ը իր TTL ուշացումով չափազանց դանդաղ է այն ընդհատման համար, որի դեմ նախագծում եք։

Ինչ ստուգել հաջորդիվ

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

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