দুটি সাইটের মধ্যে বিদ্যমান VPN দিয়ে IPv6 রাউটিং

শুধু IPv4 থাকা WANও ভেতরের IPv6 বহন করতে পারে। সিলেক্টর, কার্নেল রুট, ফরওয়ার্ডিং এবং উত্তর চুপচাপ ফেলে দেওয়া ফেরত প্রিফিক্স অনুসরণ করুন।

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

দুটি হেডার, দুটি ঠিকানা পরিবার

IPsec টানেল মোডে ভেতরের IPv6 প্যাকেটটি ESP হেডারের পেছনের পেলোড হয়ে যায়। সেই ESP প্যাকেট বহনকারী বাইরের হেডার IPv4 বা IPv6 হতে পারে এবং local_addrs ও remote_addrs অনুসরণ করে। WireGuard একই কাজ করে কম আড়ম্বরে: ভেতরের প্যাকেটটি সঙ্গীর প্রান্তের দিকে যাওয়া UDP ডেটাগ্রামের পেলোড। দুটিই ভেতরের হেডার অক্ষত রাখে, তাই দূরের পক্ষ ডিক্যাপসুলেশনের পরে সেটি রাউট করতে পারে।

সাইটগুলোর মধ্যের পথ শুধু UDP 4500 দেখে যখন IPsec NAT ট্রাভার্সাল ব্যবহার করে, বা ডিফল্ট WireGuard শ্রোতার জন্য UDP 51820। পথের যেকোনো রাউটার শুধু IPv4 হতে পারে এবং IPv6 ট্রাফিক তবুও পার হয়, কারণ এটি সেই পথে কখনো IPv6 প্যাকেট হিসেবে দেখা যায় না। এটি পরিষ্কার প্রথম বিভাজন দেয়: tcpdump -ni eth0 udp port 51820 এনক্রিপ্টেড পথ দেখায়, tcpdump -ni wg0 ip6 ভেতরের ট্রাফিক দেখায়। বাইরের ক্যাপচার ব্যস্ত আর ভেতরের শান্ত হলে বোঝায় কার্নেল IPv6 টানেলে ঢোকাচ্ছে না; এটি রাউটিং বা নীতি, লিঙ্কের অবস্থা নয়।

গেটওয়ে ফরওয়ার্ড করার সময় ভেতরের Hop Limit-ও কমায়, তাই প্রান্তগুলো IPv6 পথে রাউটার হিসেবে গণ্য হয়। বাইরের হপ সংখ্যা ও ভেতরের Hop Limit আলাদাভাবে চলে, এবং দূরের গেটওয়েতে মরা প্যাকেট ফরওয়ার্ডিংয়ে মরেছে, এনক্রিপশনে নয়।

সিলেক্টর ও AllowedIPs অনুমতি তালিকা

IKEv2 আলোচনা করে child SA কোন ভেতরের প্রিফিক্স বহন করতে পারে। strongSwan 5.9 ও পরবর্তীতে সেগুলো swanctl.conf-এ লেখা দেখতে এমন:

children {
  net6 {
    local_ts  = 2001:db8:aa::/48
    remote_ts = 2001:db8:bb::/48
    mode = tunnel
    esp_proposals = aes256gcm16-prfsha384-ecp384
    start_action = trap
  }
}

যদি local_ts ও remote_ts বাদ দেন, strongSwan সেগুলো নিজের নির্বাচিত ইন্টারফেসের সাবনেট থেকে বের করে। দ্বৈত স্ট্যাক হোস্টে ওই শর্টকাট প্রায়ই শুধু IPv4 জোড়া দেয়: SA উঠে যায় এবং IPv6 ESP কোডে পৌঁছানোর আগেই প্রত্যাখ্যাত হয়। দুটি প্রিফিক্সই লিখলে SA সেগুলো বহনে সক্ষম হয়, এবং start_action = trap প্রথম মিলে যাওয়া প্যাকেটে এটি তোলে।

