Veelgestelde problemen
Twee servers, één `wg0.conf` die je met de hand intypt, en de vraag of het pakketje van je distributie wel de kernelmodule meebrengt. WireGuard bestaat uit weinig meer dan dat, en dat is precies het punt.
Dit artikel zet een werkende site-to-site tunnel op tussen twee Linux-hosts met WireGuard 1.0.20210914 of nieuwer. Je leert waarom elke regel in het configuratiebestand er staat, zodat je hem later zelf kunt aanpassen als je netwerk verandert.
Vereisten
- Twee Linux-systemen met kernel 5.6 of hoger. Vanaf die versie zit WireGuard in de mainline kernel en heb je geen DKMS-pakket meer nodig.
- Root-toegang op beide machines, of sudo.
- `wireguard-tools` versie 1.0.20210914 of nieuwer op beide hosts. Op Debian 12 en Ubuntu 22.04 is dat het pakket `wireguard`; op RHEL 9 en afgeleiden `wireguard-tools`.
- Een publiek bereikbaar IP-adres of een DNS-naam op minstens één van de twee hosts, zodat de andere peer een eindpunt heeft om naartoe te verbinden.
- UDP-poort 51820 open in de firewall aan de kant die luistert.
```bash uname -r ```
Zit je onder 5.6, dan moet je een DKMS-module installeren en dat is een apart verhaal met eigen problemen bij elke kernel-upgrade. Upgrade liever.
Stappen
1. Installeer de tools
Op Debian en Ubuntu:```bash sudo apt update sudo apt install wireguard ```
Op RHEL 9, Rocky en AlmaLinux:
```bash sudo dnf install wireguard-tools ```
Je installeert hiermee alleen `wg` en `wg-quick`. De kernelmodule zit al in je kernel. Dat is het hele pakket — geen daemon, geen service die op de achtergrond draait, geen configuratie-database.
2. Genereer op elke host een sleutelpaar
Doe dit op beide machines, niet één keer en dan kopiëren.```bash umask 077 wg genkey | tee privatekey | wg pubkey > publickey ```
De `umask 077` zorgt dat de privésleutel alleen voor jou leesbaar is. Zonder die regel schrijf je hem weg met de standaardrechten en kan elke gebruiker op de machine hem lezen. WireGuard waarschuwt daar niet voor.
Bekijk het resultaat:
```bash cat privatekey cat publickey ```
De privésleutel verlaat de machine nooit. De publieke sleutel mag je vrij delen — die gaat straks in de configuratie van de andere peer.
3. Noteer de netwerkgegevens
WireGuard gebruikt zijn eigen adressen voor de tunnel, los van je bestaande netwerken. Kies een subnet dat nergens anders in gebruik is, bijvoorbeeld `10.10.9.0/24`.Voor deze opzet:
- Host A (Amsterdam): publiek IP `203.0.113.10`, tunnel-IP `10.10.9.1`, lokaal netwerk `10.10.10.0/24`
- Host B (Rotterdam): publiek IP `203.0.113.20`, tunnel-IP `10.10.9.2`, lokaal netwerk `10.10.11.0/24`
4. Schrijf de configuratie op host A
Maak `/etc/wireguard/wg0.conf`:```ini
[Interface]
Address = 10.10.9.1/24
ListenPort = 51820
PrivateKey =
[Peer]
PublicKey =
De `[Interface]`-sectie beschrijft de lokale kant: welk IP deze machine in de tunnel krijgt en op welke poort hij luistert. De `[Peer]`-sectie beschrijft de andere kant.
`AllowedIPs` is de regel die mensen het vaakst verkeerd begrijpen. Het doet twee dingen tegelijk: het bepaalt welk verkeer WireGuard door de tunnel stuurt, en het bepaalt welk bron-IP geaccepteerd wordt van die peer. Zet je hier `10.10.11.0/24` neer, dan routeert deze host verkeer naar dat netwerk via de tunnel. Zet je het er niet neer, dan komt het verkeer niet aan — ook al staat de tunnel verder correct.
5. Schrijf de configuratie op host B
Maak `/etc/wireguard/wg0.conf` op host B:```ini
[Interface]
Address = 10.10.9.2/24
PrivateKey =
[Peer]
PublicKey =
Host B heeft geen `ListenPort` nodig, want hij initieert de verbinding. Hij heeft wel een `Endpoint` nodig: het publieke adres van host A.
`PersistentKeepalive = 25` stuurt elke 25 seconden een leeg pakketje. Dat is nodig als host B achter NAT zit. Zonder keepalive sluit de NAT-tabel de mapping na een paar minuten en kan host A host B niet meer bereiken — ook al staat de tunnel aan beide kanten nog "up". De keerzijde: het kost je een klein beetje verkeer en het houdt de verbinding permanent open, wat op een laptop op accu merkbaar is.
6. Zet beide tunnels op
Op host A:```bash sudo wg-quick up wg0 ```
Op host B:
```bash sudo wg-quick up wg0 ```
`wg-quick` leest het configuratiebestand, maakt de interface aan, zet het IP-adres, stelt de routes in en laadt de sleutels in de kernel. Meer doet het niet. Je kunt het script lezen als je wilt weten wat er precies gebeurt — het is een paar honderd regels shell.
7. Zet IP-forwarding aan
Dit is de stap die mensen overslaan, waarna het verkeer tussen de twee LAN's niet aankomt.Op beide hosts:
```bash echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf sudo sysctl --system ```
Zonder forwarding accepteert de kernel wel pakketten op de tunnel-interface, maar stuurt hij ze niet door naar het andere netwerk. De tunnel is dan "up" en je kunt pingen naar `10.10.9.1`, maar niet naar iets in `10.10.10.0/24`. Dat onderscheid tussen "tunnel werkt" en "routering werkt" kost veel mensen een avond.
8. Maak de tunnels permanent
`wg-quick up` is tijdelijk. Na een reboot is de interface weg. Systemd regelt dat:```bash sudo systemctl enable wg-quick@wg0 sudo systemctl start wg-quick@wg0 ```
Doe dit op beide hosts. De service heet `wg-quick@wg0.service`, waarbij `wg0` de bestandsnaam van je configuratie is. Noem je het bestand `wg1.conf`, dan wordt de service `wg-quick@wg1`.
Wat dit je kost: de tunnel start nu bij elke boot, ook als je hem even niet wilt. Je moet hem expliciet stoppen met `systemctl stop wg-quick@wg0` in plaats van hem gewoon niet op te starten. Voor een server is dat precies wat je wilt; voor een testmachine is het een extra handeling.
Verificatie
Kijk op host A of de peer gezien wordt:```bash sudo wg show ```
Je ziet de interface, de publieke sleutel, de listen-poort en per peer een `latest handshake`-regel. Staat daar een tijd binnen enkele minuten, dan is de tunnel tot stand gekomen. Staat er `(never)`, dan is er nog nooit verkeer uitgewisseld en klopt er iets niet aan het endpoint of de firewall.
Test vervolgens de routering, niet alleen de tunnel:
```bash ping -c 3 10.10.9.2 ping -c 3 10.10.11.1 ```
De eerste ping gaat over de tunnel zelf. De tweede gaat over de tunnel én door naar het achterliggende netwerk. Alleen als beide werken, is de site-to-site-koppeling functioneel.
Veelgestelde problemen
Handshake lukt niet, `wg show` blijft `(never)` tonen. Negen van de tien keer is dit de firewall. UDP-poort 51820 moet open staan aan de kant die luistert. Controleer met `sudo ss -ulnp | grep 51820` of WireGuard daadwerkelijk luistert, en test de poort van buitenaf. WireGuard antwoordt niet op ICMP en niet op een leeg UDP-pakket, dus een `ping` naar de poort zegt niets.Tunnel is up, maar hosts in het andere subnet zijn onbereikbaar. Controleer `net.ipv4.ip_forward`. Draai je op een host die zelf ook gateway is, dan moet je daarnaast controleren of de clients in je LAN een route naar het tunnel-subnet hebben. Vaak wijst de default gateway van die clients naar je router, en die router weet niets van `10.10.9.0/24`. Je hebt dan een statische route nodig op de router, of je moet de WireGuard-host als gateway opgeven.
Verbinding valt weg na een paar minuten stilte. Dit is NAT-timeout. Zet `PersistentKeepalive = 25` in de `[Peer]`-sectie van de kant die achter NAT zit. Doe dit alleen daar — aan beide kanten is zinloos verkeer.
WireGuard heeft geen ingebouwd sleutelbeheer. Er is geen gebruikersdatabase, geen certificaatautoriteit, geen ingebouwde revocatie. Je ruilt dat in voor een codebase van een paar duizend regels die je in een middag doorleest, in plaats van de honderdduizenden regels van OpenVPN of IPsec. Wil je een overzicht van wie toegang heeft, dan zul je dat zelf bij moeten houden — of een front-end als wg-easy voorzetten, met het beheer dat daarbij hoort.