WireGuard VPN veilig instellen voor serverbeheerders

Een onderhoudsnetwerk in plaats van openbaar toegankelijke beheerpoorten

Openbaar toegankelijke beheerpoorten vergroten het aanvalsoppervlak van een server: SSH-inlogpogingen, verkeerde configuraties van beheerinterfaces en per ongeluk blootgestelde monitoringdiensten zijn rechtstreeks bereikbaar vanuit externe netwerken. Een WireGuard-verbinding vermindert deze zichtbaarheid, omdat in eerste instantie alleen een gedefinieerde UDP-poort bereikbaar hoeft te blijven voor de versleutelde tunnel. WireGuard maskeert het verkeer echter niet als HTTPS en biedt geen TCP-transportmodus.

Het geschikte doelbeeld voor het VPN-beheer is meestal een hub-and-spoke-netwerk: de server beheert de interface wg0 en krijgt daarvoor bijvoorbeeld het interne adres 10.77.0.1 toegewezen. De laptop van een bevoegde persoon maakt verbinding als afzonderlijke peer en gebruikt bijvoorbeeld 10.77.0.10. SSH, een interne webconsole of monitoring-eindpunten accepteren vervolgens toegang via het tunnelnetwerk in plaats van via het openbare serveradres.

Dit is geen VPN voor eindgebruikers, die bedoeld is om al het internetverkeer van een apparaat om te leiden. Voor onderhoud is een beperkt toegangsmodel zinvoller: de tunnel dient alleen als route naar duidelijk omschreven beheersdoelen. Een volledige tunnel kan weliswaar bewust worden ingezet, maar beïnvloedt daarnaast ook de routing, het DNS-gebruik en de bereikbaarheid van externe diensten. Deze neveneffecten zijn voor een zuivere onderhoudstoegang meestal niet nodig.

De Onderhoudsnetwerk is uitsluitend een netwerkbeperking. Het bepaalt niet welk Linux-account zich mag aanmelden, welke commando’s dit account mag uitvoeren of of het besturingssysteem up-to-date is. Daarnaast heb je SSH-sleutels en persoonlijke accounts nodig, passend beperkte sudo-rechten, firewallregels, beveiligingsupdates, logboekregistratie en een goed onderhouden noodtoegang. Zo blijft een fout in één enkele beveiligingslaag niet de enige bepalende factor voor de toegang.

Sleutels, peers en toegestane IP-adressen correct indelen

Elke WireGuard-peer beschikt over een eigen sleutelpaar. De privésleutel blijft uitsluitend op de bijbehorende server, laptop of beheerapparaat; op de tegenpartij wordt alleen de daaruit afgeleide openbare sleutel opgeslagen. Een optionele PresharedKey vult de publieke-sleutelcryptografie aan met extra symmetrisch sleutelmateriaal. Het vormt een extra beveiligingslaag, maar vervangt noch de privésleutels, noch een traceerbaar sleutelbeheer.

Leg een Peer per apparaat , niet één gemeenschappelijke peer voor een team. Hierdoor kan een verloren werkstation of een apparaat van een dienstverlener dat niet langer nodig is, gericht worden verwijderd. De WireGuard-sleutels verlenen toegang tot het onderhoudsnetwerk. Los daarvan verifiëren SSH-sleutels een persoon of een apparaat bij de SSH-dienst; het intrekken ervan moet daarom op beide niveaus worden gepland.

Bijzonder belangrijk zijn de Toegestane IP-adressen op de server. Bij WireGuard vormen ze een Cryptokey Routing Table: voor uitgaande pakketten bepalen ze de juiste peer op basis van het bestemmingsadres. Voor inkomende, reeds geauthentificeerde pakketten beperken ze tegelijkertijd de interne bronadressen die deze peer mag gebruiken. De instelling is daarom meer dan alleen een gewone route-specificatie.

Als de laptop van de beheerder het adres 10.77.0.10 krijgt, hoort er op de server voor precies deze peer AllowedIPs = 10.77.0.10/32. De /32-toewijzing koppelt één enkel tunneladres aan deze peer. Als je aan elke admin-peer standaard 10.77.0.0/24 zou toewijzen, zou deze toewijzing onduidelijk worden en zou de configuratie onnodig breed worden opgezet. Controleer bovendien of het gekozen VPN-netwerk niet botst met locatie-, container- of thuisnetwerken.

