Ta med ein jobb-VPN til Dei sameinte arabiske emirata: kva du først bør stadfeste

Start ei jobbreise med eit snevrare spørsmål enn om VPN-programvare er tillaten generelt. Det nyttige spørsmålet er kva privat system du må nå, gjennom kva bedriftsgateway, og kven som støttar eininga om tunnelen ikkje kjem opp. Alt anna om tilknyting er ein andre samtale, og å blande dei to gir ein plan som ikkje svarar på nokon av dei. Ein skriftleg plan skil dei.

Kva det dokumenterte brukstilfellet faktisk dekkjer

Telekomregulatoren i Dei sameinte arabiske emirata, TDRA, publiserer Retningslinjer for internett som handlar om organisatorisk bruk av VPN-teknologi for å nå interne nettverk, saman med ei eiga drøfting av innhaldsfiltrering og kommunikasjonstenester. Det er ulike tema. Eit selskap som når sitt eige intranett gjennom sin eigen gateway, er eit skildra organisatorisk brukstilfelle, ikkje ei generell fråsegn om kvar teneste ein reisande måtte bruke. Det er heller ikkje ei juridisk fråsegn om den konkrete reisa di, og å lese det som ein av dei to er der dei fleste debattane om dette temaet byrjar.

Les dei publiserte retningslinjene direkte i staden for eit samandrag, og handsam denne sida som ei sjekkliste for planlegging, ikkje som råd om den juridiske stillinga di. For alt utanfor det dokumenterte tilfellet med intern tilgang høyrer spørsmåla til ein kvalifisert lokal advokat og til reisepolicyen til arbeidsgivaren din.

Knyt arbeidet til ein bestemd gateway

Skriv ned systema du faktisk treng: intranettet, eit dokumentlager, den interne applikasjonen som ikkje finst utanfor bedriftsnettet. Still så IT to spørsmål: kva godkjend gateway som betener desse systema, og om reiseprofilen endrar noko anna på eininga. Svaret er vanlegvis meir spesifikt enn profilnamnet antydar.

Nokre organisasjonar publiserer ein eigen reisegateway med eit anna sertifikat eller eit anna autentiseringstrinn; andre ventar at du brukar den vanlege profilen, som kan rute all trafikk og ikkje berre bedriftsområda. Profilnamnet fortel sjeldan kva. Spør, eller les rutetabellen når du er tilkopla.

Å vite kva du har endrar det du bør vente. Ein fulltunnelprofil sender også den vanlege nettlesinga di gjennom selskapet, noko som kanskje er nettopp det arbeidsgivaren ønskjer, og i alle fall noko som bør forståast før reisa og ikkje under henne. Han identifiserer også støttevegen, fordi personen som kan utstede eit sertifikat på nytt eller tilbakestille ein konto, vanlegvis er tilgjengeleg i arbeidstida i éi tidssone. Det betyr meir enn klientversjonen.

Kva profilen gjer med resten av trafikken din

Ein splittunnelprofil ber berre bedriftsperfiksa; ein fulltunnelprofil ber alt. Ingen av dei er iboande betre, men berre éin passar til det snevre tilfellet med intern tilgang, og skillnaden er ei konfigurasjonsavgjerd organisasjonen din allereie har teke. Du kan lese resultatet på eininga i staden for å gjette frå profilnamnet:

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

Den andre kommandoen viser kva grensesnitt som ville bere trafikk til ei bedriftsadresse. Om også dei vanlege destinasjonane dine blir løyste gjennom tunnelen, er profilen fulltunnel, og all forventning om at vanleg nettlesing blir utanfor, er feil. Betre å oppdage det før reisa enn under ein samtale.

DNS følgjer same logikk. Ein resolver som tunnelen skyv, avgjer kvar namn går, og ein delt konfigurasjon kan sende interne namn til selskapet og alt anna til den lokale resolveren, eller omvendt avhengig av korleis han er bygd. Sjekk kva resolver eininga faktisk brukar etter tilkopling, ikkje kva profilen lovde. Eit oppslag på eit internt namn frå eit hotellnettverk er den snøggaste måten å sjå skillnaden.

Førebu feilvegen før du flyr

Gå ut frå at tunnelen ikkje koplar til på første forsøk frå eit hotellnettverk, og avgjer på førehand kva du vil gjere. Det tyder den godkjende fallbacken IT-teamet ditt støttar, kontakten som kan hjelpe på tvers av tidssoner, og det lokale nummeret til eininga om autentisering er avhengig av ein telefon. Å skrive ned desse tre er skillnaden mellom ein plan og ei intensjon.

Test dei støtta autentiserings- og gjenopprettingstrinna før reisa, inkludert ein kvar annan faktor som krev ei registrert eining. Ein faktor som treng eit roamingnummer du ikkje har aktivert, er ein feil du kan føreseie i dag og ikkje kan rette på flyplassen. Test også fallbacken, ikkje berre den primære vegen, og gjer det frå eit nettverk som ikkje er kontor-LAN-et ditt. Ein fallback ingen har prøvd, er eit håp snarare enn ein plan.

Hald fallbacken innanfor dei godkjende alternativa til organisasjonen. Ein improvisert offentleg utgang er ikkje ein støtteveg, og det er ikkje ei avgjerd ein tek åleine på eit hotellrom. Om den godkjende fallbacken også sviktar, er det rette neste steget støttekontakten, ikkje ein annan utgang.

Ta vare på oppteikninga og sjekk henne på nytt

Lagre planen der du vil finne han: gateway-namnet, den støtta kontakten, systema du trengde, og datoen du sjekka retningslinjene til regulatoren. Retningslinjer og organisasjonspolicy endrar seg, og eit notat med dato er verd meir enn ei minning. Det gjer også den neste reisa billegare å planleggje.

Gå deretter gjennom planen for delane som ikkje handlar om teknologi i det heile — kva du gjer om ei teneste du venta er utilgjengeleg, og kven som avgjer om reisa held fram. Dei svara ligg vanlegvis hos ein person, ikkje i ei klientinnstilling.