Jinsi ya kuweka WireGuard VPN kwenye VPS

What you are building

A WireGuard VPN on a server you own is about forty lines of config: one key pair, one interface file, one sysctl, one NAT rule, one firewall hole. The install is trivial, so most of this guide covers what breaks — key permissions, AllowedIPs, forwarding and DNS.

WireGuard is a Layer 3 tunnel in the kernel, mainline since Linux 5.6, so Ubuntu 24.04 and Debian 13 ship it with no external module. No cipher negotiation, no certificate authority, no username/password step: a peer is a public key plus the IP addresses that key may use. A packet failing its MAC check is dropped with no reply, so the port does not answer scans. The flip side: no auth server exists, so removing access means deleting a peer on the box.

Kagua uwezo wa virtualisation kwanza

WireGuard inahitaji kernel inayoweza kupokea module, na kwenye KVM VPS inafanya kazi moja kwa moja. Kwenye container virtualisation zinazotumia kernel ya host — OpenVZ, LXC — amri ya kwanza itashindwa na RTNETLINK answers: Operation not supported, na mbadala ni utekelezaji wa userspace wa wireguard-go. Kagua kwa kutumia sudo modprobe wireguard && echo ok kwanza.

Tengeneza funguo bila kuzivujisha

/etc/wireguard/server.key inayoweza kusomwa na kila mtu ni sawa na kutokuwa na VPN kabisa. Mstari wa kawaida wa umask 077 && wg genkey | sudo tee ... hauna uhakika, kwa sababu sudo hutumia umask yake yenyewe kwenye faili ambalo tee hutengeneza. Weka hali ya ulinzi (mode) wazi.

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

Tengeneza jozi ya mteja (client pair) kwa njia hiyo hiyo. wg genpsk huongeza funguo ya awali iliyoshirikishwa (pre-shared key) inayochaguliwa, ambayo ni mstari mmoja katika kila konfigi.

Kioleshi cha seva: /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; onyo la wakati wa kuanza kwamba faili inaweza kufikiwa na kila mtu inamaanisha kuwa uliruka hatua hiyo. Address ni anwani ya seva ndani ya njia ya mawasiliano (tunnel), inayobeba mask ya subnet nzima ya VPN. Chagua kiwango ambacho hakitajatua na mitandao mingine — 192.168.1.0/24 inagongana na nusu ya router za nyumbani ambazo wateja wako nyuma yake, na njia ya mawasiliano itashindwa kimya kimya kwa njia ya ndani (local route).

AllowedIPs ya peer kwenye upande wa server ni /32, anwani moja ya njia ya mawasiliano ambayo mteja anamiliki. Ukitoa IP inayoruhusiwa (allowed IP) sawa kwa peer mbili, itahamia kwenye ile iliyosanidiwa mwishoni, na ya kwanza itachaapokea trafiki bila kutoa kosa lolote. Acha SaveConfig isiwekwe, au wg-quick down itafuta na kuandika upya faili hii kutoka kwenye hali ya sasa (live state).

Badilisha sanduku kuwa router

Server ya Linux hupoteza paketi ambazo hazijatengenezwa kwake. Forwarding na source NAT vyote havipo kwa kima kawaida.

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 safi hufanya kazi hadi baada ya kuwasha upya (reboot) na kisha huacha kufanya kazi bila taarifa. NAT inahitaji interface ya egress — NIC inayofikia internet, siyo wg0. Usichukulie eth0; chukua yako kutoka ip route show default, kwa sababu picha za sasa hutumia majina kama enp1s0 au ens3.

Firewall: port, na njia ya kuelekeza (forward path)

Faili moja ya nftables inahusisha filter na NAT. Andika /etc/nftables.conf — hii inafuta seti ya sheria zilizopo, hivyo ruka hatua hii kwenye mashine inayotumiwa tayari na ufw au 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
  }
}

Itekeleze kwa kutumia sudo systemctl enable --now nftables, huku ukiacha session ya pili ya SSH ikiwa wazi: policy drop pamoja na makosa ya uandishi kwenye sheria ya SSH itakufunga nje ya server yako mwenyewe. Angalia kile ambacho forward chain haikiruhusu — wg0 hadi wg0. Wenza (peers) wanaweza kufikia internet, lakini si wenza wao; ongeza iifname "wg0" oifname "wg0" accept kwa VPN ya peer-to-peer. Chain hiyo hiyo inaamua kile ambacho peer anaweza kukigusa kwenye server yenyewe, jambo ambalo ni muhimu wakati mashine inatumika pia kama box ya maendeleo ya mbali inayotumia Claude Code ndani ya tmux na hutaki kuweka upande huo hadharani.