Netwerkgrenzen en toegangsmodel plannen

Plan het VPN-adresnetwerk vóór de installatie. Kies een privébereik dat niet overlapt met bestaande LAN’s, cloudnetwerken, Docker- of Kubernetes-netwerken, noch met veelgebruikte thuisnetwerken. Bepaal welke systemen via de tunnel bereikbaar moeten zijn: alleen de gatewayserver, een afgebakend beheernetwerk of afzonderlijke diensten. Hieruit vloeien later clientroutes, firewallregels en eventueel terugroutes voort.

Documenteer voor elk apparaat de verantwoordelijke gebruiker, de openbare WireGuard-sleutel, het vaste tunnel-IP-adres, het doel van de toegang en de procedure voor intrekking. Groepen moeten worden ingedeeld op basis van taken, zoals beheer, databasebeheer of externe ondersteuning, en niet op basis van een algemene regel als „VPN mag alles“. Zorg bovendien voor een onafhankelijke noodtoegang, bijvoorbeeld een providerconsole. Controleer deze voordat je wijzigingen aanbrengt in de firewall, SSH of routing, zodat een foutieve regel er niet toe leidt dat je wordt buitengesloten.

De Firewall is de primaire netwerkgrens: deze staat de WireGuard-UDP-poort toe op de openbare interface, maar laat SSH-verbindingen uitsluitend toe via de ingangsinterface wg0 respectievelijk de daadwerkelijk gebruikte WireGuard-interface. Een aanvullende controle van het VPN-bronnetwerk kan de regel verder verfijnen, maar mag de interface-koppeling niet vervangen. Zo accepteert de firewall geen pakketten die via de openbare interface binnenkomen, louter op basis van een opgegeven VPN-bronadres. WireGuard koppelt geauthenticeerde interne adressen aan peers; deze garantie geldt voor pakketten die via de tunnelinterface zijn geaccepteerd.

Op SSH-niveau komen daar sleutels in plaats van aanmelding met een wachtwoord, persoonlijke accounts en zo beperkt mogelijke sudo-regels bij. OpenSSH kan met AllowUsers Koppel accounts bovendien aan bronadressen of CIDR-netwerken. Deze tweede beveiligingslaag vormt een aanvulling op de wg0 gebonden firewallregel, maar vervangt deze niet.

Openbare webtoepassingen moeten nog steeds worden beveiligd via HTTPS met de juiste certificaten. De handleiding voor het beveiligen van een website met TLS Dit niveau is bedoeld voor toegang via de browser. WireGuard beschermt daarentegen de toegang tot het privé-beheernetwerk; het vervangt noch TLS voor openbare diensten, noch de aanmelding, de rechtencontrole en het onderhoud daarvan.

Basisconstructie met wg-quick zonder routingvalkuilen

Voor een enkele onderhoudsserver volstaat een strak punt-tot-punt-scenario: de server draait wg0 met het tunneladres 10.77.0.1/24, de laptop van de administratie krijgt permanent 10.77.0.10/32. De openbare server accepteert alleen UDP voor WireGuard. De volgende bestanden vormen een configuratievoorstel voor wg-quick; ze bevatten bewust geen echte sleutels.

Op de server koppelt een peer de openbare sleutel van de laptop aan precies dat tunneladres. De privésleutel van de server blijft uitsluitend in het lokale bestand opgeslagen. Sla de configuratie bijvoorbeeld op onder /etc/wireguard/wg0.conf en beperk de leestoegang tot de beheercontext, omdat daarin een geheime sleutel staat. Openbare sleutels zijn daarentegen bestemd voor de betreffende tegenpartij.

[Interface]
Address = 10.77.0.1/24
ListenPort = <UDP_PORT>
PrivateKey = <SERVER_PRIVATE_KEY>

[Peer]
# Administrations-Laptop Person A
PublicKey = <ADMIN_A_PUBLIC_KEY>
AllowedIPs = 10.77.0.10/32

