দূরবর্তী ব্যবহারকারীরা VPN হাবের মধ্য দিয়ে দ্বিতীয় সাইটে পৌঁছাতে পারেন না

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

ট্রানজিটের জন্য তিনটি লুকআপ দরকার, একটি টানেল নয়

প্রতিটি ডিভাইস নিজের দীর্ঘতম-প্রিফিক্স মিল তৈরি করে এবং তা ভুলে যায়। ল্যাপটপকে 10.20.0.50 তার স্থানীয় রাউটারের বদলে টানেলে পাঠাতে হবে। হাবকে দূরবর্তী-অ্যাক্সেস ইন্টারফেসে আসা প্যাকেট নিয়ে সাইট-টু-সাইট ইন্টারফেসে দিতে হবে। সদর দপ্তরকে ব্যবহারকারীর ঠিকানার জন্য উত্তর টানেলের মধ্য দিয়ে ফেরত পাঠাতে হবে। তিনটির যেকোনো একটি ব্যর্থ হলে ব্রাউজারে একই দেখায়: নীরবতা।

এই কারণেই প্রতিটি টানেল আলাদাভাবে পরীক্ষা করা এত কম প্রমাণ করে। হাবের LAN ঠিকানায় পিং করা প্রথম সিদ্ধান্তটি চালায়, আর সদর দপ্তর থেকে হাবে পিং করা তৃতীয়টি চালায়। যে প্যাকেটটি ব্যর্থ হয় তার উৎস ব্যবহারকারী পুল এবং গন্তব্য দ্বিতীয় সাইট, তাই আগে ওই প্রিফিক্সগুলো লিখে নিন। এখানে পুল 10.80.0.0/24, হাবের LAN 10.10.0.0/24 এবং সদর দপ্তর 10.20.0.0/24।

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

একটি OpenVPN দূরবর্তী-অ্যাক্সেস সার্ভারে ক্লায়েন্ট সংযোগের সময় রুটগুলো শেখে। পুশ ছাড়া একটি স্প্লিট-টানেল ক্লায়েন্ট 10.20.0.50 নিজের গেটওয়েতে পাঠায় এবং প্যাকেটটি কখনো টানেলে ঢোকে না।

push "route 10.20.0.0 255.255.255.0"

পুশ করা রুট ক্লায়েন্ট সংযোগ করার সময় কার্যকর হয়, তাই যে ব্যবহারকারী অনলাইনে থাকেন তিনি পুনরায় সংযোগ না করা পর্যন্ত কিছু দেখেন না। ক্লায়েন্টে যাচাই করুন: Linux-এ ip route get 10.20.0.50, Windows-এ route print। আউটপুটে টানেল ইন্টারফেসের নাম থাকা উচিত।

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

হাবকে একটি প্রকৃত ইগ্রেস রুট দিন

হাবের সদর দপ্তরের প্রিফিক্সের জন্য নিজের পরবর্তী হপ দরকার। রাউটেড টানেলে সেটি সাইট-টু-সাইট ইন্টারফেসের মধ্য দিয়ে একটি সাধারণ রুট, এবং একটি কমান্ডই নির্বাচিত রুট ও নির্বাচিত উৎস দুটোই দেখায়:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

যেখানে সাইট-টু-সাইট অংশটি নিজেই OpenVPN, সেখানে রুটটি সেই কনফিগারেশনেই থাকতে পারে, পিয়ারের টানেল ঠিকানাকে গেটওয়ে হিসেবে নিয়ে: route 10.20.0.0 255.255.255.0 172.30.0.2। গেটওয়ে ঐচ্ছিক নয়। এটি বাদ দিলে পরবর্তী হপ বাস্তবায়নের একটি ডিফল্টে পড়ে, যা একক-দূরবর্তী ক্লায়েন্ট আর বহু-পিয়ার হাবের মধ্যে আলাদা।

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

দূর পাশকে ব্যবহারকারী পুল পর্যন্ত বাড়ান

সদর দপ্তর ইতিমধ্যে হাবের LAN, 10.10.0.0/24 কভার করে। ব্যবহারকারী পুল দ্বিতীয় প্রিফিক্স এবং সেটিও সিলেক্টরগুলিতে থাকতে হবে, নইলে 10.80.0.25-এ ঠিকানো কোনো উত্তর কোনো পলিসি কভার করে না। প্রতিটি পিয়ার নিজের পাশ থেকে প্রিফিক্স সেটের একই জোড়ার নাম দেয়:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

