Ejecute un endpoint personal WireGuard con un historial mínimo
Cree una pequeña VPN autoalojada, separe el enrutamiento de la administración y revise los registros creados alrededor de WireGuard.
De un vistazo
Autoalojar WireGuard te da control sobre pares, claves, enrutamiento y configuración de la VPN. No elimina al proveedor de alojamiento ni todos los registros del sistema. Protege el material de claves, prueba las reglas de cortafuegos y revisa la retención del sistema operativo y de las aplicaciones antes de describir el endpoint como sin registros.
Sepa qué cambia el autoalojamiento
Una VPN personal le da control del extremo, las claves de pares y la configuración. Puede inspeccionar el sistema invitado en lugar de depender solo de la política de actividad de un proveedor comercial. También le da una dirección estable cuya reputación no se comparte con miles de clientes de VPN no relacionados.
Esa dirección generalmente se asocia con su propio tráfico, por lo que ofrece menos cobertura de multitud que una salida compartida. El operador del VPS y la red ascendente siguen formando parte del modelo de confianza. El autoalojamiento es útil para el control y la conectividad privada; no proporciona automáticamente anonimato ni cifrado de extremo a extremo para cada aplicación.
Prepare un sistema Linux simple y dispositivos cliente
Use una distribución Linux mantenida, acceso root para los cambios iniciales de red y un extremo público accesible por UDP. WireGuard es ligero para un uso personal modesto, mientras que la cuota de tráfico y la velocidad de conexión suelen ser las principales limitaciones. Un mayor rendimiento o múltiples cargas de trabajo pueden cambiar los requisitos de CPU y memoria.
Planifique una identidad de par por dispositivo para que un teléfono perdido pueda revocarse sin reemplazar todas las claves. Decida qué direcciones y servicios deben atravesar el túnel. Un túnel de internet completo necesita reenvío y generalmente traducción de direcciones; una malla privada entre servidores puede que no.
Genere las claves localmente y asigne los pares de forma explícita
Genere la clave privada de cada dispositivo en ese dispositivo y comparta solo la clave pública correspondiente. Restrinja los permisos de los archivos de claves y evite pasar configuraciones completas de cliente por correo no protegido o notas compartidas. Un código QR que contiene una configuración contiene la clave privada y también debe protegerse.
La interfaz del servidor normalmente tiene una dirección de túnel privada, un puerto de escucha UDP y una entrada de par por cliente. AllowedIPs combina el enrutamiento y la autorización de direcciones de pares. Dé a cada cliente su propia dirección de túnel en lugar de usar rangos de pares superpuestos del lado del servidor.
umask 077
wg genkey > privatekey
wg pubkey < privatekey > publickeyHaga que el enrutamiento y el cortafuegos funcionen juntos
Habilite el reenvío requerido por las familias de direcciones que elija y configure el cortafuegos para permitir el tráfico del túnel y la salida prevista. Para una pasarela de internet IPv4 común, eso incluye una regla de enmascaramiento adecuada en la interfaz pública. Haga coincidir la regla con el nombre real de la interfaz y la subred.
Exponga solo el escucha UDP requerido y su ruta de administración protegida. Un protocolo de enlace exitoso por sí solo no demuestra que el enrutamiento funcione. Compruebe la accesibilidad a internet, DNS y el tráfico de retorno. Persista la configuración tras el reinicio usando el mecanismo de servicio WireGuard compatible con la distribución.
Configure los clientes sin crear fugas
Un cliente necesita la clave pública del servidor, la dirección del extremo y el puerto, su propia dirección de túnel y las rutas que se enviarán al túnel. Para un túnel completo IPv4, la ruta es 0.0.0.0/0; IPv6 también requiere una configuración intencional, a menudo ::/0 con enrutamiento IPv6 funcional o bloqueo explícito donde no sea compatible.
Elija cómo se gestionan las consultas DNS y pruebe desde cada cliente. Si el túnel está destinado a proteger todo el tráfico, verifique qué ocurre cuando se desconecta. Un interruptor de seguridad basado en cortafuegos puede impedir el acceso directo accidental, pero debe adaptarse y probarse para el dispositivo en lugar de darse por sentado a partir de una única configuración de ruta.
- Compruebe la dirección pública que muestra un extremo de prueba de confianza.
- Pruebe la resolución de DNS y el comportamiento de IPv6.
- Confirme que los servicios previstos funcionan a través del túnel.
- Verifique el resultado después de reiniciar el servidor y el cliente.
- Pruebe la pérdida de conexión si necesita que el tráfico se detenga cuando falla la VPN.
Minimice el historial en todo el sistema
WireGuard expone el estado activo de los pares, como los últimos protocolos de enlace y los contadores de transferencia; normalmente no mantiene por sí mismo un historial de navegación persistente. Esa distinción importa: una configuración de par y el estado actual del extremo todavía existen. Los scripts adicionales pueden escribir esas observaciones en disco si los añade.
Revise los componentes circundantes: el diario del sistema, el registro del cortafuegos, la contabilidad del tráfico, los registros del resolutor DNS y los agentes de monitorización. Use una retención de diagnóstico proporcionada en lugar de afirmar que la máquina no contiene ningún registro. El cifrado del almacenamiento aborda algunos riesgos del disco, mientras que un VPS en funcionamiento sigue dependiendo de su infraestructura subyacente.
- Evite scripts innecesarios que archiven la actividad de conexión de pares.
- Desactive el historial de consultas DNS cuando no sea necesario.
- Mantenga los diagnósticos operativos acotados y de corta duración.
- Proteja la configuración de pares y las claves privadas.
- Revise los contenidos de monitoreo y respaldo de terceros.
Separe la ruta de datos de la VPN de la administración
WireGuard transporta UDP y no se ejecuta a través del transporte SOCKS ordinario TCP de Tor. Mantenga la ruta de datos de la VPN en su ruta de red normal. SSH o un panel de administración privado pueden usar por separado Tor, incluido un servicio onion autorizado por el cliente.
Esto protege la conexión de administración de exponer una IP de administrador directa, mientras que el punto de conexión de la VPN sigue recibiendo tráfico de red de sus clientes. Pagar de forma privada y usar una administración protegida no cambian ese hecho de la ruta de datos. Mantenga claras las protecciones y sus límites.
Mantenga las claves, la capacidad y el acceso
Revoque los dispositivos perdidos eliminando sus claves de par e emita reemplazos por separado. Mantenga actualizado el software del host, conserve un respaldo protegido de la configuración y monitoree la capacidad sin archivar innecesariamente la actividad del usuario. Verifique el consumo de transferencia antes de que amenace la asignación mensual.
El punto de conexión también puede convertirse en una ruta privada a un servicio doméstico u otro VPS. Añada rutas y permisos de firewall deliberadamente en lugar de exponer todos los servicios de la máquina. Comience con la disposición de red más pequeña que resuelva el problema, luego amplíela con la misma disciplina de claves y registros.