Jinsi ya kuseti WireGuard VPN kwenye VPS yako

Unachojenga

WireGuard VPN kwenye seva unayomiliki inahitaji takriban mistari arobaini ya usanidi: jozi moja ya funguo, faili moja ya interface, sysctl moja, sheria moja ya NAT, na tundu moja la firewall. Usakinishaji ni rahisi, kwa hivyo mwongozo huu unashughulikia zaidi mambo yanayoweza kuharibika, ruhusa za funguo, AllowedIPs, usambazaji wa pakiti (forwarding) na DNS.

WireGuard ni tunnel ya Layer 3 iliyo ndani ya kernel, na imekuwa sehemu ya mainline tangu Linux 5.6, kwa hivyo Ubuntu 24.04 na Debian 13 huja nayo bila kuhitaji moduli ya nje. Hakuna mazungumzo ya cipher, hakuna mamlaka ya cheti (certificate authority), na hakuna hatua ya jina la mtumiaji/nenosiri: peer ni ufunguo wa umma (public key) pamoja na anwani za IP ambazo ufunguo huo unaweza kutumia. Pakiti inayofeli ukaguzi wake wa MAC hutupwa bila jibu, kwa hivyo port haijibu skani za mtandao. Upande wa pili wa sarafu: hakuna seva ya uthibitishaji (auth server), kwa hivyo kuondoa ufikiaji kunamaanisha kufuta peer kwenye seva hiyo.

Kagua uboreshaji wa mfumo (virtualisation) kwanza

WireGuard inahitaji kernel ambayo unaweza kupakia moduli ndani yake, na kwenye KVM VPS inafanya kazi bila marekebisho yoyote. Kwenye uboreshaji wa mfumo wa aina ya container unaoshiriki kernel ya mwenyeji (host), kama vile OpenVZ au LXC, amri ya kwanza inafeli kwa RTNETLINK answers: Operation not supported, na njia mbadala ni utekelezaji wa userspace wa wireguard-go. Kagua kwanza kwa kutumia sudo modprobe wireguard && echo ok.

Tengeneza funguo bila kuzivujisha

Faili la /etc/wireguard/server.key linaloweza kusomwa na kila mtu ni sawa na kutokuwa na VPN kabisa. Mstari wa kawaida wa umask 077 && wg genkey | sudo tee ... hautegemeki, kwa sababu sudo hutumia umask yake yenyewe kwenye faili linaloundwa na tee. Weka mode kwa njia ya 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 kwa njia ile ile. wg genpsk huongeza pre-shared key ya hiari, mstari mmoja katika kila usanidi.

Kiolesura 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 hiyo; onyo wakati wa kuanza (startup warning) kwamba faili linaweza kusomwa na kila mtu linamaanisha umesahau kufanya hivyo. Address ni anwani ya seva ndani ya tunnel, inayobeba mask ya subnet nzima ya VPN. Chagua masafa ambayo hutakutana nayo kwenye mitandao mingine, 192.168.1.0/24 inagongana na nusu ya ruta za nyumbani ambazo wateja wako wanazitumia, na tunnel itapoteza muunganisho kimya kimya kuelekea njia ya ndani (local route).

AllowedIPs ya peer upande wa seva ni /32, anwani moja ya tunnel inayomilikiwa na mteja huyo. Ukipa peers wawili IP ileile inayoruhusiwa (allowed IP), trafiki itaelekea kwa yule aliyesanidiwa mwisho, na wa kwanza ataacha kupokea trafiki bila ujumbe wowote wa hitilafu kuonekana. Acha SaveConfig bila kuwekwa, au wg-quick down itaandika upya faili hili kutoka kwenye hali ya sasa ya mfumo (live state).

Geuza seva kuwa kipanga njia (router)

Seva ya Linux hupoteza pakiti ambazo hazijaelekezwa kwake. Uelekezaji (forwarding) na source NAT vyote havijawashwa kwa chaguo-msingi.

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 ya kawaida hufanya kazi hadi reboot inayofuata kisha huacha kufanya kazi kimya kimya. NAT inahitaji interface ya egress, yaani NIC inayofikia mtandao wa Internet, si wg0. Usikubali eth0; chukua yako kutoka ip route show default, kwa sababu picha (images) za sasa hutumia majina kama enp1s0 au ens3.

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

Faili moja la nftables hushughulikia filter na NAT. Andika /etc/nftables.conf, amri hii hufuta (flushes) sheria zilizopo, kwa hivyo usitumie hii kwenye seva inayodhibitiwa 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
  }
}

Tekeleza kwa kutumia sudo systemctl enable --now nftables, huku ukiwa na session ya pili ya SSH ikiwa wazi: policy drop pamoja na kosa la kuandika (typo) kwenye sheria ya SSH itakufungia nje ya seva yako mwenyewe. Zingatia kile ambacho forward chain hairuhusu, wg0 hadi wg0. Peers hufikia Internet, siyo wao kwa wao; ongeza iifname "wg0" oifname "wg0" accept kwa ajili ya VPN ya peer-to-peer. Chain hiyo hiyo hudhibiti kile ambacho peer anaweza kugusa kwenye seva yenyewe, jambo ambalo ni muhimu wakati seva inafanya kazi pia kama remote development box inayoendesha Claude Code ndani ya tmux na hutaki kuweka upande huo hadharani.

Kwenye seva ya ufw: ufw allow 51820/udp, DEFAULT_FORWARD_POLICY="ACCEPT" ndani ya /etc/default/ufw, na sheria ya *nat POSTROUTING MASQUERADE juu 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) zilizotokana na AllowedIPs. enable --now ndiyo nusu muhimu: wg-quick up wg0 inayoendeshwa kwa mkono hupotea baada ya reboot inayofuata, na uboreshaji wa kernel unamaanisha reboot. Unit inayoshindwa kurejea baada ya moja ya reboot hizo hubaki kimya hadi mtu ajaribu kuunganisha, kwa hivyo OnFailure= drop-in kwenye wg-quick@wg0 inayoelekeza kwenye seva yako mwenyewe ya ntfy ndiyo njia rahisi zaidi ya kupata taarifa kwenye simu yako badala ya kusubiri mtumiaji aliyefungiwa nje akupigie simu.

Usanidi wa mteja, na mpangilio ambao 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 hufanya kazi mbili tofauti kwa wakati mmoja, na kuzichanganya ndiyo chanzo cha mkanganyiko mwingi kuhusu WireGuard.

Kwa upande wa kutoka (outbound), hii ni jedwali la uelekezaji (routing table). Pakiti ambayo marudio yake yanalingana na AllowedIPs ya peer husimbwa kwa njia fiche na kutumwa kwa peer huyo. 0.0.0.0/0, ::/0 hutuma kila kitu kupitia handaki (tunnel), yaani full tunnel, ambapo seva inakuwa njia chaguo-msingi (default route). Split tunnel ni orodha finyu zaidi: AllowedIPs = 10.8.0.0/24, 10.20.0.0/16 hubeba trafiki ya VPN pamoja na mtandao mmoja wa kibinafsi ulio nyuma ya seva, na kila kitu kingine hubaki kwenye njia yake ya ndani. Orodha hiyo finyu ndiyo inayokuruhusu kuweka huduma mbali kabisa na mtandao wa umma, kama vile instance ya Nextcloud ya kibinafsi kwenye VPS iliyofungwa kwenye anwani ya tunnel, au VMs za maabara ya nested-virtualisation zinazoendeshwa kwenye mashine hiyo hiyo, zibaki kufikika kwa peers na zisizoonekana kwa mtu mwingine yeyote.

Kwa upande wa kuingia (inbound), hii ni orodha ya udhibiti wa ufikiaji (access-control list). Pakiti iliyofunguliwa (decrypted) kutoka kwa peer ambayo anwani yake ya chanzo haipo kwenye AllowedIPs ya peer huyo hutupwa. Hiyo ndiyo sababu seva huorodhesha 10.8.0.2/32 kwa ajili ya kompyuta ya mkononi: ingizo la 0.0.0.0/0 hapo lingemruhusu mteja huyo kughushi (spoof) anwani yoyote ndani ya tunnel.

