SharePoint لنکس شائع شدہ URL کی وجہ سے VPN پر ٹوٹ جاتے ہیں
VPN کے ذریعے لوڈ ہونے والا SharePoint صفحہ اب بھی ایسے نام پر دستاویز لنکس واپس کر سکتا ہے جسے آپ کا کلائنٹ حل نہیں کر سکتا۔ DNS، راستہ، TLS اور شائع شدہ URL چیک کریں۔
VPN کے ذریعے SharePoint صفحہ کھلتا ہے، اور پہلا دستاویز لنک ایسے نام کے ساتھ ناکام ہوتا ہے جو کبھی ایڈریس بار میں نہیں تھا۔ یہی خلا پورا مسئلہ ہے: صفحہ ایک 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 کے بارے میں نہیں ہے۔