SSD Nodes Learn Hosting plans →
கல்வி வழிகாட்டிகள் Matt Connorஆல் Matt Connor · புதுப்பிக்கப்பட்டது 2026-10-07

VPS-ல் சொந்தமாக WireGuard VPN அமைப்பது எப்படி?

Linux VPS-ல் WireGuard VPN நிறுவும் முறை, key generation, wg0.conf கட்டமைப்பு, IP forwarding மற்றும் NAT விதிகளை விளக்குகிறோம். Handshake தோல்விகளைத் தவிர்க்கும் நுணுக்கங்கள் இங்கே.

நீங்கள் உருவாக்குவது என்ன

நீங்கள் சொந்தமாக வைத்திருக்கும் server-ல் ஒரு WireGuard VPN அமைப்பது சுமார் நாற்பது வரிகள் கொண்ட configuration ஆகும்: ஒரு 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-ல் தோல்வியுற்றால், அது எந்த பதிலும் இன்றி நிராகரிக்கப்படும், எனவே அந்த port எந்தவிதமான scans-க்கும் பதிலளிக்காது. இதன் மறுபக்கம்: இதில் auth server கிடையாது, எனவே ஒருவருக்கான அணுகலை நீக்க வேண்டுமெனில், அந்த box-லிருந்து அந்த peer-ஐ நீக்க வேண்டும்.

முதலில் virtualisation-ஐச் சரிபார்க்கவும்

WireGuard இயங்க kernel module-ஐ ஏற்றும் வசதி தேவை. KVM VPS-ல் இது இயல்பாகவே செயல்படும். Host kernel-ஐப் பகிரும் container virtualisation தொழில்நுட்பங்களான OpenVZ மற்றும் LXC ஆகியவற்றில், முதல் கட்டளை RTNETLINK answers: Operation not supported பிழையுடன் தோல்வியடையும். அத்தகைய சூழலில் wireguard-go userspace implementation-ஐப் பயன்படுத்த வேண்டும். முதலில் sudo modprobe wireguard && echo ok கட்டளையைப் பயன்படுத்தி இதைச் சரிபார்க்கவும்.

ரகசியங்களை கசியவிடாமல் keys உருவாக்குதல்

