Limite un receptor VPN a las interfaces que pretendía

Un servicio VPN es accesible desde donde esté enlazado su socket y su cortafuegos lo permita. Son dos decisiones separadas, y normalmente la gente solo toma una de ellas. Leer el receptor real lleva diez segundos y resuelve una cuestión que las conjeturas no pueden. Empiece por ahí y luego cambie un control cada vez.

Todo lo siguiente supone que puede ejecutar comandos en el host con root o sudo.

Lea los sockets antes de cambiar nada

En Linux, ss -lunp enumera los receptores UDP con su dirección local, puerto y proceso, y ss -ltnp hace lo mismo con TCP. Busque el puerto de la VPN y lea con cuidado la columna de dirección. 0.0.0.0:51820 y [::]:51820 significan todas las interfaces, mientras que 10.0.0.5:51820 significa una dirección en una interfaz. El manual de ss documenta las columnas si la salida no le resulta familiar. Si falta el nombre del proceso, ejecute el mismo comando con sudo, porque la columna de propietario necesita privilegios.

Anote la dirección. Es el hecho del que depende el resto de esta guía.

Enlácese a una dirección, no a un deseo

OpenVPN enlaza el receptor a una dirección concreta con su directiva local, y esa es la forma admitida de acotarlo a nivel de proceso. No todas las implementaciones ofrecen un equivalente, y un protocolo sin opción de enlace no puede estrecharse de este modo. Si la suya no tiene ninguna, el cortafuegos es su único control, y las notas de despliegue deberían decirlo claramente. En un host con varias direcciones, enlácese a la que mira hacia el túnel; enlazarse a una dirección flotante suele ser un error.

Un servicio que debe sobrevivir a un cambio de dirección necesita un plan para el enlace obsoleto, no solo una línea de configuración.

Compruebe la familia de direcciones por separado

IPv4 e IPv6 son sockets separados. Un proceso enlazado a 0.0.0.0 aún puede aceptar IPv6 mediante un socket de doble pila, o puede que no, según la opción del socket y el valor predeterminado de la plataforma. Leer solo la línea IPv4 ha engañado a más de una revisión de despliegue. Enumere ambas familias antes de concluir que el receptor es estrecho.

Si IPv6 no forma parte del diseño, desactivarlo a nivel de socket es más limpio que esperar que el cortafuegos lo cubra. Es una decisión de política, así que anótela junto con el resto de elecciones de interfaz.

Superponga el cortafuegos al enlace

Un enlace estrecho no sustituye una regla de cortafuegos, y una regla de cortafuegos no estrecha un enlace comodín. Use ambos: enlácese donde la implementación lo admita y luego permita el puerto solo desde las fuentes que deberían alcanzarlo. Los grupos de seguridad de la nube se sitúan delante del cortafuegos del host, así que compruebe ambos cuando la ruta cruce una frontera de VPC. La regla efectiva es la intersección de las dos, y cada capa solo puede restar accesibilidad.

Pruebe desde una fuente permitida y desde una excluida deliberadamente. Una conexión desde localhost no demuestra nada sobre la frontera pública.

Anote lo que eligió

Anote la dirección enlazada, la interfaz que la posee, la regla de cortafuegos y su propósito. Una NIC de repuesto o una dirección de nube reasignada pueden cambiar la exposición sin que nadie edite el perfil. Ponga fecha a la nota, porque las direcciones de nube se mueven entre revisiones más a menudo de lo que la gente espera.

Esa nota es lo que convierte la próxima revisión en una comparación en lugar de un proyecto de arqueología.