একটি ডিভাইসের local_ts অন্যটির remote_ts। হাবের ব্লকটি সদর দপ্তরে কপি করলে জোড়াটি উল্টে যায়, ফলে চাইল্ড SA কখনো ওঠে না।

পুরোনো ipsec.conf সিনট্যাক্সে কমা-বিভক্ত leftsubnet ব্যবহার হয়। চলমান সিকিউরিটি অ্যাসোসিয়েশন যে সিলেক্টরগুলো নিয়ে আলোচনা করেছে সেগুলো ধরে রাখে, তাই সম্পাদনার পরে টানেলটি পুনঃপ্রতিষ্ঠা করুন। 10:00-এ বদলানো একটি সিলেক্টর 09:40-এ ওঠা SA-এর বিরুদ্ধে পরীক্ষা করলে এখনও ব্যর্থ হয়, অথচ কনফিগ ফাইলটি সব সময় সঠিক দেখায়।

তারপর শেষ হপটি যাচাই করুন। দূর প্রান্তে ip route get 10.80.0.25 টানেলের দিকে নির্দেশ করা উচিত। যদি সার্ভিসটি LAN রাউটারকে তার ডিফল্ট গেটওয়ে হিসেবে ব্যবহার করে, সেই রাউটারেরও রিটার্ন রুট দরকার, নইলে উত্তর সেখানেই মরে। ওই সেগমেন্টে tcpdump -ni eth1 host 10.80.0.25 চালালে দেখা যায় উত্তরটি প্রান্ত থেকে আদৌ বেরিয়েছিল কি না।

হাবে ফ্লোটি অনুমোদন করুন

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

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

রিভার্স-পাথ ফিল্টারিং তার পাশের নীরব ব্যর্থতা: দুটি অংশ ভিন্ন ইন্টারফেসে থাকলে rp_filter=1 উত্তরটি ফেলে দিতে পারে, অথচ গ্রহণ নিয়মের কাউন্টার নড়ে না। একটি প্রচেষ্টার আগে ও পরে iptables -vnL FORWARD তুলনা করুন। যে নিয়ম কখনো বাড়ে না সেখানে পৌঁছানোই হয় না, তাই এটি পুনর্লিখনের বদলে এক স্তর নিচে দেখুন।

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

ক্লায়েন্ট থেকে যাচাই করুন, তারপর উল্টো ক্রমে রোলব্যাক করুন

কেবল ICMP নয়, একটি TCP পোর্ট পরীক্ষা করুন, কারণ পিং পাস করতে পারে অথচ সার্ভিস ব্লকড থাকে। ক্লায়েন্ট থেকে nc -vz 10.20.0.50 445 এবং traceroute -n 10.20.0.50 দেখায় দ্বিতীয় হপটি হাবের টানেল ঠিকানা কি না। হাবে, tcpdump -ni tun0 host 10.20.0.50 এবং সাইট-টু-সাইট ইন্টারফেসে একই ফিল্টার: দুটোতেই অনুরোধ কিন্তু কোনোটিতেই উত্তর না থাকলে সমস্যাটি দূর পাশে সরে যায়।

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

একটি রোলব্যাক তালিকা রাখুন, কারণ চারটি বস্তু বদলেছে এবং তিনটি সহজে ভুলে যাওয়ার মতো: পুশ করা রুট, হাবের রুট, সিলেক্টর এবং ফায়ারওয়াল নিয়ম। উল্টো ক্রমে সেগুলো ফিরিয়ে নিন, SA পুনঃপ্রতিষ্ঠা করুন এবং একজন ব্যবহারকারীকে পুনরায় সংযোগ করতে দিন। আংশিক রোলব্যাক এমন একটি টানেলের দিকে রুট রেখে যায় যা আর মেলে না, আর তা মূল নীরবতার চেয়ে পড়া কঠিন। OpenVPN 2.6 ম্যানুয়াল আপনার সংস্করণের জন্য push, route এবং iroute নথিভুক্ত করে।