Op de laptop verwijst Endpoint naar het openbare serveradres en de gekozen UDP-poort. Voor puur serveronderhoud dient als clientzijde Toegestane IP-adressen meestal alleen 10.77.0.1/32 nodig. Hierdoor wordt uitsluitend het verkeer naar het VPN-adres van de server via de tunnel geleid; internetverkeer van de laptop blijft zijn gebruikelijke route volgen.

[Interface]
Address = 10.77.0.10/32
PrivateKey = <ADMIN_A_PRIVATE_KEY>

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = <SERVER_PUBLIC_ADDRESS>:<UDP_PORT>
AllowedIPs = 10.77.0.1/32
PersistentKeepalive = <ONLY_IF_NEEDED>

De vermelding 0.0.0.0/0 Op de client betekent een IPv4-standaardroute via de tunnel daarentegen: een Volledige tunnel. wg-quick leidt routes af uit AllowedIPs en verwerkt standaardroutes met aanvullende policy-routing-logica. Dit is mogelijk bij een bewust zo geplande toegang, maar beïnvloedt onder andere het externe dataverkeer en kan DNS- of bereikbaarheidsproblemen aan het licht brengen.

Dit voorbeeld heeft uitsluitend betrekking op IPv4. Als de server over openbare IPv6-connectiviteit beschikt, moet TCP-poort 22 ook daar expliciet door de IPv6-firewall worden geblokkeerd of moet de SSH-dienst op de juiste manier worden gekoppeld. Een gesloten IPv4-toegang biedt geen bescherming tegen een IPv6-listener die nog steeds openbaar bereikbaar is. Plan IPv6-tunneladressen en prefixen aan de clientzijde afzonderlijk; ::/0 dat zou dan ook een standaardroute voor IPv6 zijn en geen neutrale aanvulling op de IPv4-configuratie.

Activeer eerst de tunnel, controleer de verbinding met het VPN-adres en log via SSH in een tweede sessie hierop in. Pas als deze methode betrouwbaar werkt en er een onafhankelijke console- of noodtoegang beschikbaar is, moet je de openbare SSH-toegang verwijderen. Controleer daarbij zowel IPv4 als, indien van toepassing, IPv6. Privésleutels horen niet thuis in tickets, chatlogs of versiebeheer.

Routingmodellen en firewallregels vergelijken

De firewall handhaaft het gewenste toegangsmodel. Op de openbare interface mag deze de vastgestelde WireGuard-UDP-poort accepteren; TCP-poort 22 mag daar daarentegen niet open blijven staan als algemene beheertoegang. SSH wordt in plaats daarvan alleen toegestaan voor pakketten waarvan de inkomende interface wg0 respectievelijk de gebruikte WireGuard-interface. Een aanvullende controle van het bronnetwerk kan het toegestane VPN-bereik verder beperken, maar een regel die uitsluitend op het bronadres is gebaseerd, is niet voldoende.

De koppeling aan de ingangsinterface voorkomt dat een pakket dat binnenkomt via de openbare interface, louter vanwege een vervalst bronadres uit het VPN-gebied, voldoet aan de SSH-toegangsvoorwaarden. De cryptografische koppeling van peer en intern adres door WireGuard is van toepassing op geauthentificeerde pakketten op de tunnelinterface. De specifieke firewall-syntaxis moet aansluiten bij de gebruikte software en zowel de interface als de adresfamilie eenduidig specificeren.

Houd uitdrukkelijk rekening met openbare IPv6-connectiviteit. Als alleen de IPv4-toegang voor TCP 22 wordt verwijderd, kan SSH via IPv6 nog steeds bereikbaar blijven vanaf het internet. Blokkeer de poort daarom ook in de IPv6-regels of configureer de SSH-dienst zodanig dat deze niet luistert op een openbaar IPv6-adres. IPv4- en IPv6-regels moeten afzonderlijk worden gecontroleerd.

Bij een statusgebonden firewall volstaat het niet om alleen de gewenste heenweg in gedachten te nemen. Antwoordpakketten van een toegestane verbinding moeten ook de client bereiken; bij toegang achter een gateway komt daar bovendien de terugweg vanuit het doelnetwerk bij. Een algemene vrijgave van het gehele VPN-subnet voor alle diensten maakt van het onderhoudsnetwerk onnodig een breed intern toegangsnetwerk.

