OpenVPN দিয়ে পাবলিক প্রিফিক্স: ফেরার পথ ঠিক করা

টানেল উঠে আসা এবং ক্লায়েন্টের ওপারের দিকে পিং করা দেখুন, তারপর VPN-এর পেছনে থাকা একটি পাবলিক ঠিকানা অন্য জায়গা থেকে উত্তর দেয়, বা একেবারেই দেয় না। এই উপসর্গটির সাধারণত সাইফার বা সার্টিফিকেটের সঙ্গে কোনো সম্পর্ক নেই। প্রোভাইডারের রাউট করা প্রিফিক্স একটি IP রুট হিসেবে পৌঁছে দেওয়া হয়, এবং OpenVPN দিয়ে বহন করা মানে সেই রুটটি দুটি স্তরে পুনরুত্পাদন করা এবং ফেরার পথে সোর্স ঠিকানাটি সংরক্ষণ করা। WAN ব্রিজ করা প্রয়োজন নেই, এবং ঠিকানাটি একটি ইন্টারফেসে যোগ করলে আপস্ট্রিম রুট তৈরি হয় না।

প্রিফিক্সটি আগে আপনার কাছে রাউট করতে হবে

প্রোভাইডারকে জিজ্ঞাসা করুন ব্লকটি কীভাবে পৌঁছে দেওয়া হয়। আপনার সার্ভারের প্রধান ঠিকানায় রাউট করা প্রিফিক্স আর প্রোভাইডার যে ঠিকানাগুলো WAN সেগমেন্টে সরাসরি পৌঁছাতে চায় সেগুলো আলাদা জিনিস। এখানে কেবল প্রথম মডেলটি ডিজাইনের সঙ্গে কাজ করে।

যদি প্রোভাইডার 198.51.100.64/28 আপনার এন্ট্রি সার্ভারে রাউট করে, তবে ওই রেঞ্জের প্যাকেট সার্ভারে পৌঁছে সেখানেই থেমে যায়, যদি আপনি সেগুলো ফরওয়ার্ড না করেন। আর যদি প্রোভাইডার বরং রেঞ্জটি আপনার আপলিংকে ব্রিজ করে, তবে সার্ভারকে এর জন্য ARP-এর উত্তর দিতে হবে, যা আলাদা সমস্যা।

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

দুটি রাউটিং স্তর: কার্নেল রুট এবং iroute

OpenVPN-এর প্রিফিক্সটি দুটি জায়গায় দরকার। কার্নেলকে জানতে হবে প্রিফিক্সটি টানেল ডিভাইসের, যাতে ফরওয়ার্ড করা প্যাকেট ডিফল্ট রুটের বদলে OpenVPN-এ ঢোকে। OpenVPN-কেও জানতে হবে কোন প্রমাণিত ক্লায়েন্ট প্রিফিক্সটির মালিক, আর সেটি হলো ক্লায়েন্ট-নির্দিষ্ট ডিরেক্টরির iroute এন্ট্রি।

সার্ভার-সাইড রুটটি এমন দেখায়, যেখানে প্রিফিক্স ও মাস্ক বরাদ্দের সঙ্গে মিলতে হবে:

ip route add 198.51.100.64/28 dev tun0

ক্লায়েন্ট-নির্দিষ্ট কনফিগারেশন মালিকানা বরাদ্দ করে। এটি ক্লায়েন্ট সার্টিফিকেটের কমন নেমে নামকরণ করা CCD ফাইলে রাখুন, এবং নিশ্চিত করুন যে ডিরেক্টরিটি সার্ভার আসলে পড়ে:

iroute 198.51.100.64 255.255.255.240

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

সার্ভিস ঠিকানাটি কোথায় থাকে

ডেলিগেট করা প্রিফিক্স টানেলের নিজস্ব ঠিকানার সমান নয়। চাইলে লিংকটি প্রাইভেট স্পেস থেকে নম্বর দিন, এবং পাবলিক সার্ভিস ঠিকানাটি সেখানে রাখুন যেখানে সার্ভিসটি সত্যিই চলে।

যে Linux ক্লায়েন্ট সার্ভিসটি স্থানীয়ভাবে টার্মিনেট করে, সেখানে একটি হোস্ট ঠিকানাই যথেষ্ট:

ip address add 198.51.100.70/32 dev lo

যদি প্রিফিক্সটি আরও পরে একটি VM হোস্ট বা অন্য LAN-এ রাউট হয়, তবে বরং সেই ডাউনস্ট্রিম পথ ও তার ফেরার রুট কনফিগার করুন। ব্লকের প্রতিটি ঠিকানা VPN ক্লায়েন্টে অ্যাসাইন করা প্রয়োজন নেই এবং পরে দ্বন্দ্ব তৈরি করে।

ফেরার পথে পাবলিক সোর্স রাখুন

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

এন্ট্রি সার্ভারে একটি বিস্তৃত masquerade নিয়মই সাধারণ অপরাধী। এটি পাবলিক সোর্সকে সার্ভারের প্রধান ঠিকানায় পুনর্লিখন করে, এবং ক্লায়েন্ট আসলটি কখনও দেখে না:

iptables -t nat -S POSTROUTING

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

বিশ্বাস করার আগে দুই দিকই যাচাই করুন

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

কার্নেলকে জিজ্ঞাসা করুন একটি ডেলিগেট করা ঠিকানা কোন পথ নেয়, এবং একটি অনুরোধ চলার সময় টানেলটি দেখুন:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

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

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

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