Azure P2S. VNet-ի փոփոխությունից հետո Windows-ի մեկ հաճախորդի երթուղիները կորչում են

Երկու նոթբուք նույնականացվում են նույն Azure point-to-site դարպասի մոտ, և միայն մեկը հասնում է նոր միացված VNet-ին։ Երկուսն էլ ցույց են տալիս Connected, ուստի նույնականացումը տարբերությունը չէ. տարբերությունը նպատակակետ երթուղիներն են։ Սկսեք ձախողվող հաճախորդից, համեմատեք մեկ նպատակակետ և միայն դրանից հետո որոշեք՝ բացը դարպասի փաթեթի՞ն է պատկանում, թե՞ տեղական երթուղիների աղյուսակին։

Սկսեք ձախողվող հաճախորդից, ոչ թե դարպասից

Հաստատեք տոպոլոգիան նախքան նոթբուքին մեղադրելը։ Ստուգեք, թե որ VNet-երն են միացված դարպասի VNet-ին և արդյոք նոր ցանցը ուղղակիորեն peered է, թե հասանելի է առանձին site-to-site թունելով։ Եթե նոր VNet-ը բացարձակապես միացված չէ դարպասի VNet-ին, ոչ մի հաճախորդի փաթեթ չի կարող երթուղավորել դեպի այն, և աշխատող նոթբուքը հենց այն անոմալիան է, որը պետք է բացատրվի։ Գրեք պատասխանը, որովհետև այն որոշում է՝ հաճախորդի՞ն եք վրիպազերծում, թե՞ դարպասը։

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

Համեմատեք մեկ նպատակակետ route print-ով

Ընտրեք թույլատրված ռեսուրսի IP և համեմատեք երկու նոթբուքերը երկու անգամ՝ անջատված, ապա միացված։ Windows-ում route print -4 թվարկում է IPv4 երթուղիները նպատակակետի նախածանցով, ինտերֆեյսով, հաջորդ ցատկով և մետրիկայով։ Գրանցեք այն տողը, որը իրականում կհաղթի այդ նպատակակետի համար՝ VPN բառը պարունակող գրառումները հաշվելու փոխարեն։

Ընտրությունը սկզբում ամենաերկար նախածանցով է, ապա մետրիկայով, ուստի ավելի կոնկրետ տեղական երթուղին կարող է հաղթել թունելի երթուղուն՝ առանց սխալ թվալու։ Եթե նախատեսված նպատակակետը 10.24.0.0/16-ի սահմաններում է, առողջ հաճախորդը ցույց է տալիս համապատասխան երթուղի VPN ինտերֆեյսում, մինչդեռ ձախողվող հաճախորդը նույն հասցեն ուղարկում է իր լռելյայն դարպասին։

Հակասող տեղական նախածանցը կարող է առաջացնել նույն ախտանիշը։ Նախքան որևէ բան ավելացնելը, որոշեք, թե երկու դեպքերից որն ունեք՝ ընդհանրապես թունելի երթուղի չկա՞, թե՞ թունելի երթուղին պարտվում է ավելի կոնկրետին։

TTL expired-ը երթուղիների բաշխման սխալ չէ

Ping-ը, որը վերադարձնում է TTL expired in transit, ասում է, որ փաթեթը սպառել է իր ցատկերի քվոտան, ինչը սովորաբար նշանակում է փոխանցման օղակ, այլ ոչ թե կոտրված VPN դրայվեր։ Windows-ի ping-ը ընդունում է TTL մինչև 255, և արժեքը բարձրացնելը օղակը չի վերանորոգում. այն միայն հետաձգում է նույն սխալը։ Ընկալեք հաղորդագրությունը որպես ուղու ախտանիշ, ոչ որպես ապացույց երթուղիների բաշխման մասին։

Օգտագործեք tracert -4 10.24.1.10՝ տեսնելու, թե որտեղ է ուղին կրկնվում։ Եթե նույն երկու ցատկերը հայտնվում են նորից ու նորից, փնտրեք երթուղի, որը թունելին ուղղված տրաֆիկը հետ է ուղարկում թունել կամ տեղական երթուղիչ, որը վերադարձնում է այն։

Վերաստեղծեք փաթեթը այն դարպասի վրա, որը տիրապետում է դրան

Microsoft-ը փաստագրում է, որ Windows-ի հաճախորդի փաթեթները պետք է կրկին ներբեռնվեն և տեղադրվեն համապատասխան տոպոլոգիական փոփոխություններից հետո։ Վերցրեք ընթացիկ փաթեթը այն Azure դարպասից, որը սպասարկում է այս պրոֆիլը, ապա կիրառեք այն այդ հաճախորդի համար աջակցվող ընթացակարգով։ Անկապ VPN հավելվածի գործարկվող ֆայլը փոխարինելը նույն գործողությունը չէ, ինչ դարպասին հատուկ կարգավորումների վերաստեղծումը։ Փաթեթը կրկին ներբեռնելը էժան է. տեղական երթուղիների գուշակումը՝ ոչ։

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

Azure P2S-ի երթուղավորման սցենարները առանձնացնում են ուղղակիորեն peered VNet-երը այլ թունելներով հասանելի ցանցերից, և նոր փաթեթը չի կարող peer-ը դարձնել տրանզիտիվ։ Windows-ի site-to-site կամ BGP որոշ սցենարներ նույնպես պահանջում են ձեռքով կարգավորված հեռավոր երթուղիներ, ուստի փաթեթի թարմացումը երթուղիների բաշխման ունիվերսալ մեխանիզմ չէ։

Ժամանակավոր երթուղին թողեք ժամանակավոր

Ձեռքով երթուղին կարող է մեկուսացնել բացակայող հաճախորդի երթուղին, բայց կառուցեք այն իրական նախագծից՝ route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, առանց մշտական դրոշակի, որպեսզի այն անհետանա վերագործարկման ժամանակ։ Ընտրեք ինտերֆեյսի ինդեքսը և հաջորդ ցատկը միացված VPN ադապտերից, ոչ թե գուշակությունից։

Մի՛ թողեք փորձնական երթուղին որպես մշտական մրցակից սեփականատեր։ Ապագա պրոֆիլի թարմացումները կարող են ավելացնել նույն նախածանցը այլ մետրիկայով, և այդ ժամանակ ձեռքով գրառումը լուռ որոշում է, թե որ ուղին կհաղթի։ Գրանցեք հեռացման քայլը փոփոխության մեջ։

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