হটস্পটের মাধ্যমে PPTP: TCP 1723 কেবল অর্ধেক

পরীক্ষাগুলো ক্রমানুসারে করুন: নিয়ন্ত্রণ সংযোগ খোলে কি না, GRE পথে টিকে থাকে কি না, সার্ভার কলটি গ্রহণ করে কি না, এবং প্রমাণীকরণ সম্পূর্ণ হয় কি না। একটি PPTP ক্লায়েন্টের 1723-এ TCP সেশন এবং ডেটা বহনকারী GRE পথ—দুটোই দরকার, আর একটি হটস্পট একটি পার করে অন্যটি ফেলে দিতে পারে। ক্রমানুসারে করলে অনুমান না করে কোন সীমানা তদন্ত করতে হবে তা জানা যায়। Windows-এর ত্রুটি নম্বর তা আপনার জন্য করে না।

GRE হলো IP প্রোটোকল 47। এটি TCP বা UDP পোর্ট 47 নয়, আর এই পার্থক্যই ফায়ারওয়াল নিয়ে বেশিরভাগ বিভ্রান্তির ব্যাখ্যা দেয়।

দুই পথ, এক সংযোগ

নিয়ন্ত্রণ সংযোগটি গন্তব্য পোর্ট 1723-এ একটি সাধারণ TCP সেশন, যা বেশিরভাগ নেটওয়ার্ক বিনা আপত্তিতে অনুমোদন করে। ডেটা পথটি GRE, প্রোটোকল 47, আর প্রথমটি অনুমোদনকারী ফায়ারওয়াল দ্বিতীয়টি সম্পর্কে সম্পূর্ণ অজ্ঞ থাকতে পারে। এই সমন্বয় এমন ক্লায়েন্ট তৈরি করে যা শুরু হয়েছে মনে হয় কিন্তু কিছুই বহন করে না—প্রত্যাখ্যাত সংযোগের চেয়ে অনেক কম তথ্যবহুল লক্ষণ। অপারেটর সম্পর্কে কিছু সিদ্ধান্তে আসার আগে দুই পথ আলাদাভাবে পরীক্ষা করুন।

অনুবাদ নিজের শর্ত যোগ করে। পোর্ট ভাগাভাগি করা গেটওয়ে-গুলোর প্রায়ই PPTP-সচেতন ALG দরকার হয়, যাতে কল শনাক্তকারীগুলো ঠিকানার সঙ্গে পুনর্লিখন করা যায়, আর তা ছাড়া একটি গেটওয়ে সেশনকে প্যাকেট হারানোর মতো দেখতে ভাবে নষ্ট করতে পারে। এই আচরণ সাধারণ কিন্তু বাস্তবায়ন-নির্ভর, তাই যেকোনো ভেন্ডর সীমাকে প্রতিটি হটস্পটের বৈশিষ্ট্য নয়, উদাহরণ হিসেবে ধরুন।

হটস্পট আরও দুই সীমানা যোগ করে

ক্লায়েন্ট ট্রাফিক সাধারণত ফোনের নিজস্ব শেয়ারিং NAT এবং তারপর অপারেটর-স্তরের অনুবাদ পার হয়ে সার্ভারে পৌঁছায়। অফিস রাউটারের একটি নিয়ম অন্য কারও মালিকানাধীন মিডলবক্স মেরামত করতে পারে না, তাই বাড়ির দিকের পোর্ট ফরওয়ার্ডিং খুব কমই কাজে লাগে। বেরিয়ে যাওয়া ক্লায়েন্টের জন্যও অন্তর্মুখী পোর্ট খোলার দরকার নেই; অনূদিত সংযোগের উত্তর গেটওয়ে যে অবস্থা তৈরি করেছে তার মধ্য দিয়ে ফিরে আসে। NAT-এর পিছনে হোস্ট করা সার্ভারের সম্পূর্ণ ভিন্ন প্রয়োজনীয়তা রয়েছে।

PPTP passthrough নামের একটি মেনু আইটেম, যেখানে আছে, সেই ডিভাইসটি এই প্রোটোকল কীভাবে সামলায় তা নির্ধারণ করে। এটি ফোনে VPN হোস্ট করা বা প্রতিটি প্রোটোকল নিঃশর্তে ফরওয়ার্ড করার একই বৈশিষ্ট্য নয়, আর এটি চালু করা GRE পার করার সাধারণ অনুমতি নয়।

807-কে রায় নয়, বিচ্ছেদ হিসেবে পড়ুন

Windows 807-কে একটি বিচ্ছিন্ন সংযোগ হিসেবে জানায়, যা কারণ নয় ফলাফল বর্ণনা করে। এর ত্রুটি তালিকা 806-কে GRE-সম্পর্কিত শ্রেণি হিসেবে আলাদা করে, আর তত্ত্ব গড়ার আগে এই পার্থক্য জানা ভালো। কোনো সংখ্যাই প্রকাশ করে না অপারেটর প্রোটোকল 47 ফিল্টার করেছে কি না, সার্ভারের ধারণক্ষমতা শেষ হয়েছে কি না, বা শংসাপত্র ঠিক ছিল কি না। ত্রুটি বলে সেশন শেষ হয়েছে; পথ বলে কোথায়।

হটস্পটে সফল একটি ব্রাউজার পরীক্ষা কেবল প্রমাণ করে সাধারণ অ্যাপ্লিকেশন পথ কাজ করে। এটি GRE সম্পর্কে কিছুই বলে না।

ব্যর্থ হওয়া ধাপটি আলাদা করুন

ল্যাপটপ, সার্ভার ও প্রোফাইল অপরিবর্তিত রাখুন, তারপর কেবল অ্যাক্সেস নেটওয়ার্কটি অন্য অনুমোদিত একটিতে বদলান। ফলাফল বদলালে, আপনার নিয়ন্ত্রণাধীন সীমানায় TCP ও GRE বিনিময় ধারণ করুন এবং যে প্রাচীনতম ধাপটি কখনো ঘটে না তা খুঁজুন: নিয়ন্ত্রণ প্রতিষ্ঠা, কল সেটআপ, ডেটা বিতরণ, বা PPP প্রমাণীকরণ। প্রত্যেকটি ক্যাপচারে ভিন্ন স্বাক্ষর রাখে। কাজ করা নেটওয়ার্কের সঙ্গে ব্যর্থ একটির তুলনা ত্রুটির লেখা আবার পড়ার চেয়ে অনেক বেশি তথ্যবহুল।

এসবই ইতিমধ্যে বিদ্যমান একটি স্থাপনার রোগনির্ণয়। এটি নতুন PPTP সেবা দাঁড় করানোর পক্ষে যুক্তি নয়, আর প্রোটোকলটি দর-কষাকষি করে এড়ানো যায় না: ভিন্ন ক্লায়েন্ট ইনস্টল করলে অপরিবর্তিত সার্ভার অন্য কিছু বলতে শুরু করে না।

চলমান অ্যাক্সেসের জন্য, VPN-এর মালিকের সঙ্গে একটি সমর্থিত মাইগ্রেশনে সম্মত হন। চেকলিস্টটি একটি সমাধান নয়, একটি সিদ্ধান্ত দিয়ে শেষ হয়।