L2TP: মারাত্মক সিগন্যাল 15, NO_PROPOSAL_CHOSEN এবং অনুপস্থিত modp1024

আপনার সংযোগ আটকে যায়, ক্লায়েন্ট বেরিয়ে যায়, আর স্ক্রিনের শেষ লাইনটি death_handler: Fatal signal 15 received। সেই লাইনটি একটি বিচ্ছিন্নতার কথা জানায়, কারণ নয়। IPsec লগে এক লাইন উপরে প্রায় সবসময় NO_PROPOSAL_CHOSEN থাকে, এবং এই জোড়াটি বিনিময়ের 2 নম্বর পর্যায়ের দিকে ইঙ্গিত করে, যেখানে দুই পক্ষ এনক্রিপশন ও হ্যাশের পছন্দ তুলনা করে এবং কোনো মিল না থাকলে থেমে যায়। সেই ধাপে লগইন তথ্য এখনো পাঠানো হয়নি, তাই পাসওয়ার্ড আবার লিখলে ফলাফল বদলাবে না।

Linux ক্লায়েন্টে সাধারণত দুটি জিনিস ওই ছেদটি খালি করে। স্থানীয় ডিমন প্রোফাইলের চাওয়া Diffie-Hellman গ্রুপ আর প্রয়োগ না করতে পারে, অথবা প্রোফাইল 1 নম্বর পর্যায়ের প্রস্তাব 2 নম্বর পর্যায়ের ঘরে বহন করতে পারে। দুটোই লগে চিহ্ন রেখে যায়, এবং কোনোটিই অ্যাকাউন্টের সমস্যা নয়।

দুটি বার্তা আসলে কী বলে

IKE পর্যায়ে পর্যায়ে দরকষাকষি করে। 1 নম্বর পর্যায় একটি সুরক্ষিত চ্যানেল গড়ে এবং নিজের অ্যালগরিদম বেছে নেয়; 2 নম্বর পর্যায়, অর্থাৎ চাইল্ড SA, আলাদা সেটের অধীনে ট্রাফিক বহন করে। NO_PROPOSAL_CHOSEN হলো সেই বিজ্ঞপ্তি যা উত্তরদাতা তখন ফেরত পাঠায় যখন প্রস্তাবিত কোনো সমন্বয়ই গ্রহণযোগ্য নয়, এবং এটি INFORMATIONAL বিনিময়ের ভেতরে [ HASH N(NO_PROP) ] হিসেবে দেখা যায়।

সিগন্যাল 15 ভিন্ন ঘটনা: কিছু একটা স্থানীয় প্রক্রিয়াকে থামতে বলেছে এবং হ্যান্ডলার সেটি লিপিবদ্ধ করেছে। দুটি লাইন একসাথে দেখা গেলে ক্রমটি কারণভিত্তিক, আগে প্রত্যাখ্যান তারপর বন্ধ হওয়া।

লগইন তথ্যে হাত দেওয়ার আগে দরকষাকষিটি পড়ুন

ডিমন যেখানে লেখে সেখানে লগের মাত্রা বাড়ান, তারপর আউটপুট দেখতে দেখতে আবার সংযোগ করুন। NetworkManager হোস্টে L2TP প্লাগইন সেই মাত্রা ব্যাকএন্ডে দেয়, এবং বার্তাগুলো বিতরণ অনুযায়ী journal বা পুরনো syslog ফাইলে পৌঁছায়। এগুলোর যেকোনোটি বিনিময়টি দেখাবে: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' বা tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'।

pluto নাম উল্লেখ করা লাইনটি libreswan থেকে আসে, charon আসে strongSwan থেকে, এবং দুটোই একই অবস্থা ভিন্ন শব্দে বোঝায়। খোঁজার যোগ্য রূপটি হলো যেটি অনুপস্থিত গ্রুপটির নাম নেয়, যেমন algorithm 'modp1024' is not supported, কারণ এটি অস্পষ্ট ব্যর্থতাকে নির্দিষ্ট করে তোলে।

modp1024 কোথায় গেল

Diffie-Hellman গ্রুপ 2 এতটাই দুর্বল যে বেশ কিছু ডিস্ট্রিবিউশন 3.30 থেকে এটি libreswan-এ কম্পাইল করা বন্ধ করেছে। তখন বছরের পর বছর আগে লেখা বা শুধু aes128-sha1-modp1024 তালিকাভুক্ত করা গেটওয়ে নির্দেশিকা থেকে নেওয়া প্রোফাইল স্থানীয় ডিমনকে এমন কিছু করতে বলে যা তার পক্ষে আদৌ সম্ভব নয়। নতুন NetworkManager-l2tp বিল্ড সেই ফলাফলকে আরও সম্ভাব্য করে: 1.2.16 থেকে তারা সেটটিকে Windows 10 ও iOS ধাঁচের প্রস্তাব দিয়ে বদলে দেয় এবং libreswan শনাক্ত হলেই modp1024 বাদ দেয়। বিপরীত পক্ষ প্রায়ই নির্দোষ এবং এখনো আপনি যে গ্রুপটি কনফিগার করেছেন ঠিক সেটিই দেয়।

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

