PPTP ও L2TP/IPsec ব্যবহারকারীর নামের প্রম্পট আসার আগেই কেন থেমে যায়?
ব্যবহারকারীর নামের প্রম্পট না আসার অর্থ PPP কখনো শুরু হয়নি, তাই ত্রুটি ট্রান্সপোর্ট, কী বিনিময় বা টানেল স্থাপনে। পুনরায় ইনস্টল করার আগে ধাপের ক্রম যাচাই করুন।
ব্যবহারকারীর নামের প্রম্পট না আসা একটি রোগনির্ণয়ের উপহার: PPP এখনো শুরু হয়নি, তাই অ্যাকাউন্ট, পাসওয়ার্ড ও ডোমেইন নীতি এখনো জিজ্ঞাসা করা হয়নি। PPTP বা L2TP/IPsec সংযোগে ক্লায়েন্ট শংসাপত্র চায় কেবল তখনই, যখন টানেল বিদ্যমান এবং সার্ভার একটি PPP সেশন শুরু করেছে। ওই মুহূর্তের আগে যা ব্যর্থ হতে পারে তা হলো ট্রান্সপোর্ট, কী বিনিময় বা টানেল স্থাপন, যা «VPN নষ্ট» ধারণার চেয়ে অনেক ছোট একটি ক্ষেত্র।
অনুপস্থিত প্রম্পট ত্রুটিকে তিনটি ধাপে সংকুচিত করে
শেষ যে ধাপটি দৃশ্যত সফল হয়েছে তা লিখে রাখুন, কারণ প্রতিটির মালিক ও সমাধান আলাদা। দুটি ধাপ আগে আটকে থাকা অবস্থায় অ্যাকাউন্ট সেটিংস অনুমান করা হলো একটি বিকেল হারানোর উপায়।
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
প্রম্পট ছাড়াই যার সময় শেষ হয়ে যায় সেই ক্লায়েন্ট কখনো IPsec সংযুক্তি পায়নি, তাই ত্রুটি IKE-তে বা আপনার প্যাকেটগুলো গেটওয়েতে পৌঁছায় কি না তাতে। যে ক্লায়েন্ট শংসাপত্র যাচাই করছে বলে জানিয়ে পরে ঝরে যায়, সে বার্তার ইঙ্গিতের চেয়ে আরও এগিয়েছিল। প্রম্পটের পরে প্রত্যাখ্যান এলে তা PPP প্রমাণীকরণ, আর তার জায়গা অ্যাকাউন্ট নিবন্ধে, এই নিবন্ধে নয়।
প্রথম ধাপ: ফায়ারওয়াল যে প্রোটোকল চুপচাপ ফেলে দেয়
PPTP-এর নিয়ন্ত্রণ চ্যানেলের জন্য TCP 1723 এবং ডেটা পথের জন্য IP প্রোটোকল 47 দরকার, আর দুটি আলাদাভাবে চলে। অনেক নেটওয়ার্ক 1723 এগিয়ে দেয় কিন্তু প্রোটোকল 47 ফেলে দেয়, ফলে এমন টানেল তৈরি হয় যা দর কষাকষি করে অথচ কিছুই বহন করে না। NAT করা রাউটারের GRE-সক্ষম পাস-থ্রুও দরকার, আর শুধু IPv6-ভিত্তিক অ্যাক্সেস পথ কোনো কনফিগারেশনেই PPTP বহন করতে পারে না।
IPsec-এর উপর L2TP IKE-তে পোর্ট 500 এবং NAT ট্রাভার্সালে পোর্ট 4500 খরচ করে, তারপর L2TP ট্রাফিককেই 1701-এ মোড়ে, আর সংযুক্তি তৈরি হলে ESP সুরক্ষিত পেলোড বহন করে। দুটি নিয়ন্ত্রণ পোর্ট অনুমোদন করে ESP না দিলে ঠিক শিরোনামের উপসর্গই পাবেন: দৃশ্যমান অগ্রগতি, তারপর শংসাপত্রের কোনো ডায়ালগের আগেই মৃত ক্লায়েন্ট। ফোনের হটস্পট থেকে পরীক্ষা করা ক্লায়েন্টের সমস্যা আর পথের সমস্যা আলাদা করার সস্তা উপায়।
দ্বিতীয় ধাপ: যে কী কী নয়, যে প্রস্তাব দেওয়া হয় না
মিলছে না এমন পূর্ব-শেয়ারকৃত কী দ্রুত ও নিঃশব্দে ব্যর্থ হয়, আর সাধারণ রূপটি হলো স্ক্রিনে সঠিক দেখানো একটি কী যা পেস্ট করা লাইন ব্রেক বা শেষে একটি স্পেস বহন করছে। Linux ক্লায়েন্টে ডায়ালগই সবসময় সত্যের উৎস নয়: NetworkManager-এর L2TP প্লাগইন গোপন তথ্য রাখে /etc/ipsec.d/-এর অধীনে ফাইলে, আর /etc/ipsec.secrets এখনো যে পুরোনো প্রতি-সংযোগ ফাইল অন্তর্ভুক্ত করে সেটিই আপনার এইমাত্র টাইপ করা ফাইলের বদলে ব্যবহৃত হবে। ওই ফাইলটি নিরাপদ জায়গায় কপি করুন, অন্তর্ভুক্তির পথ থেকে সরান, তারপর কী-টি হাতে আবার টাইপ করুন।
এই ধাপের বাকি অর্ধেক হলো প্রস্তাব। দুই প্রান্তকে একই 1 নম্বর ফেজের অ্যালগরিদম সেট — এনক্রিপশন, অখণ্ডতা ও Diffie-Hellman গ্রুপ — এবং 2 নম্বর ফেজের জন্য মিলন্ত ESP রূপান্তরে একমত হতে হবে, নয়তো সংযুক্তি আদৌ তৈরি হয় না। যে গেটওয়ে কেবল 3DES, SHA1 ও MODP1024 দেয় সে শক্তিশালী অ্যালগরিদমে সাজানো ক্লায়েন্টকে প্রত্যাখ্যান করবে, আর তার লগ প্রত্যাখ্যাত রূপান্তরের নাম বলে। সেবাটি আবার চালু না করে লগ পড়লে লগই অসঙ্গতির নাম বলে। ফোরামের থ্রেড থেকে অ্যালগরিদমের স্ট্রিং কপি না করে গেটওয়েকে জিজ্ঞাসা করুন সে সত্যিই কোন রূপান্তরে দর কষাকষি করবে: তার ঠিকানায় ছোড়া ike-scan যে রূপান্তরগুলোতে সে দর কষাকষি করবে সেগুলোই ফেরত দেয়। যদি একমাত্র প্রস্তাব এমন ক্রিপ্টোগ্রাফি হয় যা আপনার নীতি আর অনুমোদন করে না, তবে সমাধান ক্লায়েন্টকে নামিয়ে আনার মধ্যে নয়, গেটওয়েতেই।
Windows-এ কী ও প্রমাণীকরণ পদ্ধতি থাকে VPN প্রোফাইলে, আর অসঙ্গতি ধরা পড়ে শংসাপত্রের প্রম্পটের পরে নয়, আগেই। যেখানে গ্রহীতা Windows Server, সেখানে নিশ্চিত করুন দূরবর্তী অ্যাক্সেস ভূমিকা ইনস্টল করা, শংসাপত্রটি ক্লায়েন্টরা যে নামে সংযোগ করে তার সঙ্গে মেলে, এবং কোনো পোর্ট ফিল্টার উপরের প্রোটোকলগুলোর চেয়ে সংকীর্ণ নয়।
তৃতীয় ধাপ: টানেল আছে, PPP শুরু হয় না
IKE শেষ হওয়ার পরও প্রম্পট না এলে ফায়ারওয়াল নয়, টানেল ডেমন দেখুন। L2TP-এর UDP 1701-এ শোনা কিছু দরকার — Linux-এ xl2tpd বা kl2tpd, Windows-এ দূরবর্তী অ্যাক্সেস সেবা — আর ইনস্টল করা কিন্তু বন্ধ একটি সেবা ক্লায়েন্টের দিক থেকে ফেলে দেওয়া প্যাকেটের মতোই দেখায়। ইতিমধ্যে যাচাই করা নিয়ম আবার খোলার আগে শ্রোতাটি দেখুন। এরপর PPP-কে দর কষাকষি করতে হয়, আর প্রথম LCP বিনিময়ই হলো যেখানে নিঃশব্দ ব্যর্থতা সাধারণত জমে।
এই ধাপের একটি ফাঁদ মোটেও নেটওয়ার্কের ত্রুটি নয়: Windows একসঙ্গে একটি নির্দিষ্ট VPN ধরনের কেবল একটি সংযোগ অনুমোদন করে, তাই দ্বিতীয় চেষ্টা 937 ত্রুটি দেয়, «এই ধরনের আরেকটি সংযোগ ব্যবহৃত হচ্ছে»। এটি স্থানীয় নিয়ম, আর এর পাশ কাটানোর উপায় আলাদা ডিভাইস, আলাদা টানেল ধরন, বা ইতিমধ্যে থাকা একমাত্র সংযোগটি ভাগ করে নেওয়া।
অনুমান না করে ধাপের ক্রমে লগ পড়ুন
ক্লায়েন্ট বন্ধ করুন, আবার চালু করুন, আর উপাদানগুলো যে ক্রমে লগ লেখে সেই ক্রমে পড়ুন। অর্থাৎ প্রথমে IPsec ডেমন — strongSwan বা Libreswan, আর ipsec --version কোনটি তা বলে দেয় — তারপর L2TP ডেমন, তারপর pppd। ব্যর্থতার আগে যে উপাদান শেষে লিখেছে সেটিই তদন্তের ধাপ চিহ্নিত করে, কারণ ক্রমে তার পরে যা আসে তা আদৌ চলে না।
সংরক্ষিত সেশন নয়, নতুন সংযোগ দিয়ে যাচাই করুন, কারণ ক্যাশ থেকে পুনঃসংযোগ করা ক্লায়েন্ট বিনিময়ের অংশ বাদ দিয়ে পুরোনো ফল পুনরুৎপাদন করতে পারে। পৌঁছানো, কী বিনিময়, টানেল ও PPP এক এক করে, সেই ক্রমে নিশ্চিত করুন। তখন অনুপস্থিত প্রম্পট রহস্য থাকা বন্ধ করে এমন একটি তালিকার দ্বিতীয় লাইন হয়ে ওঠে যা নিয়ে সত্যিই কাজ করা যায়। ওই তালিকাই আপনি নেটওয়ার্ক দলকে দেন, নইলে তাদের এমন ত্রুটির জন্য ফায়ারওয়াল দেখতে বলা হবে যা চালু না হওয়া ডেমনে বাস করে।