কোন VPN ধাপটি ব্যর্থ হলো: IPsec, L2TP নিয়ন্ত্রণ, নাকি PPP প্রমাণীকরণ
শেষ যে ধাপটি সফল হয়েছে তা খুঁজুন, তারপর কেবল সেই স্তরটি ঠিক করুন: IPsec, L2TP নিয়ন্ত্রণ চ্যানেল, PPP প্রমাণীকরণ বা ঠিকানা বণ্টন।
আপনি পাসওয়ার্ড বদলেছেন আর কিছুই বদলায়নি, কারণ ব্যর্থতা কখনোই PPP-তে ছিল না। L2TP/IPsec পাঁচটি সম্পূর্ণ ভিন্ন হ্যান্ডঅফের জন্য একটি সংযোগ ত্রুটি জানায়, আর প্রতিটি হ্যান্ডঅফের নিজস্ব মেরামত আছে। উল্টো দিকে কাজ করুন: শেষ যে ধাপটি সফল হয়েছে তা খুঁজুন এবং কেবল তার পরে যা আসে তা বদলান। নিচের ক্রমটিই ঠিক করে দেয় আপনি প্রথমে কোন প্রমাণ সংগ্রহ করবেন।
চারটি প্রশ্নের উত্তর ক্রমানুসারে দিন
নতুন একটি চেষ্টা জোর করুন, কারণ কিছু ক্লায়েন্ট প্রোফাইল সংযোগ বিচ্ছিন্ন করে আবার যুক্ত না করা পর্যন্ত আগের ত্রুটিটাই দেখাতে থাকে। তারপর এর উত্তর দিন: কোনো IPsec নিরাপত্তা সংযুক্তি ছিল কি, একটি L2TP নিয়ন্ত্রণ সংযোগ ও কল দেখা গেল কি, PPP কোনো প্রমাণীকরণ সিদ্ধান্তে পৌঁছাল কি, এবং IPCP ক্লায়েন্টকে ঠিকানা দিল কি? প্রথম না-ই সেই ধাপ যা আপনি ঠিক করবেন। তার পরের সবকিছু অপরীক্ষিত, তাই কখনো সংযুক্তি না থাকলে প্রত্যাখ্যাত ব্যবহারকারীনাম কিছুই প্রমাণ করে না।
তুলনার আগে দুই প্রান্তের ঘড়ি মিলিয়ে নিন। যে পুনঃচেষ্টা IPsec পরিষ্কার করে PPP-তে ব্যর্থ হয়েছে, তা একটিমাত্র ব্যর্থতার মতো দেখায় যখন ক্লায়েন্ট কেবল শেষ বার্তাটি দেখায় আর সার্ভার লগ আগের চেষ্টাটি ধরে রাখে। সবচেয়ে জোরে লাইনটি নয়, টাইমস্ট্যাম্প ধরে পড়ুন।
যখন আপনার কাছে কেবল ব্যবহারকারীর স্ক্রিনশট থাকে, তখন সবচেয়ে সস্তা বিভাজনটির উপর নির্ভর করুন: ভুল পূর্ব-শেয়ার করা কী আর কখনো উত্তর না দেওয়া xl2tpd Windows ডায়ালগে একই লেখা তৈরি করে, তবু একটির জন্য দুই প্রান্তে গোপন তথ্য বদলাতে হয় আর অন্যটির জন্য সার্ভারেই একটি ডেমন চালু করা বা ফায়ারওয়াল নিয়ম দরকার। মাঝখানের কোনো ডিভাইস ভেতরের 1701 ফেলে দিতে পারে না একবার ট্রান্সপোর্ট-মোড IPsec তা মুড়ে ফেললে, তাই নেই এমন পথ-ফিল্টার খুঁজতে যাবেন না।
প্রতিটি স্তর আসলে কী নিয়ন্ত্রণ করে
IPsec দুই পিয়ারের মধ্যে প্যাকেট রক্ষা করে; L2TP সেই সুরক্ষিত পথের ভেতরে একটি PPP সেশন বহন করে, সে কারণেই RFC 3193 নিজস্ব টানেলের বদলে ট্রান্সপোর্ট মোড নির্দিষ্ট করে। ক্লায়েন্টের লেবেলে L2TP লেখা, তাই টানেল আর লগইন একটিমাত্র ব্যবস্থা মনে হয়। তা নয়: L2TP নিয়ন্ত্রণ সংযোগ যেখানে স্থাপনা এটি চালু করে সেখানে টানেলের প্রান্তবিন্দু প্রমাণীকরণ করে, আর PPP সার্ভার নীতির অধীনে CHAP, PAP বা MS-CHAPv2 দিয়ে ব্যবহারকারীকে আলাদাভাবে প্রমাণীকরণ করে।
এই বিভাজনই সেই দুটি গোপন তথ্য ব্যাখ্যা করে যা মানুষ বারবার গুলিয়ে ফেলে। পূর্ব-শেয়ার করা কী IPsec পিয়ারদের প্রমাণীকরণ করে। ব্যবহারকারীনাম ও পাসওয়ার্ড PPP-এর কাছে ব্যবহারকারীকে চিহ্নিত করে। শংসাপত্র দিয়ে প্রমাণীকরণকারী প্রোফাইলে Windows-এর শেয়ার করা গোপন তথ্য আবার টাইপ করলে ব্যর্থ ধাপে কিছুই বদলায় না, আর PPP পাসওয়ার্ড সম্পাদনা করে অনুপস্থিত সুরক্ষিত চ্যানেল দেওয়া যায় না। একই সংযম প্রযোজ্য পরিচয় যাচাইয়েও: টানেল পেতে পিয়ার পরিচয় বা শংসাপত্র যাচাই বন্ধ করবেন না, কারণ তখন যা সংযুক্ত হয় তা পথ, পিয়ার নয়।
প্রমাণীকরণই PPP-এর শেষও নয়। ব্যবহারকারী গৃহীত হওয়ার পর IPCP ক্লায়েন্টের ঠিকানা এবং সার্ভার যে DNS ও WINS অপশন দিতে রাজি তা নিয়ে দরকষাকষি করে। ক্লায়েন্ট CHAP বা MS-CHAPv2 পাস করেও ঠিকানাহীন থাকতে পারে, যা রাউটিং সমস্যা নয় বরং PPP-এর ভেতরের ব্যর্থতা। IPsec ছাড়া সাধারণ L2TP বৈধ ও অসুরক্ষিত থাকে, তাই সফল সংযোগ কখনোই প্রমাণ করে না ট্রাফিক সুরক্ষিত; সার্ভার কী দাবি করে তা দেখুন, ক্লায়েন্টের লেবেল নয়।
প্রথম অনুপস্থিত ধাপ থেকেই সিদ্ধান্ত নিন
সারণিটি বাঁ থেকে ডানে প্রথম অনুপস্থিত জিনিস ধরে পড়ুন। ডান কলামটিই সেই মুহূর্তে করার যোগ্য একমাত্র কাজ; তার বাঁয়ের সবকিছু ইতিমধ্যেই প্রমাণিত, আর তা আবার পরীক্ষা করলে তথ্য না যোগ হয়ে বিভ্রাটের সময় নষ্ট হয়।
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
তিনটি সারি সতর্কতার যোগ্য। 1701 সারিটিই NAT-এর পেছনের Windows ক্লায়েন্টরা সাধারণত যেখানে পৌঁছায়: সংযুক্তি সম্পন্ন হয়, তারপর কিছুই আসে না, আর কারণ খারাপ পাসওয়ার্ড নয়, এনক্যাপসুলেশন। IPCP সারিটিই ভুল করে রাউট সমস্যা হিসেবে পড়া হয়, কারণ Windows অনুপস্থিত ঠিকানাকে 720 ত্রুটিতে মুড়ে দেয় আর ট্রে আইকন কেবল বলে সংযোগ ব্যর্থ হয়েছে; সেই ব্যর্থতা প্রমাণীকরণের পরে ও রাউটিংয়ের আগে বসে। শেষ সারিটি মোটেই IPsec ব্যর্থতা নয়, যদিও ট্রে আইকন বলে সংযোগ বিচ্ছিন্ন।
যে কমান্ডগুলি স্তর আলাদা করে
strongSwan চালানো Linux সার্ভারে swanctl --list-sas প্রতিষ্ঠিত সংযুক্তিগুলো পিয়ার পরিচয়সহ তালিকা করে, আর ipsec statusall পুরোনো strongSwan ও libreswan হোস্ট ঢেকে দেয়। নিচে ip xfrm state কার্নেলের প্রকৃত সংযুক্তি দেখায়, আর ss -lunp | grep 1701 প্রমাণ করে xl2tpd কোথায় বাঁধা। নিয়ন্ত্রণ সংযোগ ও কল আসতে দেখতে xl2tpd -D সামনের দিকে চালান, এবং প্রস্তাবিত পদ্ধতি ও উত্তর দেখতে /etc/ppp/options.xl2tpd-এ pppd ডিবাগ চালু করুন।
লগ সফল প্রমাণীকরণ দেখানোর পরের প্রশ্ন হলো IPCP সম্পন্ন হলো কি না। দেখুন /etc/xl2tpd/xl2tpd.conf-এর [lns default] অংশে ip range-এ এখনো মুক্ত ঠিকানা আছে কি না, এবং ক্লায়েন্ট প্রত্যাশা করলে /etc/ppp/options.xl2tpd সত্যিই ms-dns ও ms-wins বহন করে কি না। নিঃশেষিত পুল আর অনুপস্থিত DNS অপশন তারে ভিন্নভাবে দেখায়: প্রথমটি ক্লায়েন্টকে ঠিকানাহীন ও 720 নিয়ে রাখে, দ্বিতীয়টি ঠিকানা দেয় কিন্তু রিজলভার দেয় না, তাই নাম ব্যর্থ হয় অথচ কাঁচা ঠিকানায় ping কাজ করে। কোনোটিই পাসওয়ার্ড আবার দিয়ে ঠিক হয় না।
ক্লায়েন্টে NetworkManager-এর L2TP প্লাগইন pppd-এর কথোপকথন জার্নালে লেখে, তাই journalctl -u NetworkManager -b সাধারণত টানেল উঠেছে, প্রমাণীকরণ প্রত্যাখ্যাত আর কোনো টানেলই নেই আলাদা করে। Windows-এ Get-VpnConnection প্রোফাইলের প্রকৃত প্রমাণীকরণ সেটিং জানায়, আর Event Viewer-এ Application-এর অধীনে RasClient ইভেন্ট ব্যর্থ উপাদানের নাম বলে। ডায়ালগ খুব অস্পষ্ট হলে netsh ras set tracing * enable চালু করুন।
ক্যাপচারে একটি সতর্কতা দরকার। ট্রান্সপোর্ট-মোড IPsec-এ ভেতরের UDP 1701 এনক্রিপ্টেড থাকে, তাই বাইরের ইন্টারফেসে ক্যাপচার ESP দেখায়, বা NAT-T-এর অধীনে UDP 4500, এবং L2TP একেবারেই নয়। ক্যাপচারে 1701 না থাকা প্রত্যাশিত এবং বন্ধ পোর্টের প্রমাণ নয়; দেখুন ESP বা 4500 কাউন্টার নড়ছে কি না।
NAT, MTU আর রুট: স্ট্যাক কোথায় আপনাকে বিভ্রান্ত করে
কিছু প্রমাণীকৃত হওয়ার আগেই NAT ধরে নেওয়া ভেঙে দেয়। ESP নিজস্ব IP প্রোটোকল, তাই অনুবাদকারী ডিভাইস এটি ফেলে দেয় যদি না পিয়াররা এনক্যাপসুলেট করে; UDP 4500 ঠিক সেটাই দেয়। যে Windows সার্ভার নিজেই হোম রাউটার বা ক্লাউড NAT গেটওয়ের পেছনে থাকে, সেখানে IPsec ধাপটি 789 ত্রুটিতে ব্যর্থ হয় যতক্ষণ না PolicyAgent কী-এর অধীনে AssumeUDPEncapsulationContextOnSendRule 2-এ সেট হয় ও মেশিন রিস্টার্ট হয়, আর ব্যর্থতাটি বন্ধ পোর্ট থেকে আলাদা করা যায় না। NAT-এর পেছনের ক্লায়েন্ট সহজ: সার্ভারে পাবলিক ঠিকানা থাকলে UDP 4500-এ NAT-T তাদের বহন করে এবং সেই মান জড়িত নয়।
PPP ওঠার পর ব্ল্যাকহোলড MTU মৃত টানেলের মতো আচরণ করে: ছোট প্যাকেট পার হয়, TLS হ্যান্ডশেক বা পৃষ্ঠা লোড আটকে যায়, আর ক্লায়েন্ট তখনো সংযুক্ত দেখাতে পারে। সার্ভারকে দোষ দেওয়ার আগে ইন্টারফেস MTU কমান বা গেটওয়েতে MSS ক্ল্যাম্প করুন। স্প্লিট-টানেল রাউটিং আরেক প্রতারক; ভুল মাস্কে পাঠানো সাবনেট টানেল সুস্থ রেখে একটি অ্যাপ্লিকেশনকে অপ্রাপ্য করে। ব্যক্তিগত হোস্টনাম নিজের একটি ধাপ যোগ করে: কোয়েরি স্থানীয় রিজলভার দিয়ে বেরোলে কোনো রুট পরীক্ষার আগেই নামটি সমাধান হতে ব্যর্থ হয়।
শংসাপত্র স্পর্শ করার আগে চেকলিস্ট
তালিকাটি ক্রমে কাজ করুন এবং প্রথম ব্যর্থ আইটেমে থামুন। প্রতিটি ধাপ সস্তা, আর প্রতিটি একেকটি সম্পূর্ণ শ্রেণির সম্পাদনা বাদ দেয়।
- দুই প্রান্তেই সংযুক্তি আছে তা নিশ্চিত করুন, সংযোগ-লেবেল নয় পিয়ার পরিচয়ে মিলিয়ে।
- UDP 1701 xl2tpd-এ পৌঁছায় তা নিশ্চিত করুন; কলহীন সংযুক্তিই আপনার ব্যর্থতা।
- পাসওয়ার্ড ভুল ধরে নেওয়ার আগে PPP-এর রায়, আর প্রমাণীকৃত হলে IPCP-এর ফল পড়ুন।
- এখনই শংসাপত্র সার্ভার যে ফরম্যাটে চায় তা দিয়ে আবার দিন, কারণ ডোমেইন উপসর্গ অ্যাকাউন্ট বদলে দেয়।
- তবু ব্যর্থ হলে দুই প্রান্ত মিলিত টাইমস্ট্যাম্পে ক্যাপচার করুন এবং ধাপে ধাপে তুলনা করুন।
দ্বিতীয় ধাপে থামা মানে পথ বা এনক্যাপসুলেশন সমস্যা, আর কোনো পাসওয়ার্ড সম্পাদনা তা নড়াবে না। তৃতীয় ধাপে থামা মানে লগ ইতিমধ্যেই যে পদ্ধতি বা ঠিকানা-পুল ঠিক করতে হবে তার নাম বলে দিয়েছে। দুই ক্ষেত্রেই পরের পরিবর্তনটি এমন যা আপনি যুক্তি দিয়ে ব্যাখ্যা করতে পারেন, এবং আপনি এমন সেটিংয়ের মধ্যে ঘোরা বন্ধ করেন যা কখনোই জড়িত ছিল না।