At tage en arbejds-VPN med til De Forenede Arabiske Emirater: hvad du først skal bekræfte

Begynd en arbejdsrejse med et snævrere spørgsmål end om VPN-software overhovedet er tilladt. Det nyttige spørgsmål er, hvilket privat system du skal nå, gennem hvilken virksomhedsgateway, og hvem der supporterer enheden, hvis tunnelen ikke kommer op. Alt andet om forbindelse er en anden samtale, og at blande de to giver en plan, der ikke besvarer nogen af dem. En skriftlig plan adskiller dem.

Hvad det dokumenterede brugstilfælde egentlig dækker

De Forenede Arabiske Emiraters telekommunikationsmyndighed, TDRA, offentliggør Retningslinjer for internettet der handler om organisatorisk brug af VPN-teknologi til at nå interne netværk, sammen med en separat drøftelse af indholdsfiltrering og kommunikationstjenester. Det er forskellige emner. En virksomhed, der når sit eget intranet gennem sin egen gateway, er et beskrevet organisatorisk brugstilfælde, ikke en generel erklæring om hver tjeneste, en rejsende måtte bruge. Det er heller ikke en juridisk udtalelse om din konkrete rejse, og at læse det som en af de to er, hvor de fleste diskussioner om emnet begynder.

Læs de offentliggjorte retningslinjer direkte i stedet for et resumé, og betragt denne side som en tjekliste til planlægning, ikke som rådgivning om din juridiske stilling. For alt uden for det dokumenterede tilfælde med intern adgang hører spørgsmålene til en kvalificeret lokal advokat og til din arbejdsgivers rejsepolitik.

Knyt arbejdet til en bestemt gateway

Skriv de systemer ned, du faktisk har brug for: intranettet, et dokumentlager, den interne applikation, der ikke findes uden for virksomhedens netværk. Stil derefter IT to spørgsmål: hvilken godkendt gateway der betjener de systemer, og om rejseprofilen ændrer noget andet på enheden. Svaret er som regel mere specifikt, end profilnavnet antyder.

Nogle organisationer offentliggør en særlig rejsegateway med et andet certifikat eller et andet godkendelsestrin; andre forventer, at du bruger den almindelige profil, som kan rute al trafik og ikke kun virksomhedens områder. Profilnavnet fortæller sjældent hvilken. Spørg, eller læs routingtabellen, når du er forbundet.

At vide, hvilken du har, ændrer det, du bør forvente. En profil med fuld tunnel sender også din almindelige browsing gennem virksomheden, hvilket måske er præcis det, arbejdsgiveren ønsker, og i hvert fald noget, der skal forstås før rejsen og ikke under den. Den identificerer også supportvejen, fordi den person, der kan genudstede et certifikat eller nulstille en konto, normalt er tilgængelig i arbejdstiden i én tidszone. Det betyder mere end klientversionen.

Hvad profilen gør ved resten af din trafik

En profil med opdelt tunnel bærer kun virksomhedens præfikser; en profil med fuld tunnel bærer alt. Ingen af dem er iboende bedre, men kun én passer til det snævre tilfælde med intern adgang, og forskellen er en konfigurationsbeslutning, som din organisation allerede har truffet. Du kan læse resultatet på enheden i stedet for at gætte ud fra profilnavnet:

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

Den anden kommando viser, hvilken grænseflade der ville bære trafik til en virksomhedsadresse. Hvis dine almindelige destinationer også opløses gennem tunnelen, er profilen fuld tunnel, og enhver forventning om, at almindelig browsing bliver udenfor, er forkert. Bedre at opdage det før rejsen end under et opkald.

DNS følger samme logik. En resolver, som tunnelen skubber, bestemmer, hvor navne går hen, og en opdelt konfiguration kan sende interne navne til virksomheden og alt andet til den lokale resolver, eller det omvendte afhængigt af, hvordan den er bygget. Tjek, hvilken resolver enheden faktisk bruger efter forbindelsen, ikke hvilken profilen lovede. Et opslag på et internt navn fra et hotelnettværk er den hurtigste måde at se forskellen.

Forbered fejlvejen, før du flyver

Antag, at tunnelen ikke forbinder i første forsøg fra et hotelnettværk, og beslut på forhånd, hvad du vil gøre. Det betyder den godkendte fallback, som dit IT-team supporterer, kontakten der kan hjælpe på tværs af tidszoner, og det lokale nummer til enheden, hvis godkendelse afhænger af en telefon. At skrive de tre ned er forskellen mellem en plan og en hensigt.

Test de understøttede godkendelses- og gendannelsestrin før rejsen, inklusive enhver anden faktor, der kræver en registreret enhed. En faktor, der kræver et roamingnummer, du ikke har aktiveret, er en fejl, du kan forudse i dag og ikke kan rette i lufthavnen. Test også fallbacken, ikke kun den primære vej, og gør det fra et netværk, der ikke er dit kontor-LAN. En fallback, ingen har prøvet, er et håb snarere end en plan.

Hold fallbacken inden for organisationens godkendte muligheder. En improviseret offentlig udgang er ikke en supportvej, og det er ikke en beslutning, man tager alene på et hotelværelse. Hvis den godkendte fallback også fejler, er det korrekte næste skridt supportkontakten, ikke en anden udgang.

Gem optegnelsen, og tjek den igen

Gem planen, hvor du kan finde den: gatewaynavnet, den understøttede kontakt, de systemer du havde brug for, og datoen for, hvornår du tjekkede myndighedens retningslinjer. Retningslinjer og organisationspolitik ændrer sig, og en note med en dato er mere værd end en erindring. Det gør også den næste rejse billigere at planlægge.

Gennemgå derefter planen for de dele, der slet ikke handler om teknologi — hvad du gør, hvis en tjeneste, du forventede, ikke er tilgængelig, og hvem der afgør, om rejsen fortsætter. De svar ligger som regel hos en person, ikke i en klientindstilling.