Portare una VPN di lavoro negli EAU: cosa confermare prima

Inizi un viaggio di lavoro con una domanda più stretta di quella se il software VPN sia consentito in generale. La domanda utile è a quale sistema privato deve arrivare, attraverso quale gateway aziendale e chi supporta il dispositivo se il tunnel non si alza. Tutto il resto sulla connettività è una seconda conversazione, e mescolare le due produce un piano che non risponde a nessuna. Un piano scritto le separa.

Cosa copre realmente il caso d’uso documentato

L’autorità di regolamentazione delle telecomunicazioni degli EAU, la TDRA, pubblica Linee guida per internet che trattano l’uso organizzativo della tecnologia VPN per raggiungere reti interne, insieme a una discussione separata sul filtraggio dei contenuti e sui servizi di comunicazione. Sono argomenti distinti. Un’azienda che raggiunge la propria intranet attraverso il proprio gateway è un caso d’uso organizzativo descritto, non un’affermazione generale su ogni servizio che un viaggiatore potrebbe usare. Non è nemmeno un parere legale sul suo viaggio specifico, e leggerlo come una delle due cose è dove iniziano la maggior parte dei dibattiti su questo tema.

Legga le linee guida pubblicate direttamente invece di un riassunto, e tratti questa pagina come una lista di controllo per la pianificazione, non come un consiglio sulla sua posizione legale. Per tutto ciò che sta fuori dal caso documentato di accesso interno, le domande spettano a un legale locale qualificato e alla politica di viaggio del suo datore di lavoro.

Mappi il lavoro su un gateway specifico

Annoti i sistemi di cui ha davvero bisogno: la intranet, un archivio documenti, l’applicazione interna che non esiste fuori dalla rete aziendale. Poi ponga due domande all’IT: quale gateway approvato serve quei sistemi e se il profilo di viaggio altera qualcos’altro nel dispositivo. La risposta è di solito più specifica di quanto suggerisca il nome del profilo.

Alcune organizzazioni pubblicano un gateway di viaggio dedicato con un certificato diverso o un passaggio di autenticazione diverso; altre si aspettano che usi il profilo ordinario, che può instradare tutto il traffico e non solo gli intervalli aziendali. Il nome del profilo raramente dice quale. Chieda, o legga la tabella di routing una volta connesso.

Sapere quale ha cambia ciò che dovrebbe aspettarsi. Un profilo a tunnel completo manda anche la sua navigazione ordinaria attraverso l’azienda, il che può essere esattamente ciò che il datore di lavoro intende e sicuramente qualcosa da capire prima del viaggio e non durante. Identifica anche il percorso di supporto, perché chi può riemettere un certificato o reimpostare un account è di solito raggiungibile in orario di lavoro in un fuso orario. Questo conta più della versione del client.

Cosa fa il profilo al resto del suo traffico

Un profilo a tunnel diviso trasporta solo i prefissi aziendali; un profilo a tunnel completo trasporta tutto. Nessuno è intrinsecamente migliore, ma solo uno corrisponde al caso ristretto di accesso interno, e la differenza è una decisione di configurazione che la sua organizzazione ha già preso. Può leggere il risultato sul dispositivo invece di indovinarlo dal nome del profilo:

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

Il secondo comando mostra quale interfaccia porterebbe il traffico a un indirizzo aziendale. Se anche le sue destinazioni ordinarie si risolvono attraverso il tunnel, il profilo è a tunnel completo, e qualsiasi aspettativa che la navigazione ordinaria resti fuori è sbagliata. Meglio scoprirlo prima del viaggio che durante una chiamata.

Il DNS segue la stessa logica. Il resolver spinto dal tunnel decide dove vanno i nomi, e una configurazione divisa può mandare i nomi interni all’azienda e tutto il resto al resolver locale, o il contrario secondo come è stata costruita. Verifichi quale resolver usa davvero il dispositivo dopo la connessione, non quale il profilo ha promesso. Una ricerca di un nome interno da una rete d’albergo è il modo più rapido per vedere la differenza.

Prepari il percorso di guasto prima di volare

Dia per scontato che il tunnel non si connetta al primo tentativo da una rete d’albergo, e decida in anticipo cosa fare. Significa l’alternativa approvata supportata dal suo team IT, il contatto che può aiutare in fusi orari diversi e il numero locale del dispositivo se l’autenticazione dipende da un telefono. Scrivere questi tre è la differenza tra un piano e un’intenzione.

Provi i passaggi di autenticazione e recupero supportati prima del viaggio, incluso qualsiasi secondo fattore che richieda un dispositivo registrato. Un fattore che richiede un numero in roaming che non ha attivato è un guasto che può prevedere oggi e non può correggere in aeroporto. Provi anche l’alternativa, non solo il percorso principale, e lo faccia da una rete che non è la LAN dell’ufficio. Un’alternativa che nessuno ha provato è una speranza, non un piano.

Mantenga l’alternativa nelle opzioni approvate dall’organizzazione. Un’uscita pubblica improvvisata non è un percorso di supporto, e non è una decisione da prendere da soli in una camera d’albergo. Se anche l’alternativa approvata fallisce, il passo successivo corretto è il contatto di supporto, non un’uscita diversa.

Conservi il registro e lo ricontrolli

Salvi il piano dove lo troverà: il nome del gateway, il contatto supportato, i sistemi che le servivano e la data in cui ha verificato le linee guida dell’autorità. Le linee guida e la politica organizzativa cambiano, e una nota con data vale più di un ricordo. Rende anche più economica la pianificazione del prossimo viaggio.

Poi riveda il piano per le parti che non riguardano affatto la tecnologia: cosa farà se un servizio atteso non è disponibile, e chi decide se il viaggio prosegue. Quelle risposte di solito le ha una persona, non un’impostazione del client.