WireGuard-এর একটি তালিকা দুটি কাজ করে। সঙ্গী ব্লকে AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 পাঠানোর সময় বসানো রুট এবং গ্রহণের সময় প্রয়োগ করা ফিল্টার দুটোই: যে ডিক্রিপ্টেড প্যাকেটের ভেতরের উৎস ওই সঙ্গীর তালিকার বাইরে পড়ে সেটি চুপচাপ ফেলে দেওয়া হয়। wg-quick প্রতিটি এন্ট্রির জন্য রুট যোগ করে, তাই নিচের সঙ্গী ব্লকের আলাদা ip -6 route কমান্ড দরকার নেই।

[Interface]
Address = 2001:db8:aa:ff::1/64, fd00:aa:ff::1/64
ListenPort = 51820

[Peer]
PublicKey = <site-b-public-key>
Endpoint = 203.0.113.20:51820
AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48

দুটি তালিকাই আয়নার মতো হতে হবে: সাইট B সাইট A-এর প্রিফিক্সকে দূরের সিলেক্টর মেনে গ্রহণ করে এবং সেটি ফিরিয়ে রাউট করে, আর টানেল তখনই কাজ করে যখন দুই দিক একমত হয়। অসমমিত তালিকা সেই উপসর্গ দেয় যা সবচেয়ে বেশি সময় নেয় — সুস্থ হ্যান্ডশেক, এক পাশে চলা কাউন্টার, এবং A থেকে B-তে সফল ping যখন B থেকে কিছুই A-তে পৌঁছায় না।

ফরওয়ার্ডিং, রুট ও ফেরত প্রিফিক্স

Linux আপনার কথা না বললে IPv6 ফরওয়ার্ড করে না, এবং সেটিং ইন্টারফেসের বদলে namespace অনুযায়ী:

sysctl -w net.ipv6.conf.all.forwarding=1
ip -6 route add 2001:db8:bb::/48 dev wg0
ip -6 route get 2001:db8:bb::10 from 2001:db8:aa::10

দ্বিতীয় লাইনটি সেই যেটি রুট-ভিত্তিক নকশায় মানুষ ভুলে যায়। নীতি-ভিত্তিক IPsec প্রিফিক্সের সাথে মেলে এমন XFRM নীতি বসায়, কিন্তু vti6 বা WireGuard থাকা রুট-ভিত্তিক সেটআপের সেই ডিভাইসের দিকে নির্দেশ করা সত্যিকারের IPv6 রুট দরকার। sysctl-টি /etc/sysctl.d/-এর নিচে টেকসই রাখুন; নইলে পুনরায় বুট ফরওয়ার্ডিং চুপচাপ বন্ধ করে দেয়।

ফরওয়ার্ডিংয়ের একটি পার্শ্বপ্রতিক্রিয়া আছে যা জানা দরকার: কার্নেল তখন রাউটার ঘোষণা উপেক্ষা করে যদি না net.ipv6.conf.<wan>.accept_ra 2 হয়, তাই যে গেটওয়ের WAN ঠিকানা SLAAC-এ আসে সে ফরওয়ার্ডিং চালু করার মুহূর্তেই নিজের ডিফল্ট রুট হারাতে পারে। একই ফাইলে সেই ইন্টারফেসে accept_ra = 2 সেট করুন এবং রুট টিকে থাকে। সাইট B-এর কোরকেও টানেল গেটওয়ে থেকে 2001:db8:aa::/48 শিখতে হবে, স্থির রুট বা টানেলের ওপর রাউটিং প্রোটোকল দিয়ে, নইলে উত্তর B-এর নিজের নেটওয়ার্কেই মরে যায়।

চার ধাপের পরীক্ষা যা ভাঙনের জায়গা চিহ্নিত করে

এই ক্রমে কাজ করুন এবং প্রথম ব্যর্থ ধাপে থামুন, কারণ প্রতিটি পরের ধাপ আগেরগুলোর ওপর নির্ভর করে।

  1. সিলেক্টর: swanctl --list-sas child SA-তে IPv6 প্রিফিক্সের জোড়া দেখানো উচিত, বা wg show wg0 allowed-ips দূরের প্রিফিক্স সঙ্গে নতুন latest-handshakes।
  2. কার্নেল রুট: ip -6 route get 2001:db8:bb::10 টানেল ডিভাইস দিয়ে উত্তর দিতে হবে, WAN ইন্টারফেস দিয়ে নয়।
  3. ভেতরের ক্যাপচার: tcpdump -ni wg0 ip6 আসল LAN হোস্টের মধ্যে ping করার সময়। যে প্যাকেট বেরোয় কিন্তু একটিও ফেরে না সেগুলো B-এর রুট বা ফায়ারওয়ালের দিকে ইঙ্গিত করে; একেবারে প্যাকেট না থাকলে ধাপ 1 বা 2-এর দিকে ফিরিয়ে নেয়।
  4. গন্তব্য: B হোস্টে ss -6 -ltn নিশ্চিত করে সেবাটি IPv6-এ শুনছে, এবং স্থানীয় ফায়ারওয়াল কাউন্টার দেখায় প্যাকেট গৃহীত হয়েছে না ফেলা হয়েছে।

MTU একই ধাপে পড়ে। IPv6 রাউটার বিভাজন করে না, তাই অতি বড় প্যাকেট ফেলে দেওয়া হয় এবং Packet Too Big প্রেরকের কাছে ফেরে। যদি হ্যান্ডশেক ও ছোট ping কাজ করে কিন্তু ফাইল স্থানান্তর আটকে যায়, পেলোড কমান যতক্ষণ না সেটি পার হয়: ping -6 -s 1400 -c 3 2001:db8:bb::10। WireGuard ইন্টারফেসের ডিফল্ট MTU 1420 বাইট এবং IPv4-এর ওপর IPsec আরও বেশি কাটে, তাই ভেতরের MTU সেট করা ICMPv6 ফেলে দেওয়া ফায়ারওয়ালের মধ্য দিয়ে পথের MTU খোঁজার আশার চেয়ে ভালো।

ফায়ারওয়ালের সমস্যার মতো দেখানো ব্যর্থতার ধরন

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

দ্বিতীয়টি ICMPv6 ফিল্টারিং। Neighbor Discovery ও Packet Too Big সাধারণ পরিচালনার অংশ, রোগনির্ণয়ের নয়, এবং যে নীতি সব ICMPv6 ফেলে দেয় সেটি এমন টানেল বানায় যা সংযুক্ত হয়, প্রমাণিত হয় এবং তারপর ছোট প্যাকেটের চেয়ে বড় যেকোনো কিছুতে আটকে যায়। যে ধরনগুলোর ওপর পথ নির্ভর করে সেগুলো অনুমতি দিন এবং কাউন্টার চালু রাখুন যাতে ফেলা দৃশ্যমান হয়।

তৃতীয়টি সেই প্রিফিক্স যা টানেলে যোগ হয় কিন্তু যে সাইটের মালিকানা সেটির ঠিকানা পরিকল্পনায় কখনো যোগ হয় না, তাই কোনো রাউটার এটি ঘোষণা করে না এবং কোনো হোস্ট এটি থেকে উত্তর দিতে পারে না। একটি প্রিফিক্স ও একটি হোস্ট জোড়া দিয়ে শুরু করুন, দুই দিক চার ধাপে প্রমাণ করুন, তারপর বাকিটা যোগ করুন; নষ্ট প্রিফিক্স পুনর্নকশার বদলে কনফিগারেশনে এক লাইন থাকে। খোলা রাখার যোগ্য একমাত্র সরকারি রেফারেন্স RFC 8200 , যা টানেলের বহন করা হেডার সংজ্ঞায়িত করে।

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