pfSense OpenVPN: অন্য রাউটারের পেছনের নেটওয়ার্কে পৌঁছানো

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

কোনো নিয়ম বদলানোর আগে একটি প্যাকেটকে ওই তিনটি সিদ্ধান্তের মধ্য দিয়ে অনুসরণ করুন, কারণ প্রতিটি মালিকের নিয়ন্ত্রণ আলাদা এবং ব্যর্থতার ধরনও আলাদা।

একটি প্যাকেট, তিনটি রাউটিং সিদ্ধান্ত

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

এর যেকোনো একটির ব্যর্থতা একই ব্যবহারকারী-প্রতিবেদন তৈরি করে। এজন্যই ডিবাগিংয়ের ক্রম টুলের চেয়ে বেশি গুরুত্বপূর্ণ।

ক্লায়েন্টকে প্রিফিক্স দিন, অনুমান নয়

IPv4 টানেল নেটওয়ার্ক /30-এর চেয়ে বড় এমন একটি pfSense SSL/TLS সার্ভারে, IPv4 Local network(s) ফিল্ডটি সংযোগের সময় ক্লায়েন্টদের কাছে রুট বিতরণ করে। ক্লায়েন্ট নিজে একটি বানাবে এই ভরসার বদলে ডাউনস্ট্রিম প্রিফিক্সটি সেখানে যোগ করুন। তারপর সংযোগের পর ক্লায়েন্টের প্রকৃত টেবিলটি পড়ুন, কারণ route-nopull সহ একটি প্রোফাইল বা একটি রুট ফিল্টার সার্ভার যা পাঠিয়েছে তা উপেক্ষা করতে পারে। সার্ভার সম্পূর্ণ সঠিক থাকতে পারে, অথচ ক্লায়েন্ট কিছুই ইনস্টল করে না।

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

pfSense-কে অভ্যন্তরীণ রাউটারের দিকে নির্দেশ করুন

pfSense-এ একটি স্ট্যাটিক রুটের জন্য সংজ্ঞায়িত ও পৌঁছানো যায় এমন একটি গেটওয়ে দরকার, আর সেই গেটওয়ের জন্য নির্বাচিত ইন্টারফেসটি অবশ্যই এমন হতে হবে যা সত্যিই সেখানে পৌঁছায়, যেমন Netgate-এর স্ট্যাটিক-রুট নির্দেশিকা বর্ণনা করে। একটি উদাহরণস্বরূপ বিন্যাসে ট্রানজিট লিংক ফায়ারওয়ালে 192.168.77.1 এবং অভ্যন্তরীণ রাউটারে 192.168.77.2, আর সার্ভিস নেটওয়ার্ক তার পেছনে 172.16.30.0/25। তখন রুটটি প্রিফিক্স ও পরবর্তী হপের নাম বলে, সার্ভিসের ঠিকানা নয়। দূরবর্তী নেটওয়ার্কের একটি ঠিকানা গেটওয়ে হিসেবে ব্যবহার করা এমন একটি রুট বানানোর সাধারণ উপায় যা সঠিক দেখায় কিন্তু কোথাও ফরওয়ার্ড করে না।

ইন্টারফেসকে একটি নাম দেওয়া তার ওপারের নেটওয়ার্কগুলো বর্ণনা করে না। স্ট্যাটিক রুটই সেই বর্ণনা।

দূরের পক্ষকে পুলটি জানতে হবে

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

এই নকশার জন্য কোনো অনুবাদ দরকার নেই, আর ক্লায়েন্টের উৎস ঠিকানাকে দৃশ্যমান রাখলে ডাউনস্ট্রিম নেটওয়ার্ক তার নিজস্ব নীতি প্রয়োগ করতে পারে।

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

তিন-মালিকের পরিকল্পনাটি অনুমোদিত অ্যাপ্লিকেশনের পাশে সংরক্ষণ করুন, যাতে পরবর্তী প্রশাসক পথটি নতুন করে আবিষ্কার না করে পুনর্গঠন করতে পারেন।