VPS वर WireGuard VPN कसे सेट करायचे?

तुम्ही काय तयार करत आहात

तुमच्या स्वतःच्या सर्व्हरवर WireGuard VPN तयार करण्यासाठी साधारणपणे चाळीस ओळींची कॉन्फिगरेशन लागते: एक key pair, एक interface file, एक sysctl, एक NAT rule आणि एक firewall hole. याची इन्स्टॉलेशन प्रक्रिया अत्यंत सोपी आहे, म्हणून या मार्गदर्शकाचा बराचसा भाग तांत्रिक त्रुटींवर आधारित आहे — जसे की key permissions, AllowedIPs, forwarding आणि DNS.

WireGuard हा kernel मधील Layer 3 tunnel आहे. Linux 5.6 पासून हे mainline मध्ये आहे, त्यामुळे Ubuntu 24.04 आणि Debian 13 मध्ये कोणतेही external module न वापरता ते उपलब्ध असते. यामध्ये cipher negotiation, certificate authority किंवा username/password ची आवश्यकता नसते: एक peer म्हणजे एक public key आणि त्या key द्वारे वापरले जाऊ शकणारे IP addresses होय. जर एखादा packet MAC check मध्ये फेल झाला, तर कोणताही reply न देता तो drop केला जातो, त्यामुळे port स्कॅन्सना प्रतिसाद देत नाही. याचा दुसरा परिणाम असा की: कोणताही auth server अस्तित्वात नसतो, त्यामुळे कोणाची प्रवेशाची सुविधा (access) काढून टाकण्यासाठी त्या मशीनवरील peer डिलीट करणे आवश्यक असते.

प्रथम व्हर्च्युअलायझेशन तपासा

WireGuard साठी मॉड्यूल लोड करता येईल असे kernel आवश्यक आहे. KVM VPS वर हे थेट (out of the box) काम करते. OpenVZ किंवा LXC सारख्या container virtualisation मध्ये host kernel शेअर केले जाते. अशा वेळी पहिली command RTNETLINK answers: Operation not supported मुळे fail होते. अशा वेळी fallback म्हणून wireguard-go userspace implementation वापरले जाते. प्रथम sudo modprobe wireguard && echo ok वापरून तपासा.

कीज (keys) लीक न होता तशा तयार करा

ज्या /etc/wireguard/server.key ला जगभरातील कोणीही वाचू शकते, त्याचा अर्थ असा आहे की VPN अजिबात वापरत नाही. सामान्य umask 077 && wg genkey | sudo tee ... ओळ विश्वासार्ह नाही, कारण sudo फाईल tee तयार करताना स्वतःचा umask लागू करते. मोड (mode) स्पष्टपणे सेट करा.

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) देखील त्याच पद्धतीने तयार करा. wg genpsk एक वैकल्पिक pre-shared key जोडते, जी प्रत्येक config मध्ये एक ओळ असते.

The server interface: /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 it; जर फाईल सर्व वापरकर्त्यांसाठी (world accessible) खुली असेल, तर तुम्हाला स्टार्टअप वॉर्निंग (startup warning) मिळेल. Address हा टनेल मधील सर्व VPN सबनेटचा पत्ता आहे. असा रेंज निवडा जो इतर नेटवर्कमध्ये वापरला जात नाही — 192.168.1.0/24 मुळे क्लायंटच्या होम राउटरशी कॉन्फ्लिक्ट होऊ शकते, ज्यामुळे टनेल स्थानिक राउटला (local route) हरते.

server बाजूवरील peer चा AllowedIPs हा /32 असतो, जो त्या क्लायंटचा एकमेव टनेल पत्ता असतो. जर दोन peers ला एकच allowed IP दिला, तर तो शेवटच्या कॉन्फिगर केलेल्या peer कडे वळतो आणि पहिला peer कोणताही एरर न दाखवता ट्रॅफिक मिळवणे थांबवतो. SaveConfig unset ठेवा, अन्यथा wg-quick down सध्याच्या स्थितीनुसार (live state) ही फाईल पुन्हा लिहिते.

बॉक्सला राउटरमध्ये रूपांतरित करा

