আপনার স্প্লিট টানেল অ্যাপে পৌঁছায় কিন্তু তার DNS সার্ভারে নয়
একটি স্প্লিট টানেল অ্যাপের সাবনেট রুট করতে পারে এবং তবুও তার পাশের রিজলভারটি ফেলে দিতে পারে। হোস্ট রুটটি যোগ করুন, তারপর দেখুন Windows আসলে কোন সার্ভার বেছে নেয়।
অ্যাপ্লিকেশনের সাবনেট রুট করা স্প্লিট টানেলের স্পষ্ট অংশ, এবং এটিই পুরো কাজ নয়। রিজলভার প্রায়ই যে অ্যাপ্লিকেশনকে সেবা দেয় তার থেকে ভিন্ন ঠিকানায় থাকে, তাই কাজ করা টানেলও লুকআপটিকে তার বাইরে রেখে দিতে পারে। যে প্রোফাইল 10.80.0.0/16 বহন করে এবং আর কিছু না, সেটি 10.90.0.53-এর জন্য কোয়েরিটি স্থানীয় ইন্টারফেস দিয়ে পাঠায়, যেখানে কোনো প্রাইভেট জোন নেই। রিজলভারের পথটি যোগ করুন, তারপর সমস্যার দ্বিতীয় অংশটি দেখুন: ক্লায়েন্ট আসলে কোন সার্ভার বেছে নেয়।
মিথ: একটি রুটই পুরো সেবা ঢেকে দেয়
স্প্লিট টানেল হলো সংযোগের মধ্য দিয়ে যাওয়া গন্তব্যের একটি তালিকা, কোনো সেবার বর্ণনা নয়। অ্যাপ্লিকেশনের সাবনেট এবং রিজলভারের ঠিকানা দুটি গন্তব্য, এবং একটি প্রোফাইল একটি ছাড়া অন্যটি বহন করতে পারে। যখন তা ঘটে, অ্যাপ্লিকেশন ঠিকানা দিয়ে পৌঁছানো যায় কিন্তু তার নাম ব্যর্থ হয়, যা রাউটিং ফাঁকের বদলে DNS ত্রুটির মতো দেখায়।
রিজলভারের চারপাশের সাবনেটও স্বয়ংক্রিয়ভাবে ঢাকা পড়ে না। একটি ঠিকানার জন্য হোস্ট রুট সেই রিজলভারের জন্য যথেষ্ট এবং তার প্রতিবেশীদের খোলে না। হোস্ট রুটের অর্থ এটাই: নকশায় সংকীর্ণ, এবং পরের সেবাটি একই সাবনেটে এলে ভুলে যাওয়া সহজ।
লুকআপ কাজ করার জন্য তিনটি বিষয় সত্য হতে হবে: ক্লায়েন্ট রিজলভারের ঠিকানাটি টানেল দিয়ে রুট করে, গেটওয়ে সেই অনুরোধ গ্রহণ করে ও পাঠিয়ে দেয়, এবং রিজলভার যে উৎস পায় তা গ্রহণ করে। উত্তরটিও সম্মত পথে ফিরে আসতে হবে। এর একটি বাদ পড়লে লক্ষণ একই থাকে, তাই কনফিগারেশন স্পর্শ করার আগে ঠিকানা তালিকাটি লিখে রাখা মূল্যবান।
প্রোফাইলে কোন ঠিকানাগুলো থাকতে হবে তা নির্ধারণ করুন
গন্তব্যগুলো ক্রমে তালিকাভুক্ত করুন: অ্যাপ্লিকেশন নেটওয়ার্ক, রিজলভারের ঠিকানা এবং পাবলিক এন্ডপয়েন্ট যা টানেলটিকেই সমাপ্ত করে। তৃতীয়টি কখনোই টানেলের ভেতরে রুট করা যাবে না, কারণ বাইরের সংযোগের এমন পথ দরকার যা টানেলের আগেই বিদ্যমান।
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
DNS-এর জন্য UDP ও TCP দুটিই অন্তর্ভুক্ত করুন, কারণ বাস্তবায়ন থেকে UDP-এর পাশাপাশি TCP সমর্থন আশা করা হয়, আর অবরুদ্ধ TCP পথ পরিষ্কার ব্যর্থতার বদলে ধীর, আংশিক ব্যর্থতা তৈরি করে। প্রাইভেট জোনটি যদি IPv6-এর মাধ্যমেও পরিবেশিত হয়, তাহলে সমতুল্য হোস্ট ব্যতিক্রমটি IPv6 ঠিকানা ও প্রিফিক্স ব্যবহার করে এবং এটি আলাদা এন্ট্রি।
কিছু যোগ করার আগে প্রোফাইল ইতিমধ্যে কী ঢাকে তা লিখে রাখুন। নকল রুট ক্ষতিকর নয়, কিন্তু অপ্রত্যাশিত বিদ্যমান রুট আপনাকে বলে প্রোফাইলটি আপনার পাওয়া ঠিকানা পরিকল্পনার চেয়ে ভিন্ন পরিকল্পনার জন্য নকশা করা হয়েছে।
সংযোগের মালিকের মাধ্যমে হোস্ট রুট যোগ করুন
স্থানীয়ভাবে পরিচালিত নেটিভ Windows প্রোফাইলে রুটটি মেশিনের বৈশ্বিক রাউটিং টেবিলের বদলে সংযোগের অন্তর্গত। প্রথমে সংযোজনটি প্রিভিউ করুন, তারপর প্রোফাইল যে সুযোগ ব্যবহার করে একই সুযোগে তা প্রয়োগ করুন।
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
প্রথম কমান্ডটি কিছু ইনস্টল না করেই পরিবর্তনটি প্রিভিউ করে, আর দ্বিতীয়টি প্রোফাইল বর্তমানে যে রুটগুলো বহন করে তা তালিকাভুক্ত করে। Microsoft-এর Add-VpnConnectionRoute-এর রেফারেন্স প্রতি-ব্যবহারকারী ও সর্ব-ব্যবহারকারী সুযোগগুলো নথিভুক্ত করে; সর্ব-ব্যবহারকারী প্রোফাইলের নিজস্ব সুযোগ প্যারামিটার প্রয়োজন, এবং সর্ব-ব্যবহারকারী প্রোফাইলের বিরুদ্ধে প্রতি-ব্যবহারকারী কমান্ড ব্যর্থ হয় বা ভুল জায়গায় পড়ে।
প্রোফাইলটি পরিচালিত হলে বা ভেন্ডর ক্লায়েন্ট থেকে এলে পরিবর্তনটি সেই মালিকের। সংযোগ নীতির ওপরে স্থায়ী সিস্টেম রুট স্তূপ করা কাজ করে যতক্ষণ না নীতি আবার প্রয়োগ হয় এবং রুটটি হারিয়ে যায়, যা সাধারণত পরীক্ষার সময় নয়, সাপোর্ট কলের সময় ঘটে। এই ব্যর্থতা নীরব: রুটটি অদৃশ্য হয়, নামটি সমাধান হওয়া বন্ধ করে, এবং কেউ দুটি ঘটনা মেলায় না। পরিবর্তনটি মালিকের নিজের রেকর্ডে রাখুন যাতে পরবর্তী পুনঃপ্রয়োগ তা মুছে ফেলার বদলে বহন করে।
প্রয়োগের পরে রুটটি কার্যকর হয়েছে ধরে নেওয়ার বদলে প্রোফাইলটি আবার সংযুক্ত করুন। সচল সংযোগে রুট পরিবর্তন সবসময় ধরা পড়ে না, এবং পুনঃসংযোগ আপনার ব্যবহারকারীরা আসলে যে অবস্থায় থাকবেন তা পুনরুৎপাদনও করে।
ক্লায়েন্ট আসলে কোন রিজলভার ব্যবহার করেছে তা পরীক্ষা করুন
একটি রুট রিজলভারে ঠিকানাযুক্ত প্যাকেট নিয়ন্ত্রণ করে। কোন নামগুলো সেখানে পাঠানো উচিত তা এটি নির্ধারণ করে না, এবং সেই নির্বাচন আলাদা প্রক্রিয়া। Windows-এ কার্যকর নেমস্পেস নিয়ম প্রতিটি ডোমেইনের জন্য একটি রিজলভার বেছে নিতে পারে, আর প্রোফাইলের DNS সেটিংস একটি ডিফল্ট সরবরাহ করে। এই দুটি স্তর কোনো ত্রুটি না তৈরি করেই মতানৈক্য করতে পারে, তাই সরাসরি কোয়েরি প্রমাণের অর্ধেক মাত্র।
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
প্রথম কমান্ডটি বলবৎ নেমস্পেস নীতি মুদ্রণ করে, আর দ্বিতীয়টি প্রাইভেট রিজলভারকে সরাসরি অ্যাপ্লিকেশনের নাম জিজ্ঞাসা করে। সরাসরি উত্তর প্রমাণ করে পথ ও রিজলভার কাজ করে; এটি প্রমাণ করে না যে অ্যাপ্লিকেশনের নিজের লুকআপ সেই সার্ভার বেছে নিয়েছে। এটিকে একই নামের সাধারণ লুকআপ এবং অ্যাপ্লিকেশন যে উত্তর পায় তার সঙ্গে তুলনা করুন।
ক্যাশে এবং ব্রাউজার-স্তরের সিকিউর DNS হিসাব করুন, যা ব্যবহারকারীর টাইপ করা নামের জন্য সিস্টেম রিজলভারকে সম্পূর্ণভাবে এড়িয়ে যেতে পারে। সার্চ সাফিক্স আরেকটি বিভ্রান্তি: এটি সংক্ষিপ্ত নামকে পূর্ণভাবে যোগ্য নামে প্রসারিত করে এবং কোন সার্ভার উত্তর দেয় তার সঙ্গে কোনো সম্পর্ক নেই।
শেষে আবার সংযুক্ত হয়ে সাধারণ লুকআপ পুনরাবৃত্তি করুন, তারপর নিশ্চিত করুন সাধারণ ব্রাউজিং এখনও তার অনুমোদিত নীতি অনুসরণ করে। অসংলগ্ন একটি নাম সমাধান করতে প্রাইভেট রিজলভারকে পাবলিক দিয়ে প্রতিস্থাপন করা কোনো সমাধান নয়, এবং এটি প্রাইভেট কোয়েরিগুলোকে নিঃশব্দে এমন জায়গায় সরিয়ে দেয় যেখানে তাদের কখনো যাওয়ার কথা ছিল না।