ลิงก์ SharePoint ใช้ไม่ได้ผ่าน VPN เพราะ URL ที่เผยแพร่
หน้า SharePoint ที่โหลดผ่าน VPN ยังอาจคืนลิงก์เอกสารด้วยชื่อที่ไคลเอนต์ของคุณแก้ไม่ได้ ตรวจสอบ 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 อีกต่อไป