Llevar una VPN de trabajo a los EAU: qué conviene confirmar primero

Empiece un viaje de trabajo con una pregunta más concreta que si el software VPN está permitido en general. La pregunta útil es a qué sistema privado necesita llegar, a través de qué puerta de enlace de la empresa y quién da soporte al dispositivo si el túnel no arranca. Todo lo demás sobre la conectividad es una segunda conversación, y mezclar ambas produce un plan que no responde a ninguna. Un plan escrito las separa.

Qué cubre en realidad el caso de uso documentado

El regulador de telecomunicaciones de los EAU, la TDRA, publica Directrices de internet que abordan el uso organizativo de la tecnología VPN para llegar a redes internas, junto con un análisis separado del filtrado de contenidos y los servicios de comunicaciones. Son temas distintos. Una empresa que llega a su propia intranet a través de su propia puerta de enlace es un caso de uso organizativo descrito, no una declaración general sobre cada servicio que un viajero pueda utilizar. Tampoco es una opinión jurídica sobre su viaje concreto, y leerlo como cualquiera de las dos cosas es donde empiezan la mayoría de los debates sobre este tema.

Lea las directrices publicadas directamente en lugar de un resumen, y trate esta página como una lista de comprobación de planificación y no como un consejo sobre su situación jurídica. Para todo lo que quede fuera del caso documentado de acceso interno, las preguntas corresponden a un abogado local cualificado y a la política de viajes de su empleador.

Asigne el trabajo a una puerta de enlace concreta

Anote los sistemas que realmente necesita: la intranet, un almacén de documentos, la aplicación interna que no existe fuera de la red de la empresa. Después plantee dos preguntas a TI: qué puerta de enlace aprobada da servicio a esos sistemas y si el perfil de viaje altera algo más del dispositivo. La respuesta suele ser más específica de lo que sugiere el nombre del perfil.

Algunas organizaciones publican una puerta de enlace de viaje dedicada con un certificado distinto o un paso de autenticación distinto; otras esperan que use el perfil ordinario, que puede encaminar todo el tráfico y no solo los rangos corporativos. El nombre del perfil rara vez dice cuál es. Pregunte, o lea la tabla de enrutamiento una vez conectado.

Saber cuál tiene cambia lo que debería esperar. Un perfil de túnel completo envía también su navegación habitual a través de la empresa, lo que puede ser exactamente lo que pretende el empleador y sin duda es algo que conviene entender antes del viaje y no durante. También identifica la vía de soporte, porque la persona que puede reemitir un certificado o restablecer una cuenta suele estar disponible en horario laboral en una zona horaria. Eso importa más que la versión del cliente.

Qué hace el perfil con el resto de su tráfico

Un perfil de túnel dividido solo transporta los prefijos corporativos; un perfil de túnel completo lo transporta todo. Ninguno es intrínsecamente mejor, pero solo uno encaja con el caso concreto de acceso interno, y la diferencia es una decisión de configuración que su organización ya ha tomado. Puede leer el resultado en el dispositivo en lugar de adivinarlo por el nombre del perfil:

ip -4 route
ip -4 route get 10.20.4.10
nmcli connection show --active

El segundo comando muestra qué interfaz llevaría el tráfico a una dirección corporativa. Si sus destinos habituales también se resuelven a través del túnel, el perfil es de túnel completo, y cualquier expectativa de que la navegación habitual quede fuera es errónea. Mejor descubrirlo antes del viaje que durante una llamada.

El DNS sigue la misma lógica. El resolutor que empuja el túnel decide adónde van los nombres, y una configuración dividida puede enviar los nombres internos a la empresa y todo lo demás al resolutor local, o lo contrario según cómo se haya construido. Compruebe qué resolutor usa realmente el dispositivo después de conectarse, no cuál prometió el perfil. Una consulta de un nombre interno desde una red de hotel es la forma más rápida de ver la diferencia.

Prepare la vía de fallo antes de volar

Dé por hecho que el túnel no conectará al primer intento desde una red de hotel, y decida de antemano qué hará. Eso significa la alternativa aprobada que respalda su equipo de TI, el contacto que puede ayudar en distintas zonas horarias y el número local del dispositivo si la autenticación depende de un teléfono. Escribir esos tres es la diferencia entre un plan y una intención.

Pruebe los pasos de autenticación y recuperación admitidos antes de viajar, incluido cualquier segundo factor que requiera un dispositivo registrado. Un factor que necesita un número de itinerancia que no ha activado es un fallo que puede prever hoy y no puede arreglar en el aeropuerto. Pruebe también la alternativa, no solo la vía principal, y hágalo desde una red que no sea la LAN de su oficina. Una alternativa que nadie ha probado es una esperanza, no un plan.

Mantenga la alternativa dentro de las opciones aprobadas por la organización. Una salida pública improvisada no es una vía de soporte, y no es una decisión que se tome solo en una habitación de hotel. Si la alternativa aprobada también falla, el siguiente paso correcto es el contacto de soporte, no una salida distinta.

Conserve el registro y vuelva a comprobarlo

Guarde el plan donde vaya a encontrarlo: el nombre de la puerta de enlace, el contacto admitido, los sistemas que necesitaba y la fecha en que comprobó las directrices del regulador. Las directrices y la política organizativa cambian, y una nota con fecha vale más que un recuerdo. También hace más barato planificar el siguiente viaje.

Después revise el plan en las partes que no tienen nada que ver con la tecnología: qué hará si un servicio que esperaba no está disponible y quién decide si el viaje sigue adelante. Esas respuestas suelen tenerlas una persona, no un ajuste del cliente.