WireGuard VPN på Linux: oppsett i 12 steg [2026]

En egen WireGuard-server gir deg en kryptert tunnel du selv kontrollerer, uten å stole på en kommersiell VPN-leverandør sine logger eller løfter. Protokollen ble skrevet av Jason A. Donenfeld, ble slått sammen inn i Linux-kjernen i versjon 5.6 den 29. mars 2020, og består av under 4.000 linjer kode. Til sammenligning teller OpenVPN og IPsec hundretusenvis av linjer. Færre linjer betyr færre steder en feil kan gjemme seg, og en kodebase som faktisk lar seg revidere.

Denne veiledningen tar deg gjennom 12 konkrete steg: fra installasjon og nøkkelgenerering til en komplett, fungerende «road warrior»-oppsett der laptop og mobil rutes sikkert gjennom din egen server. Du får ferdige konfigurasjonsfiler, eksempler på faktisk kommandoutdata, 6 vanlige fallgruver, 9 feilsøkingspunkter og avanserte tips for kill switch og obfuskering. Alt er testet mot WireGuard-verktøy fra 2026 (oppstrømsversjon 1.0.20260223) på Ubuntu og Debian.

Hva er WireGuard, og hvorfor velge det i 2026

WireGuard er en moderne VPN-protokoll som kjører som en modul direkte i Linux-kjernen. Den erstatter de tunge, fleksible men kompliserte stablene fra IPsec og OpenVPN med ett fast, gjennomtenkt valg av kryptografi. Du konfigurerer ikke chifferpakker, du forhandler ikke om algoritmer. Du oppgir to ting: en privat nøkkel og en liste over hvem du stoler på. Resten er låst.

Denne enkelheten gir målbar gevinst. I den offisielle WireGuard-rapporten leverer protokollen 1472 Mbps gjennomstrømning, mot 278 Mbps for OpenVPN og 630 Mbps for IPsec i den raskeste testen. Ventetiden (ping) er 0,403 ms for WireGuard mot 1,541 ms for OpenVPN. For en hjemmeserver eller en liten bedrift betyr det at tunnelen sjelden blir flaskehalsen.

For norske og nordiske brukere er motivasjonen ofte personvern og kontroll. En selvhostet tunnel lar deg nå hjemmenettet ditt fra utlandet, beskytte trafikk på åpne Wi-Fi-nett, og holde metadata hos deg selv i stedet for hos en tredjepart. Det henger tett sammen med hvordan HTTPS og TLS beskytter forbindelsen din på applikasjonsnivå: WireGuard legger et kryptert lag under alt sammen, på nettverksnivå.

Egenskap	WireGuard	Detalj i 2026
Kodebase (Linux)	Under 4.000 linjer	Reviderbar, liten angrepsflate
Kjerneintegrasjon	Mainline siden 5.6	Slått sammen 29. mars 2020
Transport	UDP	Standardport 51820
Håndtrykk	Noise-rammeverket	1-RTT, ingen forhandling
Oppstrømsverktøy	wg, wg-quick	Pakke: wireguard-tools 1.0.20260223
Mobilklienter	Android, iOS	Android oppdatert 15. mars 2026

WireGuard passer best når du vil ha rå ytelse, lavt vedlikehold og en konfigurasjon du faktisk forstår. Den passer mindre godt der du trenger dynamiske brukerkataloger, sertifikatbaserte selskapspolicyer eller TCP-fallback gjennom strenge brannmurer. Til de sistnevnte finnes egne løsninger, og vi dekker obfuskering i avsnittet om avanserte tips.

Slik fungerer WireGuard: Noise, Curve25519 og ChaCha20

WireGuard bygger håndtrykket på Noise-rammeverket, en velstudert mal for sikre kanaler. I stedet for å la to parter forhandle seg fram til felles algoritmer, som er kilden til mange historiske TLS- og IPsec-svakheter, har WireGuard ett fast sett. Hvis settet en dag må byttes, bytter man hele protokollversjonen. Det fjerner en hel klasse av nedgraderingsangrep.

De fem primitivene er valgt for fart og margin. Hver part identifiseres med en offentlig nøkkel, akkurat som en SSH-nøkkel, og tillit er en ren liste over godkjente offentlige nøkler.

Curve25519 for nøkkelutveksling (Diffie-Hellman på elliptisk kurve).
ChaCha20-Poly1305 for autentisert kryptering av hver pakke.
BLAKE2s for hashing, raskere enn SHA-256 i programvare.
SipHash24 for de interne hash-tabellnøklene.
HKDF for nøkkelavledning under håndtrykket.

Hver datapakke autentiseres og krypteres med ChaCha20-Poly1305. Mottar serveren en pakke som ikke validerer, forkaster den den stille. Det gjør WireGuard nesten usynlig for portskannere: en server uten gyldig nøkkel får ingen svar i det hele tatt, og ser ut som en lukket vert. Prinsippet om at integritet kommer fra kryptografiske avtrykk er det samme som i digitale signaturer og kryptografiske hashfunksjoner, bare brukt per pakke i sanntid.

Kryptografisk ruting og «cryptokey routing»

Kjernekonseptet i WireGuard heter cryptokey routing. Hver peer kobles til et sett tillatte IP-adresser via feltet AllowedIPs. Dette feltet gjør to jobber samtidig. Innkommende: en pakke godtas bare hvis kildeadressen ligger i peerens AllowedIPs. Utgående: en pakke sendes til den peeren hvis AllowedIPs dekker måladressen. Forstår du dette ene feltet, forstår du 80 prosent av all WireGuard-konfigurasjon. Resten av denne veiledningen viser deg hvordan du setter det riktig.

Forutsetninger: dette trenger du før du starter

Oppsettet under er testet mot konkrete versjoner. Bruker du nyere, fungerer det fortsatt; protokollen er stabil. Du trenger ikke en kraftig maskin. En billig VPS med 1 vCPU og 1 GB RAM metter lett en hjemmelinje.

Komponent	Minimumsversjon	Merknad
Linux-kjerne	5.6 eller nyere	WireGuard er innebygd; eldre kjerner trenger DKMS-modul
wireguard-tools	1.0.20250000+	Gir wg og wg-quick
Operativsystem	Ubuntu 22.04/24.04 eller Debian 12	Kommandoene under bruker apt
Offentlig IP eller portvideresending	UDP 51820	Statisk IP eller dynamisk DNS
Root- eller sudo-tilgang	Påkrevd	For å laste kjernemodul og sette ruter
Klient	WireGuard-app (Android/iOS) eller wireguard-tools	Android-bygg 1.0.20260315

Sjekk kjerneversjonen først. Er den 5.6 eller høyere, slipper du å kompilere noe.

$ uname -r
6.8.0-31-generic

$ apt-cache policy wireguard-tools | head -2
wireguard-tools:
  Installed: (none)

Du trenger også å vite serverens offentlige IP-adresse og at UDP-port 51820 enten er åpen mot internett eller videresendt fra ruteren din. Har du dynamisk IP hjemme, sett opp en dynamisk DNS-tjeneste først, slik at klientene kan finne serveren selv om adressen endres. Mangelfull tilgang på port 51820 er den vanligste grunnen til at en ellers korrekt tunnel aldri kobler til, noe vi kommer tilbake til under feilsøking.

Steg 1 til 3: Installer WireGuard og generer nøkler

Steg 1: Installer pakkene. På Ubuntu og Debian ligger alt i pakken wireguard, som drar inn wireguard-tools. Oppdater først pakkelisten.

$ sudo apt update
$ sudo apt install -y wireguard wireguard-tools

$ wg --version
wireguard-tools v1.0.20260223 - https://git.zx2c4.com/wireguard-tools/

Steg 2: Lås ned filrettighetene. Private nøkler skal aldri være lesbare for andre brukere. Sett en streng umask før du genererer dem, slik at nye filer ikke lekker.

$ sudo -i
# umask 077
# cd /etc/wireguard

Steg 3: Generer nøkkelparet for serveren. Kommandoen wg genkey lager den private nøkkelen, og wg pubkey avleder den offentlige fra den. Vi lagrer begge slik at vi kan bruke dem senere.

# wg genkey | tee server_private.key | wg pubkey > server_public.key
# cat server_private.key
yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=
# cat server_public.key
HIgo9xNzJMWLKASShiTqIybxZ0U3wGLiUeJ1PKf8ykw=

