Linux VPS पर WireGuard VPN कैसे सेटअप करें

आप क्या बना रहे हैं

अपने स्वयं के सर्वर पर WireGuard VPN बनाना लगभग चालीस लाइनों का कॉन्फ़िगरेशन है: एक की-पेयर, एक इंटरफ़ेस फ़ाइल, एक sysctl, एक NAT नियम और एक फ़ायरवॉल होल। इसका इंस्टॉलेशन बहुत सरल है, इसलिए इस गाइड का अधिकांश भाग उन समस्याओं पर केंद्रित है जो आ सकती हैं, जैसे की-परमिशन, AllowedIPs, फॉरवर्डिंग और DNS।

WireGuard कर्नल में एक Layer 3 टनल है, जो Linux 5.6 के बाद से मेनलाइन का हिस्सा है, इसलिए Ubuntu 24.04 और Debian 13 में यह बिना किसी बाहरी मॉड्यूल के आता है। इसमें कोई सिफर नेगोशिएशन, सर्टिफिकेट अथॉरिटी या यूजरनेम/पासवर्ड का चरण नहीं होता है: एक पीयर का मतलब है एक पब्लिक की और वे IP एड्रेस जिनका वह की उपयोग कर सकती है। यदि कोई पैकेट अपना MAC चेक पास नहीं कर पाता है, तो उसे बिना किसी उत्तर के ड्रॉप कर दिया जाता है, इसलिए पोर्ट स्कैन का कोई जवाब नहीं देता है। इसका दूसरा पहलू यह है कि कोई ऑथेंटिकेशन सर्वर नहीं होता है, इसलिए एक्सेस हटाने का मतलब है बॉक्स से उस पीयर को डिलीट करना।

सबसे पहले वर्चुअलाइजेशन की जाँच करें

WireGuard को ऐसे kernel की आवश्यकता होती है जिसमें आप module लोड कर सकें, और KVM VPS पर यह सीधे काम करता है। container virtualisation (जैसे OpenVZ या LXC) पर, जो host kernel को साझा करते हैं, पहला command RTNETLINK answers: Operation not supported के साथ विफल हो जाता है, और ऐसी स्थिति में wireguard-go userspace implementation का उपयोग करना पड़ता है। सबसे पहले sudo modprobe wireguard && echo ok के साथ जाँच करें।

Keys को लीक किए बिना generate करें

World-readable /etc/wireguard/server.key का मतलब है कि VPN का कोई सुरक्षा लाभ नहीं है। सामान्य umask 077 && wg genkey | sudo tee ... लाइन अविश्वसनीय है, क्योंकि sudo फाइल tee द्वारा बनाए जाने पर अपना खुद का umask लागू करता है। Mode को स्पष्ट रूप से set करें।

sudo apt update && sudo apt install -y wireguard nftables
sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/server.key'
sudo sh -c 'wg pubkey < /etc/wireguard/server.key > /etc/wireguard/server.pub'
sudo chmod 600 /etc/wireguard/server.key

Client pair को भी उसी तरह generate करें। wg genpsk एक वैकल्पिक pre-shared key जोड़ता है, जो प्रत्येक config में एक लाइन होती है।

सर्वर इंटरफ़ेस: /etc/wireguard/wg0.conf

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <contents of /etc/wireguard/server.key>

[Peer]
PublicKey = <laptop public key>
PresharedKey = <psk, optional>
AllowedIPs = 10.8.0.2/32

chmod 600 इसे सुरक्षित करें; स्टार्टअप पर चेतावनी कि फ़ाइल world accessible है, इसका मतलब है कि आपने इसे अनदेखा किया है। Address टनल के अंदर सर्वर का पता है, जिसमें पूरे VPN सबनेट का मास्क शामिल है। ऐसी रेंज चुनें जो आपको वास्तविक नेटवर्क में न मिले, 192.168.1.0/24 आपके क्लाइंट्स के पीछे मौजूद आधे होम राउटर के साथ टकराता है, और फिर टनल चुपचाप लोकल रूट के कारण काम करना बंद कर देती है।

