কেন OpenVPN ক্লায়েন্টরা গেটওয়ের IPsec সিলেক্টর মিস করে

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

গেটওয়ের ping এমন প্রবাহ পরীক্ষা করে যা আপনার ক্লায়েন্ট কখনো ব্যবহার করে না

কোন নীতি প্রযোজ্য হবে তা সোর্স অ্যাড্রেসই ঠিক করে। গেটওয়েতে তৈরি প্যাকেট তার স্থানীয় LAN বা টানেল এন্ডপয়েন্টের অ্যাড্রেস নিয়ে বের হয়, আর যে নীতি তার সাথে মেলে সেটি ঠিক সেই ক্ষেত্রের জন্যই লেখা। ক্লায়েন্টের প্যাকেট OpenVPN ইন্টারফেসে আসে ক্লায়েন্ট পুলের একটি অ্যাড্রেস নিয়ে, যা সম্পূর্ণ ভিন্ন একটি সিলেক্টর।

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

অ্যাপ্লিকেশনের সত্যিই যে দূরবর্তী প্রিফিক্স দরকার সেটি পুশ করুন

সংযুক্ত ক্লায়েন্টের জন্য 10.8.0.0/24 এবং সুরক্ষিত দূরবর্তী নেটওয়ার্কের জন্য 172.30.239.0/25 — এই উদাহরণ জোড়াটি ধরুন। ক্লায়েন্টের দরকার দ্বিতীয় প্রিফিক্সের পথ, গেটওয়ের LAN-এর নয় এবং অন্য কোনো টানেল অ্যাড্রেসেরও নয়। পুলে পুশ করা রুটই ক্লায়েন্টকে সেই ট্রাফিক গেটওয়ের হাতে দিতে বাধ্য করে। এটি ছাড়া প্যাকেট কখনোই আপনার ডিবাগ করা নীতি-সিদ্ধান্তে পৌঁছায় না।

যে Community সার্ভার পুশ করা রুট গ্রহণ করে, সেখানে নির্দেশনাটি আসল মাস্ক নেয়: push "route 172.30.239.0 255.255.255.128"। Access Server একই গন্তব্য ইনস্টল করা সংস্করণের প্রাইভেট-নেটওয়ার্ক বা অ্যাক্সেস-রুল সেটিংসের মাধ্যমে কনফিগার করে, আর রাউটেড বা অনূদিত মোড সচেতনভাবে বেছে নেওয়া হয়। মালিক কনফিগারেশনের বদলে জেনারেট করা ফায়ারওয়াল চেইন সম্পাদনা করলেই একটি কার্যকর সেটআপ পুনরুৎপাদনের অযোগ্য হয়ে পড়ে।

সংযোগের পর সার্ভারের ইচ্ছা নয়, ক্লায়েন্টের রাউটিং টেবিল পড়ুন। কেবল পুল ঢাকা রুট মানে পুশটি কখনো পৌঁছায়নি, আর টানেল দিয়ে ডিফল্ট রুট এই প্রয়োজনের চেয়ে বিস্তৃত এবং পরবর্তীতে আপনাকে বিভ্রান্ত করবে। মাস্কও প্রিফিক্সের সাথে যাচাই করুন, কারণ /25 কে /24 হিসেবে পুশ করলে প্রতিবেশী অ্যাড্রেসের ট্রাফিক এমন পথে যায় যা তা বহন করতে পারে না। তারপর নিশ্চিত করুন যে ক্লায়েন্ট ওই গন্তব্যের জন্য টানেল ইন্টারফেস বেছে নিয়েছে।

সিলেক্টরগুলোতে ক্লায়েন্ট পুল অন্তর্ভুক্ত করুন

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

কনফিগার করা প্রস্তাবের সাথে সাথে সমঝোতা হওয়া নীতিও পরীক্ষা করুন, যেমন strongSwan-এ ipsec statusall বা আপনার বাস্তবায়নের সমতুল্য স্ট্যাটাস কমান্ড দিয়ে। নীতি-ভিত্তিক IPsec-এ সাধারণ রুট কোনো ফিজিক্যাল ইন্টারফেসের দিকে থাকতে পারে অথচ মেলানো ট্রাফিক তখনও এনক্রিপ্টেড, তাই টানেল ডিভাইস না থাকা কিছুই প্রমাণ করে না। সিলেক্টর জোড়াগুলো আপনার লিখে রাখা পুল ও প্রিফিক্সের সাথে মিলিয়ে দেখুন।

গেটওয়েতে সাধারণ সোর্স NAT-ও মিলটি ভাঙতে পারে। যদি নীতি যাচাইয়ের আগে masquerade নিয়ম ক্লায়েন্টের সোর্স পুনর্লিখন করে, তবে প্যাকেট আর আপনার লেখা সিলেক্টরের মতো দেখায় না। বিস্তৃত masquerade নিয়ম দ্বিতীয় VPN-এর দুর্বল সমাধান হওয়ার একটি কারণ এটিই: এটি বদলে দেয় কোন নীতি প্রযোজ্য হবে এবং দূরবর্তী পক্ষ কোন অ্যাড্রেস লগ করবে। আপনি যে ট্রাফিক রাউট করতে চান তা অব্যাহতি দিন, অথবা সচেতনভাবে অনুবাদ করুন এবং সিলেক্টরগুলো মিলিয়ে হালনাগাদ করুন।

সচেতনভাবে রাউটিং বা অনুবাদ বেছে নিন

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

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

ফরওয়ার্ডিং ও উত্তরে চক্রটি বন্ধ করুন

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

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

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