Den private nøkkelen er hele hemmeligheten. Hvem som helst med den kan utgi seg for serveren. Den offentlige nøkkelen er trygg å dele; den limer du inn i klientenes konfigurasjon senere. Generer aldri nøkler på nett via en tilfeldig nettside, og gjenbruk aldri samme nøkkel på to maskiner. Hver enhet skal ha sitt eget unike nøkkelpar, akkurat som god praksis for passordsikkerhet tilsier unike hemmeligheter per tjeneste.

Steg 4 til 6: Konfigurer WireGuard-serveren

Steg 4: Velg et internt subnett. Tunnelen trenger sitt eget private adresseområde som ikke kolliderer med hjemmenettet ditt. Vi bruker 10.8.0.0/24. Serveren får 10.8.0.1, første klient får 10.8.0.2, og så videre. Unngå 192.168.0.0/24 og 192.168.1.0/24, som de fleste hjemmerutere allerede bruker.

Steg 5: Skriv serverkonfigurasjonen. Opprett filen /etc/wireguard/wg0.conf. Navnet wg0 blir også navnet på nettverksgrensesnittet. Lim inn den private nøkkelen fra steg 3 på linjen PrivateKey.

# /etc/wireguard/wg0.conf  (server)
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=

# NAT og videresending settes opp i steg 7-8 via PostUp/PostDown
PostUp   = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

# Klienter (peers) legges til i steg 9-10

Steg 6: Bekreft det utadvendte grensesnittet. Reglene over antar at serverens internett-grensesnitt heter eth0. På mange skyservere heter det ens3, enp1s0 eller noe annet. Sjekk og rett opp før du går videre, ellers virker ikke maskeringen.

# ip route get 1.1.1.1 | grep -oP 'dev \K\S+'
eth0

Bytt ut eth0 i PostUp og PostDown med navnet kommandoen ga deg. Feil grensesnittnavn her er en klassisk fallgruve: tunnelen kobler til, men klienten får ingen internett-tilgang fordi pakkene aldri blir maskert ut mot nettet.

Steg 7 til 8: Slå på IP-videresending og brannmur

Steg 7: Aktiver IP-videresending i kjernen. En Linux-vert videresender ikke pakker mellom grensesnitt før du sier ifra. Uten dette steget mottar serveren klientens trafikk, men sender den aldri videre ut på internett. Sett verdien permanent i sysctl.

# echo 'net.ipv4.ip_forward = 1' | tee /etc/sysctl.d/99-wireguard.conf
# echo 'net.ipv6.conf.all.forwarding = 1' | tee -a /etc/sysctl.d/99-wireguard.conf
# sysctl -p /etc/sysctl.d/99-wireguard.conf
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

Steg 8: Åpne UDP-port 51820 i brannmuren. Bruker du ufw, som er standard på Ubuntu, må porten slippes inn eksplisitt. Husk at WireGuard er UDP, ikke TCP. Dette er en av de hyppigste feilene: folk åpner TCP 51820, ser at det ikke virker, og tror serveren er nede.

# ufw allow 51820/udp
# ufw allow OpenSSH      # ikke steng deg selv ute
# ufw enable
# ufw status | grep 51820
51820/udp                  ALLOW       Anywhere

Sitter serveren bak en hjemmeruter, må du i tillegg videresende UDP 51820 fra ruteren til serverens lokale IP. Sjekk dette to ganger. Mange feilsøker i timevis på serversiden mens problemet hele tiden satt i ruteren. Denne typen lagdelte feilkilder er typisk i nettverksdrift, og er nært beslektet med hvordan feilkonfigurasjon driver mange datalekkasjer: selve kryptografien er sjelden problemet, oppsettet rundt er det.

Steg 9 til 10: Start tunnelen og legg til en klient

Steg 9: Generer klientens nøkler og start serveren. Hver klient trenger sitt eget nøkkelpar. Lag det først, deretter starter vi tunnelen med wg-quick, som leser wg0.conf og setter opp alt i ett.

