PPTP ত্রুটি 800 বনাম 812 এবং এক মিনিট পরে সংযোগ বিচ্ছিন্ন হওয়া

একটি PPTP ক্লায়েন্টের তিনটি ত্রুটি বার্তা সাধারণত তিনটি আলাদা ত্রুটি বোঝায়। ত্রুটি 800 মানে টানেল কখনোই তৈরি হয়নি, ত্রুটি 812 মানে সার্ভার প্রমাণীকরণ পদ্ধতি প্রত্যাখ্যান করেছে, আর এক মিনিট পরে বিচ্ছিন্ন হওয়া মানে একটি কীপঅ্যালাইভ টাইমার স্থির করেছে যে সুস্থ পিয়ার চলে গেছে। প্রতিটি স্তর নিজের কারণে ব্যর্থ হয়, তাই প্রতিটির নিজস্ব পরীক্ষা দরকার।

ত্রুটি 800 মানে টানেল কখনোই তৈরি হয়নি

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

আপনার নিজের ল্যানের বাইরে থেকে সেই বাইরের পথটি পরীক্ষা করুন, কারণ অফিসের ভিতরে কাজ করা সংযোগ প্রান্ত সম্পর্কে কিছুই প্রমাণ করে না:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

যদি 1723 উত্তর দেয় আর ক্লায়েন্ট সংযোগ করার চেষ্টা করার সময় ক্যাপচার খালি থাকে, তবে পথটি প্রোটোকল 47 ফেলে দিচ্ছে। এমন রাউটার যেখানে 1723 ফরোয়ার্ড করা কিন্তু PPTP পাসথ্রু বন্ধ, ঠিক এই ধরনের চিত্র দেয়: TCP হ্যান্ডশেক সম্পন্ন হয়, তারপর GRE প্যাকেটগুলি অদৃশ্য হয়ে যায়, ফলে ব্যর্থতাটি শংসাপত্রের সমস্যার মতো দেখায় যদিও কোনো লগইন চেষ্টা করা হয়নি।

ফরোয়ার্ডটি সার্ভারের বর্তমান ল্যান ঠিকানায় নির্দেশ করুন, রাউটার যেখানে সুবিধা দেয় সেখানে PPTP পাসথ্রু চালু করুন, এবং একই বাইরের অবস্থান থেকে আবার চেষ্টা করুন। যখন GRE উজানে ফিল্টার হয় আর আপনি তা বদলাতে পারেন না, তখন TCP 443-এর উপর SSTP বা UDP 500 ও 4500-এর উপর L2TP/IPsec-এর Windows-এর দিকে আপনি যে কোনো পরিবর্তন করতে পারেন তার চেয়ে ভালো সম্ভাবনা আছে।

ত্রুটি 812 মানে সার্ভার আপনার প্রমাণীকরণ পদ্ধতি প্রত্যাখ্যান করছে

ত্রুটি 812 টানেল চালু হওয়ার পরে ফিরে আসে, তাই এটি পাসওয়ার্ডের সমস্যার মতো মনে হয়। সার্ভার সংযোগের জন্য নির্ধারিত প্রমাণীকরণ পদ্ধতিটি প্রত্যাখ্যান করছে, অগত্যা পাসওয়ার্ডটি নিজে নয়। ক্লায়েন্টে VPN এন্ট্রি খুলুন, নিরাপত্তা ট্যাবে যান, ধরনটি Point-to-Point Tunneling Protocol-এ সেট করুন, স্পষ্ট প্রোটোকল তালিকা বেছে নিন এবং Microsoft CHAP সংস্করণ 2 টিক দিন।

ডায়ালগে ক্লিক না করেই বর্তমান সেটিং পড়তে পারেন:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