PersistentKeepalive ni kwa ajili ya wateja walio nyuma ya NAT, ambapo kipanga njia (router) huweka ramani ya UDP wazi pale tu pakiti zinapopita. Inapoisha, seva haiwezi tena kumfikia mteja. PersistentKeepalive = 25 huweka ramani hiyo wazi; iweke kwenye mteja, si kwenye seva yenye IP ya umma.

DNS, na uvujaji ambao hakuna anayeugundua

Pamoja na AllowedIPs = 0.0.0.0/0 na bila mstari wa DNS =, mteja huendelea kutumia resolver aliyojifunza kutoka kwenye mtandao wa ndani, yaani router ya mkahawa iliyo kwenye 192.168.1.1. Njia hiyo ni mahususi zaidi kuliko njia ya kawaida (default route), kwa hivyo maombi ya DNS hutoka kupitia kiungo cha ndani kwa maandishi wazi (cleartext) wakati kila kitu kingine kikiwa kwenye tunnel. Trafiki inabaki kuwa ya faragha; lakini orodha ya majina haibaki hivyo.

Kuna chaguo mbili za kweli. Elekeza DNS kwenye resolver ya umma (DNS = 9.9.9.9) na maombi hayo yatapita kwenye tunnel na kutoka kupitia seva yako, ingawa resolver hiyo bado itayaona. Au endesha unbound au dnsmasq iliyofungwa kwenye 10.8.0.1, weka DNS = 10.8.0.1, na uongeze udp dport 53 iifname "wg0" accept kwenye input chain, weka mstari huo na usahau kuhusu resolver, na hakuna kitakachotatuliwa (resolve) hata kidogo.

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 anayetumia systemd-resolved.

Kuongeza na kuondoa peers bila kukata tunnel

Kuanzisha upya interface ili kuongeza mtumiaji huwakata wote waliounganishwa. Ongeza block ya [Peer] kwenye wg0.conf, kisha pakia upya seti ya peers bila kuzima huduma.

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

wg-quick strip huchapisha usanidi bila funguo za Address, DNS, na PostUp (ambazo ni za syncconf pekee), na syncconf hutumia mabadiliko hayo wakati sessions zikiwa zinaendelea. Hii husasisha peers pekee: mabadiliko ya Address bado yanahitaji kuzima na kuwasha interface kikamilifu. Batilisha ufikiaji kwa sudo wg set wg0 peer <public key> remove, kisha futa block hiyo kutoka kwenye faili ili isirejee wakati wa upakiaji ujao.

Njia za kushindwa, pamoja na ujumbe utakaouona

Handshake haikamiliki kamwe. wg show inaorodhesha peer bila latest handshake, na logi ya mteja inaonyesha:

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 ya mtoa huduma wako, ambayo ni udhibiti tofauti kwenye paneli nyingi; je, anwani ya Endpoint na port ni sahihi; je, funguo zimebadilishana? Ufunguo ulio kwenye block ya [Peer] ya mteja lazima uwe ufunguo wa public wa seva, na kinyume chake; kubandika ufunguo wa private, au ufunguo wa public wa mteja mwenyewe, husababisha dalili hii hasa. sudo tcpdump -ni any udp port 51820 kwenye seva inaonyesha kama pakiti zinafika kabisa. Moduli ya kernel haitoi logi yoyote kwa chaguo-msingi; ujumbe wa WireGuard huonekana kwenye dmesg tu baada ya kuwezesha dynamic debug (echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control), na ukiwa umewashwa, kutolingana kwa ufunguo huonekana kama invalid-MAC drop.

Handshake inafanya kazi, hakuna internet. ping 10.8.0.1 inafanikiwa lakini ping 1.1.1.1 inashindwa kwa muda (timeout): forwarding au NAT haipo. Hakikisha sysctl net.ipv4.ip_forward inasoma 1, kisha fuatilia kaunta wakati mteja anapiga ping, kwa kutumia sudo nft list ruleset au sudo iptables -t nat -L POSTROUTING -n -v. Pakiti sifuri kwenye sheria ya masquerade inamaanisha jina la interface ya egress si sahihi; kaunta inayoongezeka bila majibu inaashiria sera ya forward chain.

Internet inafanya kazi, majina 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 isiyoweza kufikika kutoka ndani ya tunnel.

