Azure S2S VPN-ը միացված է, բայց տրաֆիկ չկա. կարդացեք IKE մատյանը

Պորտալը գրում է Connected, թունելն ունի աշխատաժամանակի հաշվիչ, և ձեր վիրտուալ մեքենայից վերցված trace-ը մահանում է երկրորդ hop-ում: Կապի վիճակը նկարագրում է IKE-ի և IPsec-ի բանակցությունը, ոչ թե այն, թե արդյոք մեկ փաթեթ անցնում է քաղաքականության շերտով կողմերից որևէ մեկում: Երկու սխալ բացատրում է այս տոմսերի մեծ մասը, և դրանցից ոչ մեկը չի ուղղվում Azure-ի երթուղին փոխելով: Երկուսն էլ արդեն գրված են այն մատյանում, որը ստեղծել է դարպասը, դրա համար էլ սկսում եմ այնտեղից, ոչ թե երթուղիների աղյուսակից:

Ինչ է իրականում հաստատում Connected-ը

Միացված site-to-site կապը նշանակում է, որ 1-ին և 2-րդ փուլերը ավարտվել են և անվտանգության ասոցիացիաները գործում են: Սա հայտարարություն է բանակցության մասին. երկու կողմերը համաձայնել են առաջարկի շուրջ, փոխանակել բանալիներ և տեղադրել SA զույգը: Այն ոչինչ չի ասում այն մասին, թե արդյոք տրաֆիկի ընտրիչները համընկնում են այն ենթացանցերի հետ, որոնք դուք պաշտպանված եք համարում, և ոչ էլ այն մասին, թե արդյոք հեռավոր կողմը կուղղորդի փաթեթը ինչ-որ տեղ ապակոդավորելուց հետո: Թունելը կարող է շաբաթներ մնալ ակտիվ՝ դեն նետելով յուրաքանչյուր հետաքրքիր հոսք, և հենց այդ օրինաչափությունն է ստիպում մարդկանց վերակառուցել առողջ դարպասը:

Առաջին հերթին ստուգելի երկու սխալներն են՝ peer-ը, որը ESP-ի փոխարեն առաջարկում է AH, և վիրտուալ ցանց, որը համարակալված է այնպիսի տարածքում, որը դարպասը ներքին չի համարի:

Բացեք արտահանված մատյանը՝ նախքան երթուղիներին դիպչելը

Պորտալում բացեք վիրտուալ ցանցի դարպասը և գործարկեք VPN troubleshoot գործողությունը կապի վրա, ապա ներբեռնեք այն փաթեթը, որը այն ստեղծում է, և արխիվից հանեք: Ներսում IKE մատյան է՝ 1-ին և 2-րդ փուլերի փոխանակումներով, ժամանակադրոշմներով և ընթեռնելի որպես սովորական տեքստ: Դրանում փնտրեք transform տողը, այլ ոչ թե կարդացեք վերևից ներքև, քանի որ հետաքրքիր գրառումը սովորաբար մի քանի հարյուր տող ներքևում է: Եթե պորտալի հասանելիություն չունեք, նույն ախտորոշումները հայտնվում են դարպասի մատյանի նպատակակետում, երբ ախտորոշիչ կարգավորումները միացված են:

Երկու գրառում կրում են արժեքի մեծ մասը: Առաջինը մոտավորապես այսպես է հնչում՝ expected ESP with combined authentication and cipher, received AH: Երկրորդը անվավեր payload-ի սխալն է IKE փոխանակման ընթացքում, ինչը սովորաբար նշանակում է սխալ ձևավորված կամ չաջակցվող առաջարկի դաշտ:

Երկուսն էլ նկարագրում են, թե ինչ առաջարկեց տեղական սարքը, այնպես որ երկուսն էլ peer-ի կողմի կարգավորումներ են: Կապի Azure կողմի վերագեներացումը չի փոխում ձեր firewall-ի ուղարկած առաջարկը, և դա այնուամենայնիվ անելը այս աշխատանքի ամենահաճախ վատնված ժամն է: Peer-ի վրա 2-րդ փուլը դրեք ESP-ի վրա՝ համակցված նույնականացմամբ և ծածկագրով, և թողեք, որ այն բանակցի ալգորիթմը, ապա ստուգեք, թե արդյոք combined mode-ի նման անունով մատակարարի նշիչը լուռ ընտրում է AH առաջարկ դրա տակ:

Հաստատեք վիրտուալ ցանցի հասցեատարածքը

Դարպասը ակնկալում է, որ վիրտուալ ցանցը գտնվի մասնավոր տիրույթներում: Հանրային բլոկում համարակալված ցանցը, օրինակ 111.x-ով սկսվողը, կարող է բարձրացնել թունելը, մինչդեռ Azure-ը հրաժարվում է այդ տարածքը ներքին համարել, այնպես որ կապը առողջ է երևում և ոչ մի հոսք չի ընդունվում: Հաստատեք հասցեատարածքը՝ նախքան ընտրիչների վրա կես օր ծախսելը: Եթե համարակալումը հին բաշխումից եկած խիստ պահանջ է, լուծումը հասցեային պլանի փոփոխությունն է, ոչ թե այլ դարպաս:

Գրանցեք համընկնումը տեղական տիրույթների հետ, մինչ դեռ հասցեատարածքի վահանակում եք, որովհետև համընկնող նախածանցերը տալիս են այլ տեսակի խափանում, որը հաճախորդի կողմից նման է թվում:

Ստուգեք նախածանցերը երկու ուղղությամբ

Տեղական ցանցի դարպասի ռեսուրսը պահում է տեղական նախածանցերը, և դրանք պետք է համընկնեն այն ենթացանցերի հետ, որոնք հեռավոր սարքն իրականում պաշտպանում է: Ամփոփումը, որը ներառում է սարքի կողմից դեն նետված հասցեներ, կթողնի որոշ հոսքեր և կձախողվի մյուսների վրա, ինչը կարդացվում է որպես ընդհատվող երթուղային խափանում, ոչ թե կոնֆիգուրացիայի անհամապատասխանություն: Ստուգեք նաև հեռավոր կողմը. մի ծայրը թվարկում է /16, մինչդեռ մյուսը թվարկում է դրա ներսում երեք /24 — սա դասական մասնակի ձախողումն է: Ոչ մի ցանկ ինքնին հեղինակավոր չէ, այնպես որ համեմատեք դրանք կողք կողքի՝ փոխարենը վստահելով այն մեկին, որը տեսնում եք:

Նախածանցի փոփոխությունը միշտ չէ, որ ինքն իրեն ընկալվում է, այնպես որ պլանավորեք նորից պահել կամ վերստեղծել կապի օբյեկտը, ապա հաստատեք, որ նոր նախածանցերը հայտնվում են երկու կողմերում:

Փորձարկեք ուղին, ոչ թե ping-ը

Trace-ը, որը տարբերում է աշխատող թունելը աշխատող երթուղուց, այսպիսին է. առաջին hop-ը տեղական դարպասն է, ապա մի քանի չպատասխանող hop, ապա հեռավոր հոսթը պատասխանում է: Եթե trace-ը երբեք չի հասնում հոսթին, փորձարկեք այն TCP պորտը, որը հավելվածն իրականում օգտագործում է, որովհետև ICMP-ն բավական հաճախ է զտվում, որ ձախողված ping-ը շատ քիչ բան ապացուցի: Գործարկեք նույն trace-ը հեռավոր հոսթից դեպի Azure-ի վիրտուալ մեքենա: Երկու արդյունքների միջև ասիմետրիան բացակայող վերադարձի երթուղին կամ միայն մեկ ուղղություն թույլատրող կանոնը գտնելու ամենաարագ ճանապարհն է:

Գրեք peer-ի առաջարկը, երկու հասցեատարածքները և կապի ստեղծման ժամանակը տոմսի մեջ, որպեսզի հաջորդ ինժեները իմանա, թե որ արժեքներն են վերակառուցվել և որոնց երբեք չեն դիպչել:

Եթե մատյանը վերադառնում է դատարկ, հնարավոր է՝ դարպասը բոլորովին չի ավարտում ձեր կապը: Հաստատեք, որ տեղական ցանցի դարպասի peer հասցեն համընկնում է այն սարքի հետ, որից կարդում եք մատյանը, որովհետև մեկ բաժանորդագրության մեջ երկու դարպաս հեշտ է շփոթել վերակառուցման ժամանակ: Այդ սխալը արժենում է մեկ օր և ոչ մի մատյանում հետք չի թողնում: