Säker konfiguration av WireGuard VPN för serveradministratörer

Ett underhållsnätverk istället för offentligt tillgängliga administratörsportar

Offentligt tillgängliga administrationsportar ökar en servers attackyta: SSH-inloggningsförsök, felkonfigurationer av administratörsgränssnitt och oavsiktligt exponerade övervakningstjänster kan nås direkt från främmande nätverk. En WireGuard-anslutning minskar denna synlighet, eftersom endast en definierad UDP-port för den krypterade tunneln behöver förbli tillgänglig. WireGuard maskerar dock inte trafiken som HTTPS och erbjuder inget TCP-transportläge.

Den lämpliga målbilden för VPN-administrationen är oftast ett ”hub-and-spoke”-nätverk: Servern hanterar gränssnittet wg0 och tilldelas då till exempel den interna adressen 10.77.0.1. En behörig persons bärbara dator ansluter som en egen peer och använder till exempel 10.77.0.10. SSH, en intern webbkonsol eller övervakningsändpunkter accepterar då åtkomst via tunnelnätverket istället för via den offentliga serveradressen.

Detta är inte ett VPN för slutanvändare som är avsett att omdirigera all webbtrafik från en enhet. För underhåll är en begränsad åtkomstmodell mer lämplig: tunneln fungerar endast som en väg till tydligt angivna administrationsmål. En fulltunnel kan visserligen användas medvetet, men den påverkar dessutom routningen, DNS-användningen och tillgängligheten till externa tjänster. Dessa bieffekter är oftast inte nödvändiga för en ren underhållsåtkomst.

Das Underhållsnätverk är enbart en nätverksgräns. Den avgör inte vilket Linux-konto som får logga in, vilka kommandon detta konto får utföra eller om operativsystemet är uppdaterat. Dessutom behöver du SSH-nycklar och personliga konton, lämpligt begränsade sudo-rättigheter, brandväggsregler, säkerhetsuppdateringar, loggning och en välskött nödåtkomst. På så sätt blir inte ett fel i ett enskilt skyddslager det enda avgörande faktorn för åtkomsten.

Korrekt klassificering av nycklar, peers och tillåtna IP-adresser

Varje WireGuard-peer har ett eget nyckelpar. Den privata nyckeln förvaras uteslutande på den tillhörande servern, bärbara datorn eller administrationsenheten; på motpartens enhet lagras endast den offentliga nyckeln som härleds från den privata. En valfri fördelad nyckel (PresharedKey) kompletterar kryptografin med öppna nycklar med ytterligare symmetriskt nyckelmaterial. Den utgör ett extra skydd, men ersätter varken privata nycklar eller en spårbar nyckelhantering.

Lägg en Peer per enhet inte en gemensam peer för ett team. På så sätt kan en förlorad arbetsstation eller en enhet från en tjänsteleverantör som inte längre behövs tas bort på ett målinriktat sätt. WireGuard-nycklarna ger åtkomst till underhållsnätverket. Därifrån skilt autentiserar SSH-nycklar en person eller en enhet gentemot SSH-tjänsten; en återkallelse måste därför planeras på båda nivåerna.

Särskilt viktiga är Tillåtna IP-adresser på servern. I WireGuard bildar de en krypterad nyckelruttningstabell: För utgående paket bestämmer de vilken peer som är lämplig utifrån måladressen. För inkommande, redan autentiserade paket begränsar de samtidigt de interna källadresser som denna peer får använda. Inställningen är därför mer än en vanlig routningsangivelse.

Om den administrativa bärbara datorn tilldelas adressen 10.77.0.10 ska det på servern för just denna peer finnas AllowedIPs = 10.77.0.10/32. /32-tilldelningen kopplar en enskild tunneladress till denna peer. Om du generellt skulle tilldela varje admin-peer 10.77.0.0/24 skulle denna tilldelning bli otydlig och konfigurationen onödigt omfattande. Kontrollera dessutom att det valda VPN-nätverket inte kolliderar med varken plats-, container- eller hemnätverk.

Planera nätgränser och åtkomstmodell

Planera VPN-adressnätverket före installationen. Välj ett privat område som inte överlappar befintliga LAN, molnnätverk, Docker- eller Kubernetes-nätverk eller vanliga hemnätverk. Fastställ vilka system som ska vara tillgängliga via tunneln: endast gateway-servern, ett avgränsat administrationsnätverk eller enskilda tjänster. Detta ligger senare till grund för klientrutter, brandväggsregler och eventuellt returrutter.

Dokumentera för varje enhet vilken användare som ansvarar för den, den offentliga WireGuard-nyckeln, den fasta tunnel-IP-adressen, syftet med behörigheten och hur den återkallas. Grupperna bör utformas utifrån specifika uppgifter, till exempel drift, databasdrift eller extern support, inte utifrån en generell princip om att „VPN får göra vad som helst“. Se dessutom till att ha en oberoende nödåtkomst, till exempel en leverantörskonsol. Kontrollera den innan du gör ändringar i brandväggen, SSH eller routningen, så att en felaktig regel inte leder till att någon stängs ute.

Die Brandvägg är den primära nätverksgränsen: den tillåter WireGuard-UDP-porten på det offentliga gränssnittet, men tar endast emot SSH-anslutningar via ingångsgränssnittet wg0 respektive det WireGuard-gränssnitt som faktiskt används. En ytterligare kontroll av VPN-källnätverket kan ytterligare avgränsa regeln, men får inte ersätta gränssnittsbindningen. På så sätt accepterar brandväggen inga paket som anländer till det offentliga gränssnittet enbart på grund av en påstådd VPN-källadress. WireGuard kopplar autentiserade interna adresser till peers; denna säkerhet gäller för paket som har accepterats via tunnelgränssnittet.

På SSH-nivå tillkommer nycklar istället för inloggning med lösenord, personliga konton och så begränsade sudo-regler som möjligt. OpenSSH kan användas med AllowUsers Koppla konton till ytterligare källadresser eller CIDR-nät. Denna andra säkerhetsbarriär kompletterar den som finns vid wg0 en kopplad brandväggsregel, men ersätter den inte.

Offentliga webbapplikationer måste även i fortsättningen ha en egen transportsäkerhet via HTTPS och lämpliga certifikat. En guide till hur man säkrar en webbplats med TLS Denna nivå hanterar åtkomst via webbläsare. WireGuard skyddar däremot åtkomsten till det privata administrationsnätverket; det ersätter varken TLS för offentliga tjänster eller deras inloggning, behörighetskontroll och underhåll.

Grundläggande uppbyggnad med wg-quick utan routningsfällor

För en enskild underhållsserver räcker det med ett enkelt punkt-till-punkt-scenario: Servern kör wg0 med tunneladressen 10.77.0.1/24, den administrativa bärbara datorn får permanent 10.77.0.10/32. Den offentliga servern tar endast emot UDP-trafik för WireGuard. Följande filer är ett konfigurationsförslag för wg-quick; de innehåller medvetet inga verkliga nycklar.

På servern kopplar en peer den bärbara datorns publika nyckel till just dess tunneladress. Serverns privata nyckel förblir uteslutande i den lokala filen. Spara konfigurationen till exempel under /etc/wireguard/wg0.conf och begränsa läsåtkomsten till administrationskontexten, eftersom den innehåller en hemlig nyckel. Offentliga nycklar är däremot avsedda för respektive motpart.

[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ärbara datorn hänvisar Endpoint till den offentliga serveradressen och den valda UDP-porten. För ren serverunderhållning används som klient Tillåtna IP-adresser oftast bara 10.77.0.1/32 nödvändigt. På så sätt dirigeras endast trafiken till serverns VPN-adress in i tunneln; bärbara datorns internettrafik följer sin vanliga väg.

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

Uppgiften 0.0.0.0/0 På klienten innebär däremot en IPv4-standardväg genom tunneln: en Full Tunnel. wg-quick härleder rutter utifrån AllowedIPs och hanterar standardrutter med ytterligare policy-routing-logik. Detta är möjligt för en åtkomst som medvetet planerats på detta sätt, men påverkar bland annat extern datatrafik och kan avslöja problem med DNS eller tillgänglighet.

Exemplet gäller endast IPv4. Om servern har offentlig IPv6-anslutning måste TCP-port 22 även där uttryckligen blockeras av IPv6-brandväggen, eller så måste SSH-tjänsten bindas på lämpligt sätt. En stängd IPv4-öppning skyddar inte mot en IPv6-lyssnare som fortfarande är tillgänglig från allmänheten. Planera IPv6-tunneladresser och prefix på klientsidan separat; ::/0 Det skulle i så fall också vara en standardrutt för IPv6 och inte ett neutralt tillägg till IPv4-konfigurationen.

Aktivera först tunneln, kontrollera anslutningen till VPN-adressen och logga in via SSH i en andra session. Först när denna metod fungerar tillförlitligt och det finns en oberoende konsol- eller återställningsåtkomst bör du ta bort den offentliga SSH-åtkomsten. Kontrollera både IPv4 och, i förekommande fall, IPv6. Privata nycklar hör inte hemma i ärenden, chattloggar eller versionshantering.

Jämföra routningsmodeller och brandväggsregler

Brandväggen tillämpar den önskade åtkomstmodellen. På det offentliga gränssnittet får den ta emot den angivna WireGuard-UDP-porten; TCP-port 22 ska däremot inte lämnas öppen där som en allmän administrationsåtkomst. SSH tillåts istället endast för paket vars ingångsgränssnitt wg0 respektive det WireGuard-gränssnitt som används. En kompletterande kontroll av källnätverket kan ytterligare begränsa det tillåtna VPN-området, men en regel som enbart baseras på källadressen är inte tillräcklig.

Kopplingen till ingångsgränssnittet förhindrar att ett paket som anländer till det offentliga gränssnittet uppfyller kraven för SSH-godkännande enbart på grund av en förfalskad källadress från VPN-området. WireGuards kryptografiska tilldelning av peer och intern adress gäller för autentiserade paket på tunnelgränssnittet. Den konkreta brandväggssyntaxen måste passa den använda programvaran och entydigt beakta både gränssnittet och adressfamiljen.

Ta uttryckligen hänsyn till offentlig IPv6-anslutning. Om endast IPv4-öppningen för TCP 22 tas bort kan SSH fortfarande vara tillgängligt från internet via IPv6. Blockera därför porten även i IPv6-reglerna eller konfigurera SSH-tjänsten så att den inte lyssnar på en offentlig IPv6-adress. IPv4- och IPv6-reglerna måste kontrolleras separat.

När det gäller en tillståndsbaserad brandvägg räcker det inte att endast teoretiskt beakta den önskade utgående vägen. Svarspaket från en tillåten anslutning måste också nå klienten; vid åtkomst bakom en gateway tillkommer dessutom den återvändande vägen från målnätverket. En generell öppning av hela VPN-undernätet mot alla tjänster gör onödigtvis underhållsnätverket till ett alltför omfattande internt åtkomstnätverk.

För underhåll av en enskild server är den första modellen den mest överskådliga. Klientvägen till 10.77.0.1/32 Det räcker, och brandväggen kan tillåta SSH endast för paket som anländer via WireGuard-gränssnittet. UDP-porten förblir visserligen synlig utifrån, men utan rätt peer-nyckel ger den ingen administrativ åtkomst.

Den andra modellen kräver en tydlig åtskillnad: VPN-servern fungerar då inte bara som slutpunkt, utan även som router. Brandväggen bör tillåta exempelvis SSH till definierade administrationsservrar och HTTPS till en intern konsol, i båda fallen begränsat till WireGuard-ingångsgränssnittet, specifika målnätverk och portar. Du bör inte öppna databasportar i hela VPN-nätverket enbart för att användarna redan är anslutna.

I ett fulltunnel-upplägg fungerar VPN-servern även som gateway för internetmål. För detta måste den vidarebefordra IPv4-paket mellan wg0 och vidarebefordra den via sin upplänk; dessutom behöver svaren en väg tillbaka till VPN-nätverket. I många serverkonfigurationer används en specifik Source-NAT-regel på upplänken för detta ändamål, om uppströmsnätverket inte känner till någon rutt till VPN-prefixet. Planera dessa regler noggrant och begränsa dem till det avsedda tunnelnätet.

En Full Tunnel är inte ett säkerhetskrav från WireGuard, utan ett routningsval som görs på klienten. Eftersom wg-quick Eftersom standardrutter från AllowedIPs behandlas på ett särskilt sätt bör denna inställning endast användas i kombination med planerad namnupplösning, tillräcklig gateway-kapacitet och lämpliga utgående regler. För den vanliga VPN-administration är den oftast mer omfattande än nödvändigt. För IPv6 gäller samma planeringsfråga separat: ::/0 leder all IPv6-trafik genom tunneln.

Göra interna nätverk tillgängliga på ett målinriktat sätt

Om administratörer ska kunna nå ytterligare privata system bakom VPN-gatewayen övergår uppgiften från ren serveråtkomst till ett routat administrationsnätverk. Planera först målnätverken och tjänsterna: till exempel SSH till servrar i administrationssegmentet och HTTPS till en intern konsol. Varje ytterligare väg utvidgar förtroendeområdet och bör därför motiveras av en konkret operativ uppgift.

Den första tekniska förutsättningen är att gatewayen måste kunna vidarebefordra IPv4-paket. Kernelinställningen net.ipv4.ip_forward aktiverar detta beteende. Det bör inte betraktas som en obetydlig enradare: Enligt kärndokumentationen medför en ändring av ip_forward Övriga IPv4-konfigurationsparametrar återställs till sina standardvärden för värddatorn respektive routern. Kontrollera därför gällande nätverks- och säkerhetsriktlinjer före och efter ändringen.

För det andra behöver brandväggen uttryckliga Transitregler i båda riktningarna. En regel bör inte helt enkelt omfatta all trafik från wg0 Acceptera inte trafik till LAN. Begränsa istället trafiken till VPN-källnätverket, de avsedda måladresserna och de nödvändiga protokollen, till exempel TCP 22 till administrationsservrar och TCP 443 till en konsol. Databaser får inte ingå i detta undantag utan välgrundad anledning.

För det tredje behöver målnätverket en återväg till VPN-nätverket, till exempel en rutt för 10.77.0.0/24 via gatewayens interna adress. Utan denna returväg kan utgående trafik fungera, medan svaren inte når tillbaka till administratören. Om routning i målnätverket inte är möjlig kan Source NAT på gatewayen vara ett tekniskt alternativ; det döljer dock den ursprungliga VPN-klientadressen och försvårar därmed loggning på mottagarsidan samt mer detaljerade regler.

Välj VPN-adressnätet så att det varken krockar med administratörernas lokala nätverk eller med befintliga plats-, moln- eller containernätverk. Överlappningar gör routvalet tvetydigt och orsakar fel som kan se ut som ett WireGuard- eller brandväggsproblem. Dokumentera dessutom fasta tunneladresser och tillhörande enheter innan du aktiverar ytterligare peers eller målnätverk.

Hantera drift och förändringar på ett säkert sätt

Ett underhållsnätverk förblir överskådligt endast om varje enhet tilldelas en egen peer, ett eget nyckelpar och en fast tunnel-IP-adress. En inventarielista bör därför åtminstone innehålla tunneladress, enhetsbeteckning, ansvarig person, syfte samt utfärdande- och kontrolldatum. Tilldelningen 10.77.0.10/32 till en specifik administratörsdator gör åtkomsten spårbar och förhindrar att flera enheter använder samma VPN-identitet.

Planera in nyckelbyte som en del av den löpande driften, inte först som en reaktion på en incident. Vid utbyte av utrustning skapar du en ny peer med en ny adress eller en tydligt dokumenterad efterföljande adress, kontrollerar åtkomsten och tar därefter bort den gamla peern. Privata WireGuard-nycklar hör uteslutande hemma på respektive slutpunkt; varken biljetter eller centrala inventarielistor bör innehålla dem.

Om en bärbar dator försvinner eller om en extern person slutar, tar du bort den tillhörande peern från serverkonfigurationen. Detta hindrar personen från att få tillgång till administrationsnätverket utan att du behöver byta ut andra administratörers nycklar. Peer-avvänjning men det är inte samma sak som att återkalla en SSH-nyckel: WireGuard-nyckeln styr nätverksvägen, medan SSH-nyckeln hanterar inloggningen på målkontot.

När en peer har tagits bort kan WireGuard inte längre utbyta paket via denna peer inom ramen för en befintlig SSH-anslutning; anslutningen fastnar därför eller avslutas efter avbrott eller timeout. Avstängningen återkallar dock inte automatiskt den SSH-inloggning som redan skett på applikationsnivå och avslutar inte heller tidigare startade processer. Kontrollera därför vid en incident även SSH-auktoriseringar, pågående processer, konton och, i förekommande fall, sudo-behörigheter.

För specifika ändringar kan man wg syncconf jämföra en befintlig WireGuard-konfiguration med de uttryckliga skillnaderna; enligt handboken ska detta störa peer-sessionerna mindre än setconf. Det ersätter dock inte godkännande, dubbelkontroll eller underhållsfönster. Säkerhetskopiera den fungerande konfigurationen före varje ändring och dokumentera hur du återställer den.

Diagnos från handskakning till SSH-åtkomst

Vid ett fel ska du konsekvent skilja transport, routning och applikation åt. Börja med den offentligt tillgängliga UDP-porten och handskakningen innan du ändrar SSH-inställningarna. Kommandot wg show Visar bland annat AllowedIPs, tidpunkten för den senaste handskakningen och överföringsräknaren för konfigurerade peers. Saknade eller oförändrade värden tyder på ett problem som uppstod före själva SSH-åtkomsten.

Om en handskakning har ägt rum kontrollerar du både på klienten och servern vilken tunneladress som faktiskt har angetts samt rutten till målet. För ren gateway-hantering måste klienten kunna nå målet 10.77.0.1 via WireGuard-gränssnittet. Vid interna mål tillkommer brandväggsräknare, tillåten returtrafik och returvägen för målnätverket; en lyckad handskakning bevisar inte att dessa förutsättningar är uppfyllda.

Först när nätverksvägen stämmer kan man gå vidare till kontrollen av SSH-tjänsten. Kontrollera de poster i sshd_config, särskilt användarbehörigheter som AllowUsers, och kontrollera tjänstens status samt loggarna med hjälp av verktygen i din distribution. Därefter undersöker du användarkontot och posterna i authorized_keys och sudo-regler separat. Konfigurationsdokumentationen i sig bevisar varken att inloggningen lyckades eller att tjänsten är tillgänglig.

Identiska eller överlappande AllowedIPs är inte bara ett dokumentationsfel. Vid sändning tilldelar WireGuard måladresser till en peer utifrån dessa prefix; vid mottagning begränsar de de autentiserade peerarnas interna källadresser. Dubbla eller motstridiga värdprefix utgör därför inte en entydig, tillförlitligt spårbar Peer-tilldelning. Man bör inte förutsätta vilket konkret resultat ett administrationsverktyg ger vid övertagandet av en sådan konfiguration. Förhindra istället kollisionen redan i inventeringen och vid konfigurationskontrollen.

Genomför korrigeringar på ett kontrollerat sätt och utför diagnostik endast när nödåtkomst är tillgänglig. På så sätt förhindrar du att en felaktig ändring av peer, routing eller brandvägg samtidigt blockerar vägen tillbaka för reparation. Kontrollera efter varje övertagande återigen handskakningen, överföringsräknaren, rutten och åtkomsten till den specifikt godkända administrationstjänsten.

wg show
ip route

Verktygsvalet och säkerhetsgränserna är avgörande

Valet av administrationsmetod styrs av den befintliga serveradministrationen, inte av någon förmodad universell WireGuard-metod. wg-quick lämpar sig för överskådliga konfigurationer: Hjälpskriptet konfigurerar gränssnitt, adresser och rutter som härleds från AllowedIPs. För komplexa nätverk hänvisar dokumentationen däremot till mer specifika verktyg eller direktkonfiguration med wg och IP-verktyg.

Om en värd redan hanterar sitt nätverk deklarativt via systemd-networkd är .netdev- och .network-filer ett lämpligt alternativ. systemd-networkd stöder WireGuard-specifika inställningar och kan hämta privata nycklar från autentiseringsuppgifter; för hemligt innehåll rekommenderar dokumentationen krypterade autentiseringsuppgifter eller åtminstone restriktiva filbehörigheter som skyddsåtgärd. Detta passar särskilt bra för automatiskt driftsatta servrar.

Direkta länkar från wg och ip ger störst kontroll över automatisering, policybaserad routning och särskilda brandväggsprocesser, men kräver en tydligt underhållen driftsmodell. Hantera aldrig samma gränssnitt samtidigt via wg-quick, systemd-networkd och egna skript. Flera ansvariga instanser kan överskriva varandra när det gäller rutter, adresser eller peer-inställningar, vilket försvårar en tillförlitlig återställning.

PersistentKeepalive är endast meningsfullt för peers som befinner sig bakom NAT eller en tillståndsbaserad brandvägg, som sällan själva skickar data men ändå måste förbli tillgängliga för inkommande trafik. Om inget anges är funktionen inaktiverad; i dokumentationen anges 25 sekunder endast som ett möjligt intervall, inte som en allmän standardinställning. Mobila klienter drar ofta nytta av roaming, eftersom WireGuard kan uppdatera slutpunkten utifrån korrekt autentiserade paket.

Roaming och fasta begränsningar för slutpunkter är en avvägning: En brandvägg som endast tillåter UDP från kända källnätverk kan begränsa attackytan, men hindrar flexibel användning när man är på resande fot. WireGuard påpekar dessutom att en aktiv angripare kan omdirigera den externa källadressen och därmed underlätta en överbelastningsattack (Denial of Service) utan att behöva läsa eller ändra det krypterade innehållet.

En WireGuard-tunnel ersätter inte identitetshantering, behörighetskontroll, uppdateringar, säkerhetskopiering eller loggning. Den maskerar inte sin trafik som HTTPS och erbjuder inget TCP-läge. Offentliga webbapplikationer behöver därför fortfarande en separat TLS-säkerhetslösning; kraven och genomförandet förklaras i artikeln Konfigurera HTTPS på ett säkert sätt. Se till att tydligt skilja detta skyddslager från VPN-åtkomsten för administrationen.