Azure P2S VPN-ի վերադարձ տրաֆիկը աշխատում է միայն մեկ ուղղությամբ

Թունելի պատկերակը կանաչ է, NSG-ն թույլատրող է թվում, արդյունավետ երթուղիները ճիշտ են թվում, բայց VM-ը դեռ չի կարող կապ բացել դեպի միացված հաճախորդ։ Սովորական ենթադրությունն այն է, որ աշխատող point-to-site թունելը սիմետրիկ է. եթե հաճախորդը հասնում է VM-ին, VM-ը հասնում է հաճախորդին։ Այդ ենթադրությունը տրամաբանության սխալն է, ոչ թե կարգաբերման։ Թունելը կարող է կրել չպահանջված հոսքի մեկ ուղղությունը և գցել մյուսը, և ուղղումը կախված է նրանից, թե որ շերտն է գցում այն։

Առասպել. միացված թունելը երկկողմ թունել է

VPN թունելը քաղաքականության ուղի է, ոչ թե լար։ Յուրաքանչյուր ուղղություն համեմատվում է ընտրիչների, երթուղիների և զտիչների հետ, և դրանցից ցանկացածը կարող է թույլատրել մի ուղղությունը՝ արգելափակելով մյուսը։

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

Ստուգեք ուղղությունը նախքան հասանելիությունը ստուգելը

Ընտրեք մեկ հաճախորդի հասցե, մեկ VM հասցե և մեկ արձանագրություն։ Միացեք հաճախորդից և գրանցեք արդյունքը. ապա սկսեք նույն թեստը VM-ից և գրանցեք նաև այն։ Եթե առաջինը հաջողվում է, իսկ երկրորդը ձախողվում, ապա հաճախորդների լողավազանը, դարպասի միացումը և հաճախորդից VNet ուղին բոլորը աշխատում են։

Հաջորդ քայլը ապացույցներն են, ոչ թե ավելի շատ կանոններ։ Ստուգեք VM-ի ենթացանցի NSG-ն երկու ուղղությամբ, կարդացեք արդյունավետ երթուղիները VM-ի NIC-ում և գրավեք փաթեթներ VM-ում, մինչ հաճախորդը տրաֆիկ է ուղարկում։ Առանց պատասխանի ժամանող հարցումը զտիչի կամ վերադարձի երթուղու խնդիր է. երբեք չժամանող հարցումը ուղու խնդիր է։ Չհաջողված ping-ը մի համարեք VM-ի անհասանելիության ապացույց, որովհետև ICMP քաղաքականությունը կարող է գցել պատասխանը, մինչ TCP-ն աշխատում է։

IKEv2 point-to-site վերադարձի ուղին սովորական կասկածյալն է

Այս հոդվածի հիմքում ընկած Azure զեկույցում հաճախորդը կարող էր հասնել VM-ներին IKEv2-ով, բայց VM-ից հաճախորդ ներգնա ICMP-ն ձախողվում էր, մինչև դարպասի թունելի տեսակը չփոխվեց OpenVPN-ի։ Զեկույցի հեղինակը նշում է, որ Microsoft-ը հաստատել է սահմանափակում IKEv2 point-to-site ուղում, որտեղ VM-ից հաճախորդ վերադարձ տրաֆիկը սիմետրիկ չի երթուղվում, եթե սեսիան չի սկսել հաճախորդը։ IKEv2-ը հենվում է տրաֆիկի ընտրիչների վրա, և դարպասը այդ դեպքում չհարգեց վերադարձի ուղղությունը։

Դա OpenVPN-ը ընդհանուր առմամբ ավելի լավ թունելի տեսակ չի դարձնում։ Դա թունելի տեսակը դարձնում է փոփոխական այս աշխատանքային բեռի թեստային մատրիցայում։

Թունելի տեսակի փոխումը ծառայության փոփոխություն է, ոչ թե անջատիչ։ Յուրաքանչյուր հաճախորդի պետք է համատեղելի պրոֆիլ, և դարպասին կարող է պետք լինել այլ վկայագիր կամ նույնականացման կարգավորում։ Վերարտադրեք միակողմանի վարքը մեկ թեստային հաճախորդով և մեկ թեստային VM-ով, փոխեք տեսակը հաստատված ժամանակացույցով, ապա կրկնեք նույն ուղղության թեստերը։ Եթե վարքը պահպանվում է փոխումից հետո, թունելի տեսակը պատճառ չէր, և դուք նեղացրել եք խնդիրը՝ չդիպչելով արտադրությանը։

Առասպել. broadcast-ով հայտնաբերումը հատում է VNet-ի սահմանը

Երկրորդ ենթադրությունը ձախողվում է անկապ պատճառով։ Azure-ի վիրտուալ ցանցը չի տեղափոխում broadcast տրաֆիկ, ուստի VM-ը չի կարող broadcast շրջանակներ ստանալ տեղական ցանցից site-to-site կամ point-to-site կապով։ Հավելվածները, որոնք զուգընկերներին գտնում են broadcast-ով, օրինակ հին ֆայլերի դիտումը կամ որոշ սարքի հայտնաբերման արձանագրություններ, երբեք չեն տեսնի հեռավոր կողմը, ինչպես էլ գրված լինեն երթուղիները։

Փոխարինեք broadcast-ով հայտնաբերումը DNS անուններով, գրացուցակի ծառայությամբ կամ զուգընկերների բացահայտ ցանկով։ Եթե հավելվածը unicast այլընտրանք չունի, դիզայնին պետք է այլ հայտնաբերման մեխանիզմ, ոչ թե ավելի լայն թունել։

Ինչ փոխել և ինչպես ապացուցել

Եթե ուղղության թեստը ձախողվում է միայն IKEv2-ով, գրանցեք դարպասի թունելի տեսակը, հաճախորդների հասցեների լողավազանը և ճշգրիտ ICMP կամ TCP թեստը, ապա գնահատեք հաստատված OpenVPN պրոֆիլը տուժած հաճախորդների համար։ Եթե այն ձախողվում է բոլոր թունելի տեսակներով, աշխատեք վերադարձի ուղու վրա. հաճախորդի հասցեն պետք է երթուղելի լինի VM-ի ենթացանցից, օգտագործողի կողմից սահմանված ցանկացած երթուղի պետք է մատնանշի վավեր հաջորդ ցատկին, և հաճախորդի firewall-ը պետք է ընդունի ներգնա հոսքը։ Կցեք NSG-ի և երթուղիների ապացույցները տոմսին։

Ստուգեք հավելվածով, ոչ ping-ով։ Փոփոխությունից հետո հաջող ICMP փոխանակումը ոչինչ չի ասում ծառայության պորտի, դրա նույնականացման կամ անվան լուծման մասին։ Կրկնեք թեստը վերամիացումից հետո, որովհետև լողավազանից այլ հասցե ստացող հաճախորդը կարող է փոխել արդյունքը։ Ապա կրկնեք ևս մեկ անգամ այն բանից հետո, երբ հաճախորդը քնի և արթնանա, քանի որ հենց վերսկսված սեսիայում է միակողմանի վարքը հաճախ նորից ի հայտ գալիս։