Baadhi ya tovuti za HTTPS zinakwama. SSH na ping ni sawa; kurasa kubwa zinakwama. Hiyo ni path MTU: tunnel inaongeza overhead, na kiungo fulani katikati kinadondosha pakiti kubwa kupita kiasi bila ujumbe wa ICMP kurudi. Punguza MTU kwenye [Interface] ya mteja, jaribu 1420, kisha 1380, kisha 1280. Ikiwa kupunguza MTU kutatatua kukwama lakini kasi bado haijaridhisha, acha kukisia namba za jumla na ufuate kutafuta path MTU halisi kwa bisection na clamping TCP MSS, ambayo pia huondoa sababu ambazo si za tunnel.

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

Kuhama kutoka Streisand au OpenVPN

Streisand haifanyiwi matengenezo tena na hazina yake imehifadhiwa (archived), na kuendesha VPN kwa kutumia mfumo wa otomatiki uliotelekezwa ni hatari ya kiusalama inayojitokeza taratibu. Hakuna njia ya kufanya upgrade ya moja kwa moja, na PKI ya OpenVPN haiwezi kubadilishwa: WireGuard haina vyeti (certificates), haina CA na haina tarehe ya mwisho wa matumizi, kwa hivyo kila mteja hupata jozi mpya ya funguo (key pair).

Fanya uhamiaji sambamba; WireGuard kwenye UDP 51820 inaweza kuwepo pamoja na OpenVPN kwenye 1194 kwenye seva hiyo hiyo. Sanidi wg0, hamisha wateja mmoja baada ya mwingine, kisha simamisha huduma ya zamani. Mfumo wa jina la mtumiaji/nenosiri na ubatilishaji (revocation) wa OpenVPN hauwezi kuhamishiwa; ikiwa unahitaji akaunti au kumbukumbu za ukaguzi (audit trail), weka safu hiyo juu ya WireGuard.

Hifadhi nakala, uboreshaji, na changamoto za kiwango kikubwa

/etc/wireguard ndiyo seva yenyewe. Ihifadhi nakala (sudo tar czf wg-backup.tgz -C /etc wireguard, mode 600, iliyohifadhiwa nje ya seva) ili uweze kuijenga upya kwenye VPS mpya kwa dakika chache. Ukipoteza private key ya seva, kila configuration ya mteja lazima itolewe upya, kwa sababu wateja hufunga (pin) public key ya seva. Uboreshaji ni apt upgrade ya kawaida pamoja na reboot kwa ajili ya kernel updates, na wg-quick@wg0 hurejea yenyewe ikiwa uliiiwezesha.

Hali ya kila peer ni ndogo na crypto huendeshwa ndani ya kernel, kwa hivyo ukomo unategemea CPU na bandwidth ya VPS yako badala ya kitu chochote katika configuration hii; pima kwa iperf3 kupitia tunnel badala ya kuamini takwimu zilizochapishwa. Kinachozidi uwezo katika kiwango kikubwa ni shughuli za uendeshaji. Kila peer inahitaji IP ya kipekee ya tunnel, na kuhariri kwa mkono vizuizi sitini vya [Peer] ndiyo njia ambayo AllowedIPs zinazofanana huingia: tengeneza configs kutoka kwa script. Seva moja ni UDP endpoint moja na sehemu moja ya kufeli, na WireGuard haina clustering: redundancy inamaanisha seva ya pili yenye funguo zake. Mzunguko wa funguo (key rotation) hubaki wa mikono, kwa hivyo andika nani anashikilia ufunguo upi na jinsi unavyoweza kuufuta. Usimamizi huo ukizidi faili la maandishi, jibu la kawaida ni control plane juu ya data plane ileile ya kernel, na seva ya NetBird inayojiendesha hushughulikia ugawaji wa anwani, usambazaji wa peer, na funguo za usanidi ambazo ungekuwa unafanya kwa mkono. Ikiwa kuendesha control plane hiyo mwenyewe ni kazi nyingi, Tailscale inakuandalia moja, na mpango wake wa bure unashughulikia watumiaji sita wenye vifaa visivyo na kikomo, kiasi ambacho meli nyingi za kibinafsi hazilipii. Baada ya hapo, malipo hutegemea watu badala ya mashine, kwa hivyo kile ambacho kaya au timu ndogo hulipa hutegemea ni wanadamu wangapi wanaoingia, si idadi ya peers ungekuwa unahariri kwa mkono kwenye wg0.conf. Kwa upande huo, usimamizi wa split-tunnel AllowedIPs huwa kutangaza safu zako za kibinafsi kutoka kwa subnet router, inayotangazwa mara moja kutoka kwa VPS moja na kuidhinishwa katikati badala ya kubandikwa kwenye kila faili la mteja. Ikiwa biashara hiyo inafaa inategemea kile ambacho control plane inayohifadhiwa inaweza kufikia, na haitawahi kushikilia funguo zinazosimba trafiki yako, ingawa inaamua ni peers zipi zinazotambulishana.

