SharePoint сілтемелері жарияланған URL-дер салдарынан VPN арқылы үзіледі

VPN арқылы жүктелген SharePoint беті клиентіңіз шеше алмайтын атаумен құжат сілтемелерін қайтаруы мүмкін. DNS, маршрут, TLS және жарияланған URL-ді тексеріңіз.

SharePoint беті VPN арқылы ашылады, және бірінші құжат сілтемесі мекенжай жолағында ешқашан болмаған атаумен сәтсіз аяқталады. Бұл алшақтық — бүкіл мәселе: бет бір URL-ден келді, ал қызмет келесі сұранысты басқа URL-ден құрастырды. Жарияланған URL — сервер жағындағы шешім, сондықтан оны клиентте түзету — қате ұш. DNS-ке немесе маршруттарға қол тигізбес бұрын қызмет қай атауды қайтаратынын тексеріңіз.

Бірінші бет пен келесі сұраныс әртүрлі атауларды пайдаланады

Серверге мекенжай арқылы жеткен пайдаланушы жұмыс істейтін басты бетті көреді. Сол беттегі құжат сілтемелері қызмет жариялап жатыр деп есептейтін URL-ден жасалады, браузер тергеннен емес. Егер олар өзгеше болса, келесі басу клиент ешқашан шешпеген атауға барады.

Мекенжайды бір рет енгізу әрбір жасалған сілтемені түзетпейді, ал мекенжайға қойылған бетбелгі құжат ашылғанша мәселені жасырады.

Бұл ақауды VPN мәселесі деп қате оқу оңай, өйткені ол тек туннель пайдаланылғаннан кейін көрінеді. Іс жүзінде туннель өз жұмысын істеп тұр: ол сұранысты жұмыс істейтін жолы немесе сәйкес сертификаты жоқ атауға апарады. Екеуін де өзгертуден бұрын екі сұрақты ажыратыңыз. Бірі — пакеттің қайда баратыны, екіншісі — қызметтің қай атауды жариялауды таңдағаны.

Төрт бақылау, бір атау

Әрбір жарияланған атау төрт тәуелсіз бақылаудан өтуі керек. DNS оны нақты клиент үшін шешуі керек, маршруттау мен рұқсат саясаты жолды рұқсат етуі керек, TLS сол атауды растауы керек, ал қызмет оны жариялауға конфигурациялануы керек.

Бір бақылауға енгізілген өзгеріс қалғандарын орындамайды. Сертификат ескертуін қабылдау атауды шешуді жөндеу емес.

Төмендегі кесте — тексеру тізімінің реті. Сәтсіз болатын бірінші жолда тоқтаңыз, өйткені кейінгі түзету бұрынғы олқылықты өтей алмайды.

ControlQuestionWhere to look
DNSCan the client resolve the published name?Client resolver and split-DNS policy
Route and policyDoes the permitted path exist to the service?VPN routes and firewall rules
TLS identityDoes the certificate match the name in use?Certificate subject names and trust store
Publishing configWhich 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-ге қатысты емес.

Қатысты мақалалар