د SharePoint لینکونه د خپرې شوې URL له امله د VPN له لارې ماتېږي
د VPN له لارې بارېدونکې SharePoint پاڼه لا هم کولای شي د هغه نوم سره د سند لینکونه بیرته راوګرځوي چې ستاسو کلاینټ یې نشي حل کولای۔ DNS، لار، TLS او خپره شوې URL وګورئ۔
د VPN له لارې د SharePoint پاڼه پرانیستل کیږي، او لومړی د سند لینک د هغه نوم سره ناکام کیږي چې هیڅکله په پته پټه کې نه و۔ دا تشی هغه ټوله ستونزه ده: پاڼه له یوې 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 په اړه نه ده۔