WireGuard Mesh से प्राइवेट VPS क्लस्टर बनाएँ

संक्षेप में: कई VPS को एक प्राइवेट क्लस्टर में बदलने के लिए हर VPS नोड को एक ही प्राइवेट subnet से पते वाला WireGuard इंटरफ़ेस दें, हर दूसरे नोड को उसके public `Endpoint` और `AllowedIPs` में एक `/32` के साथ `[Peer]` के रूप में जोड़ें, UDP 51820 सिर्फ़ अपने नोड्स से allow करें, और डेटाबेस व अंदरूनी सेवाओं को public IP की जगह `wg0` पते से bind करें। लगभग दस नोड्स तक इसे हाथ से या template से संभालना आसान है; उससे आगे ऐसे टूल्स इस्तेमाल करें जो configs बनाएँ और बाँटें।

यह गाइड मानती है कि आप WireGuard VPN गाइड की बुनियादी बातें जानते हैं और SSH hardening गाइड के अनुसार हर नोड पर SSH को harden कर चुके हैं; agent forwarding के बिना bastion के ज़रिए नोड्स तक पहुँचने के लिए देखें StrictModes और agent forwarding गाइड।

VPN नोड्स के लिए address प्लान

एक ऐसी प्राइवेट रेंज चुनें जो आपके किसी और इस्तेमाल (होम LAN, Docker, Kubernetes pod रेंज) से न टकराए। छोटे क्लस्टर के लिए `/24` काफ़ी है और पते पढ़ने में आसान रहते हैं। हर नोड को एक तय पता दें और प्लान को version control में रखें, क्योंकि हर config उसी से बनता है।

हर VPS नोड पर per-peer config

Full mesh में हर नोड सीधे हर दूसरे नोड से बात करता है, इसलिए हर config में एक `[Interface]` और N-1 `[Peer]` सेक्शन होते हैं। चार नोड्स का मतलब कुल छह टनल; दस नोड्स का मतलब 45। हर नोड के पास public IP है, इसलिए `PersistentKeepalive` की आमतौर पर ज़रूरत नहीं होती; विवरण keepalive और PresharedKey गाइड में है।

1. 01.हर नोड पर `apt install wireguard` चलाएँ, फिर `umask 077; wg genkey | tee /etc/wireguard/wg0.key | wg pubkey > /etc/wireguard/wg0.pub`।
2. 02.सभी public keys और address प्लान एक जगह इकट्ठा करें।
3. 03.चाहें तो post-quantum बचाव के लिए हर नोड जोड़ी के लिए एक `wg genpsk` key बनाएँ।
4. 04.हर नोड पर नीचे दिखाए अनुसार `/etc/wireguard/wg0.conf` लिखें।
5. 05.`systemctl enable --now wg-quick@wg0` चलाएँ और `wg show` में हर peer के साथ हाल का handshake जाँचें।

# /etc/wireguard/wg0.conf on node1
[Interface]
Address = 10.88.0.1/24
ListenPort = 51820
PrivateKey = <node1 private key>

[Peer]
# node2
PublicKey = <node2 public key>
Endpoint = 203.0.113.12:51820
AllowedIPs = 10.88.0.2/32

[Peer]
# node3
PublicKey = <node3 public key>
Endpoint = 203.0.113.13:51820
AllowedIPs = 10.88.0.3/32

[Peer]
# node4
PublicKey = <node4 public key>
Endpoint = 203.0.113.14:51820
AllowedIPs = 10.88.0.4/32

Mesh में AllowedIPs कैसे काम करता है

`AllowedIPs` एक साथ दो काम करता है। बाहर जाते समय यह routing table है: `10.88.0.3` के पैकेट उस peer को जाते हैं जिसकी सूची में `10.88.0.3/32` है। अंदर आते समय यह access list है: उस peer से आया पैकेट तभी स्वीकार होता है जब उसका source पता उस peer के `AllowedIPs` के अंदर हो। इसीलिए हर peer को ठीक अपना `/32` मिलता है, पूरा `/24` नहीं।

