Sikker opsætning af WireGuard VPN for serveradministratorer

Vedligeholdelsesnetværk i stedet for offentligt tilgængelige admin-porte

Offentligt tilgængelige administrationsporte øger en servers angrebsflade: SSH-loginforsøg, fejlkonfigurationer af administrationsgrænseflader og utilsigtet eksponerede overvågningstjenester kan nås direkte fra fremmede netværk. En WireGuard-forbindelse mindsker denne synlighed, da der i første omgang kun skal være adgang til en defineret UDP-port for den krypterede tunnel. WireGuard maskerer dog ikke trafikken som HTTPS og tilbyder ingen TCP-transporttilstand.

Det mest passende mål for VPN-administrationen er som regel et hub-and-spoke-netværk: Serveren driver grænsefladen wg0 og tildeles dermed f.eks. den interne adresse 10.77.0.1. En autoriseret persons bærbare computer opretter forbindelse som en selvstændig peer og bruger f.eks. 10.77.0.10. SSH, en intern webkonsol eller overvågningsendepunkter accepterer derefter adgang via tunnelnetværket i stedet for via den offentlige serveradresse.

Dette er ikke en VPN til slutbrugere, der har til formål at omdirigere al enhedens webtrafik. Til vedligeholdelse er en snæver adgangsmodel mere hensigtsmæssig: Tunnelen fungerer udelukkende som en vej til klart definerede administrationsmål. En fuld tunnel kan ganske vist anvendes bevidst, men ændrer desuden routing, DNS-brug og tilgængeligheden af eksterne tjenester. Disse bivirkninger er som regel ikke nødvendige for en ren vedligeholdelsesadgang.

Das Vedligeholdelsesnetværk er udelukkende en netværksgrænse. Den afgør ikke, hvilken Linux-konto der må logge ind, hvilke kommandoer denne konto må udføre, eller om operativsystemet er opdateret. Derudover har du brug for SSH-nøgler og personlige konti, passende begrænsede sudo-rettigheder, firewall-regler, sikkerhedsopdateringer, logføring og en velvedligeholdt nødadgang. På den måde bliver en fejl i et enkelt beskyttelseslag ikke den eneste afgørende faktor for adgangen.

Korrekt klassificering af nøgler, peers og AllowedIPs

Hver WireGuard-peer har sit eget nøglepar. Den private nøgle forbliver udelukkende på den tilhørende server, bærbare computer eller administrationsenhed; på den modstående enhed gemmes kun den offentlige nøgle, der er afledt heraf. En valgfri PresharedKey supplerer kryptografien med offentlige nøgler med yderligere symmetrisk nøglemateriale. Den udgør et ekstra lag, men erstatter hverken private nøgler eller gennemsigtig nøgleadministration.

Læg en Peer pr. enhed , ikke en fælles peer for et team. På den måde kan en mistet arbejdsstation eller en udbyder-enhed, der ikke længere er nødvendig, fjernes målrettet. WireGuard-nøglerne giver adgang til vedligeholdelsesnetværket. Uafhængigt heraf autentificerer SSH-nøgler en person eller en enhed over for SSH-tjenesten; en tilbagekaldelse skal derfor planlægges på begge niveauer.

Særligt vigtige er Tilladte IP-adresser på serveren. I WireGuard udgør de en Cryptokey-routing-tabel: For udgående pakker bestemmer de den relevante peer ud fra destinationsadressen. For indgående, allerede autentificerede pakker begrænser de samtidig de interne kildeadresser, som denne peer må anvende. Indstillingen er derfor mere end blot en almindelig ruteangivelse.

Hvis administrations-laptoppen tildeles adressen 10.77.0.10, skal der på serveren for netop denne peer være AllowedIPs = 10.77.0.10/32. /32-tildelingen knytter en enkelt tunneladresse til denne peer. Hvis du generelt tildelte hver admin-peer 10.77.0.0/24, ville denne tildeling blive uklar, og konfigurationen ville blive unødvendigt bred. Kontroller desuden, at det valgte VPN-netværk hverken kolliderer med lokalitets-, container- eller hjemmenetværk.

Planlægning af netværksgrænser og adgangsmodel

Planlæg VPN-adressenetværket inden installationen. Vælg et privat område, der hverken overlapper med eksisterende LAN-netværk, cloud-netværk, Docker- eller Kubernetes-netværk eller med hyppigt anvendte hjemmenetværk. Fastlæg, hvilke systemer der skal være tilgængelige via tunnelen: kun gateway-serveren, et afgrænset administrationsnetværk eller enkelte tjenester. Dette danner senere grundlag for klientruter, firewall-regler og eventuelt returruter.

Dokumenter for hver enhed den ansvarlige bruger, den offentlige WireGuard-nøgle, den faste tunnel-IP-adresse, formålet med adgangen og fremgangsmåden for tilbagekaldelse. Grupper bør være oprettet ud fra specifikke opgaver, f.eks. drift, databaseadministration eller ekstern support, og ikke baseret på en generel regel om, at „VPN giver adgang til alt“. Sørg desuden for at have en uafhængig nødadgang, f.eks. en udbyderkonsol. Kontroller den, før der foretages ændringer i firewall, SSH eller routing, så en fejlagtig regel ikke fører til, at man bliver låst ude.

Die Firewall er den primære netværksgrænse: Den tillader WireGuard-UDP-porten på den offentlige grænseflade, men accepterer kun SSH-forbindelser via indgangsgrænsefladen wg0 henholdsvis den faktisk anvendte WireGuard-grænseflade. En yderligere kontrol af VPN-kildenetværket kan yderligere indsnævre reglen, men må ikke erstatte grænsefladebindingen. Firewall’en accepterer således ikke pakker, der ankommer via den offentlige grænseflade, alene på grundlag af en påstået VPN-kildeadresse. WireGuard knytter autentificerede interne adresser til peers; denne garanti gælder for pakker, der er accepteret via tunnelgrænsefladen.

På SSH-niveau kommer der nøgler i stedet for adgang med adgangskode, personlige konti og så begrænsede sudo-regler som muligt. OpenSSH kan med AllowUsers Knyt konti yderligere til kildeadresser eller CIDR-netværk. Denne anden sikkerhedsbarriere supplerer den, der er angivet i wg0 en tilknyttet firewall-regel, men erstatter den ikke.

Offentlige webapplikationer skal fortsat sikre deres datatransport via HTTPS og med passende certifikater. Vejledning i TLS-sikring af et websted Dette niveau håndterer adgang via browsere. WireGuard beskytter derimod adgangen til det private administrationsnet; det erstatter hverken TLS for offentlige tjenester eller disse tjenesters login, rettighedskontrol og vedligeholdelse.

Grundstruktur med wg-quick uden routing-fælder

For en enkelt vedligeholdelsesserver er et simpelt punkt-til-punkt-scenarie tilstrækkeligt: Serveren kører wg0 med tunneladressen 10.77.0.1/24, administrations-laptoppen får permanent 10.77.0.10/32. Den offentlige server accepterer kun UDP til WireGuard. Følgende filer er et forslag til konfiguration af wg-quick; de indeholder bevidst ingen reelle nøgler.

På serveren knytter en peer den bærbare computers offentlige nøgle til netop dens tunneladresse. Serverens private nøgle forbliver udelukkende i den lokale fil. Gem konfigurationen for eksempel under /etc/wireguard/wg0.conf og begræns læseadgangen til administrationskonteksten, da den indeholder en hemmelig nøgle. Offentlige nøgler er derimod beregnet til den pågældende modpart.

[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

På den bærbare computer henviser Endpoint på den offentlige serveradresse og den valgte UDP-port. Til ren servervedligeholdelse skal der som klient-side Tilladte IP-adresser som regel kun 10.77.0.1/32 nødvendigt. Dermed dirigeres udelukkende trafikken til serverens VPN-adresse ind i tunnelen; bærbarens internetadgang følger sin sædvanlige rute.

[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>

Oplysningen 0.0.0.0/0 På klienten betyder en IPv4-standardrute gennem tunnelen derimod: en Fuld tunnel. wg-quick udleder ruter ud fra AllowedIPs og behandler standardruter med yderligere policy-routing-logik. Dette er muligt for en adgang, der bevidst er planlagt på denne måde, men det ændrer blandt andet den eksterne datatrafik og kan afsløre DNS- eller tilgængelighedsproblemer.

Eksemplet dækker udelukkende IPv4. Hvis serveren har offentlig IPv6-forbindelse, skal TCP-port 22 også der udtrykkeligt blokeres af IPv6-firewallen, eller SSH-tjenesten skal bindes korrekt. En lukket IPv4-åbning beskytter ikke mod en IPv6-listener, der fortsat er offentligt tilgængelig. Planlæg IPv6-tunneladresser og præfikser på klientsiden separat; ::/0 Det ville i så fald ligeledes være en standardrute for IPv6 og ikke blot et neutralt tillæg til IPv4-konfigurationen.

Aktivér først tunnelen, kontroller forbindelsen til VPN-adressen, og log ind via SSH i en anden session. Først når denne fremgangsmåde fungerer pålideligt, og der er adgang via en uafhængig konsol eller en nødadgang, bør du fjerne den offentlige SSH-adgang. Kontroller både IPv4 og, hvis relevant, IPv6. Private nøgler hører hverken hjemme i supportbilletter, chatlogfiler eller versionsstyring.

Sammenligning af routingmodeller og firewall-regler

Firewallen håndhæver den ønskede adgangsmodel. På den offentlige grænseflade må den acceptere den fastlagte WireGuard-UDP-port; TCP-port 22 må derimod ikke forblive åben som en generel administrationsadgang. SSH tillades i stedet kun for pakker, hvis indgående grænseflade wg0 henholdsvis den anvendte WireGuard-grænseflade. En supplerende kontrol af kildens netværk kan yderligere indsnævre det tilladte VPN-område, men en regel, der udelukkende er baseret på kildeadressen, er ikke tilstrækkelig.

Bindingen til indgangsgrænsefladen forhindrer, at en pakke, der ankommer til den offentlige grænseflade, opfylder SSH-godkendelsen alene på grund af en forfalsket kildeadresse fra VPN-området. WireGuards kryptografiske tilknytning af peer og intern adresse gælder for autentificerede pakker på tunnelgrænsefladen. Den konkrete firewall-syntaks skal passe til den anvendte software og entydigt tage højde for både grænseflade og adressefamilie.

Sørg for udtrykkeligt at tage højde for offentlig IPv6-forbindelse. Hvis man kun fjerner IPv4-adgangen til TCP 22, kan SSH stadig være tilgængelig fra internettet via IPv6. Bloker derfor også porten i IPv6-reglerne, eller konfigurer SSH-tjenesten, så den ikke lytter på en offentlig IPv6-adresse. IPv4- og IPv6-regler skal kontrolleres separat.

Ved en tilstandsbaseret firewall er det ikke nok blot at overveje den ønskede udgående forbindelse. Svarpakker fra en tilladt forbindelse skal også nå frem til klienten; ved adgang bag en gateway kommer der desuden den returvej fra målnettet til. En generel godkendelse af hele VPN-undernetværket til alle tjenester gør vedligeholdelsesnetværket unødvendigt til et bredt internt adgangsnetværk.

Til vedligeholdelse af en enkelt server er den første model den mest overskuelige. Klientruten til 10.77.0.1/32 Det er tilstrækkeligt, og firewallen kan nu kun tillade SSH for pakker, der ankommer via WireGuard-grænsefladen. UDP-porten forbliver ganske vist synlig udefra, men uden den rette peer-nøgle giver den ikke adgang til administration.

Den anden model kræver en klar adskillelse: VPN-serveren fungerer i dette tilfælde ikke kun som endepunkt, men også som router. Firewallen bør f.eks. tillade SSH til definerede administrationsservere og HTTPS til en intern konsol, i begge tilfælde begrænset til WireGuard-indgangsgrænsefladen, specifikke målnettværk og porte. Du bør ikke frigive databaseporte i hele VPN'et alene af den grund, at brugerne allerede er forbundet.

I et Full Tunnel-opkobling fungerer VPN-serveren også som gateway for internetdestinationer. Til dette formål skal den videresende IPv4-pakker mellem wg0 og videresende den via sin uplink; desuden skal svarene have en returvej til VPN-netværket. I mange serveropsætninger anvendes der til dette formål en målrettet Source-NAT-regel på uplinket, hvis upstream-netværket ikke kender en rute til VPN-præfikset. Planlæg disse regler omhyggeligt, og begræns dem til det påtænkte tunnelnetværk.

En »Full Tunnel« er ikke et sikkerhedskrav fra WireGuard, men en routingbeslutning på klienten. Fordi wg-quick Da standardruter fra AllowedIPs behandles særskilt, bør denne indstilling kun anvendes, hvis der er planlagt navneopløsning, tilstrækkelig gateway-kapacitet og passende udgangsregler. For den sædvanlige VPN-administration er den som regel bredere end nødvendigt. For IPv6 gælder det samme planlægningsspørgsmål separat: ::/0 leder al IPv6-trafik gennem tunnelen.

Gøre interne netværk målrettet tilgængelige

Hvis administratorer skal have adgang til yderligere private systemer bag VPN-gatewayen, skifter opgaven fra ren serveradgang til et routet administrationsnetværk. Planlæg først målnettet og tjenesterne: f.eks. SSH til servere i administrationssegmentet og HTTPS til en intern konsol. Hver ekstra sti udvider tillidsområdet og bør derfor begrundes med en konkret driftsopgave.

Den første tekniske forudsætning er, at gatewayen skal have tilladelse til at videresende IPv4-pakker. Kernel-indstillingen net.ipv4.ip_forward aktiverer denne adfærd. Den skal ikke betragtes som en ubetydelig enkelt linje: Ifølge kerne-dokumentationen medfører en ændring af ip_forward Andre IPv4-konfigurationsparametre vender tilbage til deres standardværdier på henholdsvis værten og routeren. Kontroller derfor de gældende netværks- og sikkerhedsretningslinjer før og efter ændringen.

For det andet skal firewallen have eksplicitte Transitregler i begge retninger. En regel bør ikke blot omfatte al trafik fra wg0 Accepter dem ikke i LAN. Begræns dem i stedet til VPN-kildenetværket, de forudbestemte måladresser og de nødvendige protokoller, for eksempel TCP 22 til administrationsservere og TCP 443 til en konsol. Databaser forbliver uden begrundet undtagelse uden for denne tilladelse.

For det tredje skal målnettet have en returvej til VPN-netværket, f.eks. en rute til 10.77.0.0/24 via gatewayens interne adresse. Uden denne returrute kan udgående trafik fungere, mens svarene ikke finder vej tilbage til administratoren. Hvis routing i målnettet ikke er muligt, kan Source NAT på gatewayen være et teknisk alternativ; det skjuler dog den oprindelige VPN-klientadresse og gør dermed logning på målssiden og mere detaljerede regler vanskeligere.

Vælg VPN-adressenettet, så det hverken kolliderer med administratorernes lokale netværk eller med eksisterende lokations-, cloud- eller containernetværk. Overlapninger gør rutevalg tvetydigt og forårsager fejl, der kan ligne et WireGuard- eller firewall-problem. Dokumenter desuden faste tunneladresser og de tilhørende enheder, inden du aktiverer yderligere peers eller målnetværk.

Sikker styring af driften og ændringer

Et vedligeholdelsesnetværk forbliver kun overskueligt, hvis hver enhed tildeles sin egen peer, sit eget nøglepar og en fast tunnel-IP-adresse. En oversigt bør derfor som minimum indeholde tunneladresse, enhedsbetegnelse, ansvarlig person, formål samt udstedelses- og kontrol dato. Tildelingen af 10.77.0.10/32 til en bestemt administrations-bærbar gør adgangen sporbar og forhindrer, at flere enheder bruger den samme VPN-identitet.

Planlæg nøgleskift som en del af den normale driftsproces, ikke først som reaktion på en hændelse. Ved udskiftning af udstyr skal du oprette en ny peer med en ny adresse eller en klart dokumenteret efterfølgende adresse, kontrollere adgangen og derefter fjerne den gamle peer. Private WireGuard-nøgler hører udelukkende hjemme på den pågældende enhed; de må hverken indgå i billetter eller centrale inventarlister.

Hvis en bærbar computer går tabt, eller en ekstern person forlader organisationen, skal du fjerne den pågældende peer fra serverkonfigurationen. Dette forhindrer vedkommende i at få adgang til administrationsnetværket, uden at det er nødvendigt at udskifte andre administratorers nøgler. Peer-tilbagetrækning men det er ikke det samme som at tilbagekalde en SSH-nøgle: WireGuard-nøglen styrer netværksruten, mens SSH-nøglen styrer log-in på målkontot.

Når en peer er fjernet, kan WireGuard ikke længere udveksle pakker via denne peer i forbindelse med en eksisterende SSH-forbindelse; forbindelsen hænger derfor fast eller afbrydes efter en afbrydelse eller et timeout. Fjernelsen ophæver dog ikke automatisk den allerede gennemførte SSH-login på applikationsniveau og afslutter heller ikke tidligere startede processer. Kontroller derfor i forbindelse med hændelsen også SSH-godkendelser, kørende processer, konti og eventuelt sudo-rettigheder.

For at foretage målrettede ændringer kan man wg syncconf sammenligne en eksisterende WireGuard-konfiguration med de konkrete forskelle; ifølge manualen skal dette forstyrre peer-sessioner mindre end setconf. Det er dog ikke en erstatning for godkendelse, dobbeltkontrol eller vedligeholdelsesvinduer. Sørg for at gemme den fungerende konfiguration før hver ændring, og noter, hvordan du gendanner den.

Diagnose fra håndtryk til SSH-adgang

I tilfælde af en fejl skal du konsekvent adskille transport, routing og applikation fra hinanden. Start med den offentligt tilgængelige UDP-port og handshaken, inden du ændrer SSH-indstillingerne. Kommandoen wg show Viser blandt andet AllowedIPs, tidspunktet for den seneste handshake og overførselstælleren for konfigurerede peers. Manglende eller uændrede værdier tyder på et problem, der opstod før selve SSH-adgangen.

Hvis der er etableret en håndtryk, skal du på både klient og server kontrollere den faktisk indstillede tunneladresse og ruten til målet. Til ren gateway-administration skal klienten kunne nå målet 10.77.0.1 via WireGuard-grænsefladen. Ved interne mål kommer der desuden firewall-tællere, tilladt rettrafik og returruten fra målnettet i spil; et vellykket håndtryk beviser ikke, at disse forudsætninger er opfyldt.

Først når netværksstien er korrekt, skal SSH-tjenesten kontrolleres. Kontroller de relevante indtastninger for login og kildebegrænsning i sshd_config, især brugerrettigheder som AllowUsers, og kontroller tjenestestatus samt logfiler ved hjælp af værktøjerne i din distribution. Derefter undersøger du brugerkontoen og posterne i authorized_keys og sudo-reglerne er adskilt. Konfigurationsdokumentationen i sig selv er ikke bevis på hverken en vellykket login eller, at tjenesten er tilgængelig.

Identiske eller overlappende AllowedIPs er ikke blot en dokumentationsfejl. Ved afsendelse tildeler WireGuard destinationsadresser til en peer på baggrund af disse præfikser; ved modtagelse begrænser de de interne kildeadresser for den autentificerede peer. Dobbelt eller modstridende værtspræfikser udgør derfor ikke en entydig, pålidelig og sporbar Peer-tilknytning. Man bør ikke gå ud fra, hvilket konkret resultat et administrationsværktøj giver, når en sådan konfiguration implementeres. Undgå i stedet konflikter allerede i inventaret og under konfigurationskontrollen.

Overfør rettelser på en kontrolleret måde, og udfør fejlfinding kun, når der er adgang via nødkanalen. På den måde undgår du, at en fejlagtig ændring af peer-, routing- eller firewall-indstillingerne samtidig blokerer vejen tilbage til fejlretningen. Kontroller efter hver overtagelse igen håndtryk, overførselstæller, rute og adgangen til den konkret godkendte administrationstjeneste.

wg show
ip route

Valg af værktøj og sikkerhedsgrænser er afgørende

Valget af administrationsmetode afhænger af den eksisterende serveradministration og ikke af en formodet universel WireGuard-metode. wg-quick er egnet til overskuelige konfigurationer: Hjælpeskriptet konfigurerer grænseflader, adresser og ruter, der er afledt af AllowedIPs. Til komplekse netværk henviser dokumentationen derimod til mere specifikke værktøjer eller direkte konfiguration med wg og IP-værktøjer.

Hvis en vært allerede administrerer sit netværk deklarativt via systemd-networkd, er .netdev- og .network-filer et passende alternativ. systemd-networkd understøtter WireGuard-specifikke indstillinger og kan hente private nøgler fra legitimationsoplysninger; for fortroligt indhold angiver dokumentationen krypterede legitimationsoplysninger eller i det mindste restriktive filrettigheder som beskyttelsesforanstaltning. Dette passer især godt til automatisk udrullede servere.

Direkte henvisninger fra wg og ip giver den største kontrol over automatisering, policy-routing og specielle firewall-processer, men kræver en klart defineret driftsmodel. Du bør aldrig administrere den samme grænseflade samtidigt via wg-quick, systemd-networkd og egne scripts. Flere ansvarsområder kan overskrive ruter, adresser eller peer-indstillinger indbyrdes og gøre det vanskeligt at foretage en pålidelig tilbageførsel.

PersistentKeepalive er kun relevant for peers, der sjældent selv sender data bag NAT eller en tilstandsbaseret firewall, men alligevel skal forblive tilgængelige for indgående trafik. Hvis der ikke angives noget, er funktionen deaktiveret; i dokumentationen nævnes 25 sekunder blot som et muligt interval, ikke som en generel standardindstilling. Mobile klienter drager ofte fordel af roaming, fordi WireGuard kan opdatere endepunktet på baggrund af korrekt autentificerede pakker.

Roaming og faste begrænsninger for slutpunkter er et afvejningsspørgsmål: En firewall, der kun accepterer UDP fra kendte kildenetværk, kan begrænse angrebsfladen, men forhindrer fleksibel brug, når man er på farten. WireGuard påpeger desuden, at en aktiv angriber kan omdirigere den eksterne kildeadresse og dermed fremme et Denial-of-Service-angreb uden at læse eller ændre det krypterede indhold.

En WireGuard-tunnel erstatter ikke identitetsstyring, rettighedskontrol, opdateringer, sikkerhedskopiering eller logføring. Den maskerer ikke sin trafik som HTTPS og tilbyder ikke TCP-tilstand. Offentlige webapplikationer har derfor stadig brug for en separat TLS-sikring; kravene og implementeringen forklares i artiklen Sikker opsætning af HTTPS. Sørg for, at dette beskyttelseslag holdes klart adskilt fra VPN-adgangen til administration.