Por qué falla copiar la configuración del servidor OpenVPN a una sucursal

Copiar la configuración del servidor que funciona, cambiar un par de direcciones y llamarlo perfil de sucursal suele producir una conexión. Ese es el peor resultado, porque la sucursal pasa a funcionar con el papel equivocado, expone material que no debería salir del concentrador y deja una asociación de ruta que nadie recuerda haber creado. La conexión esconde tres problemas a la vez, y el túnel se levanta antes de que alguien los compruebe.

Tratar la sucursal como un par con identidad y papel de red propios es lo que hace correcto el perfil. La solución no es una copia mejor, y el resto de esta página trata de lo que un cliente debería tener de verdad.

Dos papeles que parecen un solo archivo

En modo TLS los dos pares tienen tareas complementarias. Un lado escucha, guarda el certificado y la clave del servidor y decide qué clientes pueden conectarse. El otro lado inicia, verifica al oyente y presenta su propia identidad.

Un archivo de servidor contiene directivas que no tienen sentido en un cliente: una dirección de escucha y un puerto, un conjunto de direcciones que repartir y a menudo una lista de empuje para ajustes que los clientes deberían recibir. Copiar eso a una sucursal produce un dispositivo que intenta ser a la vez oyente y cliente.

La clave privada es la parte que más importa. Un cliente nunca debe llevar la clave privada del servidor, y tampoco necesita la clave de firma de la CA. Un certificado de CA es material público de confianza; la clave de firma pertenece a donde se emiten los certificados.

Qué debe contener un perfil de sucursal

Un perfil de sucursal necesita el extremo remoto y el transporte, la identidad de servidor de confianza, el certificado y la clave propios de la sucursal, y las rutas y ajustes de DNS que la sucursal requiere de verdad. Nada más es obligatorio.

Mantenga la identidad de la sucursal separada por sitio. Dos sucursales que comparten un certificado significan que revocar una desactiva la otra, y los registros del concentrador no pueden distinguirlas. Una identidad por sitio es lo que hace funcionar tanto el rastro de auditoría como la historia de revocación.

Tenga cuidado con los flujos de los equipos. El paquete Client Export de pfSense genera perfiles para contextos de Remote Access admisibles, y su lista de servidores solo incluye servidores configurados en un modo Remote Access. Un servidor sitio a sitio de otro modo no aparece, y esa ausencia es información, no una invitación a copiar los secretos del servidor.

Si el equipo no exporta el perfil que necesita, use su flujo de cliente sitio a sitio documentado o construya el perfil a partir del ejemplo admitido de la versión instalada. Exporte una copia de seguridad del servidor a la sucursal solo si el plan es restaurar un servidor, que no lo es. Una copia también lleva material privado del concentrador, así que mover una a una sucursal es una decisión de manejo de claves, no una transferencia de archivo. Déjela en el concentrador y genere la identidad del cliente donde se emiten los certificados.

La asociación entre par y red es aparte

Un cliente de sucursal que se conecta con éxito aún no puede pasar tráfico para su LAN hasta que el concentrador sepa que este par posee ese prefijo. Esa asociación vive en el concentrador, ligada a la identidad del cliente, y es aparte de la ruta propia de la sucursal hacia las redes remotas. Sin ella, los equipos de la sucursal parecen accesibles en las estadísticas del túnel e inaccesibles en la práctica. El registro del concentrador es el lugar donde confirmar si la asociación se aplicó.

Añadir una ruta en el sistema operativo del concentrador no es lo mismo que decirle a OpenVPN qué cliente posee el prefijo. Sin la asociación por cliente, el paquete llega a la interfaz del túnel y se descarta porque ningún par reclama el destino.

En el lado de la sucursal, la necesidad correspondiente es una ruta hacia las redes que debe alcanzar, más un enrutador de LAN que sepa devolver el tráfico a la sucursal. La propiedad en el lado del servidor y las rutas de destino en el lado del cliente son objetos distintos, y un túnel que funciona solo demuestra el primer salto. Anote ambos en las notas de traspaso de la sucursal, porque el siguiente ingeniero solo encontrará uno de los dos.

Demostrar que la sucursal es el par que usted cree

Verifique la identidad antes de verificar el tráfico. El registro del concentrador debería mostrar el nombre común del certificado de la sucursal, y la dirección que recibió el cliente debería coincidir con el conjunto o la asignación fija que usted pretendía. Si el registro muestra otro nombre, el perfil lleva la identidad de otra persona.

Después verifique la asociación enviando una petición desde un equipo de la sucursal a un recurso del lado del concentrador y confirme que tiene éxito con la dirección de origen esperada. Pruebe un destino al que la sucursal no debe llegar y confirme que falla, porque una ruta permisiva que funciona por casualidad no es lo mismo que una política correcta.

Por último, revoque la identidad de la sucursal y confirme que la conexión falla mientras el certificado propio del concentrador y los demás sitios siguen funcionando. Si la revocación rompe el concentrador, se compartieron papeles e identidades en algún lugar, y ese es el hallazgo que vale la pena devolver al diseño.

Una sucursal terminada es la que tiene una identidad documentada, un perfil solo de cliente, una asociación entre par y red en el concentrador y un camino de vuelta probado. Dar la vuelta al texto de un archivo de servidor no le da ninguno de esos.