Router eller separat computer som VPN-server: sådan vælger du

Både en router og en lille computer kan afslutte en VPN, og beslutningen handler sjældent om gennemstrømning. Den handler om, hvem der anvender opdateringen klokken to om natten, hvad der ellers stopper, når den boks genstarter, og om du stadig kan nå en konsol, når tunnelen er det, der er gået i stykker. Svar på de tre spørgsmål for hver kandidat, og valget træffer sig ofte selv. Proceduren nedenfor forvandler sammenligningen til en kort liste af ting, du kan kontrollere, før du forpligter dig.

Start med det, der skal køre videre, når tunnelen svigter

Det svigt, du skal designe til, er det, hvor VPN-processen dør, og du alligevel skal nå værten. På en router deler tunnelen og internetgatewayen skæbne: én dårlig konfigurationsændring kan tage begge ned, og vejen tilbage er ofte en fysisk nulstilling. På en separat computer bliver gatewayen ved med at virke, og værten er stadig tilgængelig over LAN. Hvilket af de udfald, du kan acceptere, afgør mere end enhver funktionsliste.

Skriv svaret som en sætning: hvis VPN-værten genstarter, hvad mister husstanden eller kontoret så? Hvis svaret omfatter al internetadgang, har du accepteret et delt fejldomæne og bør sige det med vilje i stedet for at opdage det senere.

En anden tjeneste på samme apparat er ikke en reservekonsol. Den deler strømforsyningen, firmwaren og administratorkontoen.

Tæl de vedligeholdelsesflader, hver vært tilføjer

En router bringer producentfirmware med sin egen udgivelsesrytme, og VPN-funktionen er normalt et modul inde i et meget større image. En computer bringer et styresystem, en pakkehåndtering, en kerne og et sæt tjenester, som du nu ejer. Begge skal patches, og det egentlige spørgsmål er, hvilken rytme du holder, når nyhedens interesse har lagt sig.

På en Linux-vært skal du gøre den rytme synlig i stedet for at håbe på den. systemctl list-timers viser de planlagte job, og apt list --upgradable viser, hvad der venter. Noter, hvilke opdateringer der kræver genstart, for en VPN-vært, der genstarter, er et afbrud, medmindre du har planlagt det. En router uden automatisk opdateringsvej har i stedet brug for en kalenderpost, hvilket er en svagere kontrol, men en ærlig en.

Tæl også konti med. Hvert ekstra administratorlogin på VPN-værten er endnu en legitimationsoplysning at rotere og endnu en vej at tilbagekalde.

Følg vejen i det private netværk, ikke etiketten på boksen

Klienter er ligeglade med, hvor serveren kører; de er optaget af, om de beskyttede præfikser kan nås, og om der findes en returvej. Placer serveren, hvor routing er enklest, hvilket normalt betyder direkte på det segment, der holder ressourcerne. En computer bag routeren har stadig brug for portforwarding, og ressourcerne på det LAN har stadig brug for en rute tilbage til tunnelens undernet.

Kontrollér videresendelse på værten, før du bebrejder klienten. sysctl net.ipv4.ip_forward bør rapportere 1, og nft list ruleset eller iptables -S viser, om tunnelinterfacet overhovedet må videresende. En manglende masquerade-regel ser fra klientsiden præcis ud som en brudt tunnel.

Beslut også, hvad tunnelen ikke må nå. En server placeret på routeren kan se hvert undernet, som routeren router, og det er ofte mere, end adgangspolitikken sigter mod. På en separat vært er den samme isolering én firewallregel væk, og skadesradius fra en kompromitteret klient er mindre. Beskrivelsen af IPsec-gatewayen i RFC 7296 behandler dette som et routing- og politikspørgsmål, ikke et hardware-spørgsmål, og ingen af formerne er sikrere som standard, før politikken er skrevet ned.

Hold en gendannelseskonsol, der ikke afhænger af tunnelen

Den konsol, du bruger til at reparere VPN'en, kan ikke være VPN'en selv. Hold en LAN-adresse, en seriel konsol eller en udbyderkonsol, der virker, mens tunnelen er nede, og brug den mindst én gang, før du får brug for den. En out-of-band-vej, der aldrig er afprøvet, er en plan frem for en evne.

Tag backup af konfigurationen et sted, som værten selv ikke kan slette. tar -czf vpn-config-2026-11-03.tar.gz /etc/wireguard /etc/openvpn fanger nøglerne og tjenestedefinitionerne, og kopien skal forlade maskinen. Medtag firewallreglerne og klientfortegnelsen, fordi gendannelse af nøgler uden peer-listen giver en server, som ingen kan tilslutte sig. Opbevar arkivet, hvor gendannelseskonsollen kan nå det.

Skriv tilbagerulningstrinnet i samme note. En konfigurationsændring uden dokumenteret tilbagevenden er en permanent ændring, uanset hensigten.

Bekræft valget med en genstart og en opdatering

Test arrangementet, som det vil fejle, ikke som det virker på en god dag. Genstart værten, anvend en ventende opdatering, og bekræft, at tunnelen vender tilbage uden manuelle trin.

Efter genstarten skal du kontrollere de tre ting, der oftest brækker. systemctl is-active wg-quick@wg0 rapporterer, om interfacet kom tilbage, ss -lunp viser, om noget lytter på porten, og wg show viser en peer med et fuldført handshake. En tjeneste, der er aktiv uden handshake, betyder, at firewallen eller ruten er forkert, ikke daemonen.

Gentag kontrollen fra en klient på et andet netværk end det, du konfigurerede fra. Hvis tunnelen overlever en genstart, en opdatering og et skift af klientnetværk, er værtvalget afgjort for nu. Hvis ikke, er den manglende brik normalt et dokumenteret trin frem for en anden boks.