রুট-ভিত্তিক বনাম নীতি-ভিত্তিক সাইট-টু-সাইট VPN: কী আলাদা
নীতি-ভিত্তিক IPsec নির্বাচক দিয়ে ট্রাফিক বাছাই করে; রুট-ভিত্তিক তা টানেল ইন্টারফেস দিয়ে পাঠায়। দুটিরই এখনও ফায়ারওয়াল নিয়ম ও ফেরার রুট দরকার।
দুটি নকশাই একই ট্রাফিককে একই IPsec যন্ত্র দিয়ে সুরক্ষিত করে, আর এরা আলাদা হয় এতে যে কোন প্যাকেট টানেলে ঢুকবে তা কী ঠিক করে। নীতি-ভিত্তিক সংযোগে আলোচিত ট্রাফিক নির্বাচকরা সেই কাজ করে; রুট-ভিত্তিক সংযোগে টানেল ইন্টারফেসের দিকে ইশারা করা একটি রুট তা করে। দুটিকে গুলিয়ে ফেললে সেই পরিচিত সহায়তা থ্রেড তৈরি হয় যেখানে টানেল নিজেকে প্রতিষ্ঠিত বলে জানায় কিন্তু অ্যাপ্লিকেশন কিছুই পায় না। এই পার্থক্য সবচেয়ে বেশি গুরুত্বপূর্ণ যখন আপনি নেটওয়ার্ক যোগ করেন, রাউটিং প্রোটোকল চালান, বা এমন পথ ডিবাগ করেন যা চুপচাপ ভুল নির্গমন দিয়ে বেরিয়ে যায়।
টানেলে কী ঢোকে তা ঠিক করার দুটি উপায়
নীতি-ভিত্তিক VPN একটি নিরাপত্তা নীতি তৈরি করে যা উৎস ও গন্তব্য প্রিফিক্সের সঙ্গে মেলে, তারপর যা খাপ খায় তা এনক্রিপ্ট করে। প্রতিপক্ষকে সামঞ্জস্যপূর্ণ নির্বাচক নিয়ে আলোচনা করতে হয়, তাই কার্যকর পরিধি শেষ পর্যন্ত দুই পক্ষের প্রস্তাবের ছেদ হয়ে যায়। সেই ছেদের বাইরে কিছুই সুরক্ষিত নয়, রাউটিং টেবিল যা-ই বলুক।
রুট-ভিত্তিক VPN টানেলের প্রতিনিধিত্বকারী একটি ইন্টারফেস তৈরি করে এবং রাউটিং টেবিলকে তাতে ট্রাফিক পাঠাতে দেয়। IKE ডেমন এখনও অবস্থা ও প্রতি-ইন্টারফেস নীতি ইনস্টল করে, আর রুটগুলো এনক্রিপশনকে প্রতিস্থাপন করেছে বলে সিদ্ধান্ত নেওয়ার সময় মানুষ এই বিবরণটিই এড়িয়ে যায়। দুটি নকশাই IPsec দিয়ে এনক্রিপ্ট করে; শুধু নির্বাচন পদ্ধতি আলাদা।
নিচের তুলনাটি স্কোরকার্ড নয়, বরং ব্যর্থতার লক্ষণসমষ্টি হিসেবে পড়ুন, কারণ কোনো স্তম্ভ নিজে থেকে জেতে না।
| Aspect | Policy-based | Route-based |
|---|---|---|
| What selects traffic | Negotiated selectors | A route into the tunnel interface |
| Adding a network | Edit selectors on both peers | Add a route, widen the selector once |
| Dynamic routing | Awkward to run over the tunnel | Runs over the interface directly |
| Typical failure | Tunnel up, host outside the selector | Tunnel up, no route or wrong source |
নীতি-ভিত্তিক: নির্বাচকই চুক্তি
নির্বাচকরা আলোচনার বিষয়, কেবল কনফিগার করা হয় না। এক পাশে 10.10.0.0/16 এবং অন্য পাশে 10.10.1.0/24 প্রস্তাব করুন, তখন সংযুক্তি আলোচনা যেখানে থেমেছিল তা ঢাকবে আর বাকি প্রতিটি হোস্ট বাইরে থাকবে।
কনফিগারেশন ফাইলের বদলে ইনস্টল করা অবস্থা পড়ুন। Linux প্রতিপক্ষে কার্নেলের নিজস্ব টেবিলই মূল সত্য, এবং সেগুলো দেখায় আলোচনা থেকে কী টিকে গেছে। যে নীতি সঠিক প্রিফিক্সের নাম দেয় কিন্তু মিলতে পারে এমন অবস্থা নেই, তার অর্থ সংযুক্তি কখনও ওঠেনি। ভুল প্রিফিক্সের জন্য নীতির সঙ্গে জোড়া অবস্থা বিপরীত সমস্যা, এবং তা এমন টানেল বানায় যা সুস্থ দেখায় অথচ একটি সাবনেট কোথাও পৌঁছায় না।
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasআপনি যেসব প্রিফিক্স সুরক্ষিত রাখছেন বলে মনে করেন সেগুলোর সঙ্গে দুই আউটপুট তুলনা করুন। ওই একটি তুলনাই কাজ করা টানেল ও অগম্য সার্ভার নিয়ে বেশিরভাগ প্রতিবেদন সমাধান করে। কোন প্রতিপক্ষ বদলাতে হবে তাও দেখায়, কারণ অমিল সাধারণত এক দিকেই দেখা যায়।
রুট-ভিত্তিক: ইন্টারফেসই চুক্তি
XFRM ইন্টারফেস টানেলকে নাম ও পরিচয় দেয়, আর রাউটিং টেবিল তা বলে বলে ট্রাফিক সেখানে পৌঁছায়। তখন কয়েকটি দূরবর্তী প্রিফিক্স নির্বাচকের সমস্যার বদলে রাউটিংয়ের সমস্যা হয়ে ওঠে, এবং রাউটিং প্রোটোকল সেগুলো ঘোষণা করতে পারে। এটাই আসল লাভ, এনক্রিপশন নয়।
ইন্টারফেস নীতির প্রয়োজন মেটায় না। ডেমন ইন্টারফেসের পরিচয়ের সঙ্গে বাঁধা নিয়ম প্রতিটি ইন্টারফেসের জন্য ইনস্টল করে, তাই ভুল ইন্টারফেসে আসা প্যাকেট তবুও ব্যর্থ হয়। প্রতিপক্ষ যে উৎস ঠিকানায় রাজি হবে না সেটিও নিখুঁত রুট থাকা সত্ত্বেও ব্যর্থ হয়। রুট-ভিত্তিক মানে প্রবেশ রুট ঠিক করে, নীতি হারিয়ে যায়নি।
sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10রুট জায়গায় বসার পর ইন্টারফেস কাউন্টার লক্ষ্য করুন। রুট আছে কিন্তু কাউন্টার শূন্যে দাঁড়িয়ে থাকলে বোঝায় টানেলে কিছুই মেলানো হচ্ছে না, যা সাধারণত অনুপস্থিত রুটের বদলে অনুপস্থিত অবস্থার দিকে ইশারা করে।
দুটি নকশা আসলে কোথায় আলাদা হয়
নেটওয়ার্ক যোগ করা হলো কোন মডেল আপনার জন্য খাপ খায় তা পরীক্ষার সবচেয়ে পরিচ্ছন্ন উপায়। রুট-ভিত্তিক নকশা একটি রুট যোগ করে এবং সর্বাধিক একবার নির্বাচক চওড়া করে, অন্যদিকে নীতি-ভিত্তিক নকশা দুই প্রতিপক্ষেই প্রিফিক্স জোড়া সম্পাদনা করে আবার আলোচনা করে। দুটি স্থির সাবনেট সেই সম্পাদনাকে তুচ্ছ করে, আর বিশটি তা প্রকল্পে পরিণত করে।
কোনো মডেলই ফায়ারওয়ালের জায়গা নেয় না, আর তুলনাগুলো সাধারণত এই বিন্দুর আগেই থামে। প্রশস্ত নির্বাচক বা প্রশস্ত রুট ঠিক করে কী এনক্রিপ্ট হবে, কী অনুমোদিত তা নয়।
MTU-এর আচরণও বাস্তবে আলাদা। এনক্যাপসুলেশন ব্যবহারযোগ্য পেলোড কমায়, আর রুট-ভিত্তিক ইন্টারফেস নিজের MTU বহন করে, তাই দুই গেটওয়েতে MSS ক্ল্যাম্প করলে ছোট উত্তর আসে আর বড়গুলো হারিয়ে যায় এমন ব্ল্যাক-হোল লক্ষণ এড়ানো যায়। নীতি-ভিত্তিক টানেল অন্য দিক থেকে একই দেয়ালে ধাক্কা খায়, কারণ নির্বাচক প্যাকেটের আকার নিয়ে কিছু বলে না। প্রতিপক্ষকে দোষ দেওয়ার বদলে ক্ল্যাম্প সচেতনভাবে সেট করুন।
ফেরার পথ না হারিয়ে স্থানান্তর
কিছু বদলানোর আগে বিদ্যমান প্রিফিক্স জোড়া লিখে রাখুন, তারপর একটি অ্যাপ্লিকেশন পথ সরিয়ে তা শুরু থেকে শেষ পর্যন্ত দেখুন। প্রতিষ্ঠিত হওয়া টানেল মানে ফরোয়ার্ড করা টানেল নয়, আর পার্থক্য ধরা পড়ে উত্তরের দিকটায়।
প্রতিপক্ষরা সংযুক্ত হয় কিন্তু LAN হোস্ট পারে না, তখন ফেরার রুট ও দূরবর্তী হোস্ট যে উৎস ঠিকানা ব্যবহার করবে তা দেখুন। দুটি ইন্টারফেসওয়ালা হোস্ট ভুলটি থেকে উত্তর দিতে পারে, আর কোনো নির্বাচক পরিবর্তন তা সারায় না। অ্যালগরিদম সম্পাদনার আগে দুই প্রান্তে ট্রাফিক ধারণ করুন।
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-connsকাজ করার সময় টানেলের উপর নির্ভরশীল নয় এমন একটি ব্যবস্থাপনা পথ রাখুন। গেটওয়ের নিজের অ্যাক্সেস যখন আপনি যে সংযোগ ডিবাগ করছেন তার উপর চড়ে না, তখন ফিরিয়ে নেওয়া সহজ।