SharePoint লিঙ্কগুলি VPN-এ ভেঙে যায় প্রকাশিত URL-এর কারণে
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-এর বিষয়ে নয়।