Portar una VPN de feina als EAU: què cal confirmar primer

Comença un viatge de feina amb una pregunta més estreta que si el programari VPN està permès en general. La pregunta útil és a quin sistema privat necessiteu arribar, a través de quin gateway de l’empresa i qui dona suport al dispositiu si el túnel no s’aixeca. Tota la resta sobre la connectivitat és una segona conversa, i barrejar les dues produeix un pla que no respon a cap. Un pla escrit les separa.

Què cobreix realment el cas d’ús documentat

El regulador de telecomunicacions dels EAU, la TDRA, publica Directrius d’internet que tracten l’ús organitzatiu de la tecnologia VPN per arribar a xarxes internes, juntament amb una discussió separada sobre el filtratge de continguts i els serveis de comunicacions. Són temes diferents. Una empresa que arriba al seu propi intranet a través del seu propi gateway és un cas d’ús organitzatiu descrit, no una declaració general sobre cada servei que un viatger pugui utilitzar. Tampoc no és una opinió jurídica sobre el vostre viatge concret, i llegir-ho com qualsevol de les dues coses és on comencen la majoria de discussions sobre aquest tema.

Llegiu les directrius publicades directament en lloc d’un resum, i tracteu aquesta pàgina com una llista de verificació de planificació i no com un consell sobre la vostra posició jurídica. Per a qualsevol cosa fora del cas documentat d’accés intern, les preguntes corresponen a un advocat local qualificat i a la política de viatges del vostre ocupador.

Mapa la feina a un gateway concret

Anoteu els sistemes que realment necessiteu: la intranet, un dipòsit de documents, l’aplicació interna que no existeix fora de la xarxa de l’empresa. Després plantegeu dues preguntes a TI: quin gateway aprovat serveix aquests sistemes i si el perfil de viatge altera res més del dispositiu. La resposta sol ser més específica del que suggereix el nom del perfil.

Algunes organitzacions publiquen un gateway de viatge dedicat amb un certificat diferent o un pas d’autenticació diferent; d’altres esperen que feu servir el perfil ordinari, que pot encaminar tot el trànsit i no només els rangs corporatius. El nom del perfil poques vegades diu quin és. Pregunteu-ho, o llegiu la taula d’encaminament un cop connectats.

Saber quin teniu canvia què hauríeu d’esperar. Un perfil de túnel complet envia també la navegació ordinària a través de l’empresa, cosa que pot ser exactament el que vol l’ocupador i que sens dubte cal entendre abans del viatge i no durant. També identifica el camí de suport, perquè la persona que pot reemetre un certificat o restablir un compte normalment és accessible en horari laboral en una zona horària. Això importa més que la versió del client.

Què fa el perfil a la resta del vostre trànsit

Un perfil de túnel dividit només porta els prefixos corporatius; un perfil de túnel complet ho porta tot. Cap dels dos no és inherentment millor, però només un encaixa amb el cas estret d’accés intern, i la diferència és una decisió de configuració que la vostra organització ja ha pres. Podeu llegir el resultat al dispositiu en lloc d’endevinar-lo pel nom del perfil:

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

La segona ordre mostra quina interfície portaria el trànsit a una adreça corporativa. Si les vostres destinacions habituals també es resolen a través del túnel, el perfil és de túnel complet, i qualsevol expectativa que la navegació ordinària quedi fora és errònia. Val més descobrir-ho abans del viatge que durant una trucada.

El DNS segueix la mateixa lògica. El resolutor que empeny el túnel decideix on van els noms, i una configuració dividida pot enviar els noms interns a l’empresa i tota la resta al resolutor local, o al revés segons com s’hagi construït. Comproveu quin resolutor fa servir realment el dispositiu després de connectar-vos, no quin havia promès el perfil. Una consulta d’un nom intern des d’una xarxa d’hotel és la manera més ràpida de veure la diferència.

Prepareu el camí de fallada abans de volar

Suposeu que el túnel no es connectarà al primer intent des d’una xarxa d’hotel, i decidiu per endavant què fareu. Això vol dir l’alternativa aprovada que el vostre equip de TI dona suport, el contacte que pot ajudar en diferents franges horàries i el número local del dispositiu si l’autenticació depèn d’un telèfon. Escriure aquests tres és la diferència entre un pla i una intenció.

Proveu els passos d’autenticació i recuperació admesos abans de viatjar, incloent-hi qualsevol segon factor que requereixi un dispositiu registrat. Un factor que necessita un número d’itinerància que no heu activat és una fallada que podeu predir avui i que no podreu arreglar a l’aeroport. Proveu també l’alternativa, no només el camí principal, i feu-ho des d’una xarxa que no sigui la LAN de l’oficina. Una alternativa que ningú no ha provat és una esperança, no un pla.

Mantingueu l’alternativa dins de les opcions aprovades per l’organització. Una sortida pública improvisada no és un camí de suport, i no és una decisió que es prengui sol en una habitació d’hotel. Si l’alternativa aprovada també falla, el següent pas correcte és el contacte de suport, no una sortida diferent.

Conserveu el registre i torneu-lo a comprovar

Deseu el pla on el trobareu: el nom del gateway, el contacte admès, els sistemes que necessitàveu i la data en què vau comprovar les directrius del regulador. Les directrius i la política organitzativa canvien, i una nota amb data val més que un record. També fa que planificar el proper viatge surti més barat.

Després reviseu el pla per les parts que no són de tecnologia en absolut — què fareu si un servei que esperàveu no està disponible, i qui decideix si el viatge tira endavant. Aquestes respostes normalment les té una persona, no una opció de configuració del client.