Router eller separat dator som VPN-server: så väljer du

Både en router och en liten dator kan avsluta en VPN, och beslutet hänger sällan på genomströmningen. Det hänger på vem som lägger in uppdateringen klockan två på natten, vad mer som stannar när den lådan startar om, och om du fortfarande når en konsol när det är tunneln som har gått sönder. Svara på de tre frågorna för varje kandidat, och valet brukar göra sig självt. Proceduren nedan gör jämförelsen till en kort lista över saker du kan kontrollera innan du binder dig.

Börja med det som måste fortsätta köra när tunneln fallerar

Felet du måste dimensionera för är det där VPN-processen dör och du ändå måste nå värden. På en router delar tunneln och internetporten öde: en dålig konfigurationsändring kan ta ner båda, och vägen tillbaka är ofta en fysisk återställning. På en separat dator fortsätter porten att fungera, och värden är fortfarande nåbar över LAN. Vilket av dessa utfall du tål avgör mer än någon funktionslista.

Skriv svaret som en mening: om VPN-värden startar om, vad förlorar hushållet eller kontoret? Om svaret omfattar all internetåtkomst har du accepterat en delad feldomän, och det bör du säga med avsikt i stället för att upptäcka det senare.

En andra tjänst på samma enhet är inte en reservkonsol. Den delar strömförsörjning, firmware och administratörskonto.

Räkna underhållsytorna som varje värd tillför

En router kommer med tillverkarens firmware med egen utgivningstakt, och VPN-funktionen är oftast en modul inuti en mycket större avbild. En dator kommer med ett operativsystem, en pakethanterare, en kärna och en uppsättning tjänster som nu ägs av dig. Båda behöver patchas, och den verkliga frågan är vilken takt du håller när nyheten har lagt sig.

På en Linux-värd gör du den takten synlig i stället för att hoppas på den. systemctl list-timers visar de schemalagda jobben och apt list --upgradable visar vad som väntar. Anteckna vilka uppdateringar som kräver omstart, för en VPN-värd som startar om är ett avbrott om du inte har planerat det. En router utan automatisk uppdateringsväg behöver i stället en kalenderpost, vilket är en svagare kontroll men en ärlig.

Räkna också kontona. Varje extra administratörsinloggning på VPN-värden är ännu en autentiseringsuppgift att rotera och ännu en väg att återkalla.

Följ vägen i det privata nätet, inte etiketten på lådan

Klienterna bryr sig inte om var servern kör; de bryr sig om de skyddade prefixen går att nå och om det finns en returväg. Sätt servern där routningen är enklast, vilket oftast betyder direkt på det segment som håller resurserna. En dator bakom routern behöver fortfarande portvidarebefordran, och resurserna på det LAN-et behöver fortfarande en rutt tillbaka till tunnelns subnät.

Kontrollera vidarebefordran på värden innan du skyller på klienten. sysctl net.ipv4.ip_forward bör rapportera 1, och nft list ruleset eller iptables -S visar om tunnelgränssnittet alls får vidarebefordra. En saknad masquerade-regel ser från klientsidan exakt ut som en trasig tunnel.

Bestäm också vad tunneln inte får nå. En server placerad på routern ser varje subnät som den routern routar, och det är ofta mer än åtkomstpolicyn avser. På en separat värd är samma isolering en brandväggsregel bort, och skaderadien från en komprometterad klient är mindre. Beskrivningen av IPsec-porten i RFC 7296 behandlar detta som en routing- och policyfråga, inte en hårdvarufråga, och ingen av formerna är säkrare som standard förrän policyn är nedskriven.

Håll en återställningskonsol som inte är beroende av tunneln

Konsolen du använder för att reparera VPN:en kan inte vara VPN:en själv. Håll en LAN-adress, en seriell konsol eller en leverantörskonsol som fungerar medan tunneln ligger nere, och använd den minst en gång innan du behöver den. En väg utanför bandet som aldrig har övats är en plan och inte en förmåga.

Säkerhetskopiera konfigurationen någonstans där värden själv inte kan radera den. tar -czf vpn-config-2026-11-03.tar.gz /etc/wireguard /etc/openvpn fångar nycklarna och tjänstedefinitionerna, och kopian måste lämna maskinen. Ta med brandväggsreglerna och klientinventariet, eftersom att återställa nycklar utan peer-listan ger en server som ingen kan ansluta till. Förvara arkivet där återställningskonsolen kan nå det.

Skriv återstegssteget i samma anteckning. En konfigurationsändring utan dokumenterad återgång är en permanent ändring, vilken avsikten än var.

Verifiera valet med en omstart och en uppdatering

Testa arrangemanget så som det kommer att fallera, inte så som det fungerar en bra dag. Starta om värden, tillämpa en väntande uppdatering och bekräfta att tunneln kommer tillbaka utan manuella steg.

Kontrollera efter omstarten de tre saker som oftast går sönder. systemctl is-active wg-quick@wg0 rapporterar om gränssnittet kom tillbaka, ss -lunp visar om något lyssnar på porten, och wg show listar en peer med ett slutfört handslag. En tjänst som är aktiv utan handslag betyder att brandväggen eller rutten är fel, inte daemonen.

Upprepa kontrollen från en klient på ett annat nät än det du konfigurerade från. Om tunneln överlever en omstart, en uppdatering och ett byte av klientnät är värdvalet avgjort för nu. Om inte är den saknade biten oftast ett dokumenterat steg och inte en annan låda.