پیوندهای SharePoint به دلیل URLهای منتشرشده از طریق VPN خراب می‌شوند
صفحه 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 نیست.