Centralice el acceso VPN de los socios sin unir a los socios

La propuesta es razonable: cinco túneles de socios repartidos en una docena de portátiles, cinco conjuntos de versiones de cliente, cinco guiones de asistencia y un ingeniero que sabe cómo encajan. Llevarlos a un nivel de acceso controlado resuelve la dispersión de puntos finales. También crea un objeto nuevo en su arquitectura, un servicio de acceso compartido que ahora necesita su propio modelo de autorización, y el fallo que todos subestiman es un aparato central con todos los túneles habilitados que se convierte en silencio en una red de tránsito entre organizaciones que nunca aceptaron ser vecinas. Ese riesgo es una decisión de diseño, no algo que el hardware haga por sí solo. El trabajo de abajo es cómo mantengo la comodidad sin aceptar el efecto secundario accidental.

Empiece por el contrato que cada socio ya firmó

Antes de cualquier configuración, confirme que el socio permite siquiera una puerta de enlace compartida o una conexión de sitio. Una cuenta personal de acceso remoto, un requisito de postura del dispositivo o un flujo interactivo de MFA pueden no ser transferibles a un túnel compartido sin supervisión, y agrupar empleados tras una identidad de cliente copiada es el tipo de atajo que sobrevive hasta que el socio audita sus registros. Para cada conexión permitida, anote los rangos de destino, los dominios DNS privados, las fuentes internas autorizadas, el responsable de la autenticación y qué debe ocurrir cuando falle el túnel. Pida al socio que confirme por escrito la conexión compartida, incluidos los rangos de origen que aceptará. La aprobación verbal suele cambiar de significado la semana en que rota su equipo de seguridad.

Ese registro es el entregable. Si no puede escribirlo para un socio, ese socio no está listo para centralizarse.

Enrute por contexto, no solo por destino

Dos socios acabarán usando el mismo rango privado, porque cada organización elige del mismo espacio RFC 1918. Una única tabla de enrutamiento corriente no puede elegir al socio correcto solo con una dirección de destino, así que los rangos solapados necesitan contextos de enrutamiento separados u otro diseño acordado. El modelo de dominio de reenvío de RFC 4364 explica por qué importa esa separación, y un despliegue no necesita ejecutar MPLS para exigir la misma propiedad a su plataforma de puerta de enlace.

Pregunte a la plataforma algo directo: ¿pueden dos socios compartir un prefijo de destino y aun así distinguirse por el contexto de empleado del que vino la sesión? Si la respuesta es no, esa restricción da forma al diseño más que cualquier lista de funciones de un proveedor.

Donde la respuesta es sí, el contexto de enrutamiento pasa a ser lo que documenta y prueba, porque es invisible en un traceroute.

Decida qué escribe el empleado y qué registra el socio

Parte del trabajo de socios encaja en un proxy de aplicaciones o en un espacio de trabajo remoto abierto dentro del contexto de ese socio. Otro trabajo necesita acceso de red enrutado desde un segmento de empleados aprobado, y ambos producen direcciones de origen distintas y rastros de auditoría distintos en el extremo remoto. Una dirección de origen traducida compartida puede satisfacer una lista de permitidos mientras oculta qué dispositivo hizo qué, así que conserve un registro fiable de empleado a sesión y mantenga la autenticación de la aplicación en su sitio en lugar de tratar la dirección de la puerta de enlace como una identidad, lo cual es cómodo justo hasta el momento en que el socio pregunta quién lo hizo.

Después recorra una tarea real desde el lado del empleado: qué pulsan, qué se les pide y qué vería el socio si pidiera una entrada de registro. Si ese recorrido no es reproducible, el diseño no está terminado.

Deniegue explícitamente el tránsito entre socios

El hardware compartido nunca debería implicar confianza compartida. Añada la denegación como una regla deliberada con un responsable con nombre, no como un accidente de configuración ausente, y pruébela en ambas direcciones con una petición que de otro modo tendría éxito. La prueba importa porque un permiso que solo falta puede restaurarlo el siguiente ingeniero que añada una ruta para arreglar una queja no relacionada.

Escriba la denegación en el registro del socio junto a los permisos, para que la intención sobreviva a los cambios de personal.

Opérelo como un servicio compartido, no como un portátil más grande

La renovación de túneles, la rotación de credenciales, la capacidad y la sustitución de la puerta de enlace pasan ahora a ser cambios de servicio compartido, lo que significa que necesitan un calendario y una vía de comunicación que los portátiles individuales nunca exigieron. Un certificado de socio que caduca un sábado ya no es la caída de un usuario; son todas las sesiones de ese socio a la vez.

Acepte el nivel solo cuando una petición denegada entre socios falle exactamente como se pretendía y una petición permitida de un empleado llegue al destino correcto con el origen correcto. Quitar el conflicto de portátiles manteniendo intacta la frontera de cada socio es todo el objetivo; un diseño en el que cada prefijo remoto es alcanzable desde cada escritorio solo ha movido el problema.

Mantenga una tabla pequeña de socio, contexto, rangos permitidos y responsable. Será lo primero que alguien pida durante un incidente.