Azure point-to-site-ը միանում է, բայց ոչ մի մասնավոր ռեսուրս չի պատասխանում
Միացված լինելը նշանակում է միայն, որ թունելը բարձրացել է: Ստուգեք, թե ինչ կարող է կրել դարպասը, համեմատեք հասցեային տարածքները, ապա լուծեք անունը և փորձարկեք ծառայությունը:
Միացված լինելը թունելի վիճակ է, ոչ թե հայտարարություն հասանելիության մասին: Point-to-site հաճախորդը կարող է ավարտել IKE-ն, ստանալ հասցե և այդուամենայնիվ ոչնչի չհասնել, որովհետև դարպասը փոխանցում է թրաֆիկը միայն այն ցանցերի համար, որոնք VNet-ն արդեն գիտի: Կատարեք այս հինգ ստուգումները հերթականությամբ և կանգ առեք առաջին ձախողման ժամանակ: Առաջ անցնելը հենց այն ձևն է, որով DNS խնդիրը մեկ ժամ շարունակ վերաբերվում է որպես firewall-ի խնդիր:
Հերթականությունը ավելի կարևոր է, քան ցանկը:
Ստուգում 1. որոշեք, թե ինչ պետք է կրի թունելը
Azure VPN Gateway-ը ավարտում է թունելը և փոխանցում VNet-ին պատկանող թրաֆիկը. այնընդհանուր ինտերնետ ելք չէ: Եթե օգտատերերը ակնկալում են, որ իրենց զննարկումը դուրս գա Azure-ով, ապա դիզայնը սխալ է դեռևս ցանկացած հաճախորդի կարգավորումից առաջ: Միացրեք split tunneling-ը, որպեսզի տեղական ինտերնետը մնա տեղական ուղու վրա, և օգտագործեք NAT ինստանս կամ site-to-site թունել, երբ իսկապես պահանջվում է հաստատուն ելքային հասցե:
Գրեք, թե ինչին պետք է հասնի հաճախորդը, նախքան որևէ բան փորձարկելը: Առանց այդ ցանկի յուրաքանչյուր մասնակի արդյունք առաջընթաց է թվում:
Ստուգում 2. համեմատեք հասցեային տարածքները վկայագրերից առաջ
Համընկնությունը գնահատվում է ավելի լայն միջակայքերով, այնպես որ ենթացանցի մակարդակում տարբեր թվացող երկու ցանցեր դեռևս բախվում են, եթե դրանց ծնողական բլոկները համընկնում են: Դարպասի ենթացանցը պետք է լինի առանձնացված և բավականաչափ մեծ SKU-ի համար, իսկ հաճախորդի հասցեների պաշարը չպետք է բախվի VNet-ի կամ peering-ով հասանելի որևէ բանի հետ: Փոխեք պլանը և վերատեղադրեք, որովհետև փոխհատուցման համար երթուղիներ ավելացնելը ստեղծում է թունել, որը աշխատում է որոշ ուղղությունների համար և անբացատրելիորեն ոչ մյուսների: Տրամադրումն այստեղ բարձրաձայն ձախողվում է, ինչը լավ դեպքն է:
Նույնականացումը հաջորդ դարպասն է: Վկայագրի, RADIUS-ի և Entra ID-ի պրոֆիլները փոխարինելի չեն, և հաճախորդի փաթեթը տարբերվում է յուրաքանչյուրի համար:
Ստուգում 3. լուծեք մասնավոր անունը ներսից
Հաճախորդը պահում է իր սեփական լուծիչը, եթե ներբեռնված պրոֆիլը չի կրում VNet-ի DNS սերվերները, և այդ ցանկը ներկառուցվում է ներբեռնման պահին: Ավելացրեք forwarder VNet-ի ներսում, սահմանեք այն որպես VNet-ի DNS սերվեր, ապա նորից ներբեռնեք և ներմուծեք հաճախորդի փաթեթը: Հին փաթեթի վերօգտագործումը փորձարկում է միայն հին լուծիչների ցանկը:
Նախ փորձարկեք հասցեն, որովհետև դա մեկ քայլով առանձնացնում է երթուղավորումը անվանակոչումից՝ Test-NetConnection 10.20.1.4 -Port 3389:
Եթե հասցեն պատասխանում է, իսկ անունը՝ ոչ, հարցրեք լուծիչին ուղղակիորեն Resolve-DnsName files.corp.example -Server 10.20.0.4-ով: Եթե երկուսն էլ ձախողվում են, խնդիրը DNS-ում չէ, և դուք պետք է դադարեք խմբագրել DNS կարգավորումները: Azure պլատֆորմի DNS-ը 168.63.129.16 հասցեում պատասխանում է միայն VNet-ի ներսից, ուստի դրսում գտնվող հաճախորդը չի կարող այդ հասցեն օգտագործել որպես լուծիչ:
Ստուգում 4. փորձարկեք թունելի հետևում գտնվող ծառայությունը
Առողջ թունելը և փակ պորտը հաճախորդի կողմից նույնն են երևում: Ստուգեք հյուրի firewall-ը, ապա ենթացանցի կամ NIC-ի ցանցային անվտանգության խումբը, ապա արդյոք ծառայությունը լսում է մասնավոր հասցեում, և ոչ միայն loopback-ում: Թույլատրեք հաճախորդի պաշարը որպես աղբյուր՝ ինտերնետին կանոն բացելու փոխարեն, և հիշեք, որ Azure Files-ին SMB-ն պահանջում է մասնավոր վերջնակետի ուղին թունելով: Երբ ռեսուրսը պատասխանում է IP-ով, բայց ոչ անունով, վերադարձեք 3-րդ ստուգմանը՝ դարպասին չդիպչելով:
Մեկ աղյուսակը շերտերն առանձին է պահում աշխատանքի ընթացքում:
| Symptom | Layer to check |
|---|---|
| Name fails, private IP works | Resolver setting or forwarder |
| Private IP also fails | Address plan, NSG, guest firewall |
| Private works, internet fails | Expected; the gateway is not an egress |
| Connects, then drops | Tunnel type or certificate mismatch |
Ստուգում 5. գրանցեք պրոֆիլը նախքան էսկալացիան
Տոմսի մեջ նշեք դարպասի տեսակը, թունելի տեսակը, նույնականացման եղանակը և հաճախորդի օպերացիոն համակարգը: Վկայագրով IKEv2 պրոֆիլը և RADIUS պրոֆիլը ձախողվում են տարբեր պատճառներով, և այլ թունելի տեսակի համար կառուցված հաճախորդը միանում է միայն այն դեպքում, երբ դարպասը առաջարկում է համատեղելի արձանագրություն:
Փոքր թիմի համար դիմացկուն դիզայնը մեկ VNet է, մեկ DNS forwarder և փաստաթղթավորված split-tunnel հաճախորդ: Եթե պահանջը հաստատուն հանրային ելք է, ավարտեք site-to-site թունելը ձեր վերահսկած firewall-ի վրա և ինտերնետ թրաֆիկը ուղղեք այնտեղ, փոխարենը point-to-site դարպասից պահանջելու մի բան, ինչի համար այն երբեք չի կառուցվել: