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 device पर route करता है। इसके बाद WireGuard उस packet के destination address का मिलान हर 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 का एक ही अर्थ है: जिस address तक आप पहुँचना चाहते थे, वह किसी भी peer के अंतर्गत सूचीबद्ध नहीं है। एक अलग error, ping: sendmsg: Destination address required, का अर्थ है कि peer का मिलान तो हुआ लेकिन WireGuard के पास उसके लिए कोई endpoint नहीं है, क्योंकि न तो कोई configure किया गया था और न ही अभी तक कोई सीखा गया है।

अब इनबाउंड दिशा पर विचार करें। एक UDP packet listen port पर पहुँचता है। WireGuard header में receiver index से session ढूँढता है, sliding replay window के विरुद्ध counter की जाँच करता है, और फिर payload को decrypt और authenticate करता है। उसके बाद ही यह inner packet को पढ़ता है, और उस inner packet का source address भेजने वाले 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 भेज सकता है और किसी अन्य address से नहीं। वहाँ इसके बजाय 0.0.0.0/0 लिखें और वह अकेला client आपके tunnel के भीतर किसी भी source address का उपयोग करके packet भेजने में सक्षम हो जाएगा, जिसमें किसी अन्य client का address भी शामिल है।

Overlapping prefixes विशिष्टता (specificity) के आधार पर हल होते हैं, क्योंकि lookup 'longest prefix match' का उपयोग करता है। दो peers पर समान prefixes का व्यवहार अलग होता है: entry उस peer पर चली जाती है जिसे सबसे अंत में configure किया गया था, और पहला peer बिना किसी error message के उस traffic को प्राप्त करना बंद कर देता है। wg show wg0 allowed-ips उस टेबल को print करता है जो वास्तव में kernel में है, और disk पर मौजूद file और 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 को print करता है जिसे wg tool वास्तव में load करती है, और इस विभाजन को देखने का यही सबसे तेज़ तरीका है।

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

WireGuard का हैंडशेक Noise Protocol Framework से लिया गया Noise_IKpsk2 है। IK भाग एक sysadmin के लिए उपयोगी है: initiator को responder की static public key पहले से पता होती है, क्योंकि यह आपके [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 प्रदान करता है: यदि कोई आज आपके ट्रैफ़िक को रिकॉर्ड करता है और अगले साल सर्वर की 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 को पूरी तरह से अस्वीकार कर दिया जाता है, इसलिए जब तक नया हैंडशेक पूरा नहीं होता, ट्रैफ़िक रुक जाता है। जिस initiation का कोई उत्तर नहीं मिलता, उसे हर 5 सेकंड में फिर से भेजा जाता है और 90 सेकंड के बाद छोड़ दिया जाता है। यही कारण है कि wg show, latest handshake को relative age के रूप में प्रिंट करता है, और एक व्यस्त healthy tunnel उस age को कम रखती है। यदि ट्रैफ़िक भेजने के दौरान भी age बढ़ती है, तो इसका मतलब है कि हैंडशेक विफल हो रहे हैं, न कि tunnel idle है।

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

दोनों छोर एक जैसा code और एक ही config format चलाते हैं। इसमें कोई server mode नहीं होता। आप जो विषमता महसूस करते हैं, वह 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 ही नहीं हुआ था।

यही mechanism एक ऐसी सच्चाई बनाता है जिसे जानना उपयोगी है: 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 बदलना। यह एकमात्र निर्णय अधिकांश code और उन विफलता के कारणों (failure modes) को हटा देता है जो TLS-आधारित tunnel में होते हैं, और यही वह मुख्य बिंदु है जिस पर WireGuard बनाम OpenVPN की तुलना आधारित है।

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

प्रत्येक handshake संदेश में mac1 नामक एक फील्ड होता है। यह एक MAC (message authentication code) है, जिसे responder की static public key से प्राप्त की गई एक key का उपयोग करके संदेश पर compute किया जाता है। जो sender उस public key को नहीं जानता, वह एक वैध mac1 उत्पन्न नहीं कर सकता है, और receiver ऐसे पैकेट को बिना किसी जवाब के ड्रॉप कर देता है। न कोई त्रुटि, न reset, और न ही कोई ICMP संदेश।

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

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

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

एक दूसरा फील्ड, mac2, denial of service के दबाव को संभालता है। जब receiver लोड के अधीन होता है, तो वह एक वैध initiation का जवाब sender के source address से जुड़े 64-byte cookie reply के साथ देता है, और वह तब तक महंगी public key प्रक्रिया करने से इनकार करता है जब तक कि sender उस cookie को वापस न भेज दे। यह CPU पर कोई भी काम करने से पहले यह साबित करता है कि source address वास्तविक है, और यह केवल लोड होने पर ही सक्रिय होता है।

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

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

इसे काम करने योग्य बनाने वाली routing उस लाइन से कहीं अधिक दिलचस्प है। wg0 के माध्यम से एक साधारण default route लूप (loop) बना देगा, क्योंकि आपके traffic को ले जाने वाले encrypted UDP packet को भी मशीन से बाहर निकलना होता है, और वह अपने ही default route से match हो जाएगा। wg-quick इसे policy routing के साथ रोकता है। यह WireGuard के अपने outgoing packets को एक fwmark के साथ चिह्नित करता है, tunnel default route को एक अलग routing table में डालता है, और ऐसे नियम जोड़ता है जिससे केवल 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 संख्या भी है। suppress_prefixlength 0 नियम 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 के बाहर लीक होता है में कवर किया गया है।

PersistentKeepalive का वास्तविक उद्देश्य

जब कोई traffic नहीं होता, तो WireGuard कुछ भी नहीं भेजता है। न कोई heartbeat, न session refresh, और न ही wire पर कोई अन्य डेटा। यह मौन battery life बचाने और ऊपर बताए गए scanner के मामले में मदद करता है, लेकिन यह एक विशिष्ट 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 में एक empty authenticated packet भेजता है, जो उस सबसे कम सामान्य जीवनकाल के भीतर रहता है, इसलिए mapping खुली रहती है।

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

LAN को टनल के माध्यम से रूट करना WireGuard का फीचर नहीं है

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

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

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

WireGuard का काम तब समाप्त हो जाता है जब वह decrypted packet को कर्नेल को सौंप देता है। उसके बाद सब कुछ सामान्य Linux रूटिंग और फ़िल्टरिंग है, यही कारण है कि यह विफलता nft list ruleset काउंटरों या ip -s link show wg0 में दिखाई देती है, न कि wg show में। यदि आप वेब इंटरफेस के माध्यम से peers को मैनेज करना पसंद करते हैं, तो Docker में wg-easy चलाना आपके लिए peer entries जेनरेट कर देता है, हालाँकि forwarding rules अभी भी होस्ट के ही रहते हैं।

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 उसी protocol को TUN device के ऊपर userspace में implement करता है, जिसकी throughput में वास्तविक कमी आती है क्योंकि हर packet को दो बार kernel boundary पार करनी पड़ती है।

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

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

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

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

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 सेट करने की आवश्यकता है?

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

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 का काम है।