Check Point বা Nortel-এর বিপরীতে vpnc: কেন এটি আটকে যায়

লক্ষণটি ভুলভাবে পড়া সহজ: vpnc শুরু হয়, গ্রুপ পাসওয়ার্ড চায়, তারপর আলোচনার একটি ধাপে বসে থাকে যতক্ষণ না লক্ষ্য থেকে কোনো সাড়া নেই বলে জানায়। আউটপুটে গেটওয়ে পণ্যের কোনো উল্লেখ নেই, আর অ্যাকাউন্টটি ব্রাউজার থেকে কাজ করে, তাই সুস্পষ্ট সিদ্ধান্ত হলো ভুল পাসওয়ার্ড বা অবরুদ্ধ পোর্ট। এসব ক্ষেত্রে বেশিরভাগ সময় গেটওয়ে আদৌ IPsec সহযোগী নয়, তাই বিনিময় কখনো শংসাপত্র পরীক্ষা করার পর্যায়ে পৌঁছায় না। প্রোফাইলে অন্য কিছু বদলানোর আগে এই ধরনটি পরীক্ষা করা মূল্যবান।

প্রোফাইলের আরেকটি ক্ষেত্র সম্পাদনা করার আগে পণ্যটি চিহ্নিত করুন।

ব্যর্থতাটি ভুল শংসাপত্রের মতো দেখায়

vpnc প্রথমে UDP 500-এ IKE পাঠায় এবং NAT ট্রাভার্সাল দেওয়া থাকলে UDP 4500-এ পাঠায়। যে গেটওয়ে IPsec-এর বদলে SSL সমাপ্ত করে, সে দুটির কোনোটিতেই উত্তর দেয় না, তাই ক্লায়েন্ট আবার চেষ্টা করে এবং শেষে একটি সাধারণ ত্রুটি নিয়ে হাল ছেড়ে দেয়। একই অ্যাকাউন্ট যদি ছোট সহায়ক অ্যাপ্লিকেশন লোড করা ব্রাউজার পোর্টাল দিয়ে কাজ করে, তবে এটি জোরালো ইঙ্গিত যে টানেলটি SSL-ভিত্তিক এবং ক্লায়েন্ট ভুল প্রশ্ন করছে।

এখানে ব্যর্থ চেষ্টা ব্যবহারকারীর অ্যাকাউন্ট সম্পর্কে কিছুই বলে না, কারণ গেটওয়ের কাছে কোনো শংসাপত্রই উপস্থাপন করা হয়নি।

গেটওয়ে কোন প্রোটোকল দেয় তা যাচাই করুন

দুই মিনিটের অনুসন্ধান IPsec সহযোগীকে SSL পোর্টাল থেকে আলাদা করে। ক্লায়েন্ট যে নেটওয়ার্ক ব্যবহার করবে সেখান থেকেই এগুলো চালান, এবং কোনো নথিতে কোন পোর্ট লেখা আছে তা নয়, বরং কোন পোর্ট উত্তর দেয় তা পড়ুন। ফলাফলটি রাখুন, কারণ ওই একই পোর্টগুলিই ঠিক করে গেটওয়ে মালিকের কোন ক্লায়েন্ট সমর্থন করা উচিত। গেটওয়ের পাশের হোস্ট থেকে নয়, ক্লায়েন্ট নেটওয়ার্ক থেকে অনুসন্ধান করুন।

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

লগইন পৃষ্ঠায় পুনর্নির্দেশসহ খোলা 443 এবং 500 ও 4500-এ নীরবতা SSL VPN-এর দিকে ইঙ্গিত করে। 443-এ সার্ভ করা সার্টিফিকেটসহ খোলা 500 ও 4500 এমন একটি IPsec গেটওয়ের ইঙ্গিত দেয় যা ওয়েব ফ্রন্ট এন্ডও চালায়, আর vpnc ঠিক এই ক্ষেত্রের জন্যই তৈরি হয়েছিল।

Check Point-এর SSL Network Extender এবং Nortel-এর Aventail ক্লায়েন্ট দুটিই দ্বিতীয় শ্রেণিতে পড়ে, এবং কোনোটিই IKEv1 গ্রুপ সিক্রেট গ্রহণ করে না।

vpnc-এর প্রোফাইল কী প্রকাশ করতে পারে আর কী পারে না

ভেতরে vpnc একটি গ্রুপ-পূর্ব-শেয়ার্ড কী-এর বিপরীতে IKEv1 চালায়, তারপর XAuth-এর মাধ্যমে ব্যক্তিগত ব্যবহারকারীর শংসাপত্র পাঠায়। এর কনফিগারেশন ফাইলের সবকিছুই ওই বিনিময়ের অংশ: গেটওয়ে, গ্রুপের নাম, গ্রুপ সিক্রেট, ব্যবহারকারীর নাম এবং ব্যবহারকারীর পাসওয়ার্ড। এই ক্ষেত্রগুলি একটিমাত্র প্রোটোকল বর্ণনা করে, এবং এদের কোনো সমন্বয়ই ক্লায়েন্টকে অন্য প্রোটোকল বলাতে পারে না।

এজন্যই সাইফার তালিকা বাড়ানো বা সার্টিফিকেট যাচাই বন্ধ করা কখনোই এই ধরনের ব্যর্থতা সারায় না। ওই পরিবর্তনগুলি এমন এক আলোচনাকে দুর্বল করে যার জন্য গেটওয়ে শুনছে না।

গেটওয়ের সাথে মেলে এমন ক্লায়েন্ট বেছে নেওয়া

Check Point গেটওয়ের জন্য সেই গেটওয়ে সংস্করণের জন্য নির্মিত SNX প্যাকেজ ব্যবহার করুন, যা সরবরাহকারী তার দূরবর্তী অ্যাক্সেস নথির সাথে প্রকাশ করে। পুরোনো SNX বিল্ড চলতি ডিস্ট্রিবিউশনে প্রায়ই ব্যর্থ হয়, কারণ সেগুলি এমন 32-bit লাইব্রেরি প্রত্যাশা করে যা আর ইনস্টল করা নেই, আর পরিত্যক্ত প্যাকেজ প্যাচ করা সাধারণত সমর্থিত প্ল্যাটফর্মে সমর্থিত ক্লায়েন্ট চালানোর চেয়ে খারাপ।

Aventail ক্লায়েন্টরা বহু আগেই সমর্থন হারিয়েছে। যেখানে এমন গেটওয়ে এখনো সেবায় আছে, সেখানে বাস্তবসম্মত বিকল্প হলো সংস্থাটি সক্ষম করলে ব্রাউজার পোর্টাল, অথবা সমর্থিত অপারেটিং সিস্টেমে সরবরাহকারীর সমর্থিত ক্লায়েন্ট।

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