Voor het onderhoud van één enkele server is het eerste model het overzichtelijkst. De clientroute naar 10.77.0.1/32 is voldoende, en de firewall kan SSH uitsluitend toestaan voor pakketten die via de WireGuard-interface binnenkomen. De UDP-poort blijft weliswaar van buitenaf zichtbaar, maar zonder de juiste peersleutel leidt dit niet tot administratieve toegang.

Het tweede model vereist een duidelijke scheiding: de VPN-server fungeert dan niet alleen als eindpunt, maar ook als router. De firewall moet bijvoorbeeld SSH naar gedefinieerde beheerservers en HTTPS naar een interne console toestaan, telkens beperkt tot de WireGuard-invoerinterface, specifieke doelnetwerken en poorten. Je moet databasepoorten niet alleen vrijgeven voor het gehele VPN omdat de gebruikers al verbonden zijn.

Bij een full tunnel fungeert de VPN-server tevens als gateway voor internetbestemmingen. Hiervoor moet hij IPv4-pakketten doorsturen tussen wg0 en doorsturen via zijn uplink; bovendien hebben antwoorden een terugweg naar het VPN-netwerk nodig. In veel serverconfiguraties wordt hiervoor een specifieke Source-NAT-regel op de uplink gebruikt, wanneer het upstream-netwerk geen route naar het VPN-prefix kent. Plan deze regels zorgvuldig en beperk ze tot het beoogde tunnelnetwerk.

Een Full Tunnel is geen beveiligingsvereiste van WireGuard, maar een routeringsbeslissing op de client. Omdat wg-quick Aangezien standaardroutes uit AllowedIPs op een speciale manier worden verwerkt, mag deze instelling alleen worden gebruikt in combinatie met een geplande naamomzetting, voldoende gateway-capaciteit en passende uitgaande regels. Voor het gebruikelijke VPN-beheer is deze meestal ruimer geformuleerd dan nodig is. Voor IPv6 geldt dezelfde planningsvraag afzonderlijk: ::/0 leidt al het IPv6-verkeer door de tunnel.

Interne netwerken gericht toegankelijk maken

Als beheerders achter de VPN-gateway toegang moeten krijgen tot andere privé-systemen, verandert de taak van louter servertoegang naar een gerouteerd beheernetwerk. Plan eerst de doelnetwerken en diensten: bijvoorbeeld SSH naar servers in het beheerssegment en HTTPS naar een interne console. Elk extra pad breidt het vertrouwensdomein uit en moet daarom worden gemotiveerd met een concrete bedrijfstaak.

Als eerste technische voorwaarde moet de gateway IPv4-pakketten mogen doorsturen. De kernelinstelling net.ipv4.ip_forward activeert dit gedrag. Dit mag niet worden beschouwd als een onbelangrijke regel: volgens de kernel-documentatie leidt een wijziging van ip_forward andere IPv4-configuratieparameters worden teruggezet naar de standaardwaarden van de host of router. Controleer daarom de geldende netwerk- en beveiligingsrichtlijnen voor en na de wijziging.

Ten tweede heeft de firewall expliciete Doorreisregels in beide richtingen. Een regel mag niet simpelweg al het verkeer van wg0 toelaten tot het LAN. Beperk ze in plaats daarvan tot het bronnetwerk van het VPN, de beoogde bestemmingsadressen en de benodigde protocollen, bijvoorbeeld TCP 22 naar beheerservers en TCP 443 naar een console. Databases blijven, zonder gegronde uitzondering, buiten deze toestemming.

Ten derde heeft het doelnetwerk een terugweg naar het VPN-netwerk nodig, bijvoorbeeld een route voor 10.77.0.0/24 via het interne adres van de gateway. Zonder deze terugroute kan de heenweg wel werken, terwijl antwoorden de beheerder niet bereiken. Als routing in het doelnetwerk niet mogelijk is, kan Source NAT op de gateway een technisch alternatief zijn; dit verbergt echter het oorspronkelijke VPN-clientadres en bemoeilijkt daarmee de logboekregistratie aan de doelzijde en het instellen van fijnmazigere regels.

Kies het VPN-adresnetwerk zodanig dat het niet in conflict komt met lokale netwerken van beheerders, noch met bestaande locatie-, cloud- of containernetwerken. Overlappingen maken de routekeuze onduidelijk en veroorzaken fouten die kunnen lijken op een WireGuard- of firewallprobleem. Documenteer bovendien vaste tunneladressen en de bijbehorende apparaten voordat je meer peers of doelnetwerken vrijgeeft.

Bedrijfsprocessen en wijzigingen veilig begeleiden

Een onderhoudsnetwerk blijft alleen overzichtelijk als elk apparaat een eigen peer, een eigen sleutelpaar en een vast tunnel-IP-adres krijgt. Een inventarislijst moet daarom ten minste het tunneladres, de apparaataanduiding, de verantwoordelijke persoon, het doel, de uitgiftedatum en de controledatum bevatten. Door de toewijzing 10.77.0.10/32 aan een specifieke beheerderslaptop wordt het gebruik traceerbaar en wordt voorkomen dat meerdere apparaten dezelfde VPN-identiteit gebruiken.

Plan het wisselen van sleutels als een regulier bedrijfsproces, en niet pas als reactie op een incident. Bij het vervangen van een apparaat maak je een nieuwe peer aan met een nieuw adres of een duidelijk gedocumenteerd opvolgingsadres, controleer je de toegang en verwijder je daarna de oude peer. Privé-WireGuard-sleutels horen uitsluitend thuis op het betreffende eindapparaat; ze mogen noch in tickets, noch in centrale inventarislijsten worden opgenomen.

Als een laptop zoekraakt of als een externe medewerker het bedrijf verlaat, verwijder je de betreffende peer uit de serverconfiguratie. Hierdoor wordt de toegang tot het beheernetwerk geblokkeerd, zonder dat de sleutels van andere beheerders hoeven te worden vervangen. Peer-ontwenning Dit is echter niet hetzelfde als het intrekken van een SSH-sleutel: de WireGuard-sleutel regelt de netwerkroute, terwijl de SSH-sleutel de aanmelding bij het doelaccount regelt.

Nadat een peer is verwijderd, kan WireGuard via deze peer geen pakketten meer uitwisselen voor een bestaande SSH-verbinding; de verbinding loopt daardoor vast of wordt beëindigd na een afbreking of time-out. Het verwijderen van de peer maakt echter niet automatisch de reeds voltooide SSH-aanmelding op applicatieniveau ongedaan en beëindigt evenmin eerder gestarte processen. Controleer daarom bij een incident ook de SSH-autorisaties, actieve processen, accounts en, indien van toepassing, sudo-rechten.

Voor gerichte wijzigingen kan wg syncconf een bestaande WireGuard-configuratie vergelijken met de expliciete verschillen; volgens de handleiding zou dit de peer-sessies minder verstoren dan setconf. Het is echter geen vervanging voor goedkeuring, dubbele controle of onderhoudsvensters. Zorg ervoor dat je vóór elke wijziging de werkende configuratie opslaat en noteer hoe je deze kunt terugzetten.

Diagnose: van handshake tot SSH-toegang

Bij een storing moet je transport, routing en toepassing consequent van elkaar scheiden. Begin met de openbaar toegankelijke UDP-poort en de handshake, voordat je de SSH-instellingen wijzigt. Het commando wg show toont voor geconfigureerde peers onder andere de toegestane IP-adressen, het tijdstip van de laatste handshake en de overdrachtsteller. Ontbrekende of ongewijzigde waarden duiden op een probleem vóór de daadwerkelijke SSH-toegang.

Als er een handshake is, controleer je op zowel de client als de server het daadwerkelijk ingestelde tunneladres en de route naar de bestemming. Voor puur gatewaybeheer moet de client het doel 10.77.0.1 via de WireGuard-interface kunnen bereiken. Bij interne doelen komen daar nog firewalltellers, toegestaan terugverkeer en de terugroute van het doelnetwerk bij; een succesvolle handshake bewijst deze voorwaarden niet.

Pas als het netwerkpad klopt, volgt de controle van de SSH-dienst. Controleer de relevante vermeldingen voor aanmelding en bronbeperking in het bestand sshd_config, met name gebruikerstoegangen zoals AllowUsers, en controleer de status van de services en de logbestanden met de tools van je distributie. Vervolgens controleer je het gebruikersaccount en de vermeldingen in authorized_keys en de sudo-regels apart. De configuratiedocumentatie op zich bewijst noch dat de aanmelding is gelukt, noch dat de dienst bereikbaar is.

Identieke of overlappende AllowedIPs zijn niet louter een documentatiefout. Bij het verzenden wijst WireGuard op basis van deze prefixen bestemmingsadressen toe aan een peer; bij het ontvangen beperken ze de interne bronadressen van de geauthenticeerde peer. Dubbele of tegenstrijdige hostprefixen vormen daarom geen eenduidige, betrouwbaar traceerbare Peer-toewijzing. Er mag niet worden aangenomen dat een beheertool bij het overnemen van een dergelijke configuratie een bepaald resultaat oplevert. Voorkom de conflict in plaats daarvan al in de inventaris en tijdens de configuratiecontrole.

Pas correcties op een gecontroleerde manier toe en voer diagnoses alleen uit als er noodtoegang beschikbaar is. Zo voorkom je dat een foutieve wijziging in de peer-, routing- of firewallinstellingen tegelijkertijd de terugweg naar de reparatie blokkeert. Controleer na elke overname opnieuw de handshake, de overdrachtsteller, de route en de toegang tot de specifiek vrijgegeven beheersdienst.

wg show
ip route

De keuze van het gereedschap en de veiligheidsgrenzen zijn bepalend

De keuze van de beheerwijze hangt af van het bestaande serverbeheer, en niet van een zogenaamd universele WireGuard-methode. wg-quick is geschikt voor overzichtelijke configuraties: het hulpscript stelt de interface, adressen en routes die zijn afgeleid van AllowedIPs in. Voor complexe netwerken verwijst de documentatie daarentegen naar specifiekere hulpmiddelen of naar directe configuratie met wg en IP-tools.

Als een host zijn netwerk al declaratief beheert via systemd-networkd, zijn .netdev- en .network-bestanden een geschikt alternatief. systemd-networkd ondersteunt WireGuard-specifieke instellingen en kan privésleutels uit inloggegevens halen; voor vertrouwelijke inhoud noemt de documentatie versleutelde inloggegevens of ten minste restrictieve bestandsrechten als beschermingsmaatregel. Dit is met name geschikt voor automatisch geïmplementeerde servers.

Directe oproepen van wg en ip bieden de meeste controle voor automatisering, policy routing en specifieke firewallprocessen, maar vereisen een duidelijk onderhouden bedrijfsmodel. Beheer dezelfde interface nooit tegelijkertijd via wg-quick, systemd-networkd en eigen scripts. Meerdere verantwoordelijkheden kunnen routes, adressen of peer-instellingen onderling overschrijven en maken een betrouwbare rollback bemoeilijken.

PersistentKeepalive is alleen zinvol voor peers die zich achter NAT of een statische firewall bevinden, zelden zelf gegevens verzenden en toch bereikbaar moeten blijven voor inkomend verkeer. Zonder specificatie is deze functie uitgeschakeld; in de documentatie wordt 25 seconden slechts genoemd als een mogelijk interval, niet als algemene standaardinstelling. Mobiele clients profiteren vaak van roaming, omdat WireGuard het eindpunt kan bijwerken op basis van correct geauthenticeerde pakketten.

Roaming en vaste eindpuntbeperkingen zijn een afweging: een firewall die alleen UDP-verkeer van bekende bronnetwerken toelaat, kan het aanvalsoppervlak beperken, maar belemmert flexibel gebruik onderweg. WireGuard wijst er bovendien op dat een actieve aanvaller het externe bronadres kan omleiden en zo een Denial-of-Service-aanval kan faciliteren, zonder de versleutelde inhoud te lezen of te wijzigen.

Een WireGuard-tunnel is geen vervanging voor identiteitsbeheer, rechtencontrole, updates, back-ups of logboekregistratie. Het maskeert zijn verkeer niet als HTTPS en biedt geen TCP-modus. Openbare webapplicaties hebben daarom nog steeds een afzonderlijke TLS-beveiliging nodig; in het artikel worden de vereisten en de implementatie uitgelegd HTTPS veilig instellen. Maak een duidelijk onderscheid tussen deze beveiligingslaag en de VPN-toegang voor het beheer.