Kwenye mashine ya ufw: ufw allow 51820/udp, DEFAULT_FORWARD_POLICY="ACCEPT" ndani ya /etc/default/ufw, na sheria ya *nat POSTROUTING MASQUERADE juu kabisa ya /etc/ufw/before.rules.

Ianzishe chini ya systemd

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

wg-quick hutengeneza interface, huongeza anwani, na kusakinisha njia (routes) zinazotokana na AllowedIPs. enable --now ni sehemu muhimu: wg-quick up wg0 inayofanywa kwa mkono hupotea baada ya kuwasha upya mfumo, na maboresho ya kernel yanamaanisha kuhitaji kuwasha upya mfumo.

Sanifu ya mteja, na mipangilio ambayo kila mtu hukosea

[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 ina kazi mbili tofauti kwa wakati mmoja, na kuchanganya kazi hizi ndiyo chanzo cha mkanganyiko mwingi wa WireGuard.

Kwa upande wa nje (Outbound), ni meza ya njia (routing table). Paketi ambayo lengo lake linafanana na AllowedIPs ya peer inasimbwa na kutumwa kwa peer huyo. 0.0.0.0/0, ::/0 hutuma kila kitu kupitia njia hiyo — njia kamili, server ikiwa kama njia ya msingi (default route). Njia ya msplit (split tunnel) ni orodha nyembamba zaidi: AllowedIPs = 10.8.0.0/24, 10.20.0.0/16 hubeba trafiki ya VPN pamoja na mtandao mmoja wa ndani nyuma ya server, na kila kitu kingine kinaendelea kutumia njia yake ya ndani. Orodha hiyo nyembamba ndiyo inayokuwezesha kuweka huduma mbali na mtandao wa umma kabisa — nakala ya Nextcloud ya ndani kwenye VPS iliyounganishwa kwenye anwani ya tunnel, au VM za maabara za nested-virtualisation zinazojiendesha kwenye kifaa hicho hicho, zinabaki kufikiwa na peers na kuwa zisioonekana kwa kila mtu mwingine.

Kwa upande wa ndani (Inbound), ni orodha ya udhibiti wa ufikiaji (access-control list). Paketi iliyosimbuliwa kutoka kwa peer ambayo anwani yake ya chanzo haipo kwenye AllowedIPs ya peer huyo huondolewa. Ndiyo maana server inaorodhesha 10.8.0.2/32 kwa ajili ya laptop: ingizo la 0.0.0.0/0 hapo lingemruhusu mteja huyo kuiga (spoof) anwani yoyote kwenye tunnel.

PersistentKeepalive ni kwa ajili ya wateja waliopo nyuma ya NAT, ambapo router hushikilia ramani ya UDP ikiwa wazi wakati tu paketi zinapopita. Inapoisha, server inaweza kutofikia mteja tena. PersistentKeepalive = 25 hushikilia ramani hiyo ikiwa wazi — iweke kwenye mteja, siyo kwenye server yenye IP ya umma.

DNS, na uvujaji ambao hakuna anayegundua

Kwa kutumia AllowedIPs = 0.0.0.0/0 na bila mstari wa DNS =, mteja anatumia resolver aliyopata kutoka kwenye mtandao wa ndani — router ya mkahawa ilipo 192.168.1.1. Njia hiyo ina upekee zaidi kuliko njia ya kawaida (default route), hivyo maswali ya DNS yanatoka kwenye kiunganishi cha ndani bila usimbaji (cleartext) wakati kila kitu kingine kinapitia njia ya tunnel. Trafiki ni ya siri; lakini orodha ya majina si ya siri.

Chaguo mbili za uhakika. Elekeza DNS kwenye resolver ya umma (DNS = 9.9.9.9) na maswali yataingia kwenye tunnel na kutoka kwenye seva yako, ingawa resolver hiyo bado itayaona. Au tumia unbound au dnsmasq iliyounganishwa na 10.8.0.1, weka DNS = 10.8.0.1, na uongeze udp dport 53 iifname "wg0" accept kwenye input chain — ukiweka mstari huo na kusahau resolver, hakuna kitu kitakachotatua majina (resolve).

Kwenye wateja wa Linux, wg-quick hutumia DNS kupitia resolvconf; ikiwa haipo utapata resolvconf: command not found. Sakinisha openresolv, au weka PostUp = resolvectl dns %i 10.8.0.1 kwenye mteja wa systemd-resolved.

Kuongeza na kuondoa peers bila kukatisha tunnel

Kuwasha upya interface ili kuongeza mtumiaji hukatisha mawasiliano ya kila mtu aliyeunganishwa. Ongeza block ya [Peer] kwenye wg0.conf, kisha pakia upya peer set mahali ilipo.

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

wg-quick strip huchapa config bila funguo za wg-quick-only (Address, DNS, PostUp), na syncconf hutumia mabadiliko huku vikao vilivyo hai vikiendelea. Inasasisha peers pekee: Address iliyobadilika bado inahitaji down/up kamili. Ondoa kwa kutumia sudo wg set wg0 peer <public key> remove, kisha futa block hiyo kwenye faili ili isirudi wakati wa pakia upya unaofuata.

Njia za kushindwa, pamoja na maandishi utakayoyaona

Handshake haikamiliki. wg show inaonyesha peer bila latest handshake, na client inaonyesha log:

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

Hakuna kinachofika, au hakuna kinachokubaliwa. Kwa mpangilio: je, UDP 51820 iko wazi kwenye firewall ya VPS na kwenye firewall ya mtandao wa mtoa huduma wako (ambayo ni udhibiti tofauti kwenye paneli nyingi); je, anwani na port ya Endpoint ni sahihi; je, funguo (keys) zimebadilishana? Funguo kwenye block ya [Peer] ya client lazima iwe funguo ya server ya umma (public key), na kinyume chake — kubandika private key, au funguo ya umma ya client mwenyewe, husababisha tatizo hili. sudo tcpdump -ni any udp port 51820 kwenye server inaonyesha ikiwa paketi zinafika kabisa. Kernel module haionyeshi log kwa kawaida; ujumbe wa WireGuard unaonekana kwenye dmesg baada tu ya kuwasha dynamic debug (echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control), na ukiwa umewashwa, hitilafu ya funguo huonekana kama invalid-MAC drop.

Handshake inafanya kazi, hakuna internet. ping 10.8.0.1 inafanikiwa lakini ping 1.1.1.1 inakatika (timeout): forwarding au NAT haipo. Hakikisha sysctl net.ipv4.ip_forward inasoma 1, kisha angalia vihesabu (counters) wakati client inapiga ping, kwa kutumia sudo nft list ruleset au sudo iptables -t nat -L POSTROUTING -n -v. Paketi sifuri kwenye masquerade rule inamaanisha jina la interface ya egress ni kosa; kihesabu kinachoonzeka bila majibu kinaashiria sera ya forward chain.

Internet inafanya kazi, majina (names) hayafanyi kazi. ping 1.1.1.1 inafanikiwa na curl https://example.com inarudisha Could not resolve host. Mstari wa DNS haupo, au unataja resolver ambayo haiwezi kufikiwa kutoka ndani ya tunnel.

Baadhi ya tovuti za HTTPS zinakwama. SSH na ping zinafanya kazi vizuri; kurasa kubwa zinakwama. Hiyo ni path MTU: tunnel inaongeza overhead, na kiunganishi fulani katikati kinatupa paketi kubwa bila ujumbe wa ICMP kurudi. Punguza MTU kwenye client [Interface] — jaribu 1420, kisha 1380, kisha 1280.

Interface inakataa kuanza. Address already in use inamaanisha mchakato mwingine unatumia UDP 51820. Cannot find device wg0 baada ya up iliyoshindwa kwa kawaida inamaanisha konfigi ilikataliwa; soma journalctl -u wg-quick@wg0 -n 50.

Kuhamia kutoka Streisand au OpenVPN

Streisand haitunzwi tena na hifadhi yake (repository) imehifadhiwa kama kumbukumbu (archived). Kutumia VPN kwenye mfumo wa usimamizi (automation) uliotelekezwa ni tatizo la usalama la muda mrefu. Hakuna njia ya kufanya upainuzi (upgrade) kwenye mfumo uliopo, na PKI ya OpenVPN haiwezi kubadilishwa: WireGuard haina vyeti (certificates), haina CA, na haina muda wa mwisho, hivyo kila mteja hupata jozi mpya ya funguo (key pair).

Hamia kwa njia ya sambamba — WireGuard kwenye UDP 51820 inaweza kufanya kazi pamoja na OpenVPN kwenye 1194 kwenye mashine hiyo hiyo. Weka wg0, hamisha wateja mmoja baada ya mwingine, kisha zima huduma ya zamani. Mfumo wa majina ya mtumiaji/nywila na ubatilishaji (revocation) wa OpenVPN hauhamishwi; ikiwa unahitaji akaunti au kumbukumbu za ukaguzi (audit trail), weka mfumo huo juu ya WireGuard.

Backups, upgrades, and what strains at scale

/etc/wireguard ndio server. Iweke kwenye backup (sudo tar czf wg-backup.tgz -C /etc wireguard, mode 600, iwekwe nje ya mashine) ili uweze kuijenga upya kwenye VPS mpya ndani ya dakika chache. Ukipoteza private key ya server, kila client itahitaji kupewa config mpya, kwa sababu clients hufunga (pin) public key ya server. Upgrades ni apt upgrade ya kawaida pamoja na kuwasha upya (reboot) kwa ajili ya kernel updates, na wg-quick@wg0 hurudi yenyewe ikiwa uliwezesha.

Hali ya kila peer ni ndogo na crypto inafanya kazi kwenye kernel, hivyo kikomo ni CPU na bandwidth ya VPS yako badala ya kitu chochote kwenye config hii — ipime kwa kutumia iperf3 kwenye tunnel badala ya kuamini takwimu zilizochapishwa. Kitu kinachochosha wakati wa kukuza mfumo (scale) ni uendeshaji (operations). Kila peer inahitaji IP ya kipekee ya tunnel, na kuhariri kwa mkono zaidi ya blocks [Peer] sitini ndiyo njia inayozalisha AllowedIPs zinazojirudia: tengeneza configs kwa kutumia script. Server moja ni UDP endpoint moja na sehemu moja ya hitilafu (point of failure), na WireGuard haina clustering: redundancy inamaanisha server ya pili yenye keys zake. Mzunguko wa keys (key rotation) unabaki kuwa wa manual, hivyo andika nani anashikilia key gani na jinsi ya kuiondoa (revoke).

Mambo haya yote yanahitaji mashine ya Linux unayoidhibiti — IP ya umma, kernel ambayo unaweza kuweka module, na firewall unayoimiliki kuanzia mwanzo hadi mwisho.

FAQ

Kwa nini WireGuard handshake haikamiliki?

wg show kuorodhesha peer bila latest handshake inamaanisha paketi hazifiki au hazikubaliwi. Hakikisha UDP 51820 kwenye firewall ya VPS na firewall ya mtandao wa mtoa huduma wako, thibitisha host na port ya Endpoint, kisha hakikisha funguo (keys) hazijachanganywa — block ya [Peer] ya client lazima iwe na public key ya server. sudo tcpdump -ni any udp port 51820 kwenye server inaonyesha ikiwa paketi zinafika; dmesg inaripoti tu kushindwa kwa WireGuard handshake baada ya kuwasha dynamic debug (echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control), na wakati huo key mismatch itaonekana kama invalid-MAC drop.

Tunnel inaunganisha lakini sina internet. Nini kimepotea?

ping 10.8.0.1 inafanya kazi wakati ping 1.1.1.1 inatoa timeout inaashiria matatizo ya forwarding au NAT. Thibitisha kuwa sysctl net.ipv4.ip_forward inasoma 1 na kwamba imewekwa kwenye /etc/sysctl.d/, siyo tu kwa sysctl -w inayopotea baada ya reboot. Kisha kagua majina ya masquerade rule kwa interface yako ya egress kutoka ip route show default — enp1s0 au ens3, mara chache eth0.

Je, ninahitaji mstari wa DNS = kwenye client config yangu?

Kwa tunnel kamili na bila mstari wa DNS =, client inatumia resolver iliyojifunza kutoka kwenye mtandao wa ndani, na maswali hayo yanatoka kwa maandishi wazi (cleartext) kupitia link ya ndani wakati kila kitu kingine kinapitia tunnel. Elekeza DNS kwenye public resolver, au run unbound/dnsmasq iliyounganishwa na 10.8.0.1 na ufungue udp dport 53 iifname "wg0" kwenye input chain.

AllowedIPs inadhibiti nini hasa?

Inafanya kazi mbili. Kwa outbound ni routing table: traffic inayofanana na AllowedIPs ya peer inafungwa (encrypted) na kutumwa kwa peer huyo. Kwa inbound ni access-control list: paketi iliyofunguliwa ambayo chanzo chake (source) ipo nje ya AllowedIPs ya peer hiyo inaondolewa (dropped). Ndiyo maana upande wa server unaorodhesha /32 kwa kila client wakati upande wa client unaweza kuorodhesha 0.0.0.0/0.

Je, WireGuard itafanya kazi kwenye VPS yoyote?

Kwenye KVM VPS inafanya kazi kwa kutumia in-kernel module bila mipangilio ya ziada. Kwenye container virtualisation inayoshiriki kernel ya host, kama OpenVZ au LXC, modprobe wireguard inashindwa na Operation not supported na mbadala ni wireguard-go userspace implementation. Run sudo modprobe wireguard && echo ok kabla ya kitu kingine chochote.