सर्वर साइड पर पीयर का AllowedIPs एक /32 होता है, जो वह एकमात्र टनल पता है जिसका स्वामी क्लाइंट है। दो पीयर्स को एक ही allowed IP देने पर ट्रैफिक उस पीयर पर चला जाता है जिसे आखिरी बार कॉन्फ़िगर किया गया था, और पहले वाले को बिना किसी त्रुटि के ट्रैफिक मिलना बंद हो जाता है। SaveConfig को सेट न छोड़ें, अन्यथा wg-quick down इस फ़ाइल को लाइव स्टेट से ओवरराइट कर देगा।

बॉक्स को राउटर में बदलें

Linux सर्वर उन packets को drop कर देता है जो उसके लिए नहीं होते हैं। डिफ़ॉल्ट रूप से, forwarding और source NAT दोनों ही सक्षम नहीं होते हैं।

printf 'net.ipv4.ip_forward = 1\nnet.ipv6.conf.all.forwarding = 1\n' \
  | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

एक साधारण sysctl -w अगले reboot तक काम करता है और फिर चुपचाप काम करना बंद कर देता है। NAT के लिए egress interface की आवश्यकता होती है, यानी वह NIC जो इंटरनेट तक पहुँचता है, न कि wg0। eth0 को मानकर न चलें; अपना interface ip route show default से प्राप्त करें, क्योंकि वर्तमान images में enp1s0 या ens3 जैसे नाम उपयोग किए जाते हैं।

Firewall: port और forward path

एक nftables फ़ाइल filter और NAT दोनों को कवर करती है। /etc/nftables.conf लिखें, यह मौजूदा ruleset को flushes कर देता है, इसलिए यदि सर्वर पहले से ही ufw या Docker द्वारा प्रबंधित है, तो इसे न चलाएं।

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    udp dport 51820 accept
  }
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "wg0" oifname "enp1s0" accept
  }
}

table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 10.8.0.0/24 oifname "enp1s0" masquerade
  }
}

इसे sudo systemctl enable --now nftables के साथ लागू करें, और एक दूसरा SSH session खुला रखें: policy drop के साथ SSH rule में एक छोटी सी गलती भी आपको अपने ही सर्वर से बाहर कर सकती है। ध्यान दें कि forward chain क्या अनुमति नहीं देती है, wg0 से wg0 तक। Peers इंटरनेट तक पहुँच सकते हैं, लेकिन एक-दूसरे तक नहीं; peer-to-peer VPN के लिए iifname "wg0" oifname "wg0" accept जोड़ें। यही chain यह भी नियंत्रित करती है कि एक peer सर्वर पर क्या एक्सेस कर सकता है, जो तब महत्वपूर्ण होता है जब सर्वर एक tmux में Claude Code चलाने वाला remote development box के रूप में भी काम करता है और आप उस हिस्से को सार्वजनिक रूप से expose नहीं करना चाहते हैं।

ufw वाले बॉक्स पर: ufw allow 51820/udp, /etc/default/ufw में DEFAULT_FORWARD_POLICY="ACCEPT", और /etc/ufw/before.rules के शीर्ष पर एक *nat POSTROUTING MASQUERADE rule का उपयोग करें।

##
systemd के अंतर्गत इसे चालू करना

sudo systemctl enable --now wg-quick@wg0
sudo wg show

wg-quick इंटरफ़ेस बनाता है, पते जोड़ता है और AllowedIPs से प्राप्त रूट्स को इंस्टॉल करता है। enable --now इसका महत्वपूर्ण हिस्सा है: मैन्युअल रूप से चलाया गया wg-quick up wg0 अगले रीबूट के बाद हट जाता है, और kernel अपग्रेड का मतलब रीबूट ही होता है। यदि कोई यूनिट ऐसे रीबूट के बाद वापस चालू नहीं होती है, तो वह तब तक शांत रहती है जब तक कोई उससे कनेक्ट करने का प्रयास न करे। इसलिए, अपने स्वयं के ntfy सर्वर की ओर इशारा करते हुए wg-quick@wg0 पर एक OnFailure= ड्रॉप-इन का उपयोग करना, किसी लॉक-आउट उपयोगकर्ता से सुनने के बजाय अपने फोन पर इसके बारे में जानने का सबसे सस्ता तरीका है।

क्लाइंट कॉन्फ़िगरेशन, और वह सेटिंग जिसे हर कोई गलत समझता है

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

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

AllowedIPs एक साथ दो अलग-अलग काम करता है, और इन दोनों को मिला देना ही WireGuard को लेकर अधिकांश भ्रम का कारण है।

आउटबाउंड के लिए यह एक राउटिंग टेबल है। जिस पैकेट का डेस्टिनेशन किसी पीयर के AllowedIPs से मेल खाता है, उसे एन्क्रिप्ट करके उस पीयर को भेज दिया जाता है। 0.0.0.0/0, ::/0 सब कुछ टनल के माध्यम से भेजता है, जिसे फुल टनल कहते हैं, जहाँ सर्वर डिफ़ॉल्ट रूट बन जाता है। स्प्लिट टनल एक सीमित सूची है: AllowedIPs = 10.8.0.0/24, 10.20.0.0/16 VPN ट्रैफ़िक के साथ-साथ सर्वर के पीछे के एक प्राइवेट नेटवर्क को ले जाता है, और बाकी सब कुछ अपने स्थानीय रूट का उपयोग करता है। यही सीमित सूची आपको सेवाओं को पूरी तरह से सार्वजनिक इंटरनेट से दूर रखने की अनुमति देती है, जैसे कि टनल एड्रेस से जुड़ी VPS पर एक प्राइवेट Nextcloud इंस्टेंस, या उसी बॉक्स पर चल रहे नेस्टेड-वर्चुअलाइजेशन लैब VM, जो पीयर्स के लिए तो पहुँच योग्य रहते हैं लेकिन बाकी किसी के लिए अदृश्य।

इनबाउंड के लिए यह एक एक्सेस-कंट्रोल लिस्ट है। किसी पीयर से आया डिक्रिप्टेड पैकेट, जिसका सोर्स एड्रेस उस पीयर के AllowedIPs में नहीं है, उसे ड्रॉप कर दिया जाता है। यही कारण है कि सर्वर लैपटॉप के लिए 10.8.0.2/32 को लिस्ट करता है: वहाँ 0.0.0.0/0 की एंट्री होने से क्लाइंट टनल में किसी भी एड्रेस को स्पूफ (spoof) कर सकता था।

PersistentKeepalive NAT के पीछे मौजूद क्लाइंट्स के लिए है, जहाँ राउटर UDP मैपिंग को केवल तभी खुला रखता है जब पैकेट प्रवाहित हो रहे हों। जब यह समय समाप्त हो जाता है, तो सर्वर क्लाइंट तक नहीं पहुँच पाता। PersistentKeepalive = 25 इस मैपिंग को खुला रखता है, इसे क्लाइंट पर सेट करें, न कि पब्लिक IP वाले सर्वर पर।

DNS, और वह लीक जिस पर किसी का ध्यान नहीं जाता

AllowedIPs = 0.0.0.0/0 के साथ और बिना किसी DNS = लाइन के, क्लाइंट उसी resolver का उपयोग करता रहता है जिसे उसने लोकल नेटवर्क से सीखा है, यानी 192.168.1.1 पर स्थित कैफे राउटर। वह रूट डिफ़ॉल्ट रूट की तुलना में अधिक विशिष्ट होता है, इसलिए DNS क्वेरीज़ लोकल लिंक के माध्यम से cleartext में बाहर जाती हैं, जबकि बाकी सब कुछ टनल के अंदर रहता है। ट्रैफ़िक तो प्राइवेट होता है, लेकिन नामों की सूची नहीं।

दो ईमानदार विकल्प हैं। DNS को किसी पब्लिक resolver (DNS = 9.9.9.9) पर पॉइंट करें, जिससे क्वेरीज़ टनल से होकर आपके सर्वर से बाहर निकलेंगी, हालाँकि वह resolver अभी भी उन्हें देख पाएगा। या फिर unbound या dnsmasq को 10.8.0.1 पर बाइंड करके चलाएँ, DNS = 10.8.0.1 सेट करें, और इनपुट चेन में udp dport 53 iifname "wg0" accept जोड़ें, उस लाइन को सेट करें और resolver को भूल जाएँ, फिर कुछ भी रिज़ॉल्व नहीं होगा।

Linux क्लाइंट्स पर wg-quick, DNS के माध्यम से resolvconf लागू करता है; यदि यह अनुपस्थित है तो आपको resolvconf: command not found प्राप्त होता है। openresolv इंस्टॉल करें, या systemd-resolved क्लाइंट पर PostUp = resolvectl dns %i 10.8.0.1 सेट करें।

टनल को बंद किए बिना पीयर्स (peers) को जोड़ना और हटाना

किसी यूजर को जोड़ने के लिए इंटरफेस को रीस्टार्ट करने से सभी कनेक्टेड यूजर्स डिस्कनेक्ट हो जाते हैं। [Peer] ब्लॉक को wg0.conf में जोड़ें, और फिर पीयर सेट को वहीं रीलोड करें।

sudo bash -c 'wg syncconf wg0 <(wg-quick strip wg0)'

wg-quick strip कमांड wg-quick-only कीज़ (Address, DNS, PostUp) के बिना कॉन्फ़िगरेशन को प्रिंट करती है, और syncconf लाइव सेशन को प्रभावित किए बिना अंतर को लागू कर देती है। यह केवल पीयर्स को अपडेट करती है: बदले हुए Address के लिए अभी भी पूर्ण down/up प्रक्रिया की आवश्यकता होती है। sudo wg set wg0 peer <public key> remove के साथ एक्सेस रद्द करें, फिर फाइल से ब्लॉक को हटा दें, अन्यथा अगले रीलोड पर यह वापस आ जाएगा।

विफलता के प्रकार और उनसे संबंधित संदेश

हैंडशेक कभी पूरा नहीं होता। wg show में पीयर दिखाई देता है लेकिन उसमें कोई latest handshake नहीं होता, और क्लाइंट लॉग में यह दिखता है:

Handshake for peer 1 (10.0.0.10:51820) did not complete after 5 seconds, retrying (try 2)

कुछ भी प्राप्त नहीं हो रहा है, या कुछ भी स्वीकार नहीं किया जा रहा है। क्रमवार जाँचें: क्या VPS फायरवॉल पर और आपके प्रदाता के नेटवर्क फायरवॉल (जो अधिकांश पैनलों में एक अलग नियंत्रण होता है) पर UDP 51820 खुला है; क्या Endpoint पता और पोर्ट सही हैं; क्या कुंजियाँ (keys) आपस में बदल तो नहीं गई हैं। क्लाइंट के [Peer] ब्लॉक में मौजूद कुंजी सर्वर की पब्लिक कुंजी होनी चाहिए, और इसके विपरीत। प्राइवेट कुंजी या क्लाइंट की अपनी पब्लिक कुंजी पेस्ट करने पर ठीक यही समस्या आती है। सर्वर पर sudo tcpdump -ni any udp port 51820 यह दिखाता है कि पैकेट बिल्कुल भी आ रहे हैं या नहीं। कर्नेल मॉड्यूल डिफ़ॉल्ट रूप से कुछ भी लॉग नहीं करता है; WireGuard संदेश dmesg में तभी दिखाई देते हैं जब आप डायनामिक डिबग (echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control) सक्षम करते हैं। इसे चालू करने पर, कुंजी का मेल न खाना 'invalid-MAC drop' के रूप में दिखाई देता है।

हैंडशेक काम करता है, लेकिन इंटरनेट नहीं चलता। ping 10.8.0.1 सफल होता है लेकिन ping 1.1.1.1 टाइम आउट हो जाता है: इसका मतलब है कि फॉरवर्डिंग या NAT गायब है। जाँचें कि sysctl net.ipv4.ip_forward में 1 लिखा है या नहीं, फिर sudo nft list ruleset या sudo iptables -t nat -L POSTROUTING -n -v के साथ क्लाइंट के पिंग करने के दौरान काउंटर देखें। मैसक्वेरेड (masquerade) नियम पर शून्य पैकेट का मतलब है कि उसका 'egress interface' नाम गलत है; बिना किसी उत्तर के काउंटर का बढ़ना 'forward chain policy' की ओर इशारा करता है।

इंटरनेट काम करता है, लेकिन नाम (DNS) हल नहीं होते। ping 1.1.1.1 सफल होता है और curl https://example.com में Could not resolve host मिलता है। DNS लाइन गायब है, या इसमें ऐसा रिज़ॉल्वर दिया गया है जो टनल के अंदर से पहुंच योग्य नहीं है।

कुछ HTTPS साइटें हैंग हो जाती हैं। SSH और पिंग ठीक काम कर रहे हैं; बड़े पेज अटक जाते हैं। यह 'path MTU' की समस्या है: टनल ओवरहेड जोड़ती है, और बीच में कोई लिंक ICMP संदेश वापस भेजे बिना बड़े पैकेटों को ड्रॉप कर देता है। क्लाइंट के [Interface] में MTU को कम करें, पहले 1420, फिर 1380, और फिर 1280 आज़माएं। यदि MTU कम करने से अटकने की समस्या ठीक हो जाती है लेकिन थ्रूपुट अभी भी निराशाजनक है, तो अंदाज़ा लगाना बंद करें और bisection और TCP MSS clamping द्वारा वास्तविक path MTU खोजने की प्रक्रिया अपनाएं, जो उन कारणों को भी खारिज कर देती है जिनका टनल से कोई लेना-देना नहीं है।

इंटरफ़ेस शुरू होने से इनकार करता है। Address already in use का मतलब है कि किसी अन्य प्रक्रिया ने UDP 51820 को होल्ड कर रखा है। विफल up के बाद Cannot find device wg0 का मतलब आमतौर पर यह होता है कि कॉन्फ़िगरेशन को अस्वीकार कर दिया गया है; journalctl -u wg-quick@wg0 -n 50 पढ़ें।

Streisand या OpenVPN से माइग्रेशन

Streisand अब unmaintained है और इसकी repository को archive कर दिया गया है। abandoned automation पर VPN चलाना सुरक्षा के लिए एक गंभीर जोखिम है। इसका कोई in-place upgrade संभव नहीं है और OpenVPN का PKI इसमें काम नहीं करता है: WireGuard में न तो certificates होते हैं, न CA और न ही कोई expiry, इसलिए प्रत्येक client के लिए एक नया key pair बनाना आवश्यक है।

माइग्रेशन समानांतर (parallel) रूप से करें; UDP 51820 पर WireGuard और 1194 पर OpenVPN एक ही सर्वर पर साथ-साथ चल सकते हैं। wg0 को सेटअप करें, clients को एक-एक करके migrate करें और उसके बाद पुरानी service को बंद कर दें। OpenVPN का username/password और revocation model इसमें लागू नहीं होता है; यदि आपको accounts या audit trail की आवश्यकता है, तो उसे WireGuard के ऊपर एक layer के रूप में implement करें।

Backups, upgrades, और scale पर आने वाला दबाव

/etc/wireguard ही सर्वर है। इसका बैकअप लें (sudo tar czf wg-backup.tgz -C /etc wireguard, mode 600, सर्वर से बाहर रखें) और आप कुछ ही मिनटों में एक नए VPS पर इसे फिर से बना सकते हैं। यदि सर्वर की private key खो जाती है, तो प्रत्येक client configuration को फिर से जारी करना होगा, क्योंकि clients सर्वर की public key को pin करते हैं। Upgrades एक सामान्य apt upgrade प्रक्रिया है, जिसमें kernel updates के लिए reboot की आवश्यकता होती है, और यदि आपने इसे enable किया है, तो wg-quick@wg0 अपने आप वापस आ जाता है।

प्रति-peer state छोटा होता है और crypto kernel में चलता है, इसलिए इसकी सीमा इस config के बजाय आपके VPS की CPU और bandwidth क्षमता पर निर्भर करती है। इसे किसी प्रकाशित आंकड़े पर भरोसा करने के बजाय tunnel के माध्यम से iperf3 से मापें। Scale पर जो चीज दबाव डालती है, वह है operations। प्रत्येक peer को एक unique tunnel IP की आवश्यकता होती है, और साठ [Peer] blocks को हाथ से edit करने पर ही duplicate AllowedIPs आने की संभावना रहती है: configs को एक script से generate करें। एक सर्वर एक UDP endpoint और विफलता का एक बिंदु (point of failure) है, और WireGuard में कोई clustering नहीं है: redundancy का अर्थ है अपनी अलग keys वाला एक दूसरा सर्वर। Key rotation मैन्युअल ही रहता है, इसलिए लिख कर रखें कि किसके पास कौन सी key है और आप उसे revoke कैसे करेंगे। जब यह bookkeeping एक text file से बाहर हो जाए, तो सामान्य समाधान उसी kernel data plane के ऊपर एक control plane का उपयोग करना है, और एक self-hosted NetBird server उन address allocation, peer distribution और setup keys को संभालता है जिन्हें आप अन्यथा हाथ से कर रहे होते हैं। यदि उस control plane को खुद चलाना एक अतिरिक्त सर्वर जैसा लगता है, तो Tailscale आपके लिए इसे host करता है, और इसका free plan छह users को असीमित devices के साथ कवर करता है, जो कि अधिकांश व्यक्तिगत fleets के लिए पर्याप्त है। उस बिंदु के बाद शुल्क मशीनों के बजाय लोगों पर आधारित होता है, इसलिए एक household या छोटी टीम वास्तव में क्या भुगतान करती है यह इस पर निर्भर करता है कि कितने इंसानों के पास logins हैं, न कि इस पर कि आपने wg0.conf में कितने peers को हाथ से edit किया होता। उस तरफ, split-tunnel AllowedIPs bookkeeping एक subnet router से आपकी private ranges को advertise करने का रूप ले लेती है, जिसे एक VPS से एक बार announce किया जाता है और हर client file में paste करने के बजाय केंद्रीय रूप से approve किया जाता है। यह सौदा करने लायक है या नहीं, यह इस बात पर निर्भर करता है कि एक hosted control plane वास्तव में कहाँ तक पहुँच सकता है, और यह कभी भी उन keys को नहीं रखता जो आपके traffic को encrypt करती हैं, हालाँकि यह तय करता है कि कौन से peers एक-दूसरे के बारे में जानेंगे।

इन सबके लिए एक Linux box जिसे आप नियंत्रित करते हैं, एक public IP, एक ऐसा kernel जिसमें आप module load कर सकें, और एक firewall जिसे आप पूरी तरह से नियंत्रित करते हैं, की आवश्यकता होती है।

FAQ

WireGuard handshake पूरा क्यों नहीं होता है?

wg show में किसी peer को बिना latest handshake के सूचीबद्ध करने का अर्थ है कि पैकेट या तो पहुँच नहीं रहे हैं या स्वीकार नहीं किए जा रहे हैं। VPS फायरवॉल और आपके प्रदाता के अलग नेटवर्क फायरवॉल, दोनों पर UDP 51820 की जाँच करें, Endpoint होस्ट और पोर्ट की पुष्टि करें, और फिर सुनिश्चित करें कि कुंजियाँ (keys) गलत नहीं हैं; क्लाइंट के [Peer] ब्लॉक में सर्वर की public कुंजी होनी चाहिए। सर्वर पर sudo tcpdump -ni any udp port 51820 यह दिखाता है कि पैकेट पहुँच रहे हैं या नहीं; dmesg केवल डायनामिक डिबग (echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control) सक्षम करने के बाद ही WireGuard के हैंडशेक विफलताओं की रिपोर्ट करता है, जिसके बाद कुंजी बेमेल (key mismatch) होने पर इसे invalid-MAC ड्रॉप के रूप में देखा जा सकता है।

टनल कनेक्ट हो जाती है लेकिन इंटरनेट नहीं चलता। क्या कमी है?

ping 10.8.0.1 के काम करने के बावजूद ping 1.1.1.1 का टाइम-आउट होना फॉरवर्डिंग या NAT की समस्या की ओर इशारा करता है। पुष्टि करें कि sysctl net.ipv4.ip_forward में 1 लिखा है और यह /etc/sysctl.d/ में सेट है, न कि केवल किसी ऐसे sysctl -w के साथ जो रीबूट पर हट जाता है। फिर masquerade नियम की जाँच करें जो आपके वास्तविक egress इंटरफ़ेस को ip route show default, enp1s0 या ens3 से नाम देता है, जो शायद ही कभी eth0 हो।

क्या मुझे क्लाइंट कॉन्फ़िगरेशन में DNS = लाइन की आवश्यकता है?

पूर्ण टनल और बिना DNS = लाइन के, क्लाइंट स्थानीय नेटवर्क से प्राप्त रिज़ॉल्वर को ही बनाए रखता है, और वे क्वेरी स्थानीय लिंक पर स्पष्ट टेक्स्ट (cleartext) में बाहर जाती हैं जबकि बाकी सब कुछ टनल के माध्यम से जाता है। DNS को किसी पब्लिक रिज़ॉल्वर पर पॉइंट करें, या 10.8.0.1 पर बाइंड करके unbound/dnsmasq चलाएँ और इनपुट चेन में udp dport 53 iifname "wg0" को खोलें।

AllowedIPs वास्तव में क्या नियंत्रित करता है?

यह दो कार्य करता है। आउटबाउंड के लिए यह एक राउटिंग टेबल है: peer के AllowedIPs से मेल खाने वाला ट्रैफ़िक एन्क्रिप्ट होकर उस peer को भेजा जाता है। इनबाउंड के लिए यह एक एक्सेस-कंट्रोल लिस्ट है: एक डिक्रिप्ट किया गया पैकेट जिसका स्रोत उस peer के AllowedIPs के बाहर है, उसे ड्रॉप कर दिया जाता है। यही कारण है कि सर्वर साइड प्रत्येक क्लाइंट के लिए /32 सूचीबद्ध करता है जबकि क्लाइंट साइड 0.0.0.0/0 सूचीबद्ध कर सकता है।

क्या WireGuard किसी भी VPS पर चलेगा?

KVM VPS पर यह इन-कर्नेल मॉड्यूल के साथ बिना किसी अतिरिक्त सेटअप के काम करता है। कंटेनर वर्चुअलाइजेशन जो होस्ट कर्नेल साझा करते हैं, जैसे कि OpenVZ या LXC, पर modprobe wireguard विफल हो जाता है और Operation not supported एरर देता है; ऐसी स्थिति में विकल्प के तौर पर wireguard-go यूजरस्पेस इम्प्लीमेंटेशन का उपयोग किया जाता है। किसी भी अन्य चीज़ से पहले sudo modprobe wireguard && echo ok चलाकर देखें।