Levar uma VPN de trabalho aos EAU: o que confirmar primeiro

Comece uma viagem de trabalho com uma pergunta mais estreita do que se o software VPN é permitido em geral. A pergunta útil é a que sistema privado precisa de chegar, através de que gateway da empresa e quem apoia o dispositivo se o túnel não arrancar. Tudo o resto sobre conectividade é uma segunda conversa, e misturar as duas produz um plano que não responde a nenhuma. Um plano escrito separa-as.

O que o caso de uso documentado cobre na realidade

O regulador das telecomunicações dos EAU, a TDRA, publica Orientações para a internet que tratam do uso organizacional da tecnologia VPN para chegar a redes internas, a par de uma discussão separada sobre filtragem de conteúdos e serviços de comunicações. São temas distintos. Uma empresa que chega à sua própria intranet através do seu próprio gateway é um caso de uso organizacional descrito, não uma declaração geral sobre cada serviço que um viajante possa usar. Também não é um parecer jurídico sobre a sua viagem concreta, e lê-lo como qualquer das duas coisas é onde começam a maioria dos debates sobre este tema.

Leia as orientações publicadas diretamente em vez de um resumo, e trate esta página como uma lista de verificação de planeamento e não como um conselho sobre a sua posição jurídica. Para tudo o que fique fora do caso documentado de acesso interno, as perguntas pertencem a um advogado local qualificado e à política de viagens da sua entidade empregadora.

Associe o trabalho a um gateway concreto

Anote os sistemas de que realmente precisa: a intranet, um repositório de documentos, a aplicação interna que não existe fora da rede da empresa. Depois coloque duas perguntas à TI: que gateway aprovado serve esses sistemas e se o perfil de viagem altera mais alguma coisa no dispositivo. A resposta costuma ser mais específica do que o nome do perfil sugere.

Algumas organizações publicam um gateway de viagem dedicado com um certificado diferente ou um passo de autenticação diferente; outras esperam que use o perfil comum, que pode encaminhar todo o tráfego e não apenas os intervalos corporativos. O nome do perfil raramente diz qual é. Pergunte, ou leia a tabela de encaminhamento depois de estar ligado.

Saber qual tem muda o que deve esperar. Um perfil de túnel completo envia também a sua navegação comum através da empresa, o que pode ser exatamente o que o empregador pretende e é certamente algo a compreender antes da viagem e não durante. Também identifica o caminho de apoio, porque a pessoa que pode reemitir um certificado ou repor uma conta está normalmente disponível em horário laboral numa zona horária. Isso importa mais do que a versão do cliente.

O que o perfil faz ao resto do seu tráfego

Um perfil de túnel dividido transporta apenas os prefixos corporativos; um perfil de túnel completo transporta tudo. Nenhum é intrinsecamente melhor, mas só um corresponde ao caso restrito de acesso interno, e a diferença é uma decisão de configuração que a sua organização já tomou. Pode ler o resultado no dispositivo em vez de o adivinhar pelo nome do perfil:

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

O segundo comando mostra que interface transportaria o tráfego para um endereço corporativo. Se os seus destinos habituais também forem resolvidos através do túnel, o perfil é de túnel completo, e qualquer expectativa de que a navegação comum fique de fora está errada. É melhor descobri-lo antes da viagem do que durante uma chamada.

O DNS segue a mesma lógica. O resolver imposto pelo túnel decide para onde vão os nomes, e uma configuração dividida pode enviar os nomes internos para a empresa e tudo o resto para o resolver local, ou o contrário conforme a forma como foi construída. Verifique que resolver o dispositivo usa realmente depois de ligar, não qual o perfil prometeu. Uma consulta de um nome interno a partir de uma rede de hotel é a forma mais rápida de ver a diferença.

Prepare o caminho de falha antes de voar

Parta do princípio de que o túnel não vai ligar à primeira tentativa a partir de uma rede de hotel, e decida antecipadamente o que fará. Isso significa a alternativa aprovada que a sua equipa de TI apoia, o contacto que pode ajudar em diferentes fusos horários e o número local do dispositivo se a autenticação depender de um telefone. Escrever esses três é a diferença entre um plano e uma intenção.

Teste os passos de autenticação e recuperação suportados antes da viagem, incluindo qualquer segundo fator que exija um dispositivo registado. Um fator que precisa de um número de roaming que não ativou é uma falha que pode prever hoje e não pode corrigir no aeroporto. Teste também a alternativa, não apenas o caminho principal, e faça-o a partir de uma rede que não seja a LAN do seu escritório. Uma alternativa que ninguém testou é uma esperança, não um plano.

Mantenha a alternativa dentro das opções aprovadas pela organização. Uma saída pública improvisada não é um caminho de apoio, e não é uma decisão a tomar sozinho num quarto de hotel. Se a alternativa aprovada também falhar, o passo seguinte correto é o contacto de apoio, não uma saída diferente.

Guarde o registo e volte a verificá-lo

Guarde o plano onde o for encontrar: o nome do gateway, o contacto suportado, os sistemas de que precisava e a data em que verificou as orientações do regulador. As orientações e a política organizacional mudam, e uma nota com data vale mais do que uma memória. Também torna o planeamento da viagem seguinte mais barato.

Depois reveja o plano nas partes que não têm nada a ver com tecnologia — o que fará se um serviço que esperava não estiver disponível, e quem decide se a viagem avança. Essas respostas estão normalmente com uma pessoa, não numa definição do cliente.