সাইট-টু-সাইট VPN জুড়ে IPv6 প্রিফিক্স ডেলিগেশন: চেকলিস্ট

সাইট-টু-সাইট VPN জুড়ে ডেলিগেট করা IPv6 প্রিফিক্স রাউটিংয়ের জন্য যাচাই: প্রিফিক্স ম্যাপ, ট্র্যাফিক সিলেক্টর, ফরওয়ার্ডিং, MTU, ফেরার পথ এবং পুনঃনম্বরকরণ।

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

টানেল স্পর্শ করার আগেই প্রিফিক্স ম্যাপ লিখুন

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

প্রতিটি সাইটের জন্য ডেলিগেট করা প্রিফিক্স, LAN-এ প্রকৃতপক্ষে ব্যবহৃত /64, টানেলের ঠিকানা এবং প্রতিটি রাউটের মালিক লিখে রাখুন। প্রোভাইডার সাইট A-কে 2001:db8:a1::/56 ডেলিগেট করে, যা তার LAN-এ 2001:db8:a1:10::/64 সার্ভ করে; সাইট B 2001:db8:b2::/64 রাখে। সাইট A যদি কেবল ওই একটি /64 সার্ভ করে, তবে দুই প্রান্তেই পুরো /56-এর বদলে 2001:db8:a1:10::/64 লেখা উচিত।

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

দুই প্রান্তের ট্র্যাফিক সিলেক্টর রাউটের সঙ্গে মিলিয়ে নিন

IKEv2 আর WireGuard দুটোই বেমানান ট্র্যাফিক প্রত্যাখ্যান করে, এতটাই চুপচাপ যে টানেল তখনো সুস্থ দেখায়।

strongSwan-এ সিলেক্টরগুলো স্পষ্ট। সাইট A-তে:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

সাইট B-এর conn দুটি সাবনেটেরই প্রতিচ্ছবি। তারা অসঙ্গত হলে রেসপন্ডার CHILD_SA-কে TS_UNACCEPTABLE দিয়ে প্রত্যাখ্যান করে, ফলে IKE_SA ওঠার পরেও চাইল্ড SA কখনো ওঠে না। দুই দিকেই কনফিগার করা সাবনেট স্থানীয় কার্নেল টানেলের দিকে যা রাউট করে তার সমান হতে হবে।

WireGuard একই তথ্য AllowedIPs-এ বহন করে, একটি মোচড়সহ: AllowedIPs গ্রহণে সোর্স ফিল্টার এবং প্রেরণে রাউট — দুটোই। সাইট B-এর সাইট A-এর পিয়ার এন্ট্রি যদি 2001:db8:a1:10::/64 বাদ দেয়, তবে সাইট A থেকে আসা প্যাকেট বৈধ হ্যান্ডশেকেই পৌঁছায় এবং অননুমোদিত হিসেবে ফেলে দেওয়া হয়। এতে সেই চেনা প্যাটার্ন তৈরি হয়: হ্যান্ডশেক বারবার নবায়ন হয়, অথচ কোনো উত্তর বেরোয় না। দুই প্রান্ত wg show wg0 allowed-ips দিয়ে মিলিয়ে দেখুন। ডেলিগেশন বদলালে তালিকাটি আবার যাচাই করুন; পুরোনো /64 সেশন চালু রাখে আর নতুন প্রিফিক্সকে অপ্রাপ্য করে।

আগে ফরওয়ার্ডিং, ফায়ারওয়াল ও MTU বাদ দিন

আরেকটি লগ লাইন পড়ার আগে নিশ্চিত করুন গেটওয়েগুলো আদৌ ফরওয়ার্ড করে। sysctl net.ipv6.conf.all.forwarding-কে দুই ক্ষেত্রেই 1 ফেরাতে হবে, টানেল ও LAN ইন্টারফেসেও প্রয়োগ করে। সঙ্গে একটি ফাঁদ আসে: ফরওয়ার্ডিং চালু হলে accept_ra=1 থাকা ইন্টারফেস প্রোভাইডারের রাউটার অ্যাডভার্টাইজমেন্ট নেওয়া বন্ধ করে, তাই বক্সটি টানেলের ভেতরে নিখুঁত রাউট করলেও ওপরের ডিফল্ট রাউট হারাতে পারে। যেখানে প্রোভাইডার RA এখনো দরকার, সেখানে accept_ra=2 সেট করুন।

এরপর ফায়ারওয়াল নিয়মকে দুই দিকেই প্রিফিক্স অনুমোদন করতে হবে, আর ICMPv6-কে টিকে থাকতে হবে: নেইবার ডিসকভারি, প্যাকেট-টু-বিগ এবং ডেস্টিনেশন-আনরিচেবল ঐচ্ছিক নয়। এগুলো ফেলে দিলে পাথ MTU ডিসকভারি ভেঙে যায়, ফলে এমন কানেকশন পাবেন যা খোলে, তারপর প্রথম বড় রেসপন্সেই আটকে যায়। ন্যূনতম এক জোড়া নিয়ম এমন দেখায়:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

MTU এর পেছনে থাকে। টানেল ব্যবহারযোগ্য MTU-কে 1500-এর নিচে নামায়, আর IPv6 দাবি করে প্রতিটি লিংক অন্তত 1280 বহন করবে। ছোট পিং পার হয়, বড় বার্স্টে SSH সেশন জমে যায়, আর /proc/net/snmp6 এমন প্যাকেট-টু-বিগ বার্তা দেখায় যা কখনো ফেরে না। টানেলের MTU স্পষ্টভাবে সেট করুন, বা mangle টেবিলে TCP MSS ক্ল্যাম্প করুন, এবং ছোট MTU জানানো ICMPv6-কে ফিরতে দিন।

টানেলের ঠিকানা নয়, ফেরার পথ পরীক্ষা করুন

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

What you seeLikely causeFirst check
Tunnel up, every host silentremote prefix not routed into the tunnelip -6 route get on both gateways
Handshake renews, no repliessource prefix missing from selectors or AllowedIPsipsec statusall, wg show allowed-ips
Small pings pass, transfers stallMTU or ICMPv6 packet-too-big filtered/proc/net/snmp6 counters
Old prefix still worksstale /64 left in routes or selectorsdelegation lease and route table

দুটি কমান্ডই বেশিরভাগটা নিষ্পত্তি করে। সাইট A-তে ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 দেখায় সেই সোর্স থেকে উত্তর কোন ইন্টারফেস ব্যবহার করবে; সাইট B-তে আয়নাযুক্ত যাচাই চালান। তারপর গেটওয়ে নয়, একটি হোস্ট থেকে ট্র্যাফিক তৈরি করুন এবং দুই প্রান্তের কাউন্টার মিলিয়ে দেখুন।

দূরের প্রিফিক্সের জন্য নেইবার সলিসিটেশন টানেলে দেখা গেলে, ওই প্রিফিক্স এমন জায়গায় অন-লিংক যেখানে থাকা উচিত নয়; রাউট ঠিক করার আগে সেটি সারিয়ে নিন। Proxy NDP সেই ক্ষেত্রগুলো কভার করে যেখানে সত্যিই ব্রিজিং দরকার; এটি রাউটের বিকল্প নয়।

প্রিফিক্স আপনার পায়ের নিচে বদলে যাওয়ার পরিকল্পনা করুন

প্রিফিক্স ডেলিগেশন হলো ডেলিগেটিং ও অনুরোধকারী রাউটারের মধ্যে একটি লিজ, আর নবায়নে ভিন্ন ব্লক ফিরতে পারে: প্রোভাইডার মাইগ্রেশনের পর ভিন্ন /56, বা টানেল যতদিন চালু আছে তার চেয়ে ছোট লিজ। পুরোনো প্রিফিক্স যে প্রতিটি জায়গায় নাম লেখা আছে, সব একসঙ্গে পুরোনো হয়ে যায়: রাউট, সিলেক্টর, AllowedIPs, ফায়ারওয়াল নিয়ম, DNS রেকর্ড এবং আক্ষরিক ঠিকানা হার্ডকোড করা যেকোনো মনিটরিং। বার্তাপ্রবাহ আছে RFC 8415।

যেখানে প্রিফিক্স সরে যাওয়ার সম্ভাবনা আছে, সেখানে এমন একটি অভ্যন্তরীণ অ্যাড্রেস প্ল্যান রাখুন যা তার ওপর নির্ভর করে না এবং সীমান্তে অনুবাদ করুন। NPTv6 স্টেটলেস বিকল্প এবং অভ্যন্তরীণ নীতি পাঠযোগ্য রাখে, কিন্তু এটি প্রিফিক্স অনুবাদ, কোনো জাদু স্তর নয়: /64 সীমানা মিলতে হবে, চেকসাম সমন্বয় করতে হয়, আর আক্ষরিক ঠিকানা এমবেড করা অ্যাপ্লিকেশন তবুও ভাঙে। প্রোভাইডারের ঠিকানা শুরু থেকে শেষ পর্যন্ত রাখলে, লিজের আচরণ ও পরিবর্তনের পদ্ধতি অ্যাড্রেস প্ল্যানে লিখে রাখুন।

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

সম্পর্কিত নিবন্ধ