PPTP পাসথ্রু নেই: Windows VPN এর 807 ত্রুটি সারান
শুধু TCP 1723 ফরোয়ার্ড করলে PPTP এর 807 ত্রুটি মিটে যায় না। GRE হলো IP প্রোটোকল 47, তাই রাউটারের পাসথ্রু বা স্পষ্ট প্রোটোকল নিয়ম দরকার।
TCP 1723 ফরোয়ার্ড করলে প্রায়ই PPTP এর প্রথম অংশ ঠিক হয় আর বাকিটা ভাঙা থাকে, তাই Windows চেষ্টা করলেই আবার 807 ত্রুটি দেয়। পরের প্রবৃত্তি হলো পোর্ট 47 এর জন্য নিয়ম যোগ করা, আর ঠিক এই ধাপেই একটা দুপুর নষ্ট হয়: GRE হলো IP হেডারের একটি প্রোটোকল নম্বর, কোনো পোর্ট নয় যা ফরোয়ার্ডিং টেবিল মেলাতে পারে। রাউটার প্রোটোকল 47 পাস না করা পর্যন্ত এবং সেটিকে একই কলে বেঁধে না দেওয়া পর্যন্ত টানেল শুরু হতে পারে না। নিচের অংশগুলো দুটি চ্যানেল আলাদা করে, তারপর এক এক করে পরীক্ষা করে।
পোর্ট টেবিলে প্রোটোকল নম্বরের কোনো সারি নেই
PPTP দুটি কথোপকথন ব্যবহার করে যা ভিন্নভাবে ব্যর্থ হয়। TCP 1723 এর কথোপকথন কলটি শুরু করে, লিংকের তথ্য পাঠায় এবং ব্যবহারকারী সংযোগ কাটলে সেটি বন্ধ করে। পেলোডের দিকটি GRE এর ভিতরে চলে, যা IP হেডার প্রোটোকল নম্বর 47 দিয়ে চিহ্নিত করে, আর সেই টানেলের ভিতরে PPP লিংক নিয়ে দরকষাকষি করে যখন MS-CHAPv2 পরিচয়পত্র যাচাই করে।
যেহেতু GRE কোনো ট্রান্সপোর্ট হেডার বহন করে না, তাই এটি কোনো পোর্ট প্রকাশ করে না, ফলে পোর্টের জন্য লেখা নিয়মের মেলানোর কিছু থাকে না। যে রাউটার 1723 ফরোয়ার্ড করে, সে ওই TCP সেশনের জন্য একটি ম্যাপিং তৈরি করে এবং সেখানেই থেমে যায়। যে ফার্মওয়্যার দ্বিতীয় অর্ধেক সামলায়, সে এই বৈশিষ্ট্যকে PPTP পাসথ্রু বা PPTP ALG বলে, আর কিছু ফার্মওয়্যার দুটির কোনোটিই দেয় না এবং ফাঁকটির কথা কখনো বলে না। চেকবক্সের লেবেলের চেয়ে প্রোটোকল 47 আদৌ স্বীকৃত কি না সেটাই বেশি জরুরি।
ডেটা পথ মরে গেলে Windows কী জানায়
807 ত্রুটি বলে সংযোগটি সম্পূর্ণ করা যায়নি, যার মানে বাস্তবে কলটি সার্ভারে পৌঁছেছে কিন্তু ডেটা চ্যানেল ওঠেনি। এটি অ্যাকাউন্ট সম্পর্কে নয়, ট্রান্সপোর্ট সম্পর্কে রায়। 691 ত্রুটি হলো সেইটি যা পরিচয়পত্র বা প্রমাণীকরণ প্রোটোকলের অমিলের দিকে ইঙ্গিত করে, তাই এটি আপনাকে সম্পূর্ণ অন্য জায়গায় পাঠায়।
পাসওয়ার্ডে হাত দেওয়ার আগে ট্রান্সপোর্ট নিয়ে কাজ করুন। 807 এর পেছনে ছুটে পরিচয়পত্র বদলালে আসল ত্রুটি জায়গাতেই থাকে এবং পরের চেষ্টা পড়তে আরও কঠিন হয়।
কেন দ্বিতীয় ক্লায়েন্ট কাজ করা টানেল ভেঙে দেয়
তাদের আলাদা করার কোনো পোর্ট না থাকায় NAT ডিভাইস দুটি HTTPS সেশন যেভাবে আলাদা করে, সেভাবে দুটি PPTP ক্লায়েন্ট আলাদা করতে পারে না। তাই অনেক ভোক্তা ডিভাইস একটি PPTP কল অনুমোদন করে এবং উৎস ঠিকানা দিয়ে সেটি ট্র্যাক করে। যে ল্যাপটপ একা কাজ করত, দ্বিতীয় মেশিন ডায়াল করলেই সেটি সম্পূর্ণ হওয়া বন্ধ করে দেয়, আর ক্লায়েন্টের দিক থেকে ব্যর্থতাটি এলোমেলো দেখায়। এই ধরনটি ফার্মওয়্যারের, এবং কোনো প্রোফাইল পরিবর্তনই তা বদলাবে না।
দুই ক্লায়েন্ট ডায়াল করার সময় সংযোগ তালিকাটি দেখুন। যদি কেবল প্রথম হোস্টই কখনো ম্যাপিং ধরে রাখে, তবে রাউটার তার সমর্থনের সীমায় পৌঁছে গেছে এবং ক্লায়েন্টের কোনো সেটিংই তা সরাবে না।
কোন অর্ধেক ব্যর্থ হচ্ছে তা প্রমাণ করুন
রাউটারে কিছু বদলানোর আগে নিশ্চিত করুন TCP 1723 পৌঁছাচ্ছে, কারণ সেই উত্তরই ঠিক করে আপনি কোন অর্ধেক পরীক্ষা করছেন। এগুলো Windows ক্লায়েন্ট থেকে আপনার নিজের সার্ভার নামের বিপরীতে চালান। প্রথমটি ছাপে পোর্টটি উত্তর দিয়েছে কি না, আর দ্বিতীয়টি কোনো ডায়ালগ ছাড়াই ডায়াল করে, যা বারবার চেষ্টাকে তুলনাযোগ্য করে।
Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"
পোর্ট পরীক্ষায় সত্য ফল মানে নিয়ন্ত্রণ চ্যানেল খোলা এবং GRE ই অবশিষ্ট সন্দেহভাজন। মিথ্যা ফল মানে রাউটিং, ফিল্টার বা ফরোয়ার্ড ভাঙা, এবং GRE এর কোনো পরিবর্তনই তা উদ্ধার করবে না। ডেটার দিকটি যেখানে দেখা যায় সেখানেই দেখতে হবে, সার্ভারের প্রান্তে বা রাউটারে।
tcpdump -ni any proto 47
Wireshark এর সমতুল্য হলো ডিসপ্লে ফিল্টার ip proto 47, যা শেল-এ স্বচ্ছন্দ নয় এমন কাউকে দেওয়া সহজ। কোনো উত্তর ছাড়াই GRE এলে বোঝায় ফেরার পথটি ঠিক করতে হবে।
কীভাবে ত্রুটিটি সত্যিই সারানো যায়
যেখানে রাউটার সেটিংটি দেখায়, সেখানে PPTP পাসথ্রু চালু করুন, বা নিয়ম গ্রহণ করে এমন ফার্মওয়্যারে প্রোটোকল 47 স্পষ্টভাবে অনুমোদন করুন। RouterOS-এ ফরোয়ার্ড নিয়মটি সরাসরি প্রোটোকলের সঙ্গে মেলে, যা পোর্ট-ভিত্তিক ফরোয়ার্ড কখনোই করতে পারত না। ভোক্তা ফার্মওয়্যার সাধারণত একই সিদ্ধান্ত একটি চেকবক্সের পেছনে লুকায়, কখনো পোর্ট ফরোয়ার্ডিংয়ের বদলে নিরাপত্তা সেটিংসের নিচে। এমন কোনো নিয়ন্ত্রণ না থাকলে ক্লায়েন্টের কিছুই তা পূরণ করবে না।
/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre
PPTP বদলানো হলো অন্য বিকল্প এবং প্রায়ই সস্তা। যে রাউটার নিজেই VPN শেষ করে, সে আগত ক্লায়েন্টদের জন্য দ্বৈত NAT এড়ায়, আর পোর্ট-ভিত্তিক NAT যেই প্রোটোকল ইতিমধ্যেই সামলায় তার কোনো পাসথ্রুই লাগে না: UDP এর উপর OpenVPN, TCP 443 এর উপর SSTP, বা NAT-T সহ L2TP/IPsec যা ESP কে UDP 4500 এ মুড়ে দেয়। PPTP নির্ভর করে MS-CHAPv2 এর উপরও, যার নথিভুক্ত দুর্বলতাগুলো ত্রুটি সরে যাওয়ার পরেও এটিকে নতুন স্থাপনার জন্য খারাপ পছন্দ করে তোলে।
কোন নিয়মটি পার্থক্য তৈরি করল তা লিখে রাখুন, কারণ দ্বিতীয় ব্যবহারকারী প্রবেশ চাইলে একই সাইট একই সীমার মুখে পড়বে। প্রোটোকল পর্যায়ের সমাধান নেটওয়ার্ক নোটে থাকা উচিত, যেখানে পরের প্রকৌশলী তাকাবেন।