அனைவரும் வாசிக்கக்கூடிய (world-readable) /etc/wireguard/server.key என்பது VPN-இல்லாத நிலைக்கு சமமானது. பொதுவான umask 077 && wg genkey | sudo tee ... கட்டளை நம்பகத்தன்மையற்றது, ஏனெனில் sudo தனது சொந்த umask-ஐ tee உருவாக்கும் கோப்பிற்குப் பயன்படுத்துகிறது. எனவே, கோப்பின் அனுமதியை (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 ஜோடியை உருவாக்கவும். wg genpsk ஒரு விருப்பத்தேர்வு pre-shared key-ஐச் சேர்க்கிறது; இது ஒவ்வொரு configuration கோப்பிலும் ஒரு வரியாக இருக்கும்.

சர்வர் இடைமுகம்: /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 சப்நெட்டின் முழு முகமூடியையும் (mask) கொண்ட, டன்னலுக்குள் இருக்கும் சர்வரின் முகவரியாகும். பொதுவான நெட்வொர்க்குகளில் நீங்கள் சந்திக்காத ஒரு வரம்பைத் தேர்ந்தெடுக்கவும்; 192.168.1.0/24 உங்கள் கிளையண்டுகள் பயன்படுத்தும் பல வீட்டு ரௌட்டர்களுடன் மோதக்கூடும், அவ்வாறு நடந்தால் டன்னல் எந்த எச்சரிக்கையும் இன்றி உள்ளூர் ரூட்டிங்கிற்கு (local route) வழிவிட்டுத் தோற்றுவிடும்.

சர்வர் பக்கத்தில் ஒரு பியரின் (peer) AllowedIPs என்பது /32 ஆகும், இது அந்த கிளையண்ட் வைத்திருக்கும் தனித்துவமான டன்னல் முகவரியாகும். இரண்டு பியர்களுக்கு ஒரே AllowedIP-ஐ வழங்கினால், கடைசியாக உள்ளமைக்கப்பட்ட பியருக்கு டன்னல் மாறிவிடும், முதலாவது பியர் எந்தப் பிழைச் செய்தியும் இன்றி டிராஃபிக்கைப் பெறுவதை நிறுத்திவிடும். SaveConfig-ஐ அமைக்காமல் விடவும், இல்லையெனில் wg-quick down இந்த கோப்பை நேரடி நிலையிலிருந்து (live state) மீண்டும் எழுதிவிடும்.

server-ஐ router-ஆக மாற்றுதல்

Linux server தனக்கு அனுப்பப்படாத packets-ஐ நிராகரிக்கும். இயல்பாகவே, packet 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

ஒரு bare sysctl -w அடுத்த reboot வரை மட்டுமே செயல்படும், அதன் பிறகு தானாகவே நின்றுவிடும். NAT-க்கு wg0 அல்லாமல், internet-ஐ அடையும் egress interface, அதாவது NIC தேவைப்படுகிறது. eth0-ஐ அப்படியே எடுத்துக்கொள்ள வேண்டாம்; தற்போதைய images enp1s0 அல்லது ens3 போன்ற பெயர்களைப் பயன்படுத்துவதால், ip route show default மூலம் உங்களுடைய interface பெயரை உறுதிப்படுத்திக் கொள்ளுங்கள்.

Firewall: port மற்றும் forward path

ஒரே nftables கோப்பு filter மற்றும் NAT ஆகிய இரண்டையும் கையாள்கிறது. /etc/nftables.conf கட்டளையை இயக்கினால், ஏற்கனவே உள்ள ruleset நீக்கப்படும் (flush); எனவே, ufw அல்லது Docker மூலம் நிர்வகிக்கப்படும் server-களில் இதைத் தவிர்க்கவும்.

#!/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 கட்டளையில் ஒரு சிறிய பிழை ஏற்பட்டாலும், உங்கள் சொந்த server-லிருந்து நீங்கள் வெளியேற்றப்படலாம். Forward chain எதை அனுமதிக்காது என்பதைக் கவனிக்கவும், wg0 முதல் wg0 வரை. Peers இணையத்தை அணுகலாம், ஆனால் தங்களுக்குள் தொடர்புகொள்ள முடியாது; peer-to-peer VPN தேவைப்பட்டால் iifname "wg0" oifname "wg0" accept-ஐச் சேர்க்கவும். அதே chain, server-ல் ஒரு peer எதை அணுகலாம் என்பதையும் கட்டுப்படுத்துகிறது. இது, உங்கள் server tmux-ல் Claude Code இயக்கும் remote development box ஆகச் செயல்படும்போது, அந்தப் பகுதியை பொதுவெளியில் வெளிப்படுத்த விரும்பாத சூழலில் முக்கியமானது.

ufw பயன்படுத்தும் server-ல்: 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, அடுத்த முறை கணினியை reboot செய்த பிறகு நீக்கப்படும்; kernel மேம்படுத்தல்களுக்கு reboot அவசியம். அத்தகைய reboot-க்கு பிறகு மீண்டும் தொடங்கத் தவறிய ஒரு unit, யாராவது இணைக்க முயற்சிக்கும் வரை அமைதியாகவே இருக்கும். எனவே, உங்கள் சொந்த ntfy server-ஐக் குறிக்கும் wg-quick@wg0-ல் உள்ள ஒரு OnFailure= drop-in, பயனர்கள் வெளியேற்றப்பட்ட பிறகு புகார் அளிக்கும் வரை காத்திருக்காமல், உங்கள் தொலைபேசியிலேயே இது குறித்த தகவலைப் பெறுவதற்கான மிக எளிதான வழியாகும்.

Client கட்டமைப்பு மற்றும் அனைவரும் தவறு செய்யும் அமைப்பு

[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. ஒரு packet-ன் இலக்கு (destination), ஒரு peer-ன் AllowedIPs-உடன் பொருந்தினால், அது என்க்ரிப்ட் செய்யப்பட்டு அந்த peer-க்கு அனுப்பப்படும். 0.0.0.0/0, ::/0 அனைத்து traffic-ஐயும் tunnel வழியாக அனுப்புகிறது; இது ஒரு full tunnel, அதாவது server-ஐ default route-ஆக மாற்றுகிறது. Split tunnel என்பது ஒரு குறுகிய பட்டியல்: AllowedIPs = 10.8.0.0/24, 10.20.0.0/16 VPN traffic-ஐயும், server-க்கு பின்னால் உள்ள ஒரு private network-ஐயும் மட்டுமே கொண்டு செல்லும்; மற்ற அனைத்தும் அதன் உள்ளூர் (local) route-ஐயே பயன்படுத்தும். இந்த குறுகிய பட்டியல் மூலமே, சேவைகளை பொது இணையத்திலிருந்து முழுமையாகத் தவிர்க்க முடிகிறது. உதாரணமாக, tunnel address-உடன் இணைக்கப்பட்ட private Nextcloud instance on a VPS அல்லது அதே server-ல் இயங்கும் nested-virtualisation lab VMs ஆகியவற்றை, மற்றவர்களுக்குத் தெரியாமல் peers-க்கு மட்டும் அணுகக்கூடியதாக வைத்திருக்க முடியும்.

Inbound-ஐப் பொறுத்தவரை, இது ஒரு access-control list. ஒரு peer-லிருந்து வரும் decrypted packet-ன் source address, அந்த peer-ன் AllowedIPs-ல் இல்லை என்றால், அது நிராகரிக்கப்படும் (dropped). இதனால்தான் laptop-க்காக server 10.8.0.2/32-ஐப் பட்டியலிடுகிறது: அங்கே 0.0.0.0/0 என்று குறிப்பிட்டால், அந்த client tunnel-ல் உள்ள எந்த முகவரியையும் போலியாகப் பயன்படுத்த (spoof) வழிவகுக்கும்.

PersistentKeepalive என்பது NAT-க்கு பின்னால் இருக்கும் client-களுக்காக உருவாக்கப்பட்டது. அங்கே, packets செல்லும் வரை மட்டுமே router UDP mapping-ஐத் திறந்து வைத்திருக்கும். அது காலாவதியானதும், server-ஆல் client-ஐத் தொடர்பு கொள்ள முடியாது. PersistentKeepalive = 25 அந்த mapping-ஐத் திறந்து வைத்திருக்கும். இதை public IP கொண்ட server-ல் அமைக்க வேண்டாம், client-ல் மட்டும் அமைக்கவும்.

DNS மற்றும் கவனிக்கப்படாத கசிவு

AllowedIPs = 0.0.0.0/0 மற்றும் எந்த DNS = வரியும் இல்லாதபோது, உள்ளூர் நெட்வொர்க்கிலிருந்து பெற்ற resolver-ஐயே client தொடர்ந்து பயன்படுத்தும்; இது 192.168.1.1-ல் உள்ள café router ஆகும். அந்த route, default route-ஐ விட துல்லியமானது, எனவே மற்ற அனைத்தும் tunnel வழியாகச் சென்றாலும், DNS வினவல்கள் (queries) மட்டும் உள்ளூர் இணைப்பு வழியாக cleartext-ஆக வெளியேறும். traffic தனிப்பட்டதாக இருக்கும்; ஆனால் பார்க்கப்படும் பெயர்களின் பட்டியல் தனிப்பட்டதாக இருக்காது.

இதற்கு இரண்டு நேர்மையான வழிகள் உள்ளன. DNS-ஐ ஒரு public resolver-க்கு (DNS = 9.9.9.9) சுட்டிக்காட்டினால், வினவல்கள் tunnel வழியாகச் சென்று உங்கள் server-லிருந்து வெளியேறும், இருப்பினும் அந்த resolver-க்கு அவை தெரியும். அல்லது 10.8.0.1-ல் இயங்கும் unbound அல்லது dnsmasq-ஐப் பயன்படுத்தலாம், DNS = 10.8.0.1-ஐ அமைக்கலாம், மேலும் input chain-ல் udp dport 53 iifname "wg0" accept-ஐச் சேர்க்கலாம். அந்த வரியை அமைத்துவிட்டு resolver-ஐ மறந்துவிடலாம், அப்போது எதுவும் resolve ஆகாது.

Linux client-களில் wg-quick, DNS முதல் resolvconf வரை செயல்படுத்துகிறது; அது இல்லையெனில் உங்களுக்கு resolvconf: command not found கிடைக்கும். openresolv-ஐ நிறுவவும், அல்லது systemd-resolved client-ல் PostUp = resolvectl dns %i 10.8.0.1-ஐ அமைக்கவும்.

Tunnel-ஐ துண்டிக்காமல் peers-ஐ சேர்த்தல் மற்றும் நீக்குதல்

ஒரு பயனரைச் சேர்க்க interface-ஐ restart செய்வது, இணைப்பில் உள்ள அனைவரையும் வெளியேற்றிவிடும். [Peer] தொகுதியை wg0.conf-ல் இணைக்கவும், பின்னர் peer தொகுப்பை அப்படியே reload செய்யவும்.

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

wg-quick strip ஆனது wg-quick-only சாவிகள் (Address, DNS, PostUp) இல்லாமல் configuration-ஐ அச்சிடுகிறது, மேலும் syncconf ஆனது நேரடி அமர்வுகள் (live sessions) பாதிக்கப்படாமல் மாற்றங்களைச் செயல்படுத்துகிறது. இது peers-ஐ மட்டுமே புதுப்பிக்கிறது: மாற்றப்பட்ட Address-க்கு இன்னும் முழுமையான down/up தேவைப்படுகிறது. sudo wg set wg0 peer <public key> remove மூலம் அணுகலை நீக்கவும், பின்னர் கோப்பிலிருந்து அந்தத் தொகுதியை நீக்கவும், இல்லையெனில் அடுத்த reload-ன் போது அது மீண்டும் வந்துவிடும்.

தோல்வி முறைகள் மற்றும் நீங்கள் காணும் செய்திகள்

Handshake முடிவடையவில்லை. 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-லும் (பெரும்பாலான control panel-களில் இது தனி அமைப்பாக இருக்கும்) UDP 51820 port திறக்கப்பட்டுள்ளதா? Endpoint முகவரி மற்றும் port சரியாக உள்ளதா? keys மாற்றப்பட்டுள்ளதா? client-ன் [Peer] பகுதியில் உள்ள key, server-ன் public key-ஆக இருக்க வேண்டும்; இதற்கு மாறாக, private key-ஐயோ அல்லது client-ன் சொந்த public key-ஐயோ உள்ளிட்டால் இந்தச் சிக்கல் ஏற்படும். sudo tcpdump -ni any udp port 51820-ஐ server-ல் இயக்குவதன் மூலம் packets வந்து சேருகிறதா என்பதை அறியலாம். kernel module இயல்பாக எதையும் log செய்யாது; dynamic debug (echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control) வசதியைச் செயல்படுத்திய பிறகு மட்டுமே WireGuard செய்திகள் dmesg-ல் தோன்றும். அதைச் செயல்படுத்திய பின், key பொருந்தவில்லை எனில் invalid-MAC drop எனத் தெரியும்.

Handshake வேலை செய்கிறது, ஆனால் இணையம் கிடைக்கவில்லை. 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 விதியில் packets எண்ணிக்கை பூஜ்ஜியமாக இருந்தால், egress interface பெயர் தவறாக உள்ளது என்று பொருள்; பதில்கள் வராமல் counter அதிகரித்தால், அது forward chain policy-ல் உள்ள சிக்கலைக் குறிக்கிறது.

இணையம் வேலை செய்கிறது, ஆனால் பெயர்கள் (names) வேலை செய்யவில்லை. ping 1.1.1.1 வெற்றிகரமாக முடிகிறது, ஆனால் curl https://example.com ஆனது Could not resolve host-ஐத் தருகிறது. DNS வரி விடுபட்டுள்ளது அல்லது tunnel-க்குள் இருந்து அணுக முடியாத resolver-ஐ அது குறிப்பிடுகிறது.

சில HTTPS தளங்கள் முடங்குகின்றன. SSH மற்றும் ping சரியாக வேலை செய்கின்றன; பெரிய பக்கங்கள் மட்டும் முடங்குகின்றன. இது path MTU சிக்கல்: tunnel கூடுதல் சுமையை (overhead) சேர்க்கிறது, இடையில் உள்ள ஏதோ ஒரு link பெரிய packets-ஐ ICMP செய்தி அனுப்பாமலேயே நிராகரிக்கிறது. client-ன் [Interface]-ல் MTU அளவைக் குறைக்கவும்; முதலில் 1420, பின் 1380, பிறகு 1280 என முயற்சி செய்யவும். MTU அளவைக் குறைத்ததும் முடக்கம் சரியாகி, ஆனால் வேகம் குறைவாக இருந்தால், தோராயமான எண்களை முயற்சிப்பதை நிறுத்திவிட்டு bisection மற்றும் TCP MSS clamping மூலம் உண்மையான path MTU-ஐக் கண்டறிதல் என்ற வழிமுறையைப் பின்பற்றவும். இது tunnel தொடர்பில்லாத பிற காரணங்களையும் நீக்க உதவும்.

Interface தொடங்க மறுக்கிறது. Address already in use என்றால், வேறொரு process UDP 51820-ஐப் பயன்படுத்திக்கொண்டிருக்கிறது என்று பொருள். up தோல்வியடைந்த பிறகு Cannot find device wg0 என வந்தால், configuration நிராகரிக்கப்பட்டுள்ளது என்று பொருள்; journalctl -u wg-quick@wg0 -n 50-ஐப் படித்துப் பார்க்கவும்.

Streisand அல்லது OpenVPN-லிருந்து மாறுதல்

Streisand பராமரிப்பில் இல்லை, அதன் repository-ம் முடக்கப்பட்டுவிட்டது. கைவிடப்பட்ட automation கருவிகளைப் பயன்படுத்தி VPN-ஐ இயக்குவது பாதுகாப்புச் சிக்கல்களை உருவாக்கும். இதில் in-place upgrade செய்ய முடியாது. OpenVPN-ன் PKI-ஐ WireGuard-க்கு மாற்ற முடியாது: WireGuard-ல் certificates, CA அல்லது expiry கிடையாது. எனவே, ஒவ்வொரு client-க்கும் புதிய key pair உருவாக்க வேண்டும்.

இணைந்து செயல்படும் வகையில் (parallel) மாற்றத்தை மேற்கொள்ளுங்கள். ஒரே server-ல் OpenVPN 1194 port-லும், WireGuard UDP 51820 port-லும் ஒரே நேரத்தில் இயங்க முடியும். wg0-ஐ நிறுவி, ஒவ்வொரு client-ஆக மாற்றிவிட்டு, இறுதியில் பழைய service-ஐ நிறுத்துங்கள். OpenVPN-ன் username/password மற்றும் revocation முறை WireGuard-க்கு பொருந்தாது. உங்களுக்கு கணக்குகள் (accounts) அல்லது audit trail தேவைப்பட்டால், WireGuard-க்கு மேல் அந்த வசதியை அடுக்காக (layer) உருவாக்கிக்கொள்ளுங்கள்.

காப்புப்பிரதிகள், மேம்படுத்தல்கள் மற்றும் அளவீட்டில் ஏற்படும் சிக்கல்கள்

/etc/wireguard என்பது server ஆகும். இதை காப்புப்பிரதி எடுத்து (sudo tar czf wg-backup.tgz -C /etc wireguard, mode 600, server-க்கு வெளியே சேமிக்கவும்), புதிய VPS-ல் சில நிமிடங்களில் மீண்டும் கட்டமைக்க முடியும். server-ன் private key-ஐ இழந்துவிட்டால், அனைத்து client configuration-களையும் மீண்டும் வழங்க வேண்டும், ஏனெனில் client-கள் server-ன் public key-ஐ pin செய்திருக்கும். மேம்படுத்தல்கள் என்பது ஒரு சாதாரண apt upgrade மற்றும் kernel update-களுக்கான reboot மட்டுமே. நீங்கள் enable செய்திருந்தால், wg-quick@wg0 தானாகவே மீண்டும் இயங்கத் தொடங்கும்.

ஒவ்வொரு peer-ன் நிலையும் சிறியது மற்றும் crypto kernel-ல் இயங்குவதால், இந்த configuration-ஐ விட உங்கள் VPS-ன் CPU மற்றும் bandwidth அளவே உச்சவரம்பாக இருக்கும். வெளியிடப்பட்ட புள்ளிவிவரங்களை நம்புவதை விட, iperf3 மூலம் tunnel வழியாக நீங்களே அளவிடுங்கள். அளவீட்டில் (scale) சிக்கலை ஏற்படுத்துவது செயல்பாட்டு நிர்வாகமே. ஒவ்வொரு peer-க்கும் ஒரு தனித்துவமான tunnel IP தேவை. அறுபது [Peer] தொகுதிகளை கைமுறையாகத் திருத்தும்போதுதான் AllowedIPs போன்ற நகல்கள் (duplicates) உருவாகின்றன: எனவே, script மூலம் configuration-களை உருவாக்குங்கள். ஒரு server என்பது ஒரு UDP endpoint மற்றும் ஒரு தோல்விப் புள்ளி (point of failure) ஆகும். WireGuard-ல் clustering வசதி இல்லை: எனவே, redundancy தேவைப்பட்டால், சொந்த key-களுடன் கூடிய இரண்டாவது server-ஐப் பயன்படுத்த வேண்டும். Key rotation என்பது கைமுறையாகவே செய்யப்பட வேண்டும், எனவே யாரிடம் எந்த key உள்ளது மற்றும் அதை எப்படி revoke செய்வது என்பதைப் பதிவு செய்து வையுங்கள். இந்த ஆவணப்படுத்தல் ஒரு text file-ஐ விடப் பெரியதாக மாறும்போது, அதே kernel data plane-ன் மேல் ஒரு control plane-ஐப் பயன்படுத்துவதே தீர்வாகும். சுயமாக host செய்யப்படும் NetBird server, நீங்கள் கைமுறையாகச் செய்யும் address ஒதுக்கீடு, peer விநியோகம் மற்றும் setup key-களை நிர்வகிக்கும். அந்த control plane-ஐ நீங்களே இயக்குவது கூடுதல் சுமையாக இருந்தால், Tailscale உங்களுக்காக அதை host செய்யும். அதன் இலவசத் திட்டம் ஆறு பயனர்கள் மற்றும் வரம்பற்ற சாதனங்களை உள்ளடக்கியது, இது பெரும்பாலான தனிப்பட்ட பயன்பாட்டிற்குப் போதுமானது. அதற்கு மேல் செல்லும்போது, இயந்திரங்களின் எண்ணிக்கையை விட பயனர்களின் எண்ணிக்கையைப் பொறுத்தே கட்டணம் வசூலிக்கப்படும். எனவே, ஒரு குடும்பம் அல்லது சிறிய குழு செலுத்தும் கட்டணம், நீங்கள் wg0.conf-ல் கைமுறையாகத் திருத்தும் peer-களின் எண்ணிக்கையைப் பொறுத்தது அல்ல, மாறாக எத்தனை மனிதர்கள் login-களைக் கொண்டுள்ளனர் என்பதைப் பொறுத்தது. அந்த வகையில், split-tunnel AllowedIPs நிர்வாகமானது subnet router மூலம் உங்கள் private range-களை விளம்பரப்படுத்துவதாக மாறுகிறது. இது ஒரு VPS-லிருந்து ஒருமுறை அறிவிக்கப்பட்டு மையப்படுத்தப்பட்ட முறையில் அங்கீகரிக்கப்படுகிறது, ஒவ்வொரு client file-லும் நகலெடுக்க வேண்டியதில்லை. இந்த மாற்றம் அவசியமா என்பது, host செய்யப்பட்ட control plane எதை அடைய முடியும் என்பதைப் பொறுத்தது. இது உங்கள் traffic-ஐ encrypt செய்யும் key-களை ஒருபோதும் கொண்டிருக்காது, ஆனால் எந்தெந்த peer-கள் ஒருவரை ஒருவர் கண்டறியலாம் என்பதை இதுவே தீர்மானிக்கிறது.

இதற்கெல்லாம் உங்கள் கட்டுப்பாட்டில் உள்ள ஒரு Linux box, ஒரு public IP, நீங்கள் module-ஐ ஏற்றக்கூடிய ஒரு kernel மற்றும் முழுமையாக உங்கள் கட்டுப்பாட்டில் உள்ள firewall ஆகியவை தேவை.

FAQ

WireGuard handshake ஏன் முடிவடைவதில்லை?

wg show ஒரு peer-ஐ latest handshake இல்லாமல் பட்டியலிடுவது, பாக்கெட்டுகள் வந்து சேரவில்லை அல்லது ஏற்கப்படவில்லை என்பதைக் குறிக்கிறது. VPS firewall மற்றும் உங்கள் provider-ன் தனிப்பட்ட network firewall இரண்டிலும் UDP 51820 port-ஐச் சரிபார்க்கவும். Endpoint host மற்றும் port சரியாக உள்ளதா என உறுதிப்படுத்தவும். பிறகு, keys மாற்றப்படவில்லை என்பதை உறுதிப்படுத்தவும்; client-ன் [Peer] பகுதியில் server-ன் public key மட்டுமே இருக்க வேண்டும். sudo tcpdump -ni any udp port 51820 கட்டளை, server-க்கு பாக்கெட்டுகள் வந்து சேருகிறதா என்பதைக் காட்டும். dmesg, dynamic debug (echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control) வசதியைச் செயல்படுத்திய பிறகு மட்டுமே WireGuard handshake தோல்விகளைத் தெரிவிக்கும்; அப்போது key பொருந்தவில்லை என்றால், அது invalid-MAC drop எனக் காட்டும்.

Tunnel இணைகிறது, ஆனால் internet வேலை செய்யவில்லை. என்ன குறைபாடு?

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 விதியைச் சரிபார்க்கவும்; இது உங்கள் உண்மையான egress interface-ஐ ip route show default, enp1s0 அல்லது ens3 (அரிதாக eth0) மூலம் கண்டறியும்.

Client config-ல் DNS = வரி எனக்குத் தேவையா?

Full tunnel அமைப்பில் DNS = வரி இல்லையென்றால், client தனது local network-லிருந்து பெற்ற resolver-ஐயே பயன்படுத்தும். இதனால், மற்ற அனைத்தும் tunnel வழியாகச் சென்றாலும், DNS queries மட்டும் local link வழியாக cleartext-ஆக வெளியேறும். DNS-ஐ ஒரு public resolver-க்கு மாற்றவும், அல்லது 10.8.0.1-ல் இயங்கும் unbound/dnsmasq-ஐப் பயன்படுத்தி, input chain-ல் udp dport 53 iifname "wg0"-ஐத் திறக்கவும்.

AllowedIPs உண்மையில் எதைக் கட்டுப்படுத்துகிறது?

இது இரண்டு பணிகளைச் செய்கிறது. Outbound-ல் இது ஒரு routing table: ஒரு peer-ன் AllowedIPs-க்கு பொருந்தும் traffic குறியாக்கம் (encrypt) செய்யப்பட்டு அந்த peer-க்கு அனுப்பப்படும். Inbound-ல் இது ஒரு access-control list: குறியாக்கம் நீக்கப்பட்ட பாக்கெட்டின் source, அந்த peer-ன் AllowedIPs-க்கு வெளியே இருந்தால், அது நிராகரிக்கப்படும் (drop). இதனால்தான் server பக்கத்தில் ஒவ்வொரு client-க்கும் ஒரு /32 பட்டியலிடப்படுகிறது, ஆனால் client பக்கத்தில் 0.0.0.0/0 இருக்கலாம்.

எந்த VPS-லும் WireGuard இயங்குமா?

KVM VPS-ல் இது in-kernel module மூலம் கூடுதல் அமைப்புகள் இன்றி இயங்கும். OpenVZ அல்லது LXC போன்ற host kernel-ஐப் பகிரும் container virtualisation-ல், modprobe wireguard கட்டளை Operation not supported பிழையுடன் தோல்வியடையும். அதற்குப் பதிலாக wireguard-go userspace implementation-ஐப் பயன்படுத்த வேண்டும். மற்ற எதையும் செய்வதற்கு முன் sudo modprobe wireguard && echo ok கட்டளையை இயக்கவும்.