L2TP-তে NO_PROPOSAL_CHOSEN? আগে গেটওয়ে স্ক্যান করুন

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

বার্তাটি কী বাদ দেয়

প্রত্যাখ্যানটি মেইন মোডে, যেকোনো L2TP বা PPP বিনিময়ের আগে ঘটে, তাই টানেল ও ব্যবহারকারী ডেটাবেস জিজ্ঞাসা করা হয়নি। ফেজ 1 এনক্রিপশন, ইন্টিগ্রিটি ও একটি Diffie-Hellman গ্রুপ নিয়ে দরকষাকষি করে। ফেজ 2 ডেটার জন্য ESP প্রস্তাব নিয়ে দরকষাকষি করে। ফেজ 1-এর ব্যর্থতা ফেজ 2-এর PFS সেটিং বদলে ঠিক করা যায় না, এবং সম্পন্ন একটি IKE অ্যাসোসিয়েশন প্রমাণ করে না যে ESP প্রস্তাবটি উপযুক্ত।

সিনট্যাক্স সম্পাদনার আগে ব্যাকএন্ড লিখে রাখুন: ipsec --version. libreswan ও strongSwan একই অ্যালগরিদমের জন্য ভিন্ন প্রস্তাব-বানান গ্রহণ করে।

তারপর প্রত্যাখ্যানটি প্রসঙ্গে পড়ুন journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

গেটওয়ের ট্রান্সফর্ম সেট স্ক্যান করুন

একটি স্ক্যানার গেটওয়েকে সরাসরি জিজ্ঞাসা করে সে কোন ট্রান্সফর্ম নিয়ে দরকষাকষি করবে। প্রথমে স্থানীয় IPsec পরিষেবা বন্ধ করুন যাতে প্রোবটি আপনার নিজের ক্লায়েন্টের সঙ্গে প্রতিযোগিতা না করে, তারপর SA লাইনগুলো পড়ুন। তালিকাটিকে সমকক্ষ সম্পর্কে প্রমাণ হিসেবে দেখুন, সবকিছু একসঙ্গে চালু করার মেনু হিসেবে নয়।

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

পুরোনো যন্ত্রপাতি প্রায়ই 3DES, SHA1 ও MODP1024 অফার করে, কারণ পণ্য পাঠানোর সময় এগুলোই ডিফল্ট ছিল এবং কেউ সেগুলো পুনর্বিবেচনা করেনি। কাঁচা স্ক্যান আউটপুট রেখে দিন, কারণ সেদিন সমকক্ষ কী অফার করেছিল তার এটিই একমাত্র রেকর্ড। যদি এটিই পাওয়া সবচেয়ে শক্তিশালী মিল হয়, তবে সঠিক এসক্যালেশন হলো গেটওয়ে মালিকের কাছে, সবার জন্য দুর্বল ক্রিপ্টোগ্রাফি আবার চালু করা কোনো ক্লায়েন্ট কনফিগারেশনের কাছে নয়।

নিরাপত্তা না বন্ধ করেই মিলটি মেলান

কেবল সেই ট্রান্সফর্মগুলো লিখুন যা স্ক্যান ও আপনার নীতিতে দুই জায়গাতেই আছে। নিচের উদাহরণটি ফেজ 1-এ 3DES, SHA1 ও MODP1024 অফার করা একটি গেটওয়ে দেখায়। ব্যাকএন্ডের সতর্কতা লক্ষ্য করুন: libreswan 4.x modp1024 গ্রুপটি কম্পাইল করে না, তাই এটি strongSwan বা DH2 সমর্থনসহ libreswan বিল্ডের ক্ষেত্রে প্রযোজ্য। ক্লায়েন্ট নষ্ট বলে সিদ্ধান্তে পৌঁছানোর আগে সংস্করণ যাচাই করুন।

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

শেষে দেওয়া বিস্ময়চিহ্ন একটি প্রস্তাব পিন করে। এটি দিয়ে একটি পরীক্ষা আলাদা করুন, তারপর সরিয়ে দিন যাতে গেটওয়ে পরে আরও শক্তিশালী কিছু নিয়ে দরকষাকষি করতে পারে।

আবার চেষ্টা করার আগে ডেমন ও পোর্ট পরীক্ষা করুন

NetworkManager-l2tp নিজের একটি xl2tpd ইনস্ট্যান্স চালু করে। যদি সিস্টেম পরিষেবা ইতিমধ্যে UDP 1701 ধরে থাকে, ক্লায়েন্ট একটি ক্ষণস্থায়ী সোর্স পোর্টে ফিরে যায়, যা RFC 3193 অনুমোদন করে এবং কিছু সার্ভার নীরবে বাদ দেয়। পরের চেষ্টার আগে সকেটের মালিক পরীক্ষা করুন।

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

বাসি উৎপন্ন সিক্রেট আরেকটি নীরব কারণ। এর অধীনে থাকা ফাইল /etc/ipsec.d/ পুরোনো সংযোগের নামে থাকলে সেগুলো তৈরি করা প্রোফাইলের চেয়ে বেশি দিন টিকে থাকতে পারে, তাই যেগুলোতে কিছুই নির্দেশ করে না সেগুলো মুছে ফেলুন এবং আবার চেষ্টা করুন।

সবশেষে, পরামর্শটি কোথা থেকে এসেছে তা যাচাই করুন। IKEv1 XAuth-এর জন্য লেখা একটি ipsec.conf ফাইল ভিন্ন ধরনের VPN বর্ণনা করে, এবং L2TP প্রোফাইলে এর প্রস্তাবই একমাত্র ভুল লাইন নয়। আপনি যে ট্রান্সফর্ম সেট লিখেছেন তা প্রোফাইলের পাশে লিখে রাখুন, যাতে পরের ব্যক্তি প্রোবটি পুনরাবৃত্তি না করে।