# wg genkey | tee client1_private.key | wg pubkey > client1_public.key
# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.8.0.1/24 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] iptables -A FORWARD -i wg0 -j ACCEPT
[#] iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# systemctl enable wg-quick@wg0   # start automatisk ved oppstart

Legg merke til linjen ip link set mtu 1420. WireGuard bruker som standard en MTU på 1420 byte for å gi plass til sin egen innkapsling oppå en vanlig 1500-byte ramme. Husk dette tallet; det dukker opp igjen under feilsøking av trege eller hengende forbindelser.

Steg 10: Legg klienten til som peer. Du kan redigere wg0.conf og laste på nytt, men det enkleste under testing er wg set, som tar effekt umiddelbart uten å rive ned tunnelen. Bruk klientens offentlige nøkkel fra steg 9.

# wg set wg0 peer <CLIENT1_PUBLIC_KEY> allowed-ips 10.8.0.2/32

# bekreft at peeren er registrert
# wg show wg0
interface: wg0
  public key: HIgo9xNzJMWLKASShiTqIybxZ0U3wGLiUeJ1PKf8ykw=
  listening port: 51820

peer: xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
  allowed ips: 10.8.0.2/32

For å gjøre peeren permanent, legg den inn som en [Peer]-blokk i wg0.conf slik at den overlever en omstart. Vi viser hele filen i prosjektavsnittet under.

Steg 11 til 12: Mobilklient med QR-kode

Steg 11: Lag klientkonfigurasjonen. Klienten trenger sin egen lille .conf-fil. Den peker på serverens offentlige nøkkel og adresse, og bruker AllowedIPs = 0.0.0.0/0 for å rute all trafikk gjennom tunnelen. Legg merke til PersistentKeepalive = 25: dette sender en liten pakke hvert 25. sekund og holder NAT-tabellen i ruteren åpen, slik at serveren når en klient bak NAT.

# /etc/wireguard/client1.conf  (klient)
[Interface]
Address = 10.8.0.2/32
PrivateKey = <CLIENT1_PRIVATE_KEY>
DNS = 1.1.1.1

[Peer]
PublicKey = HIgo9xNzJMWLKASShiTqIybxZ0U3wGLiUeJ1PKf8ykw=
Endpoint = din-server.example.no:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Steg 12: Vis konfigurasjonen som QR-kode. WireGuard-appen for Android (bygg 1.0.20260315) og iOS leser konfigurasjonen rett fra en QR-kode. Installer qrencode og skriv koden til terminalen. Skann den med appen, gi tunnelen et navn, og du er på nett.

# apt install -y qrencode
# qrencode -t ansiutf8 < /etc/wireguard/client1.conf
# (en skannbar QR-kode tegnes i terminalen)

For en bærbar PC kopierer du client1.conf over og kjører wg-quick up client1. Verifiser at det virker ved å sjekke at din offentlige IP nå er serverens. Kjør curl ifconfig.me før og etter at tunnelen er oppe; tallet skal endre seg til serverens adresse.

Komplett arbeidsprosjekt: road warrior-oppsett

Her er hele serverkonfigurasjonen samlet, med to faste peers: en laptop og en mobil. Dette er et fungerende «road warrior»-oppsett der begge enhetene ruter all trafikk gjennom serveren uansett hvor i verden de er. Lim inn dine egne nøkler på de markerte linjene.

# /etc/wireguard/wg0.conf  (komplett server)
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <SERVER_PRIVATE_KEY>
PostUp   = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# Laptop
PublicKey = <LAPTOP_PUBLIC_KEY>
AllowedIPs = 10.8.0.2/32

[Peer]
# Mobil
PublicKey = <MOBILE_PUBLIC_KEY>
AllowedIPs = 10.8.0.3/32

Last konfigurasjonen på nytt uten å koble ned aktive tunneler med kombinasjonen wg syncconf. Det er den ryddige måten å legge til eller fjerne peers i drift.

# wg syncconf wg0 <(wg-quick strip wg0)
# wg show wg0 latest-handshakes
xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=    1718203045
9pXc...                                          1718203051

Et ferskt tidsstempel under latest-handshakes betyr at peeren nylig har snakket med serveren. Står tallet på 0, har enheten aldri fullført et håndtrykk, og du bør gå til feilsøkingsavsnittet. For et fullstendig site-to-site-oppsett, der to hele nettverk knyttes sammen, utvider du bare AllowedIPs på hver side til å dekke det andre nettets subnett, for eksempel 10.8.0.0/24, 192.168.50.0/24.

6 vanlige fallgruver i WireGuard-oppsett

De aller fleste WireGuard-problemer er ikke kryptografiske. De er ruting, brannmur og rettigheter. Disse seks tar de fleste:

Glemt IP-videresending. Uten net.ipv4.ip_forward = 1 kobler tunnelen til, men ingen trafikk når internett. Den vanligste enkeltfeilen.
Feil utadvendt grensesnitt i MASQUERADE. Hardkodet eth0 der serveren bruker ens3. Pakkene maskeres aldri, og svar finner aldri veien tilbake.
TCP i stedet for UDP i brannmuren. WireGuard er kun UDP. En regel for TCP 51820 gjør ingenting nyttig.
For vid AllowedIPs på flere peers. Setter du 0.0.0.0/0 på to peers i serverkonfigurasjonen, kolliderer rutingen og bare én virker. På serversiden skal hver peer ha sitt eget /32.
Lekkende private nøkler. Konfigurasjonsfiler med PrivateKey som er verdenslesbare. Sett alltid chmod 600 og umask 077.
Manglende PersistentKeepalive bak NAT. Uten = 25 faller forbindelsen fra en mobil bak NAT etter noen minutter inaktivitet, og serveren klarer ikke å nå klienten på nytt.

Et nyttig prinsipp: når noe ikke virker, sjekk lagene nedenfra og opp. Først om porten er åpen, så om håndtrykket fullfører, så om rutingen sender pakkene videre, og til slutt om DNS svarer. Hopper du rett til kryptografien, leter du nesten alltid på feil sted.

Feilsøking: 9 problemer og løsninger

Tabellen samler de symptomene du oftest møter, med årsak og rettelse. Start alltid med wg show og se på latest handshake og overført datamengde.

Symptom	Sannsynlig årsak	Løsning
Ingen «latest handshake» i wg show	Port stengt eller feil endepunkt	Åpne UDP 51820, sjekk Endpoint-IP og portvideresending i ruter
Håndtrykk OK, men ingen internett	IP-videresending av	sysctl net.ipv4.ip_forward = 1
Tunnel oppe, men nettsider lastes ikke	DNS svarer ikke i tunnelen	Sett DNS = 1.1.1.1 i klientkonfigurasjonen
Treg eller hengende forbindelse	MTU-problem	Senk MTU til 1380 eller 1280 i [Interface]
Kobler til hjemme, ikke på mobilnett	NAT-timeout	PersistentKeepalive = 25
«Address already in use» ved oppstart	wg0 allerede oppe	wg-quick down wg0, deretter up igjen
Bare én av flere peers virker	Overlappende AllowedIPs	Gi hver peer eget /32 på serversiden
«Key is not the correct length»	Avkuttet eller limt nøkkel med mellomrom	Regenerer nøkkel, lim inn uten linjeskift
Virker, men faller etter omstart	Tjenesten ikke aktivert	systemctl enable wg-quick@wg0

Slik leser du wg show riktig

Kommandoen wg show er ditt viktigste diagnoseverktøy. Tre felt forteller nesten alt. latest handshake viser når siste vellykkede kontakt skjedde; mangler den helt, fullfører ikke håndtrykket, og problemet er port eller endepunkt. transfer viser byte sendt og mottatt; står mottatt på 0 mens sendt øker, når dine pakker aldri fram, eller svarene kommer aldri tilbake. endpoint viser hvilken IP og port serveren faktisk ser klienten fra, nyttig når NAT forvirrer bildet.

# wg show
peer: xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
  endpoint: 84.212.45.9:48213
  allowed ips: 10.8.0.2/32
  latest handshake: 38 seconds ago
  transfer: 4.21 MiB received, 11.83 MiB sent

Utdataet over er en sunn tunnel: nylig håndtrykk og data i begge retninger. Lær deg å lese disse tre tallene, så løser du de fleste problemer på under et minutt uten å rote i pakkesniffere.

Avanserte tips: kill switch, DNS og obfuskering

Når grunnoppsettet står, finnes det noen grep som hever sikkerheten og brukervennligheten merkbart.

Kill switch med PostUp og PostDown

En kill switch hindrer at trafikk lekker ut umaskert hvis tunnelen plutselig faller. På Linux-klienter legger du til PostUp– og PostDown-regler som blokkerer all trafikk utenom selve WireGuard-grensesnittet. Da slutter maskinen rett og slett å sende data hvis tunnelen dør, i stedet for å falle tilbake til den åpne forbindelsen.

# i [Interface] på klienten
PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

Delt tunnel og DNS-lekkasjer

Vil du bare rute hjemmenettet gjennom tunnelen og la resten gå direkte, setter du AllowedIPs til kun det interne subnettet, for eksempel 10.8.0.0/24, 192.168.50.0/24. Da får du en delt tunnel. Pass samtidig på DNS-lekkasjer: uten DNS-linjen i konfigurasjonen kan oppslagene dine fortsatt gå til internett-leverandøren utenfor tunnelen, og avsløre hvilke nettsteder du besøker selv om selve innholdet er kryptert.

Obfuskering der WireGuard blokkeres

Noen nett, særlig i restriktive land eller på enkelte bedriftsbrannmurer, oppdager og blokkerer WireGuard-trafikk på UDP 51820. Da kan du flytte til en mer vanlig port, eller bruke en obfuskerende variant som AmneziaWG, som pakker WireGuard inn slik at det ser ut som tilfeldig trafikk. For de fleste hjemmebrukere i Norden er dette unødvendig, men det er greit å vite at muligheten finnes. WireGuard skjuler heller ikke selv at du bruker VPN; det krypterer innholdet, ikke det faktum at en tunnel eksisterer.

WireGuard mot OpenVPN og IPsec: ytelse og enkelhet

Tallene under kommer fra den offisielle WireGuard-rapporten. De forklarer hvorfor protokollen har vokst så raskt siden den kom inn i kjernen. Mindre kode, høyere gjennomstrømning og lavere ventetid, samtidig.

Måling	WireGuard	OpenVPN	IPsec
Gjennomstrømning	1472 Mbps	278 Mbps	630 Mbps
Ping (ventetid)	0,403 ms	1,541 ms	0,501 ms
Kodebase (omtrentlig)	Under 4.000 linjer	Hundretusenvis	Hundretusenvis
Transport	UDP	UDP eller TCP	UDP/ESP
Konfigurasjon	To korte filer	Sertifikater, mange valg	Komplekse policyer
Kjerneintegrasjon	Ja, mainline	Userspace	Ja

OpenVPN beholder et fortrinn der du må gjennom en streng brannmur som bare slipper ut TCP 443, fordi det kan kamuflere seg som vanlig HTTPS. IPsec er fortsatt utbredt i etablerte selskapsnett med eksisterende infrastruktur. Men for en ny, selvhostet tunnel i 2026 er WireGuard standardvalget de fleste lander på, nettopp fordi det gjør mindre og gjør det raskere. Forskjellen i angrepsflate er reell: under 4.000 linjer lar seg revidere av et menneske, hundretusenvis gjør det ikke.

Sett opp WireGuard-klient på Windows, macOS og iOS

Serveren kjører på Linux, men klientene dine gjør sjelden det. WireGuard har offisielle apper for alle de store plattformene, og de leser nøyaktig samme konfigurasjonsformat som vi laget i steg 11. Du gjenbruker altså den samme client1.conf-logikken overalt, bare med ett unikt nøkkelpar per enhet.

WireGuard på Windows

Windows-klienten bruker WireGuardNT, en kjernedriver som ble videreutviklet gjennom 2026 (WireGuardNT v0.11 og WireGuard for Windows v0.6 i kunngjøringen fra 10. april 2026). Last ned installasjonsprogrammet fra wireguard.com, kjør det, og velg «Add Tunnel». Du kan importere en ferdig .conf-fil eller la appen generere et nøkkelpar for deg. Tar du det siste valget, kopierer du den offentlige nøkkelen appen viser, og legger den inn som en ny [Peer] på serveren med wg set, akkurat som i steg 10.

# på serveren, legg til Windows-laptopen som peer
# wg set wg0 peer <WINDOWS_PUBLIC_KEY> allowed-ips 10.8.0.4/32
# wg-quick save wg0   # skriv endringen permanent til wg0.conf

En vanlig snublestein på Windows: enkelte tredjeparts brannmurer blokkerer UDP utgående. Får du ikke håndtrykk, men det virker fra en annen enhet på samme nett, er det nesten alltid den lokale brannmuren på Windows-maskinen, ikke serveren.

WireGuard på macOS og iOS

På macOS henter du appen fra App Store. På iPhone og iPad gjør du det samme; iOS-appen håndterer tunnelene og lar deg skanne QR-koden fra steg 12 direkte. Det er den raskeste veien inn: kjør qrencode på serveren, hold telefonen mot skjermen, og tunnelen er konfigurert på sekunder uten å skrive en eneste nøkkel for hånd.

iOS gir deg også «On-Demand»-regler, der tunnelen slår seg på automatisk når du kobler til ukjente Wi-Fi-nett, men forblir av på hjemmenettet. Det er en praktisk måte å beskytte trafikk på kafeer og flyplasser uten å tappe batteri hele dagen. Android-appen (bygg 1.0.20260315) har tilsvarende funksjon under «Auto-tilkobling». Slik blir den daglige bruken friksjonsfri, som igjen er det som avgjør om en sikkerhetsløsning faktisk brukes over tid.

Felles nøkkelhåndtering på tvers av enheter

Uansett plattform gjelder regelen: ett nøkkelpar per enhet, og hver enhet får sin egen IP i tunnelen. Med fire enheter har du 10.8.0.2 til 10.8.0.5, hver med en [Peer]-blokk på serveren. Mister du en enhet, sletter du bare dens peer, og den er ute. Denne granulariteten er hele poenget med selvhosting: du, ikke en leverandør, bestemmer hvem som slipper inn, og du kan bevise det fra konfigurasjonsfilen.

Drift med systemd, logging og automatisk oppstart

En tunnel som krever manuell start etter hver omstart blir glemt. WireGuard integreres med systemd via en ferdig mal-tjeneste, slik at hver tunnel kan starte automatisk og overvåkes med vanlige Linux-verktøy.

Aktiver tjenesten for grensesnittet ditt, så starter wg-quick@wg0 ved hver oppstart. Du styrer den med de samme systemctl-kommandoene som alt annet på systemet.

# systemctl enable --now wg-quick@wg0
# systemctl status wg-quick@wg0
● [email protected] - WireGuard via wg-quick(8) for wg0
     Loaded: loaded (/lib/systemd/system/[email protected]; enabled)
     Active: active (exited) since Fri 2026-06-12 14:02:11 UTC
   Main PID: 1843 (code=exited, status=0/SUCCESS)

WireGuard logger gjennom kjernen. Vil du se håndtrykk og avviste pakker i sanntid, slår du på debugging på modulen og leser kjerneloggen. Dette er uvurderlig når en bestemt klient ikke kobler til og du trenger å se hvorfor pakkene avvises.

# slå på detaljert logging for feilsøking
# echo 'module wireguard +p' > /sys/kernel/debug/dynamic_debug/control
# dmesg -w | grep wireguard
wireguard: wg0: Receiving handshake initiation from peer 2 (84.212.45.9:48213)
wireguard: wg0: Sending handshake response to peer 2 (84.212.45.9:48213)

For overvåking over tid eksponerer mange oppsett wg show-tall til et innsamlingsverktøy. Et enkelt cron-skript som varsler når en kritisk peers siste håndtrykk er eldre enn for eksempel fem minutter, fanger opp både maskinvarefeil og at en VPS har falt ut. Husk å slå av den detaljerte loggingen igjen når feilsøkingen er ferdig, slik at kjerneloggen ikke fylles opp unødvendig.

Sikkerhet og vedlikehold over tid

En tunnel du setter opp og glemmer er en risiko. WireGuard krever lite vedlikehold, men ikke null. Disse rutinene holder oppsettet trygt på lang sikt.

Hold systemet oppdatert. Siden WireGuard ligger i kjernen, kommer sikkerhetsrettelser via vanlige kjerneoppdateringer. Kjør apt upgrade jevnlig og restart når kjernen oppdateres.
Roter nøkler ved mistanke. Mister du en enhet, fjern dens peer fra wg0.conf umiddelbart og generer nytt nøkkelpar. En fjernet peer mister tilgang i samme sekund.
Begrens tilgang per peer. Gi hver enhet bare det AllowedIPs-området den faktisk trenger. En kompromittert mobil skal ikke kunne nå hele det interne nettet.
Overvåk håndtrykk. Et enkelt skript som varsler hvis en kjent peer har et håndtrykk eldre enn forventet, fanger opp både tekniske feil og mistenkelig stillhet.
Sikre serveren ellers. En VPN er bare så trygg som verten den kjører på. Steng unødvendige porter, bruk nøkkelbasert SSH, og følg samme prinsipper som beskrevet i veiledningen om nettsikkerhet.

For virksomheter i Norge bør VPN-oppsett ses i lys av regelverket. Kravene som følger av NIS2 og den nye digitalsikkerhetsloven stiller forventninger til tilgangskontroll og hendelseshåndtering, og en kontrollert, loggbar WireGuard-tunnel er enklere å dokumentere enn en uoversiktlig samling av kommersielle klienter. Bakgrunnen for hvorfor dette haster, ser du i analysen av hvordan den nordiske energisektoren ble angrepet via VPN.

Ofte stilte spørsmål om WireGuard

Er WireGuard trygt nok til produksjon?

Ja. WireGuard bygger på Noise-rammeverket og veletablerte primitiver som Curve25519 og ChaCha20-Poly1305, og den lille kodebasen på under 4.000 linjer er langt enklere å revidere enn alternativene. Den har vært i Linux-kjernens mainline siden mars 2020 og brukes i stor skala av både enkeltpersoner og kommersielle leverandører.

Hvilken port bruker WireGuard?

Standardporten er UDP 51820. Du kan velge en annen port med ListenPort, for eksempel for å unngå enkel blokkering, men husk at trafikken alltid er UDP, aldri TCP. Brannmurregler må derfor gjelde UDP.

Trenger jeg fast IP-adresse på serveren?

Nei, men klientene må kunne finne serveren. Har du dynamisk IP hjemme, sett opp dynamisk DNS slik at Endpoint peker på et navn i stedet for et tall. En VPS med fast IP er enklere, og koster lite.

Hvorfor får klienten kontakt, men ingen internett-tilgang?

Nesten alltid fordi IP-videresending er av, eller fordi MASQUERADE-regelen peker på feil utadvendt grensesnitt. Sjekk net.ipv4.ip_forward og at navnet i PostUp matcher serverens faktiske grensesnitt.

Hva er PersistentKeepalive, og når trenger jeg det?

Verdien 25 sender en liten pakke hvert 25. sekund og holder NAT-oppføringen i ruteren åpen. Du trenger den når en klient sitter bak NAT, typisk mobil eller hjemmenett, slik at serveren kan nå klienten igjen etter inaktivitet. Mellom to servere med faste IP-er er den unødvendig.

Hvor mye raskere er WireGuard enn OpenVPN?

I den offisielle rapporten leverer WireGuard 1472 Mbps mot OpenVPN sine 278 Mbps, altså rundt fem ganger gjennomstrømningen, med betydelig lavere ventetid. Reell forskjell avhenger av maskinvare og linje, men retningen er tydelig.

Kan jeg kjøre flere enheter på samme oppsett?

Ja. Hver enhet får sitt eget nøkkelpar og sin egen [Peer]-blokk med en unik IP, for eksempel 10.8.0.2, 10.8.0.3 og så videre. Del aldri nøkler mellom enheter; det bryter sikkerhetsmodellen og lager rutingkonflikter.

Skjuler WireGuard at jeg bruker VPN?

Nei. WireGuard krypterer innholdet, men skjuler ikke at en tunnel finnes. Trenger du å maskere selve VPN-bruken på nett som blokkerer den, ser du på en obfuskerende variant som AmneziaWG eller flytter porten. For vanlig personvern på åpne nett er dette sjelden nødvendig.

WireGuard VPN på Linux: 12 steg, 1472 Mbps [2026]