Linux सर्व्हर स्वतःला संबोधित न केलेले पॅकेट्स ड्रॉप करतो. डीफॉल्टनुसार 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 पुढील रीबूटपर्यंत काम करतो आणि त्यानंतर काम करणे थांबवतो. NAT साठी egress इंटरफेस आवश्यक आहे — म्हणजेच इंटरनेटशी जोडलेला NIC, wg0 नाही. eth0 असे गृहीत धरू नका; तुमचा इंटरफेस ip route show default मधून मिळवा, कारण सध्याच्या इमेजेसमध्ये enp1s0 किंवा ens3 सारखी नावे वापरली जातात.

Firewall: port आणि forward path

एक nftables फाईल filter आणि NAT दोन्ही हाताळते. /etc/nftables.conf लिहा — यामुळे सध्याचा ruleset flush होतो. जर तुमचा box आधीच 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
  }
}

दुसरी SSH session उघडी ठेवून sudo systemctl enable --now nftables वापरून हे लागू करा: policy drop आणि SSH rule मध्ये झालेली चूक तुम्हाला तुमच्या स्वतःच्या server मधून बाहेर (lock out) काढू शकते. forward chain काय परवानगी देत नाही ते तपासा — wg0 ते wg0. Peers इंटरनेटशी कनेक्ट होऊ शकतात, पण एकमेकांशी नाही; peer-to-peer VPN साठी iifname "wg0" oifname "wg0" accept जोडा. हीच chain peer ला server वर काय प्रवेश द्यायचा हे ठरवते. जेव्हा box चा वापर tmux मध्ये Claude Code चालवणारा remote development box म्हणून केला जातो, तेव्हा ही गोष्ट महत्त्वाची ठरते, कारण तुम्हाला तो भाग सार्वजनिकरित्या (publicly) उघड करायचा नसेल.

ufw box वर: ufw allow 51820/udp, /etc/default/ufw मध्ये DEFAULT_FORWARD_POLICY="ACCEPT", आणि /etc/ufw/before.rules च्या सुरुवातीला एक *nat POSTROUTING MASQUERADE rule.

Bring it up under systemd

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

wg-quick इंटरफेस तयार करते, ॲड्रेस जोडते आणि AllowedIPs मधून प्राप्त केलेले रूट्स इन्स्टॉल करते. enable --now हा महत्त्वाचा भाग आहे: पुढच्या रीबूटनंतर मॅन्युअलरित्या चालवलेला wg-quick up wg0 निघून जातो, आणि kernel upgrades मुळे रीबूट करणे आवश्यक ठरते.

क्लायंट कॉन्फिगरेशन आणि सर्वांकडून होणारी सामान्य चूक

