El portal VPN funciona a la perfección entre un cliente y un servidor, permitiendo que un cliente recupere recursos remotos mediante HTTP o HTTPS sin estar conectado directamente al servidor. Para ello, procesa solicitudes del cliente, a continuación busca el recurso en el servidor y, por último, lo entrega al cliente. En otras palabras, el portal VPN actúa como un tipo de proxy, más concretamente, como un proxy inverso, es decir, un proxy en el que, a diferencia de un proxy normal (de reenvío), el servidor se encuentra en una zona que recibe servicio del dispositivo Panda GateDefender, por regla general, la zona DMZ, mientras que el cliente se conecta desde una ubicación remota. Por tanto, la conexión se inicia desde el segmento de red no fiable ROJA y, sin el portal VPN, no estaría permitida.
Aunque el principio de funcionamiento se parece mucho a métodos como el reenvío de puertos, el portal VPN del dispositivo Panda GateDefender ofrece numerosas ventajas, puesto que es un servidor web con todas las funciones, que permite autenticar el cliente y restringir las IP de origen posibles para la conexión, con lo que se obtiene una comunicación más segura. Además, la capacidad de definir diversas rutas desde la conexión remota hasta distintos recursos del servidor aporta más flexibilidad a la configuración posible.
Con esta descripción, un ejemplo de uso evidente es el de permitir a un empleado o un colaborador de la empresa que acceda en remoto a un recurso que se encuentra en la intranet de la empresa sin tener que configurar ni habilitar el servidor OpenVPN. Vale la pena destacar que en un mismo dispositivo Panda GateDefender pueden coexistir un servidor VPN y un portal VPN.
Para implementar este ejemplo de uso, defina una nueva ruta y el destino. A continuación, solicite autenticación al usuario, que se puede llevar a cabo en local en el dispositivo Panda GateDefender o conectándose a una instalación LDAP/AD de la intranet.
En esta pestaña se pueden configurar las principales opciones del portal relacionadas con el nombre de dominio y el enlace activo utilizados.
En el panel Avanzado se pueden configurar algunas opciones más.
Una vez finalizada la configuración del portal principal, se pueden configurar los distintos recursos a los que se puede acceder en cada zona. En la parte inferior de la tabla se muestra una tabla con todas las rutas que ya están definidas y llevan a los recursos locales. En cada ruta se pueden llevar a cabo las acciones siguientes:
Se pueden definir nuevas rutas haciendo clic en el enlace Añadir nueva ruta situado encima de la tabla.
La ruta que lleva al recurso solicitado por el cliente.
Nota
También se incluyen todas las subrutas relacionadas con la ruta principal.
Prácticas recomendadas para autenticación anidada.
Aunque la autenticación puede estar presente tanto en el portal VPN como en la ruta a la que se llega a través del portal, se recomienda aplicar la autenticación a uno de los dos lados solamente. De hecho, la autenticación anidada presenta un pequeño problema. Considere un caso en que el portal requiere como nombre de usuario-contraseña el par juan/unacontraseña mientras que la ruta requiere mario/otracontraseña. En la primera conexión, en la ventana emergente que requiere autenticación se debe introducir el par juan/unacontraseña para obtener acceso a la ruta detrás del portal. A continuación, el par mario/otracontraseña da acceso a la ruta. Sin embargo, cuando se requiere otra página de la ruta, el portal recibe las últimas credenciales almacenadas, que son las de la ruta y no coinciden con las requeridas para el portal, por lo que se muestra otra ventana emergente para la autenticación.
Como alternativa, si la autenticación anidada es un requisito obligatorio, se sugiere utilizar el mismo par nombre de usuario-contraseña para la autenticación tanto del portal como de la ruta.