Qué debe permitir un VPS antes de poder alojar tu VPN

La instancia arranca, las instalaciones de paquetes tienen éxito y el servicio incluso informa de un estado en ejecución, pero nada se conecta. Ese patrón es habitual en los servidores privados virtuales, porque un invitado que llega cómodamente a internet aún puede ser incapaz de crear la interfaz que quiere tu protocolo. Cinco comprobaciones separan un host que puede servir un túnel de uno que solo parece preparado, y la primera comprobación que falla suele explicar todo lo demás. Cada una es barata de ejecutar y termina en una decisión, no en una nota.

Confirma la interfaz que necesita el protocolo

OpenVPN sobre TUN necesita el dispositivo de caracteres y el módulo del núcleo que hay detrás; WireGuard necesita su propio soporte en el núcleo o una implementación en espacio de usuario con expectativas coincidentes. Los contenedores gestionados pueden compartir un núcleo de host que nunca expone el dispositivo, y algunas plataformas prohíben crear interfaces de túnel sin más, independientemente de lo instalado.

Prueba la capacidad en lugar de leer una página de soporte, porque las etiquetas de marketing cambian más rápido que los límites subyacentes. Una lista de funciones escrita para un plan puede no describir el núcleo en el que el invitado se ejecuta realmente. Dos comandos cortos responden a la pregunta para los protocolos de uso común, y ambos limpian tras de sí. Los comandos de abajo no crean nada permanente y se eliminan de inmediato.

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

Un rechazo en el primer par significa que TUN no está disponible y que el modo predeterminado de OpenVPN no puede arrancar; un rechazo en la última línea significa que falta la interfaz de núcleo de WireGuard. La documentación del núcleo sobre TUN/TAP describe el dispositivo que ejercita la primera comprobación. Ninguno de los dos fallos se repara reinstalando el paquete VPN.

Recuerda que la ruta de entrada tiene dos dueños

Las reglas de red del proveedor y el cortafuegos del invitado son sistemas separados, y el tráfico debe sobrevivir a ambos. Un oyente vinculado en el invitado no significa nada si el grupo de seguridad del proveedor descarta el puerto, y una regla abierta del proveedor no hace nada si el invitado rechaza el paquete. Verifica el oyente, luego las reglas del invitado, luego el panel del proveedor, en ese orden, y confirma tanto el protocolo como el número de puerto. Saltar primero al panel del proveedor es como la gente acaba abriendo un rango que no necesitaba.

UDP es la víctima habitual: muchas plataformas permiten TCP por defecto y tratan las reglas UDP como una entrada aparte. Si la instancia está detrás del NAT del proveedor en lugar de tener una dirección pública, el reenvío de puertos en el lado del proveedor se convierte en una tercera configuración que conciliar.

Planifica la ruta de vuelta, no solo la salida

El servicio de túnel completo necesita el reenvío activado, un esquema de traducción o enrutamiento para el tráfico de los clientes y una ruta de vuelta que llegue al conjunto de clientes. Abrir un oyente no aporta nada de eso. Un túnel que se establece pero no transporta tráfico útil suele fallar aquí, no en la autenticación. Trata un apretón de manos correcto como el inicio del diagnóstico, no como su final.

Escribe el plan como tres decisiones concretas: qué rango de origen reciben los clientes, cómo sale su tráfico hacia internet y cómo encuentran el camino de vuelta las respuestas. Luego confirma que el núcleo está de acuerdo con el plan antes de probar un cliente, para que una discrepancia silenciosa no se confunda con un fallo del lado del cliente.

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

Decide el asunto IPv6 explícitamente

IPv6 llega por varios mecanismos que se comportan de forma distinta para una puerta de enlace: una dirección en la instancia, un prefijo enrutado o nada. Solo un prefijo enrutado permite al servidor entregar direcciones a los clientes de la manera habitual. Suponer que una dirección IPv6 funcional en el host implica un prefijo de cliente utilizable es un error que aparece más tarde como conectividad medio rota. Es el tipo de fallo que sobrevive a todas las pruebas realizadas solo con IPv4.

Si el proveedor no enruta ningún prefijo, decide si el túnel es solo IPv4 y si hay que decírselo a los clientes. Una ausencia documentada es más segura que una configuración parcial que manda en silencio los destinos IPv6 a un agujero negro para los usuarios conectados.

Demuéstralo desde un cliente externo

El estado local del servicio describe un proceso en un host. La prueba útil es un cliente autorizado en otra red, que se conecta con el perfil que pretendes distribuir, luego llega a una aplicación y resuelve un nombre. Vuelve a conectarte una vez también, porque un túnel que solo funciona al primer intento no cumple el requisito que más importa en la práctica.

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

Mantén los fundamentos operativos junto a la prueba: espacio para actualizaciones, registros acotados, acceso administrativo que no dependa del túnel, una consola de recuperación y una nota sobre qué pasa con los perfiles de los clientes cuando la instancia se reconstruye y cambia su dirección pública. Si una interfaz o un modelo de reenvío necesario simplemente no está disponible, ningún cambio del lado del cliente lo aportará, y el siguiente paso honesto es otro tipo de instancia, no más configuración.