SSD Nodes Learn Hosting plans →
गाइड Matt Connorलेखक: Matt Connor

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

अपने Linux VPS पर WireGuard VPN सेटअप करने का पूरा तरीका जानें। इसमें key generation, wg0.conf कॉन्फ़िगरेशन, IP forwarding, NAT नियम और handshake जैसी आम समस्याओं का समाधान शामिल है।

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

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

WireGuard कर्नल में एक लेयर 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) को लीक किए बिना जनरेट करें

यदि /etc/wireguard/server.key सभी के लिए पढ़ने योग्य (world-readable) है, तो यह VPN न होने के बराबर है। सामान्य umask 077 && wg genkey | sudo tee ... लाइन काम करती है: जब तक sudoers में umask_override सेट न हो, जो डिफ़ॉल्ट रूप से बंद रहता है, sudo आपके umask को अपने डिफ़ॉल्ट 0022 के साथ मिलाता है और इसे कभी कम नहीं करता, इसलिए tee द्वारा बनाई गई फ़ाइल का मोड 600 होता है। कुंजियाँ तब लीक होती हैं जब आप उस पाइप को umask 077 के बिना, सामान्य 022 umask के तहत, या ऐसे सर्वर पर चलाते हैं जहाँ sudoers में umask_override चालू हो। मोड को स्पष्ट रूप से सेट करें, फिर इससे कोई फर्क नहीं पड़ता।

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

क्लाइंट पेयर को भी उसी तरह जनरेट करें। wg genpsk एक वैकल्पिक प्री-शेयर्ड की (pre-shared key) जोड़ता है, जो प्रत्येक कॉन्फ़िगरेशन में एक लाइन होती है।

सर्वर इंटरफ़ेस: /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 इसे; स्टार्टअप पर यह चेतावनी कि फ़ाइल वर्ल्ड-एक्सेसिबल है, का मतलब है कि आपने इसे छोड़ दिया है। Address टनल के अंदर सर्वर का पता है, जो पूरे VPN सबनेट का मास्क रखता है। ऐसी रेंज चुनें जो आपको सामान्य नेटवर्क में न मिले, 192.168.1.0/24 उन आधे होम राउटर्स के साथ टकराता है जिनके पीछे आपके क्लाइंट्स होते हैं, और फिर टनल चुपचाप लोकल रूट से हार जाती है।

सर्वर साइड पर एक पीयर का AllowedIPs एक /32 होता है, जो वह एकमात्र टनल एड्रेस है जिसका वह क्लाइंट मालिक है। यदि आप दो पीयर्स को एक ही अलाउड 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: पोर्ट और फॉरवर्ड पाथ

एक 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 सेशन खुला रखें: policy drop और SSH नियम में एक टाइपो आपको अपने ही सर्वर से बाहर कर सकता है। ध्यान दें कि forward chain क्या अनुमति नहीं देती है, wg0 से wg0 तक। Peers इंटरनेट तक पहुँच सकते हैं, एक-दूसरे तक नहीं; peer-to-peer VPN के लिए iifname "wg0" oifname "wg0" accept जोड़ें। एक peer सर्वर पर क्या एक्सेस कर सकता है, यह इस chain का काम नहीं है: सर्वर को संबोधित packets input hook से गुजरते हैं, forward से नहीं, इसलिए input chain निर्णय लेती है, और जैसा कि लिखा गया है, यह एक peer को केवल SSH तक पहुँचने देती है और कुछ नहीं, यहाँ तक कि 10.8.0.1 पर ping भी नहीं। वहाँ iifname "wg0" icmp type echo-request accept जोड़ें, साथ ही प्रत्येक ऐसी service के लिए एक iifname "wg0" नियम जोड़ें जिसे आप केवल tunnel के माध्यम से ही सुलभ बनाना चाहते हैं, जो तब महत्वपूर्ण होता है जब सर्वर एक tmux में Claude Code चलाने वाले रिमोट डेवलपमेंट बॉक्स के रूप में कार्य करता है और आप उस हिस्से को सार्वजनिक रूप से expose नहीं करना चाहते हैं।

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

##
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) इंटरफ़ेस नाम गलत है; बिना किसी उत्तर के काउंटर का बढ़ना फॉरवर्ड चेन पॉलिसी की ओर इशारा करता है।

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