`Address` लाइन पर `/24` सिर्फ़ `wg0` पर subnet के लिए kernel route बनाता है; इसके बाद WireGuard हर destination के लिए सही peer चुनता है।

• ▹एक ही इंटरफ़ेस पर दो peers की `AllowedIPs` रेंज कभी overlap नहीं होनी चाहिए; आखिरी वाली जीतती है।
• ▹अगर कोई नोड एक प्राइवेट subnet भी route करता है (जैसे node3 पर Docker), तो बाकी नोड्स पर node3 के `AllowedIPs` में वह subnet जोड़ें।
• ▹Mesh peer में `0.0.0.0/0` तभी डालें जब आप सच में चाहते हों कि सारा ट्रैफ़िक उसी नोड से बाहर जाए।

Firewall: टनल तक सिर्फ़ आपके नोड्स पहुँचें

WireGuard unauthenticated पैकेटों का जवाब नहीं देता, फिर भी UDP 51820 को ज्ञात नोड IPs तक सीमित करने से शोर घटता है। टनल के अंदर सिर्फ़ वही पोर्ट खोलें जो हर सेवा को चाहिए। Debian 12/13 और Ubuntu 24.04 के लिए यह nftables उदाहरण `/etc/nftables.conf` में जाता है; इसे `nft -f /etc/nftables.conf` से लोड करें और `nftables.service` चालू करें। टेस्ट करते समय एक SSH सेशन खुला रखें।

table inet filter {
  set mesh_peers {
    type ipv4_addr
    elements = { 203.0.113.11, 203.0.113.12, 203.0.113.13, 203.0.113.14 }
  }
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif lo accept
    meta l4proto { icmp, ipv6-icmp } accept
    tcp dport 22 accept
    udp dport 51820 ip saddr @mesh_peers accept
    iifname "wg0" ip saddr 10.88.0.0/24 tcp dport { 5432, 6379, 9100 } accept
  }
}

सेवाओं को wg इंटरफ़ेस से bind करें

Firewall एक परत है; दूसरी परत है public पते पर बिल्कुल listen न करना। अंदरूनी सेवाओं को नोड के `wg0` पते से bind करें ताकि firewall की कोई गलती उन्हें उजागर न करे। चूँकि सेवा के bind होने से पहले `wg0` मौजूद होना चाहिए, units को systemd drop-in से क्रम में लगाएँ, या `net.ipv4.ip_nonlocal_bind = 1` से उन पतों पर bind की अनुमति दें जो अभी up नहीं हैं।

# PostgreSQL on node3: postgresql.conf
listen_addresses = '10.88.0.3'
# pg_hba.conf
host  all  all  10.88.0.0/24  scram-sha-256

# Redis: /etc/redis/redis.conf
bind 10.88.0.3

# systemctl edit postgresql  (repeat for other services)
[Unit]
[email protected]
[email protected]

Note · नतीजा `ss -tlnp` से जाँचें: अंदरूनी सेवाओं में `10.88.0.x` दिखना चाहिए, कभी `0.0.0.0` या public IP नहीं।

स्केलिंग: टूल्स पर कब जाएँ

हाथ से लिखा mesh तब तक ठीक है जब तक नोड्स कम हों और बदलाव कभी-कभार हों। हर नया नोड मतलब हर मौजूदा config को एडिट करना, इसलिए काम quadratic रूप से बढ़ता है। जब यह बोझ बन जाए, तो configs लिखने के बजाय generate करें।

NoctisNode पर सभी नए VPS नोड्स FI-1 (फ़िनलैंड) में डिप्लॉय होते हैं, हर एक dedicated IPv4 और unmetered 1 Gbps पोर्ट के साथ, और hourly billing व agent API (auto-destroy TTL के साथ) टेस्ट नोड्स जोड़ना और हटाना सस्ता बनाते हैं। प्लान Wisp tier से शुरू होते हैं; देखें VPS प्लान।

अक्सर पूछे जाने वाले सवाल