Een werk-VPN meenemen naar de VAE: wat u eerst moet bevestigen

Begin een zakenreis met een nauwere vraag dan of VPN-software in het algemeen is toegestaan. De nuttige vraag is welk privésysteem u moet bereiken, via welke bedrijfsgateway, en wie het apparaat ondersteunt als de tunnel niet opkomt. Al het overige over connectiviteit is een tweede gesprek, en beide door elkaar halen levert een plan op dat geen van beide beantwoordt. Een schriftelijk plan scheidt ze.

Wat de gedocumenteerde use case feitelijk dekt

De telecommunicatieregulator van de VAE, TDRA, publiceert Internetrichtlijnen die het organisatorische gebruik van VPN-technologie voor toegang tot interne netwerken behandelen, naast een aparte bespreking van contentfiltering en communicatiediensten. Dat zijn verschillende onderwerpen. Een bedrijf dat zijn eigen intranet via zijn eigen gateway bereikt, is een beschreven organisatorische use case, geen algemene uitspraak over elke dienst die een reiziger zou kunnen gebruiken. Het is ook geen juridisch advies over uw specifieke reis, en het als een van beide lezen is waar de meeste discussies over dit onderwerp beginnen.

Lees de gepubliceerde richtlijnen rechtstreeks in plaats van een samenvatting, en behandel deze pagina als een planningschecklist, niet als advies over uw juridische positie. Voor alles buiten de gedocumenteerde interne toegang hoort de vraag bij een gekwalificeerde plaatselijke advocaat en bij het reisbeleid van uw werkgever.

Koppel het werk aan een specifieke gateway

Schrijf de systemen op die u echt nodig hebt: het intranet, een documentopslag, de interne applicatie die buiten het bedrijfsnetwerk niet bestaat. Stel IT daarna twee vragen: welke goedgekeurde gateway die systemen bedient, en of het reisprofiel nog iets anders aan het apparaat verandert. Het antwoord is meestal specifieker dan de profielnaam suggereert.

Sommige organisaties publiceren een aparte reisgateway met een ander certificaat of een andere authenticatiestap; andere verwachten dat u het gewone profiel gebruikt, dat al het verkeer kan routeren en niet alleen bedrijfsbereiken. De profielnaam zegt zelden welke. Vraag ernaar, of lees de routingtabel zodra u verbonden bent.

Weten welke u hebt, verandert wat u moet verwachten. Een fulltunnelprofiel stuurt ook uw gewone browsen door het bedrijf, wat precies kan zijn wat de werkgever bedoelt en zeker iets om vóór de reis te begrijpen en niet tijdens. Het bepaalt ook het supportpad, omdat degene die een certificaat kan heruitgeven of een account kan resetten meestal tijdens kantooruren in één tijdzone bereikbaar is. Dat is belangrijker dan de clientversie.

Wat het profiel met de rest van uw verkeer doet

Een split-tunnelprofiel vervoert alleen de bedrijfsprefixes; een fulltunnelprofiel vervoert alles. Geen van beide is inherent beter, maar slechts één past bij de smalle interne-toegangsuse case, en het verschil is een configuratiebeslissing die uw organisatie al heeft genomen. U kunt het resultaat op het apparaat aflezen in plaats van het uit de profielnaam te raden:

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

De tweede opdracht laat zien welke interface verkeer naar een bedrijfsadres zou dragen. Als ook uw gewone bestemmingen via de tunnel worden opgelost, is het profiel fulltunnel, en elke verwachting dat gewoon browsen erbuiten blijft, is onjuist. Beter om dat voor de reis te ontdekken dan tijdens een gesprek.

DNS volgt dezelfde logica. Een resolver die door de tunnel wordt opgedrongen, bepaalt waar namen heen gaan, en een gesplitste configuratie kan interne namen naar het bedrijf sturen en al het overige naar de lokale resolver, of omgekeerd afhankelijk van hoe die is gebouwd. Controleer welke resolver het apparaat na verbinding daadwerkelijk gebruikt, niet welke het profiel beloofde. Een opzoeking van een interne naam vanaf een hotelnetwerk is de snelste manier om het verschil te zien.

Bereid het foutpad voor voordat u vliegt

Ga ervan uit dat de tunnel vanaf een hotelnetwerk niet bij de eerste poging verbindt, en beslis vooraf wat u doet. Dat betekent de goedgekeurde terugvaloptie die uw IT-team ondersteunt, het contact dat over tijdzones heen kan helpen, en het lokale nummer voor het apparaat als authenticatie van een telefoon afhangt. Die drie opschrijven is het verschil tussen een plan en een voornemen.

Test de ondersteunde authenticatie- en herstelstappen voor de reis, inclusief elke tweede factor die een geregistreerd apparaat vereist. Een factor die een roamingnummer nodig heeft dat u niet hebt geactiveerd, is een storing die u vandaag kunt voorspellen en op het vliegveld niet kunt oplossen. Test ook de terugvaloptie, niet alleen het primaire pad, en doe dat vanaf een netwerk dat niet uw kantoor-LAN is. Een terugvaloptie die niemand heeft geprobeerd, is een hoop, geen plan.

Houd de terugvaloptie binnen de goedgekeurde opties van de organisatie. Een geïmproviseerde openbare uitgang is geen supportpad, en het is geen beslissing die u alleen in een hotelkamer neemt. Als de goedgekeurde terugvaloptie ook faalt, is de juiste volgende stap het supportcontact, niet een andere uitgang.

Bewaar het record en controleer het opnieuw

Sla het plan op waar u het kunt vinden: de gateway-naam, het ondersteunde contact, de systemen die u nodig had en de datum waarop u de richtlijnen van de regulator hebt gecontroleerd. Richtlijnen en organisatiebeleid veranderen, en een notitie met datum is meer waard dan een herinnering. Het maakt ook de volgende reis goedkoper te plannen.

Loop het plan daarna na op de delen die niets met technologie te maken hebben: wat u doet als een dienst die u verwachtte niet beschikbaar is, en wie beslist of de reis doorgaat. Die antwoorden liggen meestal bij een persoon, niet bij een instelling in de client.