Yote haya yanahitaji mashine ya Linux unayoimiliki, IP ya umma, kernel unayoweza kupakia module ndani yake, na firewall unayoimiliki kikamilifu.

FAQ

Kwa nini handshake ya WireGuard haikamiliki kamwe?

wg show kuorodhesha peer bila latest handshake inamaanisha pakiti hazifiki au hazikubaliwi. Hakikisha UDP 51820 imefunguliwa kwenye firewall ya VPS na firewall ya mtandao ya mtoa huduma wako, thibitisha Endpoint host na port, kisha hakikisha funguo hazijabadilishana; block ya [Peer] ya mteja lazima iwe na ufunguo wa public wa seva. sudo tcpdump -ni any udp port 51820 kwenye seva inaonyesha kama pakiti zinafika kabisa; dmesg inaripoti tu hitilafu za handshake za WireGuard baada ya kuwezesha dynamic debug (echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control), na hapo kutolingana kwa ufunguo kutaonekana kama invalid-MAC drop.

Tunnel inaunganisha lakini sina internet. Nini kinakosekana?

ping 10.8.0.1 kufanya kazi wakati ping 1.1.1.1 inagoma inaashiria tatizo la forwarding au NAT. Thibitisha sysctl net.ipv4.ip_forward inasoma 1 na imewekwa kwenye /etc/sysctl.d/, si kwa kutumia sysctl -w pekee ambayo hupotea baada ya reboot. Kisha angalia sheria ya masquerade inayotumia interface yako halisi ya egress kutoka ip route show default, enp1s0 au ens3, mara chache eth0.

Je, ninahitaji mstari wa DNS = kwenye config ya mteja wangu?

Kwenye full tunnel bila mstari wa DNS =, mteja anabaki na resolver aliyoipata kutoka kwenye mtandao wa ndani, na maombi hayo hutoka kwa njia ya wazi (cleartext) kupitia link ya ndani wakati kila kitu kingine kinapita kwenye tunnel. Elekeza DNS kwenye resolver ya umma, au endesha unbound/dnsmasq iliyofungwa kwenye 10.8.0.1 na ufungue udp dport 53 iifname "wg0" kwenye input chain.

AllowedIPs inasimamia nini hasa?

Inafanya kazi mbili. Kwa upande wa kutoka (outbound), ni jedwali la routing: trafiki inayolingana na AllowedIPs ya peer husimbwa na kutumwa kwa peer huyo. Kwa upande wa kuingia (inbound), ni orodha ya kudhibiti ufikiaji (access-control list): pakiti iliyosimbuliwa ambayo chanzo chake kiko nje ya AllowedIPs ya peer huyo inakataliwa. Ndiyo maana upande wa seva huorodhesha /32 moja kwa kila mteja wakati upande wa mteja unaweza kuorodhesha 0.0.0.0/0.

Je, WireGuard itafanya kazi kwenye VPS yoyote?

Kwenye KVM VPS inafanya kazi na in-kernel module bila usanidi wa ziada. Kwenye container virtualization inayoshiriki kernel ya host, kama OpenVZ au LXC, modprobe wireguard inashindwa na kutoa Operation not supported na njia mbadala ni utekelezaji wa userspace wa wireguard-go. Endesha sudo modprobe wireguard && echo ok kabla ya kitu kingine chochote.