Որտեղ են Azure Point-to-Site VPN-ի մատյանները։ Նայեք Monitor-ում

Օգտատերը չի կարողանում միանալ Point-to-Site դարպասին, դուք բացում եք դարպասի թերթը, և էջում ոչ մի տեղ միացումների պատմություն չկա։ Կազմաձևում, վկայագրեր, կարգավիճակ՝ ամեն ինչ տեղում է, գրառումներ չկան։ Մատյանները գոյություն ունեն, բայց ցանցային էջերը դրանք բոլորովին չեն ստեղծում։ Դրանք գալիս են դարպասի ռեսուրսին կցված ախտորոշիչ կարգավորումից, և այդ կարգավորումը ապրում է Monitor-ում, դրա համար էլ ակնհայտ տեղում առաջին որոնումը ոչինչ չի վերադարձնում, և մարդիկ եզրակացնում են, որ ծառայությունը ոչ մի աուդիտի հետք չի պահում։

Ինչու է ձախողվում ակնհայտ որոնումը

Հին ուղեցույցները պնդում են, որ Azure Point-to-Site VPN-ը աուդիտ չունի, և դա ճիշտ էր, երբ ծառայությունը յուրաքանչյուր միացման գրառում չէր հրապարակում։ Ընթացիկ դարպասները հրապարակում են թունելի ախտորոշիչ գրառումներ, ուստի օգտակար հարցը փոխվել է՝ ոչ թե արդյոք մատյաններ կան, այլ ո՛ր ռեսուրսն է դրանք արտադրում և ո՛ր կատեգորիան եք միացրել։ Դարպասի թերթը կազմաձևման մակերես է, իսկ կազմաձևման մակերեսները հազվադեպ են միաժամանակ մատյանների դիտիչ ծառայում։ Ախտորոշիչ կարգավորումը յուրաքանչյուր ռեսուրսի համար օբյեկտ է, ուստի ձեր ընտրած ռեսուրսը որոշում է ամեն ինչ, ինչ հաջորդում է։

Շփոթության մյուս կեսը նույնականացումն է։ Վկայագրի վրա հիմնված Point-to-Site միացումները չեն առաջացնում յուրաքանչյուր օգտատիրոջ մուտքի իրադարձություն, ինչպես անում է ինքնության մատակարարը, ուստի գաղտնաբառ մուտքագրող անվանված անձի գրառում չկա։

Կցեք ախտորոշիչ կարգավորումը դարպասի ռեսուրսին

Բացեք Monitor-ը, ապա Diagnostic settings-ը, և ավելացրեք նոր կարգավորում, որի թիրախը հենց վիրտուալ ցանցի դարպասն է, այլ ոչ թե այն պարունակող վիրտուալ ցանցը։ Ընտրեք Point-to-Site ախտորոշիչ կատեգորիան՝ P2SDiagnosticLog անունով, քանի որ հենց այն է կրում յուրաքանչյուր հաճախորդի միացման գրառումները. թունելի, երթուղու կամ IKE կատեգորիաները ավելացրեք միայն այն site-to-site սխալների համար, որոնք նրանք ծածկում են։ Այնուհետև ուղարկեք տվյալները ձեր վերահսկած Log Analytics աշխատանքային տարածք, ձեր գիտակցաբար ընտրած պահպանման ժամկետով։ Անհաջող որոնումների մեծ մասը սխալ ռեսուրսին կցված կարգավորում է, ոչ թե բացակայող ֆունկցիա։

Կատեգորիաների ցանկերը տարբերվում են ըստ դարպասի տեսակի և սերնդի։ Եթե Point-to-Site կատեգորիան բացակայում է, դարպասը կարող է ավելի հին լինել ֆունկցիայից կամ աշխատել SKU-ով, որը երբեք չի արտադրում այն, ուստի թույլտվության խնդիր փնտրելուց առաջ ստուգեք աջակցվող կատեգորիաները։ Point-to-Site կատեգորիա չունեցող դարպասը կոտրված չէ. այն պարզապես չի կարող լինել այդ գրառման աղբյուրը, և ամենամոտ փոխարինողը թունելի կամ IKE կատեգորիան է, որը գրանցում է հաճախորդի հասցեն, թեև չի նկարագրում Point-to-Site նստաշրջան։ Հաստատեք կատեգորիաների ցանկը, նախքան բացակայող մատյանների մասին աջակցության դեպք բացելը։

Կարդացեք գրառումները այն աղյուսակում, որն օգտագործում է ձեր ռեժիմը

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

AzureDiagnostics
| where ResourceType == "VIRTUALNETWORKGATEWAYS"
| where _ResourceId has "gateway-name"
| where TimeGenerated > ago(2h)
| project TimeGenerated, Category, OperationName, ResultType, ResultDescription
| order by TimeGenerated desc

Սյունակների հավաքածուն հետևում է ձեր հավաքման ռեժիմին, ուստի հարցմանը վերաբերվեք որպես ձևի, ոչ թե սկրիպտի։ Այն, ինչ փնտրում եք, հաճախորդի հասցե է, որը հայտնվում և հետո անհետանում է, արդյունքի տեսակով, որը հաջողություն չէ։

Զուգակցեք դարպասի գրառումը հաճախորդի սեփական տեսքի հետ

Դարպասի մատյանները նկարագրում են թունելը, ոչ թե ինչու նոութբուքը չկարողացավ մեկը կառուցել։ Հավաքեք հաճախորդի կողմը նույն ժամանակադրոշմով՝ Windows իրադարձությունների մատյանը RAS հաճախորդի համար, macOS միացման մատյանը կամ սխալի տեքստը, որը ցուցադրել է հաճախորդի հավելվածը։ Համապատասխան հաճախորդի փորձ չունեցող դարպասի գրառումը մատնանշում է հաճախորդին. երբ հաճախորդը հաջողություն է հաղորդում, մինչ դարպասը ոչինչ չի գրանցում, դա սովորաբար նշանակում է, որ պրոֆիլն ուղղված է այլ դարպասի։

Պահեք երկու կեսերն էլ նույն տոմսում։ Միայն դարպասի մատյանը հրավիրում է սխալ եզրակացության, և միայն հաճախորդի մատյանը չի կարող ցույց տալ՝ փաթեթը երբևէ հասել է, թե ոչ։

Եթե ոչ մի տեղ ոչինչ չի հայտնվում, ստուգեք հաճախորդի ժամացույցը, նախքան հարթակին կասկածելը։ Թեքված ժամանակադրոշմները հարաբերակցությանը ձախողում են այնպես, որ ճիշտ բացակայող տվյալների տեսք ունի։

Պահպանում, շրջանակ և runbook-ի գրառում

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

Վերջապես, գրեք կարգավորման անունը, աշխատանքային տարածքը և ընտրված կատեգորիաները դարպասի runbook-ում։ Հաջորդ մարդը, ով կկարգաբերի հաճախորդին, նախ կնայի դարպասի թերթին, ոչինչ չի գտնի և կեզրակացնի, որ մատյանները գոյություն չունեն։