pfSense VPN সার্ভার ও ক্লায়েন্ট হিসেবে: দুই পথ, এক রাউটার

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

কোনো সেটিংয়ে হাত দেওয়ার আগে দুই ভূমিকার নাম দিন

প্রতিটি ইনস্ট্যান্সের জন্য চারটি তথ্য লিখে রাখুন: তার দূরবর্তী প্রতিপক্ষ, তার প্রমাণীকরণ উপাদান, যে ঠিকানা-পুলটি সে বিতরণ করে, এবং তার পেছনের নেটওয়ার্কগুলো। দুটি ইনস্ট্যান্স যন্ত্রের ওপর আলাদা বস্তু, আর আপনার নোটেও তাদের আলাদা থাকা উচিত। পরবর্তীতে প্রায় প্রতিটি বিভ্রান্তিকর উপসর্গ আসে তাদের মান গুলিয়ে ফেলা থেকে, আর দুটি ইনস্ট্যান্স একই নোট ভাগ করলে ভুল পুলটি ভুল ঘরে গিয়ে পড়ে।

প্রবেশমুখী সেবার এমন একটি টানেল নেটওয়ার্ক দরকার যা বহির্গামী টানেলের ঠিকানার সঙ্গে, বা যন্ত্রটি যে কোনো ব্যক্তিগত নেটওয়ার্ক রাউট করে তার সঙ্গে, ওভারল্যাপ না করে। ওভারল্যাপই একমাত্র ভুল যা দুই ভূমিকাতেই একসঙ্গে উপসর্গ তৈরি করে, আর কাগজেই তা ধরা অনেক সস্তা। যেকোনো একটি সেবা কনফিগার করার আগে দুই পুল ও প্রতিটি রাউট করা ব্যক্তিগত নেটওয়ার্ক এক জায়গায় তুলনা করুন।

ভাগ করা হার্ডওয়্যার মানে ভাগ করা শংসাপত্র নয়, আর দূরবর্তী প্রবেশের পুল থেকে নেওয়া ক্লায়েন্ট সার্টিফিকেট নির্গমন প্রদানকারীর বিরুদ্ধে ব্যবহারযোগ্য হওয়া উচিত নয়। আলাদা উপাদান প্রত্যাহারকেও বহরজুড়ে ঘটনার বদলে স্থানীয় সিদ্ধান্তে পরিণত করে।

সার্ভারের উত্তরগুলো WAN পথেই রাখুন

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

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

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

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

নির্গমন টানেলকে তার নিজের প্রান্তবিন্দু খেতে দেবেন না

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

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

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

কোন ব্যবহারকারীরা নির্গমন পাবে তা বাছুন

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

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

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

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

নির্গমন ব্যর্থ হলে কী হবে তা ঠিক করুন

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

ক্লায়েন্ট ইনস্ট্যান্সটি নিষ্ক্রিয় করুন, দেখুন সংযুক্ত ব্যবহারকারী এখনও কী পৌঁছাতে পারে, তারপর আবার চালু করুন। যে অনুরোধ সময়সীমা ছাড়িয়ে যায় সেটিই আপনি চাওয়া সম্পূর্ণ অবরোধের ফল; যে অনুরোধ WAN ঠিকানা দিয়ে উত্তর দেয় সেটিই আপনি নথিভুক্ত না করা ফেরত। যাচাইটি IPv6 ও DNS-এর জন্য পুনরাবৃত্তি করুন, কারণ IPv4-এর জন্য লেখা নীতি AAAA ট্রাফিক নিয়ে কিছু বলে না, আর যেকোনো টানেল দিয়ে ঠেলা রিজলভার যেখান থেকেই কোয়েরি সত্যিই বেরোয় সেখান থেকেই উত্তর দেয়।

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

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