Azure P2S VPN-ը չի կարող լուծել մասնավոր վերջնակետի անունը

Միացնում եք point-to-site թունելը, ping անում մասնավոր հասցեին, բացում հավելվածը և փոխարենը ստանում 403 կամ վկայագրի սխալ։ Երկու ախտանիշներն էլ մատնանշում են DNS-ին, բայց դրանք տարբեր խափանումներ են. մեկը նշանակում է, որ կլիենտը լուծել է հրապարակային հասցեն, մյուսը՝ որ լուծել է մասնավոր հասցեն և հետո առաջարկել անուն, որը վկայագիրը չի ծածկում։ Անցեք ստորև բերված ստուգումները հերթով և կանգ առեք առաջին ձախողման վրա, քանի որ hosts գրառումը կամ պահված պատասխանը կարող են ստիպել յուրաքանչյուր հաջորդ ստուգման անցնել սխալ պատճառով։ Այս հերթականությունը պահում եմ տեքստային ֆայլում իմ VPN պրոֆիլների կողքին, որովհետև ուղղումը ոչինչ չի փոխում թունելում և ամեն ինչ փոխում է նրանում, ինչ գիտի կլիենտը։

Սկսեք այն հասցեից, որը կլիենտը իրականում ստանում է

Հարցրեք լուծիչին ուղղակիորեն՝ հավելվածին վստահելու փոխարեն։ Windows-ում nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net-ը ցույց է տալիս, թե որ տեսքն է ստացել կլիենտը։ Հրապարակային պատասխանը նշանակում է, որ ոչինչ այլևս չի հասնի վերջնակետին. վերջնակետի մասնավոր հասցեն նշանակում է, որ DNS-ն ավարտված է, և հաջորդ ստուգումը հենց միացումն է։

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

Ստուգեք գոտին, դրա կապը և գրառումը թունելից առաջ

Երեք պայման պետք է միաժամանակ կատարվեն. մասնավոր գոտին գոյություն ունի, կապված է վիրտուալ ցանցին, որտեղից VPN դարպասը և կլիենտները մտնում են Azure, և պարունակում է A գրառում վերջնակետի համար, որը մատնանշում է մասնավոր հասցեին։ Կապեք գոտին անհետ կապ ունեցող ցանցին, և դարպասը կշարունակի լուծել հրապարակային գրառումը, մինչ թունելում ամեն ինչ առողջ տեսք կունենա։

Գոտիների անունները պատկանում են ծառայություններին, ոչ թե ընդհանրապես մասնավոր կապերին։ App Service-ը սովորաբար օգտագործում է privatelink.azurewebsites.net, պահոցն ու SQL-ը ունեն իրենց անվանատարածքները, իսկ այլ ծառայության գոտի փոխառելը ստեղծում է գոտի, որը գոյություն ունի և ոչ մի օգտակար բան չի պատասխանում։

Տվեք կլիենտին լուծիչ, որին նա իսկապես հասանելի է

168.63.129.16-ը պատասխանում է Azure վիրտուալ մեքենաներից և DNS սերվեր չէ point-to-site թունելի մյուս կողմում գտնվող նոթբուքի համար։ Կլիենտին պետք է թունելով հասանելի լուծիչ՝ Azure DNS Private Resolver-ի մուտքային վերջնակետ, վիրտուալ ցանցի ներսում փոխանցիչ, կամ VPN կլիենտի պրոֆիլում տեղափոխվող DNS սերվերի գրառումներ, որպեսզի կլիենտը ուղղակիորեն հարցնի վիրտուալ ցանցին։

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

Եթե փոխանցում եք՝ կարգավորումները հրելու փոխարեն, փոխանցեք այն անվանատարածքը, որը պատկանում է մասնավոր գոտուն՝ privatelink.azurewebsites.net, այլ ոչ ամբողջ azurewebsites.net-ը։ Պայմանական փոխանցիչը, որը կուլ է տալիս ամբողջ ծնողական վերջածանցը, ծառայության յուրաքանչյուր որոնում ուղարկում է Azure, ներառյալ նրանք, որոնք պետք է մնան տեղային։

Օգտագործեք այն անունը, որի համար տրվել է վկայագիրը