যে সার্ভার MS-CHAP v2 চায় সে PAP-এ বা স্বয়ংক্রিয় ধরনে থাকা ক্লায়েন্টকে প্রত্যাখ্যান করে, কারণ সেটি দুর্বল কিছু নিয়ে আলোচনা করে, আর কোনো ব্যবহারকারীর পাসওয়ার্ড মূল্যায়নের আগেই ত্রুটিটি আসে। অ্যাকাউন্টের বিন্যাস একই প্রত্যাখ্যানের অন্য অর্ধেক। এক ক্ষেত্রে Windows MicrosoftAccount\[email protected] আকৃতির একটি Microsoft অ্যাকাউন্ট পরিচয় পাঠিয়েছিল, অথচ সার্ভার চেয়েছিল স্থানীয় বা ডোমেইন অ্যাকাউন্ট। SERVERNAME\username টাইপ করলে Windows-কে বলা হলো কোন অ্যাকাউন্ট স্টোর দেখতে হবে, আর ত্রুটিটি চলে গেল। সংরক্ষিত শংসাপত্রকে আগের বিন্যাস পুনরাবৃত্তি করতে দেওয়ার বদলে নামটি হাতে লিখুন।

এক মিনিট পরে বিচ্ছিন্ন হওয়া একটি কীপঅ্যালাইভ সিদ্ধান্ত

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

Linux pptpd সার্ভারে সেই মানগুলি /etc/ppp/options.pptpd-এ থাকে, আর স্বাভাবিক সমাধান হলো ব্যবধান ছোট করার বদলে বাজেট বাড়ানো:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

পাঁচ সেকেন্ডের ব্যবধানে ত্রিশটি মিস একটি সংক্ষিপ্ত থেমে যাওয়াকে ক্ষমা করে, পিয়ারকে চলে গেছে ঘোষণা করার বদলে। সংখ্যাটি এক বা দুইয়ে নামালে একটি অনুবাদিত পথে সাধারণ জিটার প্রায় প্রতি মিনিটে বিচ্ছিন্নতায় পরিণত হয়। আপনার সার্ভার যদি pptpd-এর বদলে Windows RRAS হয়, তবে বরং PPP সেশন টাইমআউট ও নিষ্ক্রিয় থাকলে বিচ্ছিন্ন করার নীতি দেখুন। সেগুলি অন্য জায়গায় থাকে, আর যে pppd ফাইল নেই তা সম্পাদনা করলে কিছুই বদলাবে না।

ওভারল্যাপিং সাবনেট ডেটা পথ ভাঙে

একটি PPTP টানেল পরিষ্কারভাবে প্রমাণীত হতে পারে এবং তবুও কিছুই পৌঁছাতে পারে না যখন দুই সাইট একই ব্যক্তিগত রেঞ্জ ব্যবহার করে, যেমন অফিসে ও বাড়িতে 192.168.1.0/24। ক্লায়েন্ট বলতে পারে না একটি নির্দিষ্ট ঠিকানা কোন হোস্ট বোঝায়, আর কিছু স্ট্যাক একটি বেছে নেওয়ার বদলে রুটটি একেবারেই ইনস্টল করতে অস্বীকার করে।

এটিকে নকশার ত্রুটি ধরে এক পাশ পুনঃসংখ্যায়িত করুন, বা ক্লায়েন্টকে ইচ্ছাকৃতভাবে অনূদিত অ্যাক্সেস রেঞ্জ দিন। PPTP ক্লায়েন্ট ডিবাগ করে দুইবার বিদ্যমান ঠিকানা স্থান ঠিক করা যায় না, আর উপসর্গটি এলোমেলো বিচ্ছিন্নতার মতোই দেখাবে।

যে স্তরটি ব্যর্থ হয়েছে সেখান থেকে শুরু করুন: 800-এর জন্য GRE, 812-এর জন্য পদ্ধতি ও অ্যাকাউন্ট স্ট্রিং, সময়সূচি অনুযায়ী মারা যাওয়া টানেলের জন্য ইকো সেটিংস।