PPTP-তে LCP সমকক্ষ দ্বারা সমাপ্ত: আগে MPPE চালু করুন

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

LCP ব্যর্থতা PPP পর্যায় সম্পর্কে কী বলে

PPTP GRE-এর ভেতরে PPP মুড়ে দেয়: TCP 1723 নিয়ন্ত্রণ সংযোগ কলটি স্থাপন করে, GRE পেলোড বহন করে, তারপর LCP প্রমাণীকরণ প্রোটোকল, কম্প্রেশন ও MPPE-এর মতো অপশন নিয়ে দরকষাকষি করে। কোনো আবশ্যক অপশন তার পক্ষে অগ্রহণযোগ্য হলে সমকক্ষ LCP সমাপ্ত করে। যে লগে CHAP বা MSCHAPv2 বিনিময় সম্পন্ন হয় এবং ঠিক তার পরেই LCP শেষ হয়, সেটি নীতি প্রত্যাখ্যান, পৌঁছানোর ব্যর্থতা নয়। টানেল যদি একেবারেই আলোচনায় না পৌঁছায়, তবে LCP লাইন পড়ার আগে pppd ও তার প্লাগইন পরীক্ষা করুন।

দুটি পূর্বশর্ত সহজেই বাদ পড়ে। pppd বাইনারি থাকতেই হবে, এবং পিয়ার ফাইলে উল্লিখিত PPTP প্লাগইন ইনস্টল থাকতে হবে; প্যাকেজ না থাকলে কোনো অপশন আলোচনার আগেই ডায়াল শেষ হয়ে যায়।

যে পক্ষ MPPE দাবি করে, সেই পক্ষেই তা চালু করুন

আসল সিদ্ধান্ত হলো এনক্রিপশন নীতি কার হাতে। ক্লায়েন্ট MPPE প্রস্তাব করতে পারে, দাবি করতে পারে বা প্রত্যাখ্যান করতে পারে, সার্ভারও একই পছন্দ করে। দুই পক্ষই দাবি করলে লিঙ্ক ওঠে; এক পক্ষ দাবি করলে আর অন্য পক্ষ প্রত্যাখ্যান করলে LCP শেষ হয়।

pty "pptp vpn.example.net --nolaunchpppd"
name alice
remotename PPTP
require-mppe-128

ডায়াল করার আগে modprobe ppp_mppe দিয়ে মডিউল লোড করুন, কারণ এটি ছাড়া require-mppe-128 ব্যর্থ হয়। উইন্ডোজে সমতুল্য নিয়ন্ত্রণ হলো VPN এন্ট্রির নিরাপত্তা ট্যাব, যেখানে ক্লায়েন্টকে সার্ভার যা দেয় তা গ্রহণ না করে এনক্রিপশন দাবি করতে বলতে হয়। সার্ভার যদি এখনও LCP সমাপ্ত করে, তবে তার অপারেটরকে জিজ্ঞাসা করুন MPPE বাধ্যতামূলক, ঐচ্ছিক নাকি নিষ্ক্রিয়, কারণ সার্ভার যে সুরক্ষা প্রত্যাখ্যান করে তা ক্লায়েন্ট আলোচনা করতে পারে না। বার্তাটি সরাতে এনক্রিপশন বন্ধ করা ভুল দিক: এতে এই প্রোটোকলের একমাত্র সুরক্ষা সরে যায়।

সম্পাদনার আগে কাজ করা পিয়ার ফাইলটি সংরক্ষণ করুন। ভুলভাবে লেখা require-mppe লাইনটি একই সাধারণ LCP ব্যর্থতা তৈরি করে আপনাকে শুরুতে ফিরিয়ে দেয়।

অ্যাপলেট নয়, pppd-এর নিজের লগ পড়ুন

ডেস্কটপ অ্যাপলেট সংযোগ বিচ্ছিন্নতা দেখায় কিন্তু কারণ লুকায়, তাই ডেমন-এর একবার প্রচেষ্টার বিবরণ পড়ুন। systemd সিস্টেমে বার্তাটি জার্নালে যায়; পুরোনো সেটআপ ঐতিহ্যবাহী লগ ফাইলে লেখে।

journalctl --since "10 min ago" | grep -i -E "pppd|lcp|mppe"
tail -n 50 /var/log/syslog

একদিনের পুনঃসংযোগ নয়, একটি ডায়ালের আশপাশের সময়-জানালায় grep করুন, যাতে প্রত্যাখ্যাত অপশন সহজে চোখে পড়ে। pppd সাধারণত অপশনের নাম ও সমকক্ষের উত্তর বলে দেয়, যা জানায় নিজের প্রস্তাব বদলাবেন কি না সার্ভারের পক্ষকে তার দাবি শিথিল করতে বলবেন। প্রতিটি প্রচেষ্টায় সময়চিহ্ন রাখুন, কারণ কোন লাইন কোন কলের অন্তর্গত তা না জানলে দুটি লগ তুলনা করা বৃথা। যদি একেবারেই কোনো LCP বিনিময় না দেখা যায়, তবে ত্রুটি শিকলের আগের ধাপে এবং MPPE সন্দেহভাজন নয়।

পুনঃসংযোগ জুড়ে সমাধান ধরে রাখুন: হুকের নাম ও MTU

লিঙ্ক টিকে গেলে দুটি বিষয় ঠিক করে এটি পুনঃসংযোগ সহ্য করবে কি না। হুকগুলো /etc/ppp/ip-up.d ও /etc/network/if-up.d-এ থাকে, এবং দুই ডিরেক্টরিই run-parts প্রক্রিয়া করে, যার ফাইলনাম ফিল্টার বিন্দুযুক্ত যেকোনো নাম প্রত্যাখ্যান করে। তাই set-pptp.sh নামের স্ক্রিপ্ট বাদ পড়ে, আর set-pptp চলে। স্ক্রিপ্টের ভেতর ডিবাগ করার আগে নাম যাচাই করুন, তারপর ওই হুকের ভেতর থেকে ছোট MTU সেট করুন যাতে প্রতিটি নতুন ppp ইন্টারফেস হাতে কমান্ড ছাড়াই তা উত্তরাধিকার পায়।

run-parts --test /etc/ppp/ip-up.d
ip link set dev ppp0 mtu 1200

ইচ্ছাকৃতভাবে সেশন শেষ করতে প্রসেসের নাম প্যাটার্ন-ম্যাচ না করে pppd-এর রেকর্ড করা pid লক্ষ্য করুন, কারণ ppp আছে এমন সবকিছু খুন করলে অসম্পর্কিত লিঙ্কও ভেঙে যায়। PPTP বাতিল হয়েছে এবং MS-CHAPv2 দুর্বল, তাই এই পরীক্ষাগুলোকে এমন লিঙ্কের রক্ষণাবেক্ষণ ধরুন যা চালু থাকতেই হবে, নতুন কোথাও PPTP মোতায়েনের কারণ হিসেবে নয়।