Երբ հասցեն ճիշտ է, ի հայտ է գալիս երկրորդ խափանումը։ Պահոցը և App Service-ը հրապարակում են privatelink այլանուն, և այդ այլանունը պարտադիր չէ, որ վկայագրի անունը լինի։ privatelink.blob.core.windows.net հասցեին ուղղված AzCopy վերբեռնումը ձախողվեց վավերացմանը. նույն վերբեռնումը <account>.blob.core.windows.net/<container> հասցեին լուծվեց մասնավոր հասցեին և անցավ, այնպես որ մնաց մասնավոր ուղու վրա՝ առանց որևէ շեղման։

Կանոնը գործում է զննարկիչում և App Service-ի համար նույնպես. միացեք այն հոսթի անունով, որը ծածկում է վկայագիրը, և թողեք DNS-ը տրամադրի մասնավոր հասցեն։ Մի դիմեք վավերացումը շրջանցելուն, քանի որ այն անվանման սխալը վերածում է անվտանգության հետընթացի։ Հաջող ping-ը ապացուցում է երթուղին և ոչինչ չի ասում ձեռքսեղմման ներսում գտնվող անվան մասին, ինչի պատճառով դրանք մնում են առանձին ստուգումներ։

Չորս քայլից բաղկացած կարգ, որը մեկուսացնում է յուրաքանչյուր շերտը

1. Հաստատեք, որ VPN կլիենտն ունի point-to-site լողավազանից հասցե և երթուղի դեպի վերջնակետի մասնավոր հասցեն։
2. Լուծեք հենց այն անունը, որն օգտագործում է հավելվածը, և համեմատեք պատասխանը վերջնակետի հասցեի հետ։
3. Բացեք TCP միացում դեպի վերջնակետը ծառայության պորտին, ապա կարդացեք այդ միացման վրա ներկայացված վկայագրի անունը։
4. Միայն հիմա ստուգեք լիազորումը, քանի որ աշխատող ուղին և վավեր վկայագիրը դեռ չեն տալիս հասանելիություն ռեսուրսին։

Ճիշտ հասցեի դեպքում մերժված միացումը մատնանշում է ցանցի անվտանգության խմբին կամ մասնավոր վերջնակետի միացման վիճակին, ոչ թե DNS-ին, ուստի ստուգեք դրանք նախքան լուծիչի կարգավորումները նորից խմբագրելը։ TLS անվան անհամապատասխանությունը ձեզ վերադարձնում է URL-ի հոսթի անվանը և վկայագրի subject-ին։ Պահեք լուծման ելքը, վկայագրի անունը և ճշգրիտ URL-ը միասին. այս երեք արժեքները բացատրում են այս դեպքերի մեծ մասը՝ առանց դարպասին դիպչելու։

Որպես հսկողություն օգտագործեք վիրտուալ ցանցի ներսում գտնվող VM-ը։ Եթե անունը այնտեղ լուծվում է մասնավոր, իսկ թունելից՝ հրապարակային, գոտին և գրառումը ճիշտ են, և միակ տարբերությունը կլիենտի լուծիչի ուղին է, որը հաստատվում է ավելի արագ, քան վերջնակետի կարգավորման ևս մեկ անցումը։

Կլիենտները նույնպես պահում են։ Գրառումը, որը տասը րոպե առաջ պատասխանել էր հրապարակային, շարունակում է պատասխանել գոտին ուղղելուց հետո, ուստի դատարկեք պահոցը նախքան նորից ստուգելը։ Windows-ում ipconfig /flushdns-ը մաքրում է կլիենտի պահոցը. անվան լուծման քաղաքականության կանոնները մնում են, որոշում են, թե որ վերջածանցը որ սերվերին գնա, և կարող են շարունակել անվանատարածքը ուղարկել այն լուծիչին, որը դուք հենց նոր փոխարինեցիք։

Որտեղ է տեղը hosts գրառմանը

Վերջնակետի հասցեն hosts ֆայլում ավելացնելը լավ ախտորոշում է և վատ ձևավորում։ Այն ապացուցում է, որ անվան և հասցեի համապատասխանությունը հենց բացակայող մասն է, և թույլ է տալիս ստուգել դրանից հետո ամեն ինչ, բայց անտեսանելի է ձեր օգտատերերի համար, կոտրվում է, երբ վերջնակետի հասցեն փոխվում է, և թաքցնում է այն գոտին, որը պետք է պատասխանի։

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

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