সাইট-টু-সাইট VPN-এর উত্তর টানেল দিয়ে যাচ্ছে না
টানেল এড়িয়ে যাওয়া উত্তর হলো দূর প্রান্তের একটি রাউটিং সিদ্ধান্ত। হোস্ট টেবিল, সিলেক্টর ও rp_filter পরীক্ষা করুন, তারপর রাউট বা NAT বেছে নিন।
একটি টানেলে সকালটা কাটালাম, যা পরিষ্কারভাবে উঠে এসেছিল এবং ঠিক এক দিকেই ট্রাফিক নিয়ে যাচ্ছিল: শাখা অফিস প্রধান কার্যালয়ের ফাইল সার্ভারে পৌঁছাত, আর প্রধান কার্যালয় থেকে শাখায় খোলা প্রতিটি সংযোগ প্রথম SYN-এ মরে যেত। SA-গুলো সক্রিয় ছিল, টানেলের কাউন্টার বাড়ছিল, আর হ্যান্ডশেক কখনোই সমস্যা ছিল না। উত্তরটি এমন জায়গায় রাউট হচ্ছিল যেখানে টানেল পৌঁছায় না, আর সেই সিদ্ধান্ত দূর প্রান্তের। সাইট-টু-সাইট VPN কেবল সেই প্যাকেটগুলোই বহন করে যা হোস্ট গেটওয়ের হাতে দেয়, এবং প্রতিটি হোস্ট সেই সিদ্ধান্ত আলাদাভাবে, প্রতিটি দিকে, নিজের রাউটিং টেবিল থেকে নেয়।
দুই দিক আলাদাভাবে রাউট হয়
IP কথোপকথনের দিক নিয়ে কোনো স্মৃতি রাখে না। যে হোস্ট প্যাকেট পাঠায় সে নিজের দীর্ঘতম-প্রিফিক্স অনুসন্ধান চালায়, একটি পরবর্তী হপ বেছে নেয় এবং সিদ্ধান্তটি ভুলে যায়। অনুরোধ আর উত্তর হলো দুটি সম্পর্কহীন প্যাকেট যা কাকতালীয়ভাবে একই সংযোগের অন্তর্গত, আর টানেল হলো একটি হপ যা তাদের যেকোনোটি ব্যবহার করতে পারে বা নাও পারে। IKE বিনিময়ে কিছুই দূরবর্তী সার্ভারকে শেখায় না কীভাবে আপনার সাবনেটে পৌঁছাতে হবে; আলোচনা কেবল এই বিষয়ে একমত হয় যে কোন প্রিফিক্সগুলো এনক্রিপ্ট করা যাবে।
সেই সম্মতিই দ্বিতীয় দরজা। strongSwan-এ ট্রাফিক সিলেক্টর হলো leftsubnet এবং rightsubnet, আর যে প্যাকেটের উৎস বা গন্তব্য আলোচিত জোড়ার বাইরে পড়ে তা এনক্রিপ্ট হয় না, রাউটিং টেবিল যা-ই বলুক। যে প্রিফিক্স টানেলে রাউট হয় কিন্তু সিলেক্টরে অনুপস্থিত, তা এক নীরব একমুখী ব্যর্থতা: রাউট ঠিক দেখায়, প্যাকেট তবু খোলা অবস্থায় বেরিয়ে যায় বা ফেলে দেওয়া হয়, আর কেবল charon লগেই অভিযোগ করে।
দূরবর্তী হোস্ট আপনার টানেল সম্পর্কে কিছুই জানে না
দূরবর্তী LAN-এর ভিতরে উত্তরটি আপনার ক্লায়েন্টের উদ্দেশ্যে পাঠানো একটি সাধারণ প্যাকেট। গন্তব্য হোস্ট কোনো IPsec হেডার দেখে না এবং VPN গেটওয়েকে অগ্রাধিকার দেওয়ার কোনো কারণ তার নেই; সে আপনার প্রিফিক্স খোঁজে, তার ডিফল্ট রাউটের চেয়ে নির্দিষ্ট কিছু পায় না এবং সেটাই অনুসরণ করে। ডিফল্ট যদি কোনো মূল ফায়ারওয়ালের দিকে দেখায়, তবে ফায়ারওয়ালের হয় টানেলে ফেরার রাউট আছে, নয় নেই। না থাকলে আপনি পান নীরব বাদ, একটি ICMP unreachable, বা এমন উত্তর যা ইন্টারনেটমুখী ইন্টারফেস দিয়ে বেরিয়ে মরে যায়।
দ্বিতীয় একটি ইন্টারফেসই এটি ভাঙার জন্য যথেষ্ট, এমনকি রাউট থাকলেও। অন্য VLAN-এ ম্যানেজমেন্ট লিঙ্কযুক্ত একটি NAS, ব্যাকআপ uplinkযুক্ত একটি সার্ভার, একটি নীতি নিয়ম যা এক উৎস-পরিসরকে দ্বিতীয় টেবিলে পাঠায়: এর যেকোনোটি উত্তরটি ধরে ফেলতে পারে। Linux-এ ip rule show এবং ip route show table all এমন নিয়ম ও টেবিল দেখায় যা ডিফল্ট তালিকা লুকিয়ে রাখে।
যে মেশিন উত্তর পাঠায় সেখানেই সিদ্ধান্তটি পড়ুন
কিছু বদলানোর আগে কার্নেলকে জিজ্ঞাসা করুন এবং তাকে উৎস ঠিকানাটি দিন, কারণ উৎস-নির্ভর নিয়ম উত্তরটি বদলে দেয়।
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"
আউটপুটটি বহির্গামী ইন্টারফেস ও পরবর্তী হপের নাম বলে। ইন্টারফেসটি যদি VPN গেটওয়ের দিকে মুখ করা একটি না হয়, তবে আপনি ত্রুটিটি খুঁজে পেয়েছেন, আর বাকি কাজ হলো রাউটটি কোথায় থাকা উচিত তা বেছে নেওয়া। গেটওয়ে থেকে ping এখানে খুব কম প্রমাণ করে: এটি এমন ঠিকানা দিয়ে উত্তর দেয় যা দূরবর্তী হোস্ট বসাতে পারে, আপনার ল্যাপটপের ঠিকানা নয়।
Windows-এ সমতুল্য হলো সিদ্ধান্তের জন্য Find-NetRoute -RemoteIPAddress 10.10.5.10 এবং টেবিলের জন্য Get-NetRoute। ডিফল্টের চেয়ে বেশি মেট্রিকযুক্ত New-NetRoute দিয়ে যোগ করা রাউট নীরবে হেরে যায়, তাই এন্ট্রি নয়, মেট্রিক কলামটি পড়ুন। তারপর প্যাকেট দিয়ে নিশ্চিত করুন: দূরবর্তী LAN ইন্টারফেসে tcpdump -ni any "host 10.10.5.10 and tcp port 445" অনুরোধটি দেখায়, আর টানেলের দিকে একই ফিল্টার দেখায় উত্তর ফিরে এসেছে কি না। অনুরোধ দেখা যাচ্ছে কিন্তু উত্তর নেই মানে উত্তরটি অন্যত্র রাউট হয়েছে বা ফেলে দেওয়া হয়েছে; ভুল ইন্টারফেসে উত্তর পেলে রাউট ছুঁতে যাওয়ার আগেই আপনি অপরাধীকে পেয়ে যান।
যখন সার্ভারের গেটওয়ে VPN এন্ডপয়েন্ট নয়
অনেক সাইট সার্ভার ও কনসেন্ট্রেটরের মাঝে ফায়ারওয়াল রাখে। সেই ফায়ারওয়াল উত্তরটি ফরওয়ার্ড করে, তাই আপনার ক্লায়েন্ট প্রিফিক্সের জন্য VPN গেটওয়ের দিকে নির্দেশ করা একটি রাউট এবং দুই দিকেই ফরওয়ার্ডিং নীতি দরকার। স্টেটফুল ডিভাইস সব আরও খারাপ করে: অনুরোধটি ফায়ারওয়াল পেরিয়েছিল এমন একটি LAN হোস্ট থেকে যা সে অনুমোদন করেছিল, উত্তরটি এখন অন্য দিক থেকে আসে, আর কানেকশন-ট্র্যাকিং এন্ট্রি আর মেলে না, তাই প্যাকেটটি প্রত্যাখ্যাত না হয়ে অবৈধ হিসেবে বাদ পড়ে। এজন্যই ট্রাফিক মিলিয়ে যাওয়ার সময় পলিসি লগ খালি দেখায়।
গেটওয়ের নিজেরও একটি দ্বিতীয় ফিল্টার আছে। Linux-এর রিভার্স-পাথ ফিল্টারিং সেই প্যাকেটগুলো ফেলে দেয় যাদের উৎস যে ইন্টারফেস দিয়ে তারা এসেছে সেটি দিয়ে পৌঁছানো যায় না, আর এটি বৈধ অসমমিত প্রত্যাবর্তন পথের ঠিক সেই আকৃতিই। strongSwan ফরওয়ার্ডিং নির্দেশিকা ঠিক সেই কারণেই net.ipv4.ip_forward এবং শিথিল net.ipv4.conf.all.rp_filter দাবি করে। যেকোনো একটি গেটওয়েতে কঠোর মান 1 একটি সঠিক রাউট নীরবে ভেঙে দেয়, আর কোথায় দেখতে হবে জানলে nstat -az বাদগুলো দেখায়।
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
রাউট করুন বা অনুবাদ করুন, তারপর দুই দিকেই যাচাই করুন
দুটি মেরামত সমতুল্য নয়। রাউট যোগ করলে ক্লায়েন্টের ঠিকানা অক্ষত থাকে, তাই উৎসভিত্তিক নিয়ম, অডিট লগ এবং যে অ্যাপ্লিকেশনগুলো কলকারীকে রেকর্ড করে সেগুলো কাজ করতে থাকে; মূল্য হলো সিদ্ধান্ত নেওয়া প্রতিটি হপের রাউটটি দরকার, অর্থাৎ ভুল হওয়ার আরও বেশি জায়গা। দূরবর্তী গেটওয়েতে মাস্কারেড প্রত্যাবর্তন পথকে এক হপে সংকুচিত করে, কারণ উত্তরটি এখন গেটওয়ের নিজের ঠিকানায় পাঠানো হয়, আর লুকিয়ে রাখে কোন ক্লায়েন্ট কী করেছে।
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE
এটি সচেতনভাবে বেছে নিন: ক্লায়েন্টরা একবার গেটওয়ের ঠিকানা হিসেবে দেখা গেলে, উৎসভিত্তিক ACL আর তাদের আলাদা করতে পারে না, আর উত্তরটিকে টানেলে ফিরিয়ে লেখার জন্য conntrack-কে ম্যাপিং ধরে রাখতে হয়। সিলেক্টরগুলো যদি এখনো ক্লায়েন্ট প্রিফিক্স বাদ দেয়, তবে NAT কিছুই বদলায় না, কারণ অনুরোধটি কখনোই টানেলে ঢোকেনি।
এটিকে সারানো বলার আগে চারটি বিষয় ক্রমে নিশ্চিত করুন: উত্তর পাঠানো হোস্টের রাউট, সেটি ফরওয়ার্ড করা প্রতিটি হপের রাউট, উভয় প্রিফিক্স ঢাকা সিলেক্টর, এবং একটি ক্যাপচার যা দেখায় উত্তরটি প্রত্যাশিত উৎস নিয়ে টানেলে ঢুকছে। তারপর অন্য সাইট থেকে পরীক্ষাটি পুনরাবৃত্তি করুন। এক দিক পাস করা একটি অর্ধ-খোলা নকশা, আর দ্বিতীয় দিক সাধারণত আপনি এইমাত্র সারিয়েছেন তার চেয়ে ভিন্ন কারণে ব্যর্থ হয়।