ভিন্ন প্রভাবের দুটি মেরামত

সস্তা মেরামত হলো অ্যালগরিদম হাতে গেঁথে দেওয়া বন্ধ করা। এডিটরে দুটি প্রস্তাবের ঘরই খালি করুন এবং প্লাগইনকে এমন সেট বাছতে দিন যা দূর প্রান্ত গ্রহণ করে; গেটওয়ে আধুনিক গ্রুপ সমর্থন করলে কোনো বাড়তি কাজ ছাড়াই দরকষাকষি শেষ হয়।

দ্বিতীয় মেরামতটি strongSwan ইনস্টল করে পুরনো গেটওয়েকে নাগালের মধ্যে রাখে, যার প্যাকেজগুলো বেশিরভাগ ডিস্ট্রিবিউশনে এখনো গ্রুপ 2 প্রয়োগ করে। এটি ডিমন বদল, তাই এর দাম আছে: সরানোর আগে যাচাই করুন হোস্টের অন্য টানেলগুলো libreswan কনফিগারেশনের উপর নির্ভর করে কি না, এবং Fedora-তে NetworkManager ও strongSwan প্লাগইনের মধ্যে SELinux প্রত্যাখ্যানের আশা রাখুন। সেই প্রত্যাখ্যানগুলো IKE চিহ্নে নয়, অডিট লগে দেখা যায়, তাই সফল ইনস্টলের ঠিক পরেই টানেল ভাঙা দেখাতে পারে। যে ক্রমটি কাজ করে তা হলো আগে dnf install strongswan, তারপর rpm -e libreswan।

মিলে যাওয়া প্রস্তাবের স্ট্রিং, এবং তাদের চারপাশের ফাঁদ

যখন ঘরগুলো হাতে ভরতে হয়, 1 নম্বর পর্যায় ও 2 নম্বর পর্যায় ভিন্ন মান নেয়। Meraki ধাঁচের বিপরীত প্রান্তের বিরুদ্ধে কাজ করে বলে জানা জোড়াটি 1 নম্বর পর্যায়ে aes128-sha1-modp1024 এবং তার পেছনে 3des-sha1-modp1024 দেয়, দুটোই বিস্ময়চিহ্ন দিয়ে বন্ধ যা সেটটিকে কঠোর করে, তাই কেবল সেই প্রস্তাবগুলোই পাঠানো হয়।

এরপর 2 নম্বর পর্যায় একই কঠোর চিহ্নসহ এবং কোনো Diffie-Hellman অনুসর্গ ছাড়াই aes128-sha1 ও 3des-sha1-এ সংকুচিত হয়। -modp1024 বহন করা 2 নম্বর পর্যায়ের লাইনটি ভুল ঘরে থাকা 1 নম্বর পর্যায়ের মান, এবং উত্তরদাতা প্রতিটি পুনঃপ্রচেষ্টায় এটি প্রত্যাখ্যান করে। ওই লাইনটি দ্বিতীয় প্রোফাইলে কপি করুন, দ্বিতীয় প্রোফাইলও একইভাবে ব্যর্থ হয়, আর এভাবেই একটি টাইপিং ভুল গোটা বহরের ঘটনা হয়ে ওঠে।

অন্য ত্রুটিগুলো প্রস্তাবের অমিল না হয়েও একই পপআপ পরে। KDE-তে প্লাগইন ইনস্টল থাকলেও L2TP ধরনটি তালিকাভুক্ত হতে পারে, অথচ প্রতিটি সংযোগ সঙ্গে সঙ্গে মরে যায়, কারণ সংযোগ সম্পাদক ও রানটাইম সহায়কগুলো আলাদা প্যাকেজ হিসেবে আসে। স্ক্রিনবিহীন হোস্ট কাজ করা ডেস্কটপের প্রোফাইল পুনরায় ব্যবহার করতে পারে: এটি /etc/NetworkManager/system-connections/ থেকে কপি করুন, মোড 600-এ সেট করুন, তারপর nmcli con reload চালান। এটি nmcli con up id work-l2tp দিয়ে তুলুন, কারণ নগ্ন রূপের UUID দরকার, এবং যেকোনো পুরনো ifname এন্ট্রি সরিয়ে দিন, নইলে বাকি সব ঠিক থাকলেও ম্যানেজার Could not find source connection বলে উত্তর দেয়।

আগে থেকে ভাগ করা কী সাধারণ টেক্সট হিসেবে বা 0s এবং তারপর base64 হিসেবে সংরক্ষণ করা যায়; দুই রূপই কাজ করে, তবে মানটি গেটওয়ের সঙ্গে বাইটে বাইটে মিলতে হবে, সঙ্গে কপি করা শেষ ফাঁকা জায়গাগুলোসহ।