[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 वापरताना बहुतेक चुका होतात.

Outbound साठी हे एक routing table आहे. ज्या पॅकेटचे destination एखाद्या peer च्या AllowedIPs शी मॅच होते, ते पॅकेट एन्क्रिप्ट केले जाते आणि त्या peer कडे पाठवले जाते. 0.0.0.0/0, ::/0 सर्व ट्रॅफिक टनेलद्वारे पाठवते — म्हणजेच सर्व ट्रॅफिकसाठी सर्व्हरला default route म्हणून वापरते. Split tunnel ही एक मर्यादित यादी असते: AllowedIPs = 10.8.0.0/24, 10.20.0.0/16 मध्ये VPN ट्रॅफिक आणि सर्व्हरच्या मागे असलेले एक खाजगी नेटवर्क असते, तर इतर सर्व ट्रॅफिक त्यांच्या स्थानिक (local) मार्गावरून जाते. या मर्यादित यादीमुळेच तुम्ही काही सेवा पूर्णपणे सार्वजनिक इंटरनेटपासून वेगळ्या ठेवू शकता — उदाहरणार्थ, टनेल ॲड्रेसशी जोडलेले VPS वरील private Nextcloud instance किंवा त्याच मशीनवर चालणारे nested-virtualisation lab VMs, हे peers साठी उपलब्ध राहतात आणि इतरांना दिसत नाहीत.

Inbound साठी हे एक access-control list आहे. ज्या peer कडून आलेले decrypted पॅकेट त्याच्या peer च्या AllowedIPs मध्ये समाविष्ट नाही, ते पॅकेट ड्रॉप केले जाते. म्हणूनच सर्व्हरवर लॅपटॉपसाठी 10.8.0.2/32 ची यादी असते: तिथे 0.0.0.0/0 असल्यास, तो क्लायंट टनेल मधील कोणताही ॲड्रेस spoof करू शकतो.

PersistentKeepalive हे NAT च्या मागे असलेल्या क्लायंटसाठी असते, जिथे राउटर फक्त पॅकेट्स फ्लो होत असतानाच UDP mapping उघडे ठेवतो. जेव्हा हे संपते, तेव्हा सर्व्हर क्लायंटपर्यंत पोहोचू शकत नाही. PersistentKeepalive = 25 हे mapping उघडे ठेवते — हे क्लायंटवर सेट करा, पब्लिक IP असलेल्या सर्व्हरवर नाही.

DNS, आणि कोणाचेही लक्ष न जाणवणारी गळती (leak)

AllowedIPs = 0.0.0.0/0 आणि कोणतीही DNS = ओळ नसल्यास, क्लायंट स्थानिक नेटवर्कमधून (local network) मिळालेला resolver वापरत राहतो — म्हणजेच 192.168.1.1 वरील कॅफे राउटर. हा मार्ग (route) default route पेक्षा अधिक विशिष्ट (specific) असल्याने, इतर सर्व ट्रॅफिक tunnel मधून गेल्यामुळे DNS queries स्थानिक लिंकवरून cleartext मध्ये बाहेर जातात. ट्रॅफिक खाजगी असते; परंतु नावांची यादी (list of names) नसते.

दोन प्रामाणिक पर्याय उपलब्ध आहेत. DNS ला public resolver (DNS = 9.9.9.9) कडे निर्देशित करा आणि queries tunnel मधून तुमच्या सर्व्हरवरून बाहेर जातील, जरी तो resolver त्या queries पाहू शकतो. किंवा 10.8.0.1 ला bind केलेली unbound किंवा dnsmasq चालवा, DNS = 10.8.0.1 सेट करा, आणि input chain मध्ये udp dport 53 iifname "wg0" accept जोडा — ही ओळ सेट केल्यास resolver ची चिंता करण्याची गरज नाही, परंतु काहीही resolve होणार नाही.

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

Tunnel न ड्रॉप न करता peers जोडणे आणि काढून टाकणे

वापरकर्ता जोडण्यासाठी interface रीस्टार्ट केल्यास सर्व कनेक्टेड युजर्स डिस्कनेक्ट होतात. wg0.conf मध्ये [Peer] ब्लॉक ॲड करा आणि त्यानंतर peer set रीलोड करा.

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

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

Failure modes, with the strings you will see

Handshake never completes. wg show मध्ये peer मध्ये latest handshake नाही असे दिसते, आणि client logs मध्ये खालीलप्रमाणे येते:

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

काहीही प्राप्त होत नाहीये किंवा काहीही स्वीकारले जात नाहीये. क्रमाने तपासा: VPS firewall आणि तुमच्या provider च्या network firewall (जे बहुतेक panels मध्ये वेगळे असते) दोन्हीवर UDP 51820 open आहे का; Endpoint address आणि port बरोबर आहे का; आणि keys एकमेकांना जोडल्या आहेत का. client च्या [Peer] block मधील key ही server ची public key असणे आवश्यक आहे आणि याउलट; private key किंवा client ची स्वतःची public key paste केल्यास हीच समस्या येते. server वरील sudo tcpdump -ni any udp port 51820 मुळे packets येत आहेत की नाही हे समजते. kernel module default मध्ये काहीही log करत नाही; WireGuard messages dmesg मध्ये तेव्हाच दिसतात जेव्हा तुम्ही dynamic debug (echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control) सक्षम करता; आणि ते सुरू असताना, key mismatch मुळे invalid-MAC drop असा error येतो.

Handshake works, no internet. ping 10.8.0.1 यशस्वी होते पण ping 1.1.1.1 मध्ये timeout होतो: forwarding किंवा NAT गहाळ आहे. sysctl net.ipv4.ip_forward मध्ये 1 वाचून पहा, आणि client कडून ping करताना sudo nft list ruleset किंवा sudo iptables -t nat -L POSTROUTING -n -v वापरून counters तपासा. masquerade rule मध्ये zero packets दिसणे म्हणजे egress interface name चुकीचे आहे; counter वाढत असून replies न मिळणे म्हणजे forward chain policy मध्ये समस्या आहे.

Internet works, names do not. ping 1.1.1.1 यशस्वी होते आणि curl https://example.com मध्ये Could not resolve host मिळते. DNS line गहाळ आहे, किंवा त्यात असा resolver आहे जो tunnel मधून पोहोचू शकत नाही.

Some HTTPS sites hang. SSH आणि ping व्यवस्थित चालतात; परंतु मोठी pages stall होतात. हे path MTU मुळे होते: tunnel मुळे overhead वाढतो, आणि मधील एखादा link oversized packets ICMP message पाठवल्याशिवाय drop करतो. client वरील [Interface] मध्ये MTU कमी करा — 1420 वापरून पहा, त्यानंतर 1380, आणि नंतर 1280.

Interface refuses to start. Address already in use चा अर्थ असा आहे की दुसरी एखादी process UDP 51820 वापरत आहे. up अयशस्वी झाल्यानंतर Cannot find device wg0 येणे म्हणजे सहसा config reject झाले आहे; journalctl -u wg-quick@wg0 -n 50 तपासा.

Streisand किंवा OpenVPN कडून स्थलांतरित होणे

Streisand आता मेंटेन केले जात नाही आणि त्याचे repository archive केले आहे. Abandoned automation वर VPN चालवणे ही भविष्यात येणारी एक मोठी सुरक्षा समस्या आहे. यामध्ये in-place upgrade करण्याची सुविधा नाही. तसेच OpenVPN चे PKI रूपांतरित होऊ शकत नाही: WireGuard मध्ये certificates, CA किंवा expiry नसते, त्यामुळे प्रत्येक client ला नवीन key pair मिळतो.

Parallel migration करा — एकाच machine वर UDP 51820 वर WireGuard आणि 1194 वर OpenVPN दोन्ही एकत्र चालू शकतात. wg0 स्थापित करा, एक वेळी एक client स्थलांतरित करा आणि त्यानंतर जुनी service थांबवा. OpenVPN चे username/password आणि revocation model स्थलांतरित होत नाही; जर तुम्हाला accounts किंवा audit trail ची आवश्यकता असेल, तर ते WireGuard च्या वर एक layer म्हणून वापरा.

Backups, upgrades, and what strains at scale

/etc/wireguard हा सर्व्हर आहे. याचा बॅकअप घ्या (sudo tar czf wg-backup.tgz -C /etc wireguard, mode 600, मूळ मशीनच्या बाहेर ठेवा) आणि तुम्ही काही मिनिटांत नवीन VPS वर सर्व्हर पुन्हा तयार करू शकता. जर सर्व्हरची private key हरवली, तर प्रत्येक क्लायंट कॉन्फिगरेशन पुन्हा जारी करावे लागेल, कारण क्लायंट सर्व्हरची public key वापरतात. Upgrades ही एक सामान्य apt upgrade प्रक्रिया आहे आणि kernel updates साठी reboot आवश्यक आहे; जर तुम्ही wg-quick@wg0 सक्षम केले असेल, तर ते आपोआप सुरू होते.

प्रत्येक peer ची state लहान असते आणि crypto kernel मध्ये चालते. त्यामुळे मर्यादा या config मधील गोष्टींपेक्षा तुमच्या VPS चे CPU आणि bandwidth allowance वर अवलंबून असते — प्रकाशित आकड्यांवर विश्वास ठेवण्याऐवजी, tunnel मध्ये iperf3 वापरून त्याचे मोजमाप करा. मोठ्या प्रमाणावर (scale) काम करताना operational tasks कठीण होतात. प्रत्येक peer ला एक युनिक tunnel IP आवश्यक असतो. साठ (sixty) [Peer] blocks मॅन्युअली एडिट केल्यामुळे AllowedIPs सारख्या त्रुटी येऊ शकतात: कॉन्फिग्स स्क्रिप्टद्वारे तयार करा. एक सर्व्हर म्हणजे एक UDP endpoint आणि एक point of failure आहे. WireGuard मध्ये clustering नाही; redundancy साठी स्वतःच्या keys असलेला दुसरा सर्व्हर आवश्यक आहे. Key rotation मॅन्युअलच राहते, म्हणून कोणाकडे कोणती key आहे आणि एखादी key रद्द (revoke) कशी करायची याची नोंद ठेवा.

या सर्वांसाठी तुमच्या नियंत्रणाखालील Linux box आवश्यक आहे — public IP, module लोड करता येईल असे kernel, आणि पूर्णपणे तुमच्या नियंत्रणाखालील firewall.

FAQ

WireGuard handshake पूर्ण का होत नाही?

wg show मध्ये जर latest handshake नसेल, तर याचा अर्थ पॅकेट्स येत नाहीत किंवा स्वीकारले जात नाहीत. VPS firewall आणि तुमच्या provider च्या नेटवर्क firewall वर UDP 51820 तपासा. Endpoint host आणि port तपासा. तसेच, keys चुकीच्या नाहीत याची खात्री करा — client च्या [Peer] ब्लॉक मध्ये server ची public key असणे आवश्यक आहे. Server वरील sudo tcpdump -ni any udp port 51820 मुळे पॅकेट्स येत आहेत की नाही हे समजते; dmesg फक्त WireGuard च्या handshake failures दर्शवते, त्यासाठी तुम्हाला dynamic debug (echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control) सक्षम करावे लागेल. त्यानंतर, key mismatch असल्यास invalid-MAC drop म्हणून तो दिसून येतो.

टनेल कनेक्ट होते पण इंटरनेट चालत नाहीये. काय कमी आहे?

ping 10.8.0.1 कार्यरत आहे पण ping 1.1.1.1 मध्ये timeout होत असेल, तर हे forwarding किंवा NAT मुळे असू शकते. sysctl net.ipv4.ip_forward मध्ये 1 आहे आणि ते /etc/sysctl.d/ मध्ये सेट केले आहे याची खात्री करा. ते केवळ sysctl -w द्वारे नसावे, कारण reboot नंतर ते निघून जाते. त्यानंतर, masquerade rule मध्ये तुमच्या ip route show default मधील egress interface चे नाव तपासा — enp1s0 किंवा ens3, क्वचित प्रसंगी eth0 असते.

माझ्या client config मध्ये DNS = ओळ आवश्यक आहे का?

जर full tunnel वापरत असाल आणि DNS = ओळ नसेल, तर client स्थानिक नेटवर्कमधून मिळालेला resolver वापरतो. यामुळे इतर सर्व ट्रॅफिक टनेल मधून जाते, परंतु DNS queries स्थानिक लिंकवरून cleartext मध्ये जातात. DNS सार्वजनिक resolver कडे निर्देशित करा, किंवा 10.8.0.1 ला बांधलेले unbound/dnsmasq चालवा आणि input chain मध्ये udp dport 53 iifname "wg0" उघडा.

AllowedIPs नेमके काय नियंत्रित करते?

हे दोन कामे करते. Outbound साठी हे routing table आहे: peer च्या AllowedIPs शी मॅच होणारा ट्रॅफिक एन्क्रिप्ट केला जातो आणि त्या peer कडे पाठवला जातो. Inbound साठी हे access-control list आहे: ज्या decrypted packet चा source त्या peer च्या AllowedIPs च्या बाहेर आहे, तो packet drop केला जातो. म्हणूनच server बाजूला प्रत्येक client साठी /32 असते, तर client बाजूला 0.0.0.0/0 असू शकते.

WireGuard कोणत्याही VPS वर चालेल का?

KVM VPS वर हे in-kernel module सह कोणत्याही अतिरिक्त सेटअपशिवाय चालते. OpenVZ किंवा LXC सारख्या container virtualisation मध्ये, जे host kernel शेअर करतात, तिथे modprobe wireguard Operation not supported सह fail होते आणि fallback म्हणून wireguard-go userspace implementation वापरावे लागते. इतर काही करण्यापूर्वी sudo modprobe wireguard && echo ok चालवून पहा.