WireGuard cryptokey routing কীভাবে কাজ করে?

WireGuard যেভাবে কাজ করে, এক কথায়

WireGuard প্রতিটি প্যাকেটকে একটি public key-এর সাথে যুক্ত করে কাজ করে। এই পদ্ধতির একটি নাম আছে, cryptokey routing, এবং এটিই এর সম্পূর্ণ ডিজাইন: কোনো peer-এর পাশে থাকা AllowedIPs লাইনটি আপনার মেশিন থেকে বেরিয়ে যাওয়া প্যাকেটের জন্য রাউটিং টেবিল এবং সেই peer থেকে আসা প্যাকেটের জন্য অ্যাক্সেস কন্ট্রোল লিস্ট হিসেবে কাজ করে। একটি সেটিং, দুটি কাজ। AllowedIPs-কে এই দৃষ্টিভঙ্গি থেকে দেখুন, তাহলেই প্রতিটি WireGuard কনফিগারেশন ফাইল সহজবোধ্য হয়ে উঠবে।

এখানে IP address-ভিত্তিক কোনো সেশন টেবিল বা ইউজার ডেটাবেস নেই। একজন peer মানে হলো একটি public key এবং সেই key-টি যে ঠিকানাগুলো ব্যবহার করতে পারবে তার একটি সেট। নেটওয়ার্কের পরিবর্তন সত্ত্বেও এই বাইন্ডিং ঠিক রাখার জন্যই হ্যান্ডশেক এবং টাইমারগুলো কাজ করে। আপনি যদি তত্ত্বের আগে একটি কার্যকর টানেল তৈরি করতে চান, তবে আপনার নিজস্ব VPS-এ একটি self-hosted WireGuard VPN তৈরি করুন, তারপর কোনো কনফিগারেশন লাইন বুঝতে সমস্যা হলে এখানে ফিরে আসুন।

AllowedIPs একটি রাউটিং টেবিল এবং অ্যাক্সেস লিস্ট

প্রথমে আউটবাউন্ড বা বহির্গামী ট্র্যাফিকের বিষয়টি দেখা যাক। আপনার কার্নেল সাধারণ রাউটিং টেবিলের মাধ্যমে একটি প্যাকেটকে wg0 ডিভাইসের দিকে পাঠায়। এরপর WireGuard সেই প্যাকেটের গন্তব্য (destination) ঠিকানাকে প্রতিটি পিয়ারের (peer) জন্য নির্ধারিত AllowedIPs টেবিলের সাথে মিলিয়ে দেখে, যেখানে দীর্ঘতম প্রিফিক্স (longest prefix) অগ্রাধিকার পায়। যদি কোনো পিয়ারের সাথে মিল পাওয়া যায়, তবে সেই পিয়ারের পাবলিক কি (public key) ব্যবহার করে সেশন কি (session key) এবং UDP এন্ডপয়েন্ট নির্ধারণ করা হয়। প্যাকেটটি সেই পিয়ারের জন্য এনক্রিপ্ট করা হয় এবং সেখানে পাঠানো হয়।

যদি কোনো পিয়ারের AllowedIPs গন্তব্য ঠিকানাকে কভার না করে, তবে প্যাকেটটি পাঠানো হয় না, কারণ এটি এনক্রিপ্ট করার জন্য কোনো কি (key) পাওয়া যায় না।

ping: sendmsg: Required key not available

এই ত্রুটির অর্থ হলো: আপনি যে ঠিকানায় পৌঁছানোর চেষ্টা করছেন তা কোনো পিয়ারের তালিকায় নেই। অন্য একটি ত্রুটি, ping: sendmsg: Destination address required, এর অর্থ হলো একটি পিয়ারের সাথে মিল পাওয়া গেছে কিন্তু WireGuard-এর কাছে তার কোনো এন্ডপয়েন্ট নেই, কারণ সেটি কনফিগার করা হয়নি অথবা এখনো জানা সম্ভব হয়নি।

এখন ইনবাউন্ড বা আগত ট্র্যাফিকের বিষয়টি দেখা যাক। একটি UDP প্যাকেট লিসেন পোর্টে পৌঁছায়। WireGuard হেডারে থাকা রিসিভার ইনডেক্স থেকে সেশনটি খুঁজে বের করে, স্লাইডিং রিপ্লে উইন্ডোর বিপরীতে কাউন্টার চেক করে, এবং তারপর পেলোডটি ডিক্রিপ্ট ও অথেন্টিকেট করে। এর পরেই এটি ভেতরের প্যাকেটটি পড়তে পারে এবং সেই প্যাকেটের উৎস (source) ঠিকানাকে অবশ্যই প্রেরক পিয়ারের AllowedIPs-এর ভেতরে থাকতে হবে। যদি তা না হয়, তবে প্যাকেটটি ড্রপ করা হয়। ডাইনামিক ডিবাগ চালু থাকলে, কার্নেল নিচের মতো একটি লাইনে এর কারণ প্রিন্ট করে:

wg0: Packet has unallowed src IP (10.8.0.9) from peer 2 (203.0.113.10:51820)

এ কারণেই সার্ভার সাইডের একটি পিয়ার /32 পায়। AllowedIPs = 10.8.0.2/32 দিয়ে কনফিগার করা একটি পিয়ার শুধুমাত্র 10.8.0.2 থেকে প্যাকেট পাঠাতে পারে, অন্য কোনো ঠিকানা থেকে নয়। সেখানে 0.0.0.0/0 লিখলে সেই ক্লায়েন্ট আপনার টানেলের ভেতরের যেকোনো সোর্স অ্যাড্রেস ব্যবহার করে প্যাকেট পাঠাতে পারবে, এমনকি অন্য কোনো ক্লায়েন্টের ঠিকানাও।

ওভারল্যাপিং প্রিফিক্সগুলো নির্দিষ্টতার ভিত্তিতে সমাধান করা হয়, কারণ লুকআপটি দীর্ঘতম প্রিফিক্স ম্যাচ অনুসরণ করে। দুটি পিয়ারে অভিন্ন প্রিফিক্স থাকলে ফলাফল ভিন্ন হয়: এন্ট্রিটি সর্বশেষ কনফিগার করা পিয়ারে চলে যায় এবং প্রথম পিয়ার সেই ট্র্যাফিক পাওয়া বন্ধ করে দেয়, তবে কোথাও কোনো ত্রুটি প্রদর্শিত হয় না। wg show wg0 allowed-ips কমান্ডটি কার্নেলে বর্তমানে কার্যকর টেবিলটি প্রিন্ট করে, যা ডিস্কের ফাইল এবং চলমান অবস্থার মধ্যে অমিল থাকলে প্রকৃত অবস্থা জানার জন্য গুরুত্বপূর্ণ।

Cryptokey routing বিবেচনায় রেখে কনফিগারেশন ফাইল পড়া

সার্ভার সাইড:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <server private key>

[Peer]
PublicKey = <laptop public key>
AllowedIPs = 10.8.0.2/32

ক্লায়েন্ট সাইড:

[Interface]
Address = 10.8.0.2/32
PrivateKey = <laptop private key>

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

একই কিওয়ার্ড দুই পাশে বিপরীত ভূমিকা পালন করে। ক্লায়েন্টের ক্ষেত্রে এটি নির্দেশ করে "সব গন্তব্যের ট্রাফিক এই পিয়ারের কাছে পাঠাও"। সার্ভারের ক্ষেত্রে এটি নির্দেশ করে "এই পিয়ারের কাছ থেকে শুধুমাত্র এই নির্দিষ্ট ঠিকানাটি গ্রহণ করো"। এই অসামঞ্জস্যতা মানগুলোর মধ্যে বিদ্যমান, কোনো নির্দিষ্ট রোলের মধ্যে নয়।

এই কিগুলোর অর্ধেক আসলে প্রোটোকলের অংশ নয়। Address, DNS, MTU, PostUp এবং SaveConfig হলো wg-quick-এর অংশ, যা একটি শেল স্ক্রিপ্ট এবং এটি ইন্টারফেস চালু করার কাজ করে। কার্নেল এগুলো কখনোই দেখতে পায় না। wg-quick strip wg0 সেই সংক্ষিপ্ত কনফিগারেশনটি প্রিন্ট করে যা wg টুলটি মূলত লোড করে, এবং এই বিভাজনটি দেখার সবচেয়ে দ্রুত উপায় হলো এটি।

হ্যান্ডশেক আসলে যা করে

WireGuard-এর হ্যান্ডশেক হলো Noise Protocol Framework থেকে নেওয়া Noise_IKpsk2। IK অংশটি একজন সিস্টেম অ্যাডমিনিস্ট্রেটরের জন্য সবচেয়ে গুরুত্বপূর্ণ: ইনিশিয়েটরের কাছে রেসপন্ডারের স্ট্যাটিক পাবলিক কি আগে থেকেই জানা থাকে, কারণ এটি আপনার [Peer] ব্লকের PublicKey। এছাড়া ইনিশিয়েটর তার নিজের স্ট্যাটিক পাবলিক কি প্রথম মেসেজের ভেতরে এনক্রিপ্ট করে পাঠায়। তাই এখানে কোনো সার্টিফিকেট বিনিময় বা আইডেন্টিটি রাউন্ড ট্রিপের প্রয়োজন হয় না। কোনো প্যাসিভ পর্যবেক্ষক বুঝতে পারে না কোন কি কল করছে, যদি না তার কাছে রেসপন্ডারের প্রাইভেট কি থাকে।

এর জন্য একটি রাউন্ড ট্রিপ খরচ হয়। ইনিশিয়েশন মেসেজটি 148 বাইটের, রেসপন্সটি 92 বাইটের এবং এরপরই ডেটা আদান-প্রদান শুরু হয়। প্রতিটি পক্ষ প্রতি হ্যান্ডশেকের জন্য একটি নতুন ephemeral Curve25519 কি-পেয়ার তৈরি করে এবং সেশন কিগুলো Diffie-Hellman ফলাফলের একটি চেইন থেকে আসে, যা স্ট্যাটিক এবং ephemeral কিগুলোকে মিশ্রিত করে। এরপর ephemeral প্রাইভেট কিগুলো মুছে ফেলা হয়, যা ফরওয়ার্ড সিক্রেসি নিশ্চিত করে: কেউ যদি আজ আপনার ট্রাফিক রেকর্ড করে এবং আগামী বছর সার্ভারের প্রাইভেট কি চুরিও করে, তবুও সে রেকর্ড করা ট্রাফিক পড়তে পারবে না।

একটি হ্যান্ডশেক ইনিশিয়েশনে একটি TAI64N টাইমস্ট্যাম্প থাকে এবং প্রতিটি পিয়ার অন্য পিয়ার থেকে পাওয়া সর্বোচ্চ টাইমস্ট্যাম্পটি মনে রাখে, তাই কোনো রিপ্লেড ইনিশিয়েশন প্রত্যাখ্যাত হয়। ডেটা প্যাকেটগুলো একটি 64-বিট কাউন্টার বহন করে যা ননস (nonce) হিসেবে কাজ করে এবং রিসিভার সম্প্রতি দেখা কাউন্টারগুলোর একটি স্লাইডিং উইন্ডো বজায় রাখে। ফলে TCP-এর মতো কোনো কানেকশন স্টেট ছাড়াই রিপ্লে এবং বড় ধরনের রিঅর্ডারিং সামলানো যায়।

সেশন কিগুলো বেশিক্ষণ স্থায়ী হয় না এবং টাইমারগুলো কনফিগারযোগ্য নয়, বরং কোডের ভেতরেই কম্পাইল করা থাকে।

[
  {
    "label": "REKEY_TIMEOUT",
    "seconds": 5,
    "notes": "resend a handshake initiation that got no answer"
  },
  {
    "label": "KEEPALIVE_TIMEOUT",
    "seconds": 10,
    "notes": "send a keepalive after receiving data and sending none back"
  },
  {
    "label": "REKEY_ATTEMPT_TIME",
    "seconds": 90,
    "notes": "give up on the handshake and report the peer as down"
  },
  {
    "label": "REKEY_AFTER_TIME",
    "seconds": 120,
    "notes": "sender begins a fresh handshake for a new session key"
  },
  {
    "label": "REJECT_AFTER_TIME",
    "seconds": 180,
    "notes": "the old session key is refused and traffic stops"
  }
]

এগুলো প্রোটোকল স্পেসিফিকেশনের ধ্রুবক, কোনো পরিমাপ নয়। এদের 5 টি পুরো সেশনের জীবনচক্র নিয়ন্ত্রণ করে। 120 সেকেন্ড ব্যবহারের পর প্রেরক একটি নতুন হ্যান্ডশেক শুরু করে এবং 180 সেকেন্ড পর পুরনো কি সরাসরি প্রত্যাখ্যান করা হয়, তাই নতুন হ্যান্ডশেক সম্পন্ন না হওয়া পর্যন্ত ট্রাফিক বন্ধ থাকে। যে ইনিশিয়েশনের কোনো উত্তর পাওয়া যায় না, তা প্রতি 5 সেকেন্ড পরপর পুনরায় পাঠানো হয় এবং 90 সেকেন্ড পর তা বাতিল করা হয়। এই কারণেই wg show কমান্ডটি latest handshake কে আপেক্ষিক বয়স হিসেবে প্রদর্শন করে এবং একটি ব্যস্ত ও সুস্থ টানেলে এই বয়স কম থাকে। যদি ট্রাফিক পাঠানোর সময়ও এই বয়স বাড়তে থাকে, তবে বুঝতে হবে হ্যান্ডশেক ব্যর্থ হচ্ছে, টানেলটি অলস বসে নেই।

কেন একটি পিয়ারের কোনো ক্লায়েন্ট বা সার্ভার ভূমিকা থাকে না

উভয় প্রান্তেই একই কোড এবং একই কনফিগারেশন ফরম্যাট চলে। এখানে কোনো সার্ভার মোড নেই। আপনি যে অসামঞ্জস্যতা অনুভব করেন তা মূলত Endpoint থেকে আসে এবং Endpoint ঐচ্ছিক।

একটি কনফিগার করা এন্ডপয়েন্ট থাকা পিয়ার হ্যান্ডশেক শুরু করতে পারে। যার কোনো এন্ডপয়েন্ট নেই, সে অপেক্ষা করে এবং প্রথম সঠিকভাবে অথেন্টিকেট হওয়া প্যাকেট থেকে অপর প্রান্তের অ্যাড্রেস ও পোর্ট জেনে নেয়। এই লব্ধ এন্ডপয়েন্টটি সংরক্ষিত থাকে এবং নতুন কোনো অ্যাড্রেস থেকে বৈধ প্যাকেট আসলে তা আপডেট হয়। রোমিং এভাবেই কাজ করে: একটি ল্যাপটপ ওয়াইফাই থেকে মোবাইল নেটওয়ার্কে চলে গেলেও একই টানেল বজায় থাকে, কারণ সেশনটি আইপি অ্যাড্রেসের পরিবর্তে কি (key) এবং ইনডেক্স দ্বারা চিহ্নিত হয়। এখানে নতুন করে সংযোগ স্থাপনের প্রয়োজন হয় না, কারণ TCP-এর অর্থে এখানে কখনোই কোনো সংযোগ স্থায়ীভাবে থাকে না।

একই মেকানিজম একটি গুরুত্বপূর্ণ তথ্য তৈরি করে: পাবলিক অ্যাড্রেস থাকা পিয়ারটি সবসময় অপর প্রান্তের সর্বশেষ জানা পাবলিক আইপি সংরক্ষণ করে এবং wg show তা প্রদর্শন করে।

স্থির প্রিমিটিভ, আলোচনার কোনো সুযোগ নেই

WireGuard-এ কোনো ciphersuite তালিকা নেই। authenticated encryption-এর জন্য ChaCha20-Poly1305, key agreement-এর জন্য Curve25519, hashing-এর জন্য BLAKE2s এবং key derivation-এর জন্য HKDF ব্যবহৃত হয়। প্রতিটি ডেপ্লয়মেন্টে এগুলোই ব্যবহৃত হয়, তাই এখানে কোনো negotiation phase নেই যা বিশ্লেষণ করতে হবে এবং দুর্বল কোনো অপশনে নেমে যাওয়ার (downgrade) কোনো পথ নেই। এর বিনিময়টি স্পষ্ট: যদি এই প্রিমিটিভগুলোর কোনো একটি ভেঙে যায়, তবে সমাধান হলো পুরো প্রোটোকলের একটি নতুন ভার্সন এবং উভয় প্রান্তে আপডেট করা, কোনো কনফিগারেশন পরিবর্তন নয়। এই একটি সিদ্ধান্ত TLS-ভিত্তিক টানেলের অধিকাংশ কোড এবং ব্যর্থতার কারণ দূর করে, যা WireGuard against OpenVPN-এর তুলনার মূল বিষয়।

পোর্ট কেন স্ক্যানারের কোনো উত্তর দেয় না

প্রতিটি হ্যান্ডশেক মেসেজে mac1 নামে একটি ফিল্ড থাকে। এটি একটি MAC (message authentication code), যা রেসপন্ডারের স্ট্যাটিক পাবলিক কি (public key) থেকে প্রাপ্ত কি (key) ব্যবহার করে মেসেজের ওপর গণনা করা হয়। যে প্রেরক সেই পাবলিক কি জানে না, সে বৈধ mac1 তৈরি করতে পারে না। ফলে রিসিভার কোনো উত্তর না দিয়েই প্যাকেটটি ফেলে দেয়। কোনো এরর, রিসেট বা ICMP মেসেজ পাঠানো হয় না।

এর দৃশ্যমান ফলাফল হলো, একটি UDP স্ক্যান কোনো উত্তর পায় না।

sudo nmap -sU -p 51820 vpn.example.com

nmap open|filtered রিপোর্ট করে, যা এমন একটি পোর্টের জন্য একই উত্তর দেয় যেটিকে ফায়ারওয়াল নীরবে ড্রপ করে। আপনার পাবলিক কি যার কাছে নেই, তার জন্য WireGuard লিসেন করছে কি না তা নির্বিশেষে পোর্টটি একইভাবে আচরণ করে।

mac2 নামে একটি দ্বিতীয় ফিল্ড Denial of Service (DoS) চাপ সামলায়। রিসিভার যখন চাপের মুখে থাকে, তখন সে প্রেরকের সোর্স অ্যাড্রেসের সাথে যুক্ত একটি 64-বাইট কুকি রিপ্লাই পাঠায়। প্রেরক সেই কুকি ফেরত না পাঠানো পর্যন্ত রিসিভার কোনো ব্যয়বহুল পাবলিক কি সংক্রান্ত কাজ করে না। এটি নিশ্চিত করে যে সোর্স অ্যাড্রেসটি আসল, এবং শুধুমাত্র চাপের মুখেই এই প্রক্রিয়াটি সক্রিয় হয়।

কেন 0.0.0.0/0 একটি পিয়ারকে আপনার ডিফল্ট রাউট হিসেবে সেট করে

যেহেতু AllowedIPs হলো রাউটিং টেবিল, তাই AllowedIPs = 0.0.0.0/0, ::/0 সেই পিয়ারের জন্য প্রতিটি গন্তব্য দাবি করে। এটিই হলো সম্পূর্ণ ফুল টানেল সেটিংস।

যে রাউটিংয়ের মাধ্যমে এটি কাজ করে, তা লাইনটির চেয়েও বেশি কৌতূহলোদ্দীপক। wg0-এর মাধ্যমে একটি সাধারণ ডিফল্ট রাউট লুপ তৈরি করবে, কারণ আপনার ট্রাফিক বহনকারী এনক্রিপ্ট করা UDP প্যাকেটটিকেও মেশিন থেকে বের হতে হয় এবং সেটি তার নিজস্ব ডিফল্ট রাউটের সাথে মিলে যাবে। wg-quick পলিসি রাউটিংয়ের মাধ্যমে এটি এড়িয়ে চলে। এটি WireGuard-এর নিজস্ব আউটগোয়িং প্যাকেটগুলোকে একটি fwmark দিয়ে চিহ্নিত করে, টানেল ডিফল্ট রাউটটিকে একটি আলাদা রাউটিং টেবিলে রাখে এবং এমন নিয়ম যোগ করে যাতে শুধুমাত্র চিহ্নহীন ট্রাফিকই সেখানে পৌঁছাতে পারে। ip rule show কমান্ডটি চালান এবং আপনি ফলাফল দেখতে পাবেন:

32764:	from all lookup main suppress_prefixlength 0
32765:	not from all fwmark 0xca6c lookup 51820
32766:	from all lookup main

0xca6c হলো হেক্সাডেসিমেলে 51820 এবং 51820 হলো টেবিল নম্বর। suppress_prefixlength 0 নিয়মটি মেইন টেবিলকে তার নিজস্ব ডিফল্ট রাউট এড়িয়ে যেতে বাধ্য করে, ফলে আপনার লোকাল সাবনেটের মতো নির্দিষ্ট রাউটগুলো কার্যকর থাকে এবং বাকি সবকিছু টানেল টেবিলে চলে যায়। স্প্লিট টানেলের ক্ষেত্রে এর কোনোটিরই প্রয়োজন হয় না: AllowedIPs = 10.8.0.0/24, 10.20.0.0/16-এর মতো একটি সংকীর্ণ তালিকা মেইন টেবিলে সাধারণ রাউট হিসেবে গণ্য হয়।

ফুল টানেল নিজে থেকে নেম রেজোলিউশন ঠিক করতে পারে না, কারণ আপনার ক্লায়েন্ট লোকাল নেটওয়ার্ক থেকে যে রেজলভারটি শিখেছে তা সাধারণত অপরিবর্তিত থাকে এবং সেটির রাউট বেশি সুনির্দিষ্ট হয়। এটি একটি আলাদা কাজ, যা WireGuard টানেলের বাইরে DNS লিক হওয়া অংশে আলোচনা করা হয়েছে।

PersistentKeepalive আসলে কী কাজে লাগে

কোনো traffic না থাকলে WireGuard কিছুই পাঠায় না। কোনো heartbeat নেই, session refresh নেই, নেটওয়ার্কে কিছুই আদান-প্রদান হয় না। এই নীরবতা ব্যাটারির স্থায়িত্ব বাড়ায় এবং উপরের স্ক্যানার কেসটিতে সাহায্য করে, তবে এটি একটি নির্দিষ্ট সেটআপে সমস্যা তৈরি করে।

NAT (network address translation) বা stateful firewall-এর পেছনে থাকা কোনো peer-এর কাছে বাইরের দিক থেকে তখনই পৌঁছানো সম্ভব, যখন সেই ডিভাইসে একটি mapping বিদ্যমান থাকে এবং সেই mapping-টি কোনো outgoing packet-এর মাধ্যমে তৈরি হয়। সাধারণ UDP mapping-এর স্থায়িত্ব সাধারণত 30 সেকেন্ড থেকে শুরু হয়। একবার mapping-এর মেয়াদ শেষ হয়ে গেলে, public side থেকে আসা packet-গুলো middlebox দ্বারা বাতিল (drop) হয়ে যায় এবং NAT-এর পেছনে থাকা peer কিছু না পাঠানো পর্যন্ত tunnel-টিকে অকেজো মনে হয়। PersistentKeepalive = 25 প্রতি 25 সেকেন্ডে একটি empty authenticated packet পাঠায়, যা সবচেয়ে কম সাধারণ স্থায়িত্বের সময়ের নিচে থাকে, ফলে mapping-টি খোলা থাকে।

এটি NAT-এর পেছনে থাকা peer-এ সেট করুন। একটি public address এবং open UDP port থাকা সার্ভারে এটির প্রয়োজন নেই এবং সেখানে এটি সেট করলে শুধুমাত্র অপ্রয়োজনীয় traffic তৈরি হয়। এটিকে automatic keepalive-এর সাথে গুলিয়ে ফেলবেন না, যা কোনো peer ডেটা পাওয়ার পর এবং নিজের পাঠানোর মতো কিছু না থাকলে 10 সেকেন্ড পরে কার্যকর হয়। সেটি সবসময় চালু থাকে এবং তা কনফিগার করা যায় না।

LAN-কে টানেলের মধ্য দিয়ে রাউট করা WireGuard-এর কোনো ফিচার নয়

ধরা যাক, peer B একটি হোম নেটওয়ার্কে 192.168.50.0/24 আছে এবং peer A-কে সেখানে পৌঁছাতে হবে। দুটি আলাদা সিস্টেমকে এই বিষয়ে একমত হতে হবে, যার মধ্যে কেবল একটি হলো WireGuard।

WireGuard-এর অংশ: A-এর AllowedIPs-এ 192.168.50.0/24 যোগ করুন। এটি A-কে ওই প্রিফিক্সটি B-এর দিকে রাউট করতে বাধ্য করে এবং B থেকে আসা ওই সোর্স অ্যাড্রেসযুক্ত প্যাকেটগুলো গ্রহণ করতে দেয়। এটি ছাড়া, ক্রিপ্টোকি রাউটিংয়ের কাছে গন্তব্যের জন্য কোনো কি (key) থাকে না এবং সোর্সের জন্য কোনো অনুমতি থাকে না।

কার্নেলের অংশ: B-তে net.ipv4.ip_forward অবশ্যই 1 হতে হবে, অন্যথায় কার্নেল প্রতিটি ডিক্রিপ্ট করা প্যাকেট ফেলে দেবে যা সরাসরি B-এর উদ্দেশ্যে নয়। B-এর ফায়ারওয়ালের ফরওয়ার্ড চেইনকে এই ট্রাফিক অনুমতি দিতে হবে। LAN-এর হোস্টগুলোর 10.8.0.0/24-এর দিকে ফিরে যাওয়ার একটি রুট প্রয়োজন, অথবা B-কে সোর্স NAT প্রয়োগ করতে হবে যাতে রিপ্লাইগুলো B-এর মাধ্যমেই ফিরে আসে।

WireGuard-এর কাজ শেষ হয় decrypted packet kernel-এর কাছে হস্তান্তর করার পর। এর পরের সবকিছু সাধারণ Linux routing ও filtering-এর অংশ। তাই এই ব্যর্থতা nft list ruleset counter-এ বা ip -s link show wg0-এ দেখা যায়, wg show-এ নয়। আপনি যদি web interface-এর মাধ্যমে peer পরিচালনা করতে চান, তাহলে Docker-এ wg-easy চালিয়ে peer entry তৈরি করা আপনার হয়ে peer entry তৈরি করবে। তবে forwarding rule এখনও host-কেই পরিচালনা করতে হবে। একটি coordination layer আপনার হয়ে prefix বিতরণ করলেও এই বিভাজন একই থাকে: Tailscale subnet router দিয়ে VPS থেকে private network advertise করা প্রতিটি peer-এ manual AllowedIPs edit করার প্রয়োজন দূর করে। তবে router নিজে forwarding sysctl এবং firewall rule সেট করার দায়িত্ব আপনার।

কেন WireGuard কার্নেলের ভেতরে থাকে

wg0 একটি নেটওয়ার্ক ডিভাইস ড্রাইভার। প্যাকেটগুলো সাধারণ রাউটিং স্ট্যাকের মাধ্যমে এতে পৌঁছায়, softirq কনটেক্সটে এনক্রিপ্ট হয় এবং ইউজারস্পেসে না গিয়েই একটি UDP সকেটের মাধ্যমে বেরিয়ে যায়। এই কারণেই এটি উচ্চ থ্রুপুট প্রদান করে এবং এই কারণেই মডিউলটির কোড মাত্র চার হাজার লাইনের মধ্যে সীমাবদ্ধ থাকে, যা পর্যালোচনা করার জন্য যথেষ্ট ছোট এবং 2020 সালের মার্চ মাসে মূলধারার Linux 5.6-এ অন্তর্ভুক্ত করা হয়েছে। Ubuntu 24.04 এবং Debian 13-এ এটি বিল্ট-ইন থাকে, তাই শুধুমাত্র wireguard-tools প্যাকেজটিই অনুপস্থিত থাকে।

একটি সাধারণ ইন্টারফেস হওয়ার কিছু ব্যবহারিক সুবিধা রয়েছে। tcpdump -ni wg0 প্লেইনটেক্সট ইনার প্যাকেটগুলো দেখায়, অন্যদিকে tcpdump -ni eth0 udp port 51820 এনক্রিপ্ট করা আউটার প্যাকেটগুলো দেখায়; এই দুটির তুলনা করলে আপনি তাৎক্ষণিকভাবে বুঝতে পারবেন কোন দিকে সমস্যা হচ্ছে। netfilter এবং ট্রাফিক শেপিং wg0-কে অন্য যেকোনো লিংকের মতোই বিবেচনা করে। যেখানে কার্নেল মডিউলটি উপলব্ধ নয়, যেমন কন্টেইনার ভার্চুয়ালাইজেশনে যা হোস্ট কার্নেল শেয়ার করে, সেখানে wireguard-go একটি TUN ডিভাইসের মাধ্যমে ইউজারস্পেসে একই প্রোটোকল বাস্তবায়ন করে। তবে এতে থ্রুপুটের ক্ষেত্রে প্রকৃত ক্ষতি হয়, কারণ প্রতিটি প্যাকেটকে দুইবার কার্নেল বাউন্ডারি অতিক্রম করতে হয়।

WireGuard আপনাকে যা থেকে রক্ষা করে না

এর থ্রেট মডেলটি ইচ্ছাকৃতভাবে সংকীর্ণ রাখা হয়েছে এবং প্রোটোকলটি অত্যন্ত নিরব হওয়ায় এটি নিয়ে ভুল ধারণা তৈরি হতে পারে। বিষয়টি স্পষ্টভাবে নিচে দেওয়া হলো।

• এটি আপনি যে WireGuard ব্যবহার করছেন তা গোপন করে না। হ্যান্ডশেক মেসেজগুলোর আকার নির্দিষ্ট, প্রথম বাইটটি মেসেজের ধরন নির্দেশ করে এবং ট্রান্সপোর্ট প্রোটোকলটি হলো UDP। ডিপ প্যাকেট ইন্সপেকশন (DPI) সহজেই এটি শনাক্ত করতে পারে এবং যে নেটওয়ার্ক VPN পছন্দ করে না, তারা এটি ব্লক করতে পারে। ডিজাইন অনুযায়ী এতে কোনো অবফাসকেশন (obfuscation) রাখা হয়নি।
• এটি ট্রাফিকের পরিমাণ বা সময় গোপন করে না। পেলোডগুলো শুধুমাত্র 16-বাইটের বাউন্ডারি পর্যন্ত প্যাড করা হয়, তাই একজন পর্যবেক্ষক সহজেই বুঝতে পারে আপনি কখন ডেটা পাঠাচ্ছেন এবং মোটামুটি কী পরিমাণ ডেটা পাঠাচ্ছেন।
• এটি সর্বশেষ পরিচিত এন্ডপয়েন্ট সংরক্ষণ করে। পাবলিক অ্যাড্রেস থাকা পিয়ার অপর প্রান্তের বর্তমান পাবলিক IP সংরক্ষণ করে এবং wg show তা প্রদর্শন করে। কনফিগারেশনে নির্দিষ্ট করা টানেল অ্যাড্রেসের সাথে এটি একটি স্থিতিশীল শনাক্তকারী হিসেবে কাজ করে, যা ব্যবহারকারীকে এক নেটওয়ার্ক থেকে অন্য নেটওয়ার্কে অনুসরণ করে। আপনার নিজের VPS-এর ক্ষেত্রে এটি ঠিক আছে। বাণিজ্যিক পরিষেবাগুলো প্রোটোকলের উপরে বাড়তি একটি স্তর যোগ করে বলেই তারা এই সমস্যাটি সমাধান করতে পারে।
• এটি কোনো ব্যক্তিকে নয়, বরং একটি কি (key) অথেন্টিকেট করে। যার কাছে প্রাইভেট কি ফাইলটি আছে, সেই পিয়ার হিসেবে গণ্য হবে। /etc/wireguard-কে মোড 700 এবং কি ফাইলগুলোকে 600 মোডে রাখুন।
• এতে কোনো রিভোকেশন লিস্ট বা এক্সপায়ারি নেই। যখন আপনি প্রতিটি সার্ভার থেকে পিয়ার এন্ট্রি মুছে ফেলবেন, তখনই অ্যাক্সেস বন্ধ হবে এবং স্ট্যাটিক কিগুলো মুছে না ফেলা পর্যন্ত কার্যকর থাকবে।

এর কোনোটিই WireGuard-কে দুর্বল করে না। বরং এটি একে ছোট রাখে এবং ছোট হওয়াই এর মূল উদ্দেশ্য: এটি অথেন্টিকেশন এবং এনক্রিপশন সম্পন্ন করে, আর আইডেন্টিটি ম্যানেজমেন্ট ও অ্যাড্রেস অ্যালোকেশন আপনার তৈরি করা সিস্টেমের ওপর ছেড়ে দেয়। WireGuard compared with Tailscale-এ বর্ণিত কোঅর্ডিনেশন লেয়ারটি ঠিক এই শূন্যস্থান পূরণ করার জন্যই তৈরি, যা আপনি যে ডেটা প্লেন সম্পর্কে পড়েছেন তা ব্যবহার করে। একবার এই ধরনের লেয়ার কার্যকর হয়ে গেলে, পরবর্তী সিদ্ধান্তটি হলো টানেলের ভেতরে থাকা কোনো পরিষেবা কে ব্যবহার করতে পারবে, যা the choice between Tailscale serve and funnel একটি নির্দিষ্ট পোর্টের জন্য নির্ধারণ করে দেয়।

FAQ

WireGuard-এ cryptokey routing কী?

Cryptokey routing হলো এমন একটি নিয়ম যা প্রতিটি প্যাকেটকে একটি public key-এর সাথে যুক্ত করে। প্রতিটি peer এন্ট্রিতে AllowedIPs-এ প্রিফিক্সের একটি তালিকা থাকে। আউটবাউন্ড ট্রাফিকের ক্ষেত্রে, WireGuard প্যাকেটের গন্তব্যস্থলের সাথে প্রতিটি peer-এর তালিকার তুলনা করে এবং দীর্ঘতম প্রিফিক্স ম্যাচিংয়ের ভিত্তিতে peer নির্বাচন করে, ফলে এই তালিকাটি একটি রাউটিং টেবিল হিসেবে কাজ করে। ইনবাউন্ড ট্রাফিকের ক্ষেত্রে, প্যাকেট ডিক্রিপ্ট এবং অথেন্টিকেট হওয়ার পর, এর অভ্যন্তরীণ সোর্স অ্যাড্রেস অবশ্যই সেই peer-এর তালিকার অন্তর্ভুক্ত হতে হবে, অন্যথায় প্যাকেটটি ড্রপ করা হয়; অর্থাৎ এই তালিকাটি একটি অ্যাক্সেস কন্ট্রোল লিস্ট হিসেবেও কাজ করে। WireGuard-এ আলাদা কোনো রাউটিং কনফিগারেশন বা অভ্যন্তরীণ ফায়ারওয়াল নেই, কারণ এই একটি তালিকা উভয় কাজই সম্পন্ন করে।

আমার কি উভয় peer-এই PersistentKeepalive সেট করা প্রয়োজন?

না। এটি শুধুমাত্র NAT (network address translation) বা স্টেটফুল ফায়ারওয়ালের পেছনে থাকা সাইডে সেট করুন, যা সাধারণত ক্লায়েন্ট হয়ে থাকে। WireGuard নিষ্ক্রিয় অবস্থায় কোনো ডেটা পাঠায় না, তাই যে ম্যাপিংয়ের মাধ্যমে অপর প্রান্ত থেকে peer-এর সাথে যোগাযোগ করা হয় তা সাধারণত এক মিনিটের মধ্যেই এক্সপায়ার হয়ে যায় এবং টানেলটি একমুখীভাবে অকার্যকর মনে হতে পারে। PersistentKeepalive = 25 প্রতি 25 সেকেন্ডে একটি খালি অথেন্টিকেটেড প্যাকেট পাঠায় এবং ম্যাপিংটিকে সচল রাখে। যে peer-এর একটি পাবলিক অ্যাড্রেস এবং খোলা UDP পোর্ট রয়েছে, তার জন্য এটি প্রয়োজন নেই।

টানেলের ভেতর দিয়ে ping করলে "Required key not available" দেখায় কেন?

কারণ গন্তব্যস্থলের অ্যাড্রেসটি কোনো peer-এর AllowedIPs-এর অন্তর্ভুক্ত নয়, তাই cryptokey routing প্যাকেটটি এনক্রিপ্ট করার জন্য কোনো কি (key) খুঁজে পায়নি এবং কার্নেল তা পাঠাতে অস্বীকৃতি জানিয়েছে। wg show wg0 allowed-ips কমান্ডটি চালান এবং এর আউটপুটটির সাথে আপনার পিং করা অ্যাড্রেসটি মিলিয়ে দেখুন। একই ধরনের ত্রুটি Destination address required একটি ভিন্ন সমস্যা নির্দেশ করে: এক্ষেত্রে একটি peer ম্যাচ হয়েছে, কিন্তু WireGuard-এর কাছে এর জন্য কোনো endpoint নেই, কারণ কোনো endpoint কনফিগার করা হয়নি এবং সেই peer থেকে এখনো কোনো অথেন্টিকেটেড প্যাকেট আসেনি।

ফায়ারওয়াল কি WireGuard শনাক্ত এবং ব্লক করতে পারে?

হ্যাঁ। WireGuard আপনার ট্রাফিককে অথেন্টিকেট এবং এনক্রিপ্ট করে, তবে এটি নিজেকে গোপন করার কোনো চেষ্টা করে না। হ্যান্ডশেক মেসেজগুলো নির্দিষ্টভাবে 148 এবং 92 বাইটের হয়, প্রতিটি মেসেজের প্রথম বাইট এর ধরন শনাক্ত করে এবং ট্রান্সপোর্ট প্রোটোকল হিসেবে UDP ব্যবহৃত হয়, তাই ডিপ প্যাকেট ইন্সপেকশন (DPI) সহজেই এই প্রোটোকলটি শনাক্ত করতে পারে। যেসব নেটওয়ার্ক UDP ব্লক করে বা প্রোটোকল ফিঙ্গারপ্রিন্টিং ব্যবহার করে, তারা এটি বন্ধ করে দিতে পারে। টানেলটিকে লুকাতে হলে সেটিকে অন্য কোনো প্রোটোকলের মোড়কে পাঠাতে হবে, যা WireGuard-এর কোনো সেটিং নয় বরং একটি আলাদা টুলের কাজ।