Ta med ett jobb-VPN till Förenade arabemiraten: vad du först bör bekräfta

Börja en tjänsteresa med en snävare fråga än om VPN-programvara är tillåten i allmänhet. Den användbara frågan är vilket privat system du måste nå, via vilken företagsgateway, och vem som stöder enheten om tunneln inte kommer upp. Allt annat om anslutning är ett andra samtal, och att blanda de två ger en plan som inte svarar på något av dem. En skriftlig plan skiljer dem.

Vad det dokumenterade användningsfallet faktiskt täcker

Förenade arabemiratens telekomregulator, TDRA, publicerar Riktlinjer för internet som behandlar organisatorisk användning av VPN-teknik för att nå interna nät, vid sidan av en separat diskussion om innehållsfiltrering och kommunikationstjänster. Det är olika ämnen. Ett företag som når sitt eget intranät via sin egen gateway är ett beskrivet organisatoriskt användningsfall, inte ett generellt uttalande om varje tjänst en resenär kan använda. Det är heller inte ett juridiskt yttrande om din specifika resa, och att läsa det som något av de två är där de flesta diskussioner om ämnet börjar.

Läs de publicerade riktlinjerna direkt i stället för en sammanfattning, och behandla den här sidan som en checklista för planering, inte som råd om din juridiska ställning. För allt utanför det dokumenterade fallet med intern åtkomst hör frågorna till en kvalificerad lokal advokat och till din arbetsgivares resepolicy.

Knyt arbetet till en specifik gateway

Skriv ned de system du faktiskt behöver: intranätet, ett dokumentlager, det interna programmet som inte finns utanför företagets nät. Ställ sedan två frågor till IT: vilken godkänd gateway som betjänar dessa system, och om reseprofilen ändrar något annat på enheten. Svaret är oftast mer specifikt än profilnamnet antyder.

Vissa organisationer publicerar en egen resegateway med ett annat certifikat eller ett annat autentiseringssteg; andra förväntar sig att du använder den vanliga profilen, som kan dirigera all trafik och inte bara företagets intervall. Profilnamnet säger sällan vilken. Fråga, eller läs routingtabellen när du är ansluten.

Att veta vilken du har ändrar vad du bör förvänta dig. En fulltunnelprofil skickar också din vanliga surfning genom företaget, vilket kanske är precis vad arbetsgivaren vill och i alla fall något att förstå före resan och inte under den. Den identifierar också supportvägen, eftersom den som kan återutfärda ett certifikat eller återställa ett konto vanligtvis är tillgänglig under kontorstid i en tidszon. Det betyder mer än klientversionen.

Vad profilen gör med resten av din trafik

En delad tunnelprofil bär bara företagets prefix; en fulltunnelprofil bär allt. Ingen av dem är inneboende bättre, men bara en passar det snäva fallet med intern åtkomst, och skillnaden är ett konfigurationsbeslut som din organisation redan har fattat. Du kan läsa resultatet på enheten i stället för att gissa från profilnamnet:

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

Det andra kommandot visar vilket gränssnitt som skulle bära trafik till en företagsadress. Om även dina vanliga destinationer löses genom tunneln är profilen fulltunnel, och varje förväntan att vanlig surfning stannar utanför är fel. Bättre att upptäcka det före resan än under ett samtal.

DNS följer samma logik. En resolver som tunneln trycker ut avgör vart namn tar vägen, och en delad konfiguration kan skicka interna namn till företaget och allt annat till den lokala resolvern, eller tvärtom beroende på hur den är byggd. Kontrollera vilken resolver enheten faktiskt använder efter anslutning, inte vilken profilen lovade. En sökning på ett internt namn från ett hotellnät är det snabbaste sättet att se skillnaden.

Förbered felvägen innan du flyger

Utgå från att tunneln inte ansluter vid första försöket från ett hotellnät, och bestäm i förväg vad du gör. Det betyder den godkända reservlösning som ditt IT-team stöder, kontakten som kan hjälpa över tidszoner, och det lokala numret till enheten om autentiseringen beror på en telefon. Att skriva ned dessa tre är skillnaden mellan en plan och en avsikt.

Testa de stödda autentiserings- och återställningsstegen före resan, inklusive varje andra faktor som kräver en registrerad enhet. En faktor som kräver ett roamingnummer du inte har aktiverat är ett fel du kan förutse i dag och inte kan åtgärda på flygplatsen. Testa också reservlösningen, inte bara den primära vägen, och gör det från ett nät som inte är ditt kontors-LAN. En reservlösning som ingen har provat är ett hopp snarare än en plan.

Håll reservlösningen inom organisationens godkända alternativ. En improviserad offentlig utgång är inte en supportväg, och det är inte ett beslut man fattar ensam på ett hotellrum. Om den godkända reservlösningen också misslyckas är nästa korrekta steg supportkontakten, inte en annan utgång.

Spara posten och kontrollera den igen

Spara planen där du hittar den: gateway-namnet, den stödda kontakten, de system du behövde och datumet då du kontrollerade regulatorns riktlinjer. Riktlinjer och organisationspolicy ändras, och en anteckning med datum är värd mer än ett minne. Det gör också nästa resa billigare att planera.

Granska sedan planen för de delar som inte alls handlar om teknik — vad du gör om en tjänst du förväntade dig inte är tillgänglig, och vem som avgör om resan fortsätter. De svaren finns vanligtvis hos en person, inte i en klientinställning.