Encaminador o ordinador a part com a servidor VPN: com triar

Tant un encaminador com un ordinador petit poden acabar una VPN, i la decisió poques vegades depèn del cabal. Depèn de qui aplica l’actualització a les dues de la matinada, de què més s’atura quan aquesta caixa es reinicia i de si encara podeu arribar a una consola quan el que s’ha trencat és el túnel. Responeu aquestes tres preguntes per a cada candidat i la tria normalment es fa tota sola. El procediment següent converteix la comparació en una llista curta de coses que podeu comprovar abans de comprometre-us.

Comenceu per allò que ha de continuar funcionant quan falla el túnel

La fallada per a la qual cal dissenyar és aquella en què el procés de la VPN mor i tot i així heu d’arribar a l’amfitrió. En un encaminador, el túnel i la passarel·la d’internet comparteixen el destí: un mal canvi de configuració pot tombar tots dos, i el camí de recuperació sovint és un reinici físic. En un ordinador a part, la passarel·la continua funcionant i l’amfitrió continua sent accessible per la LAN. Quin d’aquests resultats podeu tolerar decideix més que qualsevol llista de funcions.

Escriviu la resposta en una frase: si l’amfitrió de la VPN es reinicia, què perd la llar o l’oficina? Si la resposta inclou tot l’accés a internet, heu acceptat un domini de fallada compartit i ho hauríeu de dir deliberadament en lloc de descobrir-ho més endavant.

Un segon servei al mateix aparell no és una consola de reserva. Comparteix la font d’alimentació, el firmware i el compte d’administrador.

Compteu les superfícies de manteniment que afegeix cada amfitrió

Un encaminador porta firmware del fabricant amb el seu propi ritme de versions, i la funció de VPN sol ser un mòdul dins d’una imatge molt més gran. Un ordinador porta un sistema operatiu, un gestor de paquets, un nucli i un conjunt de serveis que ara teniu. Tots dos necessiten pedaços, i la qüestió real és quin ritme mantindreu quan la novetat s’esvaeixi.

En un amfitrió Linux, feu visible aquest ritme en lloc d’esperar-lo. systemctl list-timers mostra les tasques programades i apt list --upgradable mostra què espera. Anoteu quines actualitzacions necessiten un reinici, perquè un amfitrió de VPN que es reinicia és una interrupció tret que l’hàgiu planificat. Un encaminador sense camí d’actualització automàtica necessita en canvi una entrada al calendari, que és un control més feble però honest.

Compteu també els comptes. Cada inici de sessió addicional d’administrador a l’amfitrió de la VPN és una credencial més per rotar i un camí més per revocar.

Seguiu el camí de la xarxa privada, no l’etiqueta de la caixa

Als clients no els importa on s’executa el servidor; els importa si els prefixos protegits són accessibles i si hi ha un camí de tornada. Poseu el servidor on l’encaminament sigui més simple, cosa que normalment vol dir directament al segment que conté els recursos. Un ordinador darrere de l’encaminador encara necessita una redirecció de port, i els recursos d’aquella LAN encara necessiten una ruta de tornada a la subxarxa del túnel.

Comproveu la redirecció a l’amfitrió abans de culpar el client. sysctl net.ipv4.ip_forward hauria de reportar 1, i nft list ruleset o iptables -S mostra si la interfície del túnel té permís per redirigir. Una regla masquerade que falta sembla exactament un túnel trencat des del costat del client.

Decidiu també què no ha d’assolir el túnel. Un servidor col·locat a l’encaminador veu totes les subxarxes que aquest encaminador encamina, cosa que sovint és més del que pretén la política d’accés. En un amfitrió a part, el mateix aïllament és a una regla de tallafoc de distància, i el radi de danys d’un client compromès és més petit. La descripció de la passarel·la IPsec de l’RFC 7296 ho tracta com una qüestió d’encaminament i política, no de maquinari, i cap de les dues formes és més segura per defecte fins que la política està escrita.

Manteniu una consola de recuperació que no depengui del túnel

La consola que feu servir per reparar la VPN no pot ser la VPN. Manteniu una adreça LAN, una consola sèrie o una consola del proveïdor que funcioni mentre el túnel està caigut, i feu-la servir almenys una vegada abans que calgui. Un camí fora de banda que mai s’ha exercitat és un pla, no una capacitat.

Feu una còpia de seguretat de la configuració en un lloc que l’amfitrió mateix no pugui esborrar. tar -czf vpn-config-2026-11-03.tar.gz /etc/wireguard /etc/openvpn captura les claus i les definicions dels serveis, i la còpia ha de sortir de la màquina. Incloeu les regles del tallafoc i l’inventari de clients, perquè restaurar claus sense la llista de parells produeix un servidor al qual ningú no es pot unir. Guardeu l’arxiu on la consola de recuperació el pugui abastar.

Escriviu el pas de reversió a la mateixa nota. Un canvi de configuració sense reversió documentada és un canvi permanent, fos quina fos la intenció.

Verifiqueu la tria amb un reinici i una actualització

Proveu la disposició tal com fallarà, no tal com funciona en un bon dia. Reinicieu l’amfitrió, apliqueu una actualització pendent i confirmeu que el túnel torna sense passos manuals.

Després del reinici, comproveu les tres coses que es trenquen més sovint. systemctl is-active wg-quick@wg0 informa si la interfície ha tornat, ss -lunp mostra si alguna cosa escolta al port, i wg show llista un parell amb un handshake completat. Un servei actiu sense handshake vol dir que el tallafoc o la ruta són incorrectes, no el dimoni.

Repetiu la comprovació des d’un client en una xarxa diferent de la que heu fet servir per configurar. Si el túnel sobreviu a un reinici, una actualització i un canvi de xarxa del client, la tria d’amfitrió queda resolta per ara. Si no, la peça que falta sol ser un pas documentat i no una altra caixa.