कुछ HTTPS साइटें हैंग हो जाती हैं। SSH और पिंग ठीक काम कर रहे हैं; बड़े पेज अटक जाते हैं। यह पाथ MTU की समस्या है: टनल ओवरहेड जोड़ता है, और बीच में कोई लिंक ICMP संदेश वापस आए बिना बड़े पैकेट को ड्रॉप कर देता है। क्लाइंट के [Interface] में MTU सेट करें। सामान्य 1500-बाइट लिंक पर wg-quick पहले से ही 1420 (1500 में से 80 बाइट का ओवरहेड घटाकर) चुनता है, इसलिए 1420 लिखने से कुछ नहीं बदलेगा: 1380 आज़माएँ, फिर 1280। यदि MTU कम करने से समस्या ठीक हो जाती है लेकिन थ्रूपुट अभी भी कम है, तो अंदाज़ा लगाना बंद करें और बाइसेक्शन और TCP MSS क्लैम्पिंग द्वारा वास्तविक पाथ 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 करें।

बैकअप, अपग्रेड और स्केल पर दबाव

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

प्रति-peer state छोटा होता है और crypto kernel में चलता है, इसलिए सीमा आपके VPS की CPU और bandwidth है, न कि इस config में कुछ। इसे प्रकाशित आंकड़ों पर भरोसा करने के बजाय tunnel के माध्यम से iperf3 के साथ मापें। स्केल पर जो चीज दबाव डालती है, वह है ऑपरेशन्स। प्रत्येक peer को एक unique tunnel IP की आवश्यकता होती है, और साठ [Peer] ब्लॉक्स को मैन्युअल रूप से एडिट करने से ही डुप्लिकेट AllowedIPs की समस्या आती है: configs को स्क्रिप्ट से जनरेट करें। एक सर्वर एक UDP endpoint और विफलता का एक बिंदु है, और WireGuard में कोई clustering नहीं है: रिडंडेंसी का मतलब है अपनी अलग keys वाला एक दूसरा सर्वर। Key rotation मैन्युअल रहता है, इसलिए लिखें कि किसके पास कौन सी key है और आप उसे कैसे revoke करते हैं। एक बार जब यह बुककीपिंग एक टेक्स्ट फ़ाइल से बड़ी हो जाए, तो सामान्य समाधान उसी kernel data plane के ऊपर एक control plane का उपयोग करना है, और एक self-hosted NetBird सर्वर address allocation, peer distribution और setup keys को संभालता है जिन्हें आप अन्यथा हाथ से कर रहे होते हैं। यदि उस control plane को खुद चलाना एक अतिरिक्त बोझ है, तो Tailscale आपके लिए इसे होस्ट करता है, और इसका मुफ्त Personal प्लान छह उपयोगकर्ताओं को असीमित डिवाइस और शुरुआत के लिए 50 टैग किए गए संसाधनों जैसे सर्वर के साथ कवर करता है, जो अधिकांश व्यक्तिगत बेड़े के लिए पर्याप्त है। उस बिंदु के बाद शुल्क मशीनों के बजाय लोगों पर लगता है, इसलिए एक परिवार या छोटी टीम वास्तव में क्या भुगतान करती है यह इस पर निर्भर करता है कि कितने इंसानों के पास लॉगिन हैं, न कि इस पर कि आपने कितने peers को हाथ से wg0.conf में एडिट किया है। उस तरफ, split-tunnel AllowedIPs बुककीपिंग एक subnet router से अपनी private ranges को advertise करने में बदल जाती है, जिसे एक VPS से घोषित किया जाता है और हर client फ़ाइल में पेस्ट करने के बजाय केंद्रीय रूप से अनुमोदित किया जाता है। क्या यह बदलाव करने लायक है, यह इस बात पर निर्भर करता है कि एक होस्ट किया गया control plane वास्तव में क्या एक्सेस कर सकता है, और यह कभी भी उन keys को नहीं रखता जो आपके ट्रैफ़िक को एन्क्रिप्ट करती हैं, हालाँकि यह तय करता है कि कौन से peers एक-दूसरे के बारे में जानते हैं।

इन सबके लिए एक Linux बॉक्स जिसे आप नियंत्रित करते हैं, एक public IP, एक kernel जिसमें आप मॉड्यूल लोड कर सकते हैं, और एक फ़ायरवॉल जिसे आप पूरी तरह से नियंत्रित करते हैं, की आवश्यकता होती है।

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 चलाकर देखें।

#wireguard#vpn#linux-networking#nftables#systemd#सेल्फ़-होस्टिंग