SharePoint-ի հղումները կտրվում են VPN-ով՝ հրապարակված URL-ների պատճառով
VPN-ով բեռնված SharePoint էջը դեռ կարող է վերադարձնել փաստաթղթի հղումներ անունով, որը ձեր հաճախորդը չի կարող լուծել։ Ստուգեք DNS-ը, երթուղին, TLS-ը և հրապարակված URL-ը։
SharePoint էջը բացվում է VPN-ով, և առաջին փաստաթղթի հղումը ձախողվում է անունով, որը երբեք չի եղել հասցեագոտում։ Այդ բացը հենց ամբողջ խնդիրն է՝ էջը եկել է մեկ URL-ից, իսկ ծառայությունը հաջորդ հարցումը ձևավորել է մյուսից։ Հրապարակված URL-ը սերվերի կողմի որոշում է, ուստի այն հաճախորդի վրա ուղղելը սխալ ծայրն է։ Ստուգեք, թե ծառայությունը որ անունն է վերադարձնում, նախքան DNS-ին կամ երթուղիներին դիպչելը։
Առաջին էջը և հաջորդ հարցումը օգտագործում են տարբեր անուններ
Օգտատերը, որը սերվերին հասնում է հասցեով, տեսնում է աշխատող գլխավոր էջ։ Այդ էջի փաստաթղթի հղումները ստեղծվում են այն URL-ից, որը ծառայությունը կարծում է, թե հրապարակում է, այլ ոչ թե այն բանից, ինչ մուտքագրել է զննարկիչը։ Եթե դրանք տարբերվում են, հաջորդ սեղմումը գնում է անվան, որը հաճախորդը երբեք չի լուծել։
Հասցեն մեկ անգամ մուտքագրելը չի վերանորոգում յուրաքանչյուր ստեղծված հղում, և հասցեի էջանիշը թաքցնում է խնդիրը մինչև փաստաթղթի բացվելը։
Այս ձախողումը հեշտ է սխալ կարդալ որպես VPN-ի խնդիր, քանի որ այն ի հայտ է գալիս միայն թունելն օգտագործելուց հետո։ Փաստորեն թունելն անում է իր գործը՝ այն հարցումը տանում է անվան, որն աշխատող ուղի կամ համապատասխան վկայագիր չունի։ Առանձնացրեք երկու հարցերը, նախքան դրանցից որևէ մեկը փոխելը։ Մեկն այն է, թե փաթեթը որտեղ է գնում, մյուսը՝ թե ծառայությունը որ անունն է ընտրել հրապարակելու։
Չորս վերահսկիչ, մեկ անուն
Յուրաքանչյուր հրապարակված անուն պետք է անցնի չորս անկախ վերահսկիչ։ DNS-ը պետք է այն լուծի իրական հաճախորդի համար, երթուղավորումը և մուտքի քաղաքականությունը պետք է թույլատրեն ուղին, TLS-ը պետք է վավերացնի այդ անունը, և ծառայությունը պետք է կարգավորված լինի այն հրապարակելու համար։
Մեկ վերահսկիչի փոփոխությունը չի կատարում մյուսներին։ Վկայագրի նախազգուշացումն ընդունելը անվան լուծման վերանորոգում չէ։
Ստորև բերված աղյուսակը ստուգաթերթի հերթականությունն է։ Կանգ առեք առաջին տողում, որը ձախողվում է, որովհետև ավելի ուշ ուղղումը չի կարող փոխհատուցել ավելի վաղ բացը։
| Control | Question | Where to look |
|---|---|---|
| DNS | Can the client resolve the published name? | Client resolver and split-DNS policy |
| Route and policy | Does the permitted path exist to the service? | VPN routes and firewall rules |
| TLS identity | Does the certificate match the name in use? | Certificate subject names and trust store |
| Publishing config | Which URL does the service return? | Web application settings and site model |
Կարդացեք հրապարակման մոդելը նախքան այն փոխելը
SharePoint Server-ի տեղակայումները տարբեր են։ Դասական վեբ հավելվածները կարող են օգտագործել այլընտրանքային մուտքի քարտեզագրումներ, որտեղ ներքին URL-ն այն է, ինչ ստանում է սերվերը, իսկ հանրային URL-ն այն է, ինչ նա օգտագործում է հղումները ձևավորելու համար։ Հոսթի անունով կայքերի հավաքածուները այլ մոտեցում են որդեգրում և, ըստ Microsoft-ի ուղեցույցի, չեն կարող օգտագործել AAM։
Microsoft-ի պլանավորման ուղեցույցը նույնպես AAM հատկությունները նշում է որպես հնացած և նոր պլանավորման համար խորհուրդ է տալիս հոսթի անունով կայքերի հավաքածուներ։ Դա տեղակայման մոդելը դարձնում է դրա սեփականատիրոջ հարցը, ոչ թե ձեր կարկատող լռելյայնը։
Որոշեք, թե որ մոդելն է օգտագործվում, նախքան քարտեզագրման փոփոխություն առաջարկելը։ Հոսթի անունով տեղակայմանը AAM գրառում ավելացնելը ոչինչ չի անում, իսկ դասական տեղակայմանը մեկը ավելացնելը միանգամից փոխում է բոլոր վերադարձված հղումները։ Երկուսն էլ լայն ազդեցությամբ կարգավորման փոփոխություններ են, ուստի պատրաստեք դրանք փուլերով և պահեք հետադարձ պլան։ Սա առաջարկ չէ հին քարտեզագրումները ժամանակակից միջավայր բերելու։
Հետևեք ձախողված գործողությանը, ոչ թե գլխավոր էջին
Գրանցեք նպատակակետը, որն իրականում օգտագործել է ձախողված հարցումը, հաճախորդ հավելվածը, ժամը և սխալը։ Զննարկիչը և աշխատասեղանի հավելվածը կարող են տարբեր պրոքսիի, VPN-ի կամ նույնականացման ուղիներով հասնել նույն փաստաթղթին։
Զննարկիչը կարող է հաջողության հասնել, մինչ Office հաճախորդը ձախողվում է, և այդ տարբերությունն ակնարկ է այն մասին, թե որ համատեքստն է լուծում անունը։
Եթե URL-ը և ցանցային փոխանցումը երկուսն էլ աշխատում են, և ծառայությունը դեռ մերժում է գործողությունը, մնացած խնդիրը հավելվածի մակարդակում է։ Փաստաթղթի թույլտվությունները և վճարման կարգավիճակը պատկանում են ծառայության սեփականատիրոջը, իսկ VPN երթուղին ապահովում է կապ, ոչ թե թույլտվություն։
Ստուգեք փոխանցումը սկզբից մինչև վերջ
Կատարեք ստուգումները հերթով այն հաճախորդի վրա, որը ձախողվում է՝ լուծեք հրապարակված անունը, պահանջեք էջը այդ անունով, ապա պահանջեք փաստաթղթի URL-ը էջի աղբյուրից։ Յուրաքանչյուր քայլ մեկուսացնում է մեկ վերահսկիչ։
Երեք հրաման ծածկում են լուծումը, TLS-ը և փաստաթղթի ուղին:
nslookup portal.hq.example
curl -sSI https://portal.hq.example/ | head -5
curl -sS -o /dev/null -w "%{http_code}" https://portal.hq.example/sites/team/Doc.aspxԵթե լուծումը ձախողվում է միայն թունելով, ապա կասկածելին split-DNS քաղաքականությունն է։ Եթե TLS-ը ձախողվում է, համեմատեք վկայագրի անունը հրապարակված անվան հետ, այլ ոչ թե սեղմեք նախազգուշացման միջով։ Եթե երկուսն էլ հաջողվեն, և փաստաթուղթը դեռ ձախողվում է, սխալն այլևս URL-ի մասին չէ։