SharePoint-ის ბმულები VPN-ზე ვერ იხსნება გამოქვეყნებული URL-ების გამო
VPN-ით ჩატვირთული SharePoint გვერდი შეიძლება კვლავ დააბრუნოს დოკუმენტის ბმულები ისეთი სახელით, რომელსაც თქვენი კლიენტი ვერ გადაწყვეტს. შეამოწმეთ DNS, მარშრუტი, TLS და გამოქვეყნებული URL.
SharePoint გვერდი VPN-ით იხსნება, და პირველი დოკუმენტის ბმული ვერ მუშაობს ისეთი სახელით, რომელიც არასდროს ყოფილა მისამართების ზოლში. ეს უფსკრული მთელი პრობლემაა: გვერდი ერთი URL-იდან მოვიდა, ხოლო სერვისმა შემდეგი მოთხოვნა სხვა 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-ზე აღარ არის.