WireGuard cryptokey routing कैसे काम करता है?

WireGuard कैसे काम करता है, एक विचार में

WireGuard हर packet को एक public key से जोड़कर काम करता है। इस तंत्र का एक नाम है, cryptokey routing, और यही इसका पूरा डिज़ाइन है: peer के बगल वाली AllowedIPs लाइन आपकी मशीन से बाहर जाने वाले packets के लिए routing table है और उस peer से आने वाले packets के लिए access control list है। एक सेटिंग, दो काम। AllowedIPs को इसी तरह पढ़ें और हर WireGuard config फ़ाइल समझ में आने लगेगी।

इसमें IP address द्वारा indexed कोई session table या user database नहीं होता है। एक peer का मतलब है एक public key और उन addresses का समूह जिन्हें वह key इस्तेमाल कर सकती है। handshake और timers का अस्तित्व इसलिए है ताकि नीचे का नेटवर्क बदलने पर भी यह binding सही बनी रहे। यदि आप सिद्धांत से पहले एक काम करने वाली tunnel चाहते हैं, तो अपने खुद के VPS पर एक self-hosted WireGuard VPN बनाएँ, और फिर जब कोई config लाइन आपको हैरान करे, तो यहाँ वापस आएँ।

AllowedIPs एक राउटिंग टेबल और एक्सेस लिस्ट है

सबसे पहले आउटबाउंड दिशा को देखें। आपका kernel सामान्य तरीके से main routing table के माध्यम से packet को wg0 डिवाइस पर रूट करता है। इसके बाद WireGuard उस packet के destination पते का मिलान प्रत्येक peer के allowed prefixes वाली टेबल से करता है, जिसमें सबसे लंबे prefix को प्राथमिकता दी जाती है। मिलान होने पर एक peer का नाम मिलता है, जिससे public key, फिर session key और अंत में UDP endpoint का पता चलता है। packet को उस peer के लिए encrypt करके भेज दिया जाता है।

यदि किसी भी peer का AllowedIPs destination को कवर नहीं करता है, तो कुछ भी नहीं भेजा जाता है, क्योंकि भेजने के लिए कोई key उपलब्ध नहीं होती है।

ping: sendmsg: Required key not available

उस error का एक ही मतलब है: जिस पते तक आप पहुँचने की कोशिश कर रहे थे, वह किसी भी peer के अंतर्गत सूचीबद्ध नहीं है। एक अलग error, ping: sendmsg: Destination address required, का मतलब है कि एक peer का मिलान तो हुआ लेकिन WireGuard के पास उसके लिए कोई endpoint नहीं है, क्योंकि न तो कोई configure किया गया था और न ही अभी तक कोई सीखा गया है।

अब इनबाउंड दिशा को देखें। एक UDP packet listen port पर आता है। WireGuard हेडर में receiver index से session ढूँढता है, sliding replay window के विरुद्ध counter की जाँच करता है, और फिर payload को decrypt और authenticate करता है। उसके बाद ही यह inner packet को पढ़ता है, और उस inner packet का source पता भेजने वाले peer के AllowedIPs के भीतर होना चाहिए। यदि ऐसा नहीं होता है, तो packet को drop कर दिया जाता है। यदि dynamic debug सक्षम है, तो kernel कारण को इस तरह की एक लाइन में print करता है:

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

यही कारण है कि server side पर एक peer को /32 प्राप्त होता है। AllowedIPs = 10.8.0.2/32 के साथ configure किया गया एक peer केवल 10.8.0.2 से packet भेज सकता है और किसी अन्य पते से नहीं। इसके बजाय वहाँ 0.0.0.0/0 लिखें और वह एकल client आपके tunnel के भीतर किसी भी source पते का दावा करने वाले packet को भेजने में सक्षम हो जाएगा, जिसमें किसी अन्य client का पता भी शामिल है।

Overlapping prefixes का समाधान विशिष्टता (specificity) के आधार पर होता है, क्योंकि lookup सबसे लंबे prefix मिलान (longest prefix match) द्वारा किया जाता है। दो peers पर समान prefixes अलग तरह से व्यवहार करते हैं: entry उस peer पर चली जाती है जिसे सबसे अंत में configure किया गया था, और पहला peer बिना किसी error के उस traffic को प्राप्त करना बंद कर देता है। wg show wg0 allowed-ips उस टेबल को print करता है जो वास्तव में kernel में है, और यही मायने रखता है जब disk पर मौजूद फ़ाइल और चल रही स्थिति (running state) एक-दूसरे से अलग हो जाते हैं।

Cryptokey routing को ध्यान में रखते हुए config file पढ़ना

सर्वर साइड:

[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

एक ही keyword का दोनों तरफ विपरीत प्रभाव होता है। क्लाइंट पर इसका अर्थ है "हर destination को इस peer के पास भेजें"। सर्वर पर इसका अर्थ है "इस peer से केवल यही एक address स्वीकार करें"। यह विषमता values में है, किसी भूमिका (role) में नहीं।

इनमें से आधी keys प्रोटोकॉल का हिस्सा नहीं हैं। Address, DNS, MTU, PostUp और SaveConfig, wg-quick से संबंधित हैं, जो कि वह shell script है जो interface को up करती है। kernel इन्हें कभी नहीं देखता। wg-quick strip wg0 वह संक्षिप्त config प्रिंट करता है जिसे wg टूल वास्तव में लोड करता है, और इस विभाजन को देखने का यह सबसे तेज़ तरीका है।

हैंडशेक वास्तव में क्या करता है

WireGuard का हैंडशेक Noise Protocol Framework से लिया गया Noise_IKpsk2 है। IK भाग एक sysadmin के लिए उपयोगी है: responder की static public key initiator को पहले से पता होती है, क्योंकि यह आपके [Peer] ब्लॉक में PublicKey होती है, और initiator अपना खुद का static public key पहले संदेश के भीतर एन्क्रिप्ट करके भेजता है। इसलिए इसमें कोई certificate exchange और identity round trip नहीं होता है। एक passive observer यह नहीं बता सकता कि कौन सी key कॉल कर रही है, जब तक कि उसके पास responder की private key न हो।

इसकी लागत एक round trip है। initiation संदेश 148 bytes का होता है, response 92 bytes का होता है, और डेटा तुरंत उसके बाद प्रवाहित होता है। प्रत्येक पक्ष प्रति हैंडशेक एक नया ephemeral Curve25519 key pair उत्पन्न करता है, और session keys Diffie-Hellman परिणामों की एक श्रृंखला से आती हैं जो static और ephemeral keys को मिलाती हैं। ephemeral private keys को बाद में हटा दिया जाता है, जो forward secrecy प्रदान करता है: यदि कोई आज आपके traffic को रिकॉर्ड करता है और अगले साल सर्वर की private key चुरा लेता है, तब भी वह रिकॉर्ड किए गए डेटा को नहीं पढ़ पाएगा।

एक हैंडशेक initiation में TAI64N timestamp होता है, और प्रत्येक peer दूसरे से प्राप्त सबसे बड़े timestamp को याद रखता है, इसलिए replayed initiation को अस्वीकार कर दिया जाता है। डेटा पैकेट में nonce के रूप में उपयोग किया जाने वाला 64-bit counter होता है, और receiver हाल ही में देखे गए counters की एक sliding window रखता है, इसलिए TCP-style connection state के बिना ही replays और भारी reordering को संभाल लिया जाता है।

Session keys लंबे समय तक नहीं चलती हैं, और timers को कॉन्फ़िगर करने के बजाय compile किया जाता है।

[
  {
    "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"
  }
]

ये प्रोटोकॉल विनिर्देश के स्थिरांक (constants) हैं, न कि माप। इनमें से 5 पूरे session lifecycle को संचालित करते हैं। उपयोग के 120 सेकंड के बाद sender एक नया हैंडशेक शुरू करता है, और 180 सेकंड के बाद पुरानी key को पूरी तरह से अस्वीकार कर दिया जाता है, इसलिए जब तक नया हैंडशेक पूरा नहीं हो जाता, तब तक traffic रुक जाता है। जिस initiation का कोई उत्तर नहीं मिलता, उसे हर 5 सेकंड में फिर से भेजा जाता है और 90 सेकंड के बाद छोड़ दिया जाता है। यही कारण है कि wg show, latest handshake को relative age के रूप में प्रिंट करता है, और एक व्यस्त healthy tunnel उस age को छोटा रखती है। यदि आप सक्रिय रूप से traffic भेज रहे हैं और फिर भी age बढ़ रही है, तो इसका मतलब है कि हैंडशेक विफल हो रहे हैं, न कि tunnel idle है।

किसी peer की कोई client या server भूमिका क्यों नहीं होती

दोनों छोर एक जैसा code और एक ही config format चलाते हैं। इसमें कोई server mode नहीं होता। जो विषमता (asymmetry) आपको महसूस होती है, वह Endpoint के कारण है, और Endpoint वैकल्पिक है।

एक configured endpoint वाला peer handshake शुरू कर सकता है। जिसके पास endpoint नहीं है, वह प्रतीक्षा करता है, और फिर सही ढंग से authenticate होने वाले पहले packet से दूसरी तरफ का address और port जान लेता है। वह सीखा हुआ endpoint store हो जाता है, और जब भी किसी नए address से एक valid packet आता है, तो यह update हो जाता है। roaming इसी तरह काम करती है: wifi से mobile network पर जाने वाला laptop एक ही tunnel बनाए रखता है, क्योंकि session की पहचान IP address के बजाय key और index से होती है। कुछ भी reconnect नहीं होता, क्योंकि TCP के अर्थ में कभी कुछ connect ही नहीं हुआ था।

यही तंत्र एक ऐसी सच्चाई बनाता है जिसे जानना उपयोगी है: public address वाले peer के पास हमेशा दूसरी तरफ का अंतिम ज्ञात public IP होता है, और wg show उसे print करता है।

निश्चित प्रिमिटिव्स, और बातचीत की कोई गुंजाइश नहीं

WireGuard में ciphersuite की कोई सूची नहीं है। इसमें authenticated encryption के लिए ChaCha20-Poly1305, key agreement के लिए Curve25519, hashing के लिए BLAKE2s और key derivation के लिए HKDF का उपयोग होता है। हर deployment में इनका ही उपयोग किया जाता है, इसलिए न तो पार्स करने के लिए कोई negotiation phase होता है और न ही किसी कमजोर विकल्प पर downgrade करने का कोई रास्ता। यह एक स्पष्ट समझौता है: यदि इनमें से कोई भी प्रिमिटिव टूटता है, तो इसका समाधान पूरे protocol का नया version और दोनों सिरों पर update करना है, न कि केवल configuration बदलना। यह एक निर्णय अधिकांश कोड और उन failure modes को हटा देता है जो TLS-आधारित tunnel में होते हैं, और WireGuard बनाम OpenVPN की तुलना मुख्य रूप से इसी बात पर आधारित है।

पोर्ट स्कैनर को जवाब क्यों नहीं देता है

प्रत्येक हैंडशेक संदेश में mac1 नामक एक फील्ड होती है। यह एक MAC (मैसेज ऑथेंटिकेशन कोड) है, जिसे रिस्पॉन्डर की स्टैटिक पब्लिक की (public key) से प्राप्त की गई एक की (key) का उपयोग करके संदेश पर कंप्यूट किया जाता है। जो सेंडर उस पब्लिक की को नहीं जानता, वह वैध mac1 उत्पन्न नहीं कर सकता, और रिसीवर ऐसे पैकेट को बिना किसी जवाब के ड्रॉप कर देता है। न कोई एरर, न कोई रिसेट, और न ही कोई ICMP संदेश।

इसका दृश्य परिणाम यह होता है कि UDP स्कैन में कोई प्रतिक्रिया नहीं मिलती है।

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

nmap open|filtered रिपोर्ट करता है, जो वही जवाब है जो यह उस पोर्ट के लिए देता है जिसे फायरवॉल चुपचाप ड्रॉप कर देता है। पोर्ट का व्यवहार तब भी वैसा ही रहता है चाहे WireGuard लिसन कर रहा हो या नहीं, कम से कम उन लोगों के लिए जिनके पास आपकी पब्लिक की नहीं है।

एक दूसरी फील्ड, mac2, डिनायल ऑफ सर्विस (DoS) के दबाव को संभालती है। जब रिसीवर लोड के अधीन होता है, तो वह सेंडर के सोर्स एड्रेस से जुड़े 64-बाइट कुकी रिप्लाई के साथ एक वैध इनिशिएशन का जवाब देता है, और वह तब तक महंगे पब्लिक की ऑपरेशन्स करने से इनकार करता है जब तक कि सेंडर उस कुकी को वापस न भेज दे। यह साबित करता है कि सोर्स एड्रेस वास्तविक है, इससे पहले कि उस पर कोई CPU खर्च किया जाए, और यह केवल लोड होने पर ही सक्रिय होता है।

0.0.0.0/0 किसी peer को आपका default route क्यों बना देता है

क्योंकि AllowedIPs routing table है, इसलिए AllowedIPs = 0.0.0.0/0, ::/0 उस peer के लिए हर destination का दावा करता है। यह पूरी तरह से full tunnel की सेटिंग है।

जो routing इसे काम करने योग्य बनाती है, वह उस line से कहीं अधिक दिलचस्प है। wg0 के माध्यम से एक साधारण default route loop बना देगा, क्योंकि आपके traffic को ले जाने वाले encrypted UDP packet को भी machine से बाहर निकलना होता है, और वह अपने ही default route से match हो जाएगा। wg-quick इसे policy routing के साथ रोकता है। यह WireGuard के अपने outgoing packets को एक fwmark के साथ mark करता है, tunnel default route को एक अलग routing table में डालता है, और ऐसे rules जोड़ता है जिससे केवल unmarked traffic ही उस तक पहुँच सके। 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 hex में 51820 है, और 51820 ही table number भी है। suppress_prefixlength 0 rule main table को अपने स्वयं के default route को छोड़ने के लिए मजबूर करता है, ताकि आपके local subnet जैसे विशिष्ट routes प्रभावी रहें जबकि बाकी सब कुछ tunnel table में चला जाए। split tunnel को इनमें से किसी की आवश्यकता नहीं होती: AllowedIPs = 10.8.0.0/24, 10.20.0.0/16 जैसी एक सीमित सूची main table में सामान्य routes बन जाती है।

एक full tunnel अपने आप में जिस एक चीज़ को ठीक नहीं करता, वह है name resolution, क्योंकि आपके client ने local network से जो resolver सीखा है, वह आमतौर पर वही रहता है और उसका route अधिक विशिष्ट होता है। यह एक अलग कार्य है, जिसे DNS जो WireGuard tunnel के बाहर leak होता है में कवर किया गया है।

PersistentKeepalive वास्तव में किस लिए है

जब कोई traffic नहीं होता, तो WireGuard कुछ भी नहीं भेजता है। न कोई heartbeat, न session refresh, और न ही wire पर कुछ और। यह चुप्पी battery life बचाने और ऊपर बताए गए scanner case में मदद करती है, लेकिन यह एक विशिष्ट setup को बाधित करती है।

NAT (network address translation) या stateful firewall के पीछे मौजूद peer तक बाहर से तभी पहुँचा जा सकता है जब उस device में कोई mapping मौजूद हो, और वह mapping किसी outgoing packet द्वारा बनाई गई हो। सामान्य UDP mapping का जीवनकाल लगभग 30 seconds से शुरू होता है। एक बार mapping expire हो जाने पर, public side से आने वाले packets को middlebox द्वारा drop कर दिया जाता है, और tunnel तब तक मृत दिखाई देती है जब तक कि NAT के पीछे वाला peer कुछ न भेजे। PersistentKeepalive = 25 हर 25 seconds में एक खाली authenticated packet भेजता है, जो उस सबसे छोटे सामान्य जीवनकाल के भीतर रहता है, इसलिए mapping खुली रहती है।

इसे NAT के पीछे वाले peer पर set करें। public address और open UDP port वाले server को इसकी आवश्यकता नहीं होती है, और वहाँ इसे set करने से केवल traffic बढ़ता है। इसे automatic keepalive के साथ भ्रमित न करें, जो तब सक्रिय होता है जब कोई peer data प्राप्त करता है और उसके पास वापस भेजने के लिए अपना कुछ भी नहीं होता है। वह हमेशा चालू रहता है और उसे configure नहीं किया जा सकता है। यह 10 seconds के बाद सक्रिय होता है।

LAN को tunnel के माध्यम से route करना WireGuard का feature नहीं है

मान लीजिए peer B एक home network 192.168.50.0/24 पर स्थित है, और peer A को उस तक पहुँचना है। दो अलग-अलग systems को आपस में तालमेल बिठाना होगा, और उनमें से केवल एक ही WireGuard है।

WireGuard का हिस्सा: A पर B की AllowedIPs में 192.168.50.0/24 जोड़ें। यह A को उस prefix को B की ओर route करने के लिए कहता है, और यह A को B से उन source addresses वाले packets को स्वीकार करने की अनुमति देता है। इसके बिना, cryptokey routing के पास destination के लिए कोई key नहीं होती और source के लिए कोई अनुमति नहीं होती।

Kernel का हिस्सा: B पर, net.ipv4.ip_forward को 1 होना चाहिए, अन्यथा kernel हर उस decrypted packet को drop कर देता है जो स्वयं B को संबोधित नहीं है। B के firewall की forward chain को इस traffic की अनुमति देनी होगी। LAN पर मौजूद hosts को 10.8.0.0/24 की ओर वापस जाने के लिए एक route की आवश्यकता होती है, या B को source NAT लागू करना होगा ताकि replies B के माध्यम से वापस आ सकें।

WireGuard का काम decrypted packet को kernel को सौंपने के बाद समाप्त हो जाता है। उसके बाद की पूरी प्रक्रिया सामान्य Linux routing और filtering होती है। इसी कारण यह failure nft list ruleset counters या ip -s link show wg0 में दिखाई देता है, wg show में नहीं। यदि आप peers को web interface के माध्यम से manage करना चाहते हैं, तो Docker में wg-easy चलाने से आपके लिए peer entries generate हो जाती हैं। हालांकि forwarding rules अब भी host की जिम्मेदारी रहती हैं। यही विभाजन तब भी बना रहता है जब कोई coordination layer आपके लिए prefix distribute करती है। Tailscale subnet router के साथ VPS से private network advertise करना हर peer पर manual AllowedIPs edit करने की आवश्यकता समाप्त कर देता है। लेकिन router पर forwarding sysctl और firewall rules आपको स्वयं configure करने होते हैं।

WireGuard kernel में क्यों रहता है

wg0 एक network device driver है। Packets सामान्य routing stack के माध्यम से इस तक पहुँचते हैं, softirq context में encrypt होते हैं, और userspace में जाए बिना ही UDP socket से बाहर निकल जाते हैं। यही कारण है कि इसमें throughput अधिक मिलता है, और इसी वजह से यह module लगभग चार हजार lines of code का है, जो इतना छोटा है कि इसे review करना और March 2020 में mainline Linux 5.6 में merge करना संभव हुआ। Ubuntu 24.04 और Debian 13 इसे ship करते हैं, इसलिए केवल wireguard-tools package ही अनुपलब्ध है।

एक सामान्य interface होने के व्यावहारिक परिणाम होते हैं। tcpdump -ni wg0 plaintext inner packets को दिखाता है जबकि tcpdump -ni eth0 udp port 51820 encrypted outer packets को दिखाता है, और दोनों की तुलना करने से तुरंत पता चल जाता है कि कौन सी दिशा में समस्या है। netfilter और traffic shaping, wg0 के साथ किसी अन्य link जैसा ही व्यवहार करते हैं। जहाँ kernel module उपलब्ध नहीं होता, जैसे कि container virtualisation में जो host kernel साझा करता है, वहाँ wireguard-go एक TUN device के ऊपर userspace में उसी protocol को implement करता है। इसमें throughput की वास्तविक हानि होती है क्योंकि हर packet को दो बार kernel boundary पार करनी पड़ती है।

WireGuard आपको किन चीजों से सुरक्षित नहीं रखता है

इसका थ्रेट मॉडल जानबूझकर सीमित रखा गया है, और इतना शांत प्रोटोकॉल अक्सर गलतफहमियों को जन्म देता है। इसे स्पष्ट रूप से समझें।

• यह इस बात को नहीं छिपाता कि आप WireGuard का उपयोग कर रहे हैं। हैंडशेक संदेशों का आकार निश्चित होता है, पहला बाइट संदेश का प्रकार बताता है, और ट्रांसपोर्ट UDP है। डीप पैकेट इंस्पेक्शन (DPI) इसे आसानी से पहचान लेता है, और जो नेटवर्क VPN को पसंद नहीं करते, वे इसे ब्लॉक कर सकते हैं। ऑबफस्केशन (obfuscation) को जानबूझकर इसमें शामिल नहीं किया गया है।
• यह डेटा की मात्रा या समय (timing) को नहीं छिपाता है। पेलोड को केवल 16-बाइट की सीमा तक पैड किया जाता है, इसलिए एक ऑब्जर्वर अभी भी देख सकता है कि आप कब डेटा भेज रहे हैं और लगभग कितना भेज रहे हैं।
• यह अंतिम ज्ञात एंडपॉइंट को सुरक्षित रखता है। सार्वजनिक IP वाला पीयर दूसरी तरफ के वर्तमान सार्वजनिक IP को स्टोर करता है, और wg show इसे प्रदर्शित करता है। कॉन्फ़िगरेशन में फिक्स्ड टनल एड्रेस के साथ मिलकर, यह एक स्थिर पहचानकर्ता (identifier) है जो नेटवर्क बदलते समय भी उपयोगकर्ता का पीछा करता है। अपने स्वयं के VPS पर यह ठीक है। यही कारण है कि कमर्शियल सेवाएं प्रोटोकॉल के ऊपर एक अतिरिक्त लेयर जोड़ती हैं।
• यह एक कुंजी (key) को प्रमाणित करता है, किसी व्यक्ति को नहीं। जिसके पास भी प्राइवेट की फाइल है, वही पीयर है। /etc/wireguard को मोड 700 पर और की फाइलों को 600 पर रखें।
• इसमें कोई रिवोकेशन लिस्ट या एक्सपायरी नहीं होती है। एक्सेस तब समाप्त होता है जब आप इसे रखने वाले प्रत्येक सर्वर से पीयर एंट्री को हटा देते हैं, और स्टेटिक कीज़ तब तक बनी रहती हैं जब तक आप उन्हें हटा नहीं देते।

इनमें से कोई भी बात WireGuard को कमजोर नहीं बनाती है। यह इसे छोटा बनाती है, और छोटा होना ही इसका उद्देश्य है: यह प्रमाणित और एन्क्रिप्ट करता है, और पहचान प्रबंधन (identity management) तथा एड्रेस आवंटन को उस पर छोड़ देता है जो आप इसके ऊपर बनाते हैं। WireGuard की Tailscale के साथ तुलना में वर्णित समन्वय लेयर (coordination layer) ठीक इसी कमी को पूरा करने के लिए मौजूद है, जो उसी डेटा प्लेन का उपयोग करती है जिसके बारे में आपने अभी पढ़ा है। एक बार ऐसी लेयर लागू हो जाने के बाद, अगला निर्णय यह होता है कि टनल के अंदर चल रही सर्विस तक कौन पहुँच सकता है, जिसे Tailscale serve और funnel के बीच का चुनाव एक सिंगल पोर्ट के लिए तय करता है।

FAQ

WireGuard में cryptokey routing क्या है?

Cryptokey routing वह नियम है जो प्रत्येक packet को एक public key से जोड़ता है। प्रत्येक peer entry में AllowedIPs में prefixes की एक सूची होती है। Outbound traffic के लिए, WireGuard packet के destination का मिलान प्रत्येक peer की सूची से करता है (सबसे लंबे prefix को प्राथमिकता देते हुए), इसलिए यह सूची एक routing table की तरह काम करती है। Inbound traffic के लिए, एक बार packet के decrypt और authenticate हो जाने के बाद, उसका inner source address उसी peer की सूची के भीतर होना चाहिए, अन्यथा उसे drop कर दिया जाता है; इस प्रकार यह सूची एक access control list के रूप में कार्य करती है। WireGuard में कोई अलग routing config या आंतरिक firewall नहीं होता, क्योंकि यही एक सूची दोनों काम करती है।

क्या मुझे दोनों peers पर PersistentKeepalive की आवश्यकता है?

नहीं। इसे NAT (network address translation) या stateful firewall के पीछे वाले side पर set करें, जो आमतौर पर client होता है। WireGuard idle रहने पर कुछ भी नहीं भेजता है, इसलिए वह mapping जो दूसरे side को उस peer तक पहुँचने देती है, वह अक्सर एक मिनट के भीतर expire हो जाती है, जिससे tunnel एक दिशा में मृत (dead) दिखाई देने लगती है। PersistentKeepalive = 25 हर 25 seconds में एक empty authenticated packet भेजता है और mapping को open रखता है। जिस peer का public address है और UDP port open है, उसे इसकी आवश्यकता नहीं होती।

tunnel पर ping करने पर "Required key not available" क्यों आता है?

क्योंकि destination address किसी भी peer के AllowedIPs के भीतर नहीं है, इसलिए cryptokey routing को packet encrypt करने के लिए कोई key नहीं मिली और kernel ने इसे भेजने से मना कर दिया। wg show wg0 allowed-ips चलाएँ और उस output की तुलना उस address से करें जिसे आप ping कर रहे हैं। इसी तरह की error Destination address required एक अलग समस्या है: एक peer match तो हुआ, लेकिन WireGuard के पास उसके लिए कोई endpoint नहीं है, क्योंकि न तो कोई configure किया गया है और न ही उस peer से अभी तक कोई authenticated packet प्राप्त हुआ है।

क्या कोई firewall WireGuard को detect और block कर सकता है?

हाँ। WireGuard आपके traffic को authenticate और encrypt करता है, और यह खुद को छिपाने का कोई प्रयास नहीं करता है। Handshake messages का आकार निश्चित रूप से 148 और 92 bytes होता है, हर message का पहला byte उसके प्रकार की पहचान करता है, और transport UDP होता है, इसलिए deep packet inspection आसानी से protocol की पहचान कर लेता है। जो networks UDP को block करते हैं या protocols की fingerprinting करते हैं, वे इसे रोक देंगे। Tunnel को छिपाने का मतलब है उसे किसी और चीज़ में wrap करना, जो कि WireGuard setting के बजाय एक अलग tool का काम है।