দুই সাইটের WireGuard হাবের জন্য IPv6 পরিকল্পনা: প্রিফিক্স, পিয়ার, রুট
দুটি LAN-এর জন্য একটি ব্যক্তিগত IPv6 হাব নিয়ে কাজ করুন: একটি প্রিফিক্স বেছে নিন, টানেল ঠিকানা সংরক্ষণ করুন, তারপর AllowedIPs-কে বলে দিন কোন পিয়ার কোন সাবনেটের মালিক।
দুটি LAN, একটি WireGuard হাব এবং একটি IPv6 ঠিকানা পরিকল্পনা যা তিনটি আলাদা প্রশ্নের উত্তর দিতে হবে: কোন প্রিফিক্স, কোন ঠিকানা প্রতিটি রাউটারের, এবং কোন পিয়ার কোন সাবনেটের মালিক। এর একটি ভুল হলে এমন একটি টানেল তৈরি হয় যা হ্যান্ডশেক করে কিন্তু কিছুই রুট করে না। নিচের পরিকল্পনাটি সেই ক্রমে একটি ব্যক্তিগত দুই-সাইট ডিজাইন ধরে এগোয়। এটি ইচ্ছাকৃতভাবে IPv6 ইন্টারনেট অ্যাক্সেস দেয় না।
প্রিফিক্সটি কীসের জন্য তা ঠিক করুন
সাইটগুলির মধ্যে ব্যক্তিগত সংযোগই যখন লক্ষ্য, তখন fd00::/8 থেকে একটি ইউনিক-লোকাল প্রিফিক্স স্বাভাবিক পছন্দ। প্রতিটি অবস্থানে কোন ISP পরিষেবা দেয় তা নির্বিশেষে এটি স্থিতিশীল থাকে এবং বৈশ্বিক রাউটিং টেবিলে ঘোষণা করা হয় না, তাই আপনার অভ্যন্তরীণ নম্বরায়ন ইন্টারনেটে ফাঁস হতে পারে না।
একই বৈশিষ্ট্যই সীমাবদ্ধতা। একটি ULA কোনো পাবলিক ফেরত পথ দেয় না, কারণ কোনো আপস্ট্রিম জানে না এটিকে আপনার গেটওয়েতে রুট করতে হবে। যদি প্রয়োজনীয়তার মধ্যে IPv6 ইন্টারনেট ইগ্রেস থাকে, আপনার দরকার এমন একটি প্রদানকারীর কাছ থেকে বরাদ্দ যা এটি আপনার কাছে রুট করে, এবং এটি নিজস্ব প্রিফিক্স আকারসহ একটি পৃথক ডিজাইন সিদ্ধান্ত।
প্রতিটি স্থাপনার /48 দরকার বলে ধরে নেবেন না। RFC 6177 একক বাধ্যতামূলক এন্ড-সাইট আকার থেকে সরে এসেছে, এবং সঠিক আকার নির্ভর করে আপনি কতগুলি নেটওয়ার্ক পরিচালনা করবেন তার উপর। অন্য কোনো সংস্থাও ব্যবহার করতে পারে এমন প্রিফিক্স উদ্ভাবনের বদলে RFC 4193 পদ্ধতিতে ULA তৈরি করুন। কোনো ডিভাইস কনফিগার করার আগেই ফলাফলটি ঠিকানা পরিকল্পনায় লিখুন, কারণ যে প্রিফিক্স কেউ নথিভুক্ত করেনি, সেটি এমন প্রিফিক্স যা কেউ পুনরায় ব্যবহার করবে।
প্রিফিক্সকে ভূমিকায় ভাগ করুন
নিচের উদাহরণটি fd7c:2e91:4a00::/48 ব্যবহার করে, এবং টেবিলটি সাইট অনুসারে নয়, প্রতিটি ব্লক কোথায় লেখা হয় তার ভিত্তিতে সাজানো। মানগুলিকে নমুনা হিসেবে ধরুন এবং কিছু স্থাপন করার আগে নিজেরটি তৈরি করুন।
| Where it is written | What appears there | Block used | What it establishes |
|---|---|---|---|
| Hub wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::1/128 | The hub's own tunnel identity |
| Hub wg0.conf, Site A peer | Two ranges in one AllowedIPs line | ::2/128 and :10::/64 | That A owns its tunnel address and its LAN |
| Hub wg0.conf, Site B peer | Two ranges in one AllowedIPs line | ::3/128 and :20::/64 | That B owns its tunnel address and its LAN |
| Site A wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::2/128 | A's identity as the hub sees it |
| Site B wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::3/128 | B's identity as the hub sees it |
LAN ব্লকগুলি /64 কারণ সাধারণ SLAAC একটি 64-বিট ইন্টারফেস আইডেন্টিফায়ার প্রত্যাশা করে। একটি LAN-কে ছোট ব্লকে ভাগ করলে বেশিরভাগ হোস্টে সেই ধারণা ভেঙে যায়, এবং ব্যক্তিগত পরিকল্পনায় ঠিকানা সাশ্রয়ের জন্য পরিচালন ব্যয়টি মূল্যবান নয়। উভয় LAN ব্লকই /48-এর মাঝখান থেকে আসে, ফলে নিম্ন পরিসর পরবর্তী সাইটগুলির জন্য মুক্ত থাকে।
টানেল ঠিকানাগুলি একটি প্রশাসনিক বালতি, অন-লিঙ্ক নেটওয়ার্ক নয়। প্রতিটি ইন্টারফেস এটি থেকে একটি করে /128 পায়, তাই কোনো হোস্ট টানেলে ভাগ করা সাবনেট ধরে নেয় না এবং যেখানে প্রয়োজন নেই সেখানে প্রতিবেশী আবিষ্কার চলে না। ভূমিকাগুলি আলাদা রাখুন এবং সংস্থার ঠিকানা পরিকল্পনায় লিখে রাখুন যাতে পরবর্তী সাইট কোনো ব্লক পুনরায় ব্যবহার না করে।
প্রতিটি রাউটারকে একটি টানেল ঠিকানা দিন
প্রতিটি রাউটারে একটি /128 বরাদ্দ করুন এবং কাজ করা হাবের বিদ্যমান কী ও এন্ডপয়েন্ট রাখুন। নিচের তিনটি মান কেবল হোস্ট অংশে আলাদা।
Hub: Address = fd7c:2e91:4a00:ff00::1/128
Site A: Address = fd7c:2e91:4a00:ff00::2/128
Site B: Address = fd7c:2e91:4a00:ff00::3/128এই /128 সেই ইন্টারফেসে বরাদ্দ করা একক ঠিকানা বোঝায়। পিয়ার কতগুলি গন্তব্য রুট করতে পারে সে সম্পর্কে এটি কিছু বলে না, কারণ সংযোগযোগ্যতা ইন্টারফেস প্রিফিক্সে নয়, AllowedIPs-এ প্রকাশ করা হয়।
প্রতিটি সাইট রাউটারেরও তার LAN ব্লকে একটি ঠিকানা দরকার এবং তা বিতরণের একটি উপায়, সাধারণত SLAAC-এর জন্য রাউটার বিজ্ঞাপন। WireGuard আপনার হয়ে সেই বিজ্ঞাপন পাঠায় না এবং দুটি LAN সেতু করে না। সাইট রাউটার উভয় দিকেই একটি রাউটার।
সাবনেট মালিকানা AllowedIPs-এ রাখুন
সাইট A-এর জন্য হাবের পিয়ার এন্ট্রি A-এর টানেল ঠিকানা ও A-এর LAN-এর মালিক, এবং সেই জোড়াই সম্পূর্ণ মালিকানা বিবৃতি। ওই পিয়ার অংশে আর কিছুই সাইটটির বর্ণনা দিতে হবে না।
AllowedIPs = fd7c:2e91:4a00:ff00::2/128, fd7c:2e91:4a00:10::/64সাইট B-এর পিয়ার এন্ট্রি মিলে যাওয়া জোড়টির মালিক, এবং এখানে প্রতিসাম্য সংক্ষিপ্ততার চেয়ে বেশি গুরুত্বপূর্ণ। দুটি লাইন একসাথে পড়ুন এবং মালিকানার বিভাজন এক নজরে দৃশ্যমান হয়।
AllowedIPs = fd7c:2e91:4a00:ff00::3/128, fd7c:2e91:4a00:20::/64এগুলি দুটি পৃথক পিয়ার অংশ, একটি পিয়ারের জন্য প্রতিযোগিতা করা দুটি তালিকা নয়। WireGuard AllowedIPs উভয় দিকে ব্যবহার করে: এটি বহির্গামী গন্তব্যের জন্য পিয়ার বেছে নেয়, এবং যে প্যাকেটের উৎস সেই পিয়ারকে বরাদ্দ পরিসরের সাথে মেলে না যা এটি ডিক্রিপ্ট করেছে, তা প্রত্যাখ্যান করে। পুরো /48 দুটি পিয়ারকে দিলে সেই দ্বিতীয় যাচাই বন্ধ হয়ে যায় এবং কোন সাইট কোন ব্লকের মালিক তা অস্পষ্ট হয়। এই পার্থক্যই ভুল উৎস ঠিকানাকে নীরবে গ্রহণ না করে দৃশ্যমান করে।
প্রতিটি সাইটের কেবল তার হাব পিয়ারের মাধ্যমে পৌঁছানো যায় এমন গন্তব্যগুলিই দরকার: সাইট A হাবের ঠিকানা, সাইট B-এর টানেল ঠিকানা ও B-এর LAN তালিকাভুক্ত করে, আর সাইট B সেই বিপরীত সেটটি তালিকাভুক্ত করে। তালিকাগুলি ইচ্ছাকৃতভাবে অপ্রতিসম, কারণ প্রতিটি রাউটার টপোলজির ভিন্ন দিক দেখে। দুটিই ঠিকানা পরিকল্পনা থেকে লিখুন, অন্য সাইটের কনফিগারেশন থেকে নয়, কারণ এভাবেই পুরনো পরিসর পুনঃনম্বরায়ন টিকে যায়।
wg-quick-এর সঙ্গে এই পরিসরগুলি রুটও তৈরি করে। systemd-networkd বা ম্যানুয়াল সেটআপে সমতুল্য রুট নিজে যোগ করুন; নইলে টানেল এমন প্যাকেট বহন করে যা কার্নেল কখনো তার ভিতরে পাঠায় না।
ফরওয়ার্ডিং সম্পূর্ণ করুন এবং উভয় দিক পরীক্ষা করুন
হাবে এবং উভয় সাইট রাউটারে IPv6 ফরওয়ার্ডিং সক্রিয় করুন, এবং ফরওয়ার্ড নীতিতে প্রয়োজনীয় আন্তঃসাইট পরিষেবাগুলি অনুমোদন করুন। ICMPv6 Packet Too Big বার্তাগুলি ব্যবহারযোগ্য রাখুন, কারণ সেগুলি ফেলে দিলে পাথ MTU আবিষ্কার ভেঙে যায় এবং অ্যাপ্লিকেশন ত্রুটির মতো দেখায় এমন বড়-স্থানান্তর স্থবিরতা তৈরি হয়। ফায়ারওয়াল অনুমতি ছাড়া ফরওয়ার্ড করা হাব রাউটিং ও টানেলের মাঝখানে প্যাকেটটি ফেলে দেয়। এই ব্যর্থতার ধরনটি জানা দরকার, কারণ টানেল সক্রিয় থাকে এবং কেবল কিছু ফ্লো মারা যায়।
sysctl net.ipv6.conf.all.forwarding
ip -6 route
ping -6 -c 3 fd7c:2e91:4a00:20::1সাইট A-এর একটি হোস্ট থেকে সাইট B-এর একটি হোস্টে এবং তারপর বিপরীত দিকে পরীক্ষা করুন। হাবের টানেল ঠিকানায় ping কেবল প্রথম হপ পরীক্ষা করে এবং LAN রুট ভুল থাকলেও সফল হবে। হোস্ট-থেকে-হোস্ট ফ্লোই পরিকল্পনাটি প্রমাণ করে।
বাইরের WireGuard সংযোগ IPv4-এর উপর চলতে পারে যখন ভেতরের ট্রাফিক IPv6, এবং এই স্বাধীনতা মাইগ্রেশনের সময় কাজে লাগে। পরে বৈশ্বিক IPv6 ইগ্রেস যোগ করলে প্রদানকারীর বরাদ্দ, উৎস ঠিকানা নির্বাচন এবং ফেরত রাউটিং নতুন ডিজাইন ধাপ হিসেবে পুনর্বিবেচনা করুন; উপরের ব্যক্তিগত পরিকল্পনা সাইট-থেকে-সাইট ট্রাফিকের জন্য বৈধ থাকে।