Ta med en jobb-VPN til De forente arabiske emirater: hva du først bør bekrefte

Start en jobbreise med et snevrere spørsmål enn om VPN-programvare er tillatt generelt. Det nyttige spørsmålet er hvilket privat system du må nå, gjennom hvilken bedriftsgateway, og hvem som støtter enheten hvis tunnelen ikke kommer opp. Alt annet om tilkobling er en andre samtale, og å blande de to gir en plan som ikke svarer på noen av dem. En skriftlig plan skiller dem.

Hva det dokumenterte brukstilfellet faktisk dekker

De forente arabiske emiratens telekomregulator, TDRA, publiserer Retningslinjer for internett som handler om organisatorisk bruk av VPN-teknologi for å nå interne nettverk, sammen med en egen drøfting av innholdsfiltrering og kommunikasjonstjenester. Det er forskjellige temaer. Et selskap som når sitt eget intranett gjennom sin egen gateway, er et beskrevet organisatorisk brukstilfelle, ikke en generell uttalelse om hver tjeneste en reisende måtte bruke. Det er heller ikke en juridisk uttalelse om din konkrete reise, og å lese det som en av de to er der de fleste debattene om dette temaet begynner.

Les de publiserte retningslinjene direkte i stedet for et sammendrag, og behandle denne siden som en sjekkliste for planlegging, ikke som råd om din juridiske stilling. For alt utenfor det dokumenterte tilfellet med intern tilgang hører spørsmålene til en kvalifisert lokal advokat og til arbeidsgiverens reisepolicy.

Knytt arbeidet til en bestemt gateway

Skriv ned systemene du faktisk trenger: intranettet, et dokumentlager, den interne applikasjonen som ikke finnes utenfor bedriftsnettet. Still deretter IT to spørsmål: hvilken godkjent gateway som betjener disse systemene, og om reiseprofilen endrer noe annet på enheten. Svaret er vanligvis mer spesifikt enn profilnavnet antyder.

Noen organisasjoner publiserer en egen reisegateway med et annet sertifikat eller et annet autentiseringstrinn; andre forventer at du bruker den vanlige profilen, som kan rute all trafikk og ikke bare bedriftsområdene. Profilnavnet forteller sjelden hvilken. Spør, eller les rutetabellen når du er tilkoblet.

Å vite hvilken du har endrer det du bør forvente. En fulltunnelprofil sender også den vanlige nettlesingen din gjennom selskapet, noe som kanskje er nettopp det arbeidsgiveren ønsker, og i alle fall noe som bør forstås før reisen og ikke under den. Den identifiserer også støtteveien, fordi personen som kan utstede et sertifikat på nytt eller tilbakestille en konto, vanligvis er tilgjengelig i arbeidstiden i én tidssone. Det betyr mer enn klientversjonen.

Hva profilen gjør med resten av trafikken din

En splittunnelprofil bærer bare bedriftsperfiksene; en fulltunnelprofil bærer alt. Ingen av dem er iboende bedre, men bare én passer til det snevre tilfellet med intern tilgang, og forskjellen er en konfigurasjonsbeslutning organisasjonen din allerede har tatt. Du kan lese resultatet på enheten i stedet for å gjette fra profilnavnet:

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

Den andre kommandoen viser hvilket grensesnitt som ville bære trafikk til en bedriftsadresse. Hvis også de vanlige destinasjonene dine løses gjennom tunnelen, er profilen fulltunnel, og enhver forventning om at vanlig nettlesing blir utenfor, er feil. Bedre å oppdage det før reisen enn under en samtale.

DNS følger samme logikk. En resolver som tunnelen skyver, bestemmer hvor navn går, og en delt konfigurasjon kan sende interne navn til selskapet og alt annet til den lokale resolveren, eller omvendt avhengig av hvordan den er bygget. Sjekk hvilken resolver enheten faktisk bruker etter tilkobling, ikke hvilken profilen lovet. Et oppslag på et internt navn fra et hotellnettverk er den raskeste måten å se forskjellen.

Forbered feilveien før du flyr

Anta at tunnelen ikke kobler til på første forsøk fra et hotellnettverk, og bestem på forhånd hva du vil gjøre. Det betyr den godkjente fallbacken IT-teamet ditt støtter, kontakten som kan hjelpe på tvers av tidssoner, og det lokale nummeret til enheten hvis autentisering avhenger av en telefon. Å skrive ned disse tre er forskjellen mellom en plan og en intensjon.

Test de støttede autentiserings- og gjenopprettingstrinnene før reisen, inkludert enhver annen faktor som krever en registrert enhet. En faktor som trenger et roamingnummer du ikke har aktivert, er en feil du kan forutse i dag og ikke kan rette på flyplassen. Test også fallbacken, ikke bare den primære veien, og gjør det fra et nettverk som ikke er kontor-LAN-et ditt. En fallback ingen har prøvd, er et håp snarere enn en plan.

Hold fallbacken innenfor organisasjonens godkjente alternativer. En improvisert offentlig utgang er ikke en støttevei, og det er ikke en beslutning man tar alene på et hotellrom. Hvis den godkjente fallbacken også feiler, er det riktige neste skrittet støttekontakten, ikke en annen utgang.

Ta vare på opptegnelsen og sjekk den på nytt

Lagre planen der du vil finne den: gatewaynavnet, den støttede kontakten, systemene du trengte, og datoen du sjekket regulatoriske retningslinjer. Retningslinjer og organisasjonspolicy endres, og et notat med dato er verdt mer enn en erindring. Det gjør også den neste reisen billigere å planlegge.

Gå deretter gjennom planen for delene som ikke handler om teknologi i det hele tatt — hva du gjør hvis en tjeneste du forventet er utilgjengelig, og hvem som avgjør om reisen fortsetter. De svarene ligger vanligvis hos en person, ikke i en klientinnstilling.