Un VPN de serviciu în EAU: ce trebuie confirmat mai întâi

Începeți o călătorie de serviciu cu o întrebare mai îngustă decât aceea dacă software-ul VPN este permis în general. Întrebarea utilă este la ce sistem privat trebuie să ajungeți, prin ce gateway al companiei și cine sprijină dispozitivul dacă tunelul nu pornește. Tot restul despre conectivitate este o a doua conversație, iar amestecarea celor două produce un plan care nu răspunde la niciuna. Un plan scris le separă.

Ce acoperă de fapt cazul de utilizare documentat

Autoritatea de reglementare în telecomunicații a EAU, TDRA, publică Orientări pentru internet care tratează utilizarea organizațională a tehnologiei VPN pentru a ajunge la rețele interne, alături de o discuție separată despre filtrarea conținutului și serviciile de comunicații. Acestea sunt subiecte distincte. O companie care ajunge la propriul intranet prin propriul gateway este un caz de utilizare organizațional descris, nu o declarație generală despre fiecare serviciu pe care un călător l-ar putea folosi. Nu este nici o opinie juridică despre călătoria dumneavoastră concretă, iar citirea ei ca oricare dintre cele două este locul unde încep majoritatea dezbaterilor pe acest subiect.

Citiți orientările publicate direct, nu un rezumat, și tratați această pagină ca pe o listă de verificare pentru planificare, nu ca pe un sfat privind poziția dumneavoastră juridică. Pentru tot ce este în afara cazului documentat de acces intern, întrebările aparțin unui avocat local calificat și politicii de călătorie a angajatorului dumneavoastră.

Asociați munca unui gateway anume

Notați sistemele de care aveți cu adevărat nevoie: intranetul, un depozit de documente, aplicația internă care nu există în afara rețelei companiei. Apoi puneți IT-ului două întrebări: ce gateway aprobat deservește acele sisteme și dacă profilul de călătorie schimbă altceva la dispozitiv. Răspunsul este de obicei mai specific decât sugerează numele profilului.

Unele organizații publică un gateway de călătorie dedicat, cu un certificat diferit sau un pas de autentificare diferit; altele se așteaptă să folosiți profilul obișnuit, care poate direcționa tot traficul, nu doar intervalele corporative. Numele profilului spune rar care este. Întrebați, sau citiți tabelul de rutare după ce v-ați conectat.

Să știți care este schimbă ceea ce ar trebui să așteptați. Un profil cu tunel complet trimite și navigarea obișnuită prin companie, ceea ce poate fi exact ceea ce intenționează angajatorul și este cu siguranță ceva de înțeles înainte de călătorie, nu în timpul ei. Identifică și calea de suport, pentru că persoana care poate reemite un certificat sau reseta un cont este de obicei disponibilă în timpul programului într-un singur fus orar. Asta contează mai mult decât versiunea clientului.

Ce face profilul cu restul traficului dumneavoastră

Un profil cu tunel divizat transportă doar prefixele corporative; un profil cu tunel complet transportă tot. Niciunul nu este în mod inerent mai bun, dar doar unul corespunde cazului îngust de acces intern, iar diferența este o decizie de configurare pe care organizația dumneavoastră a luat-o deja. Puteți citi rezultatul pe dispozitiv în loc să îl ghiciți din numele profilului:

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

A doua comandă arată ce interfață ar transporta traficul către o adresă corporativă. Dacă și destinațiile obișnuite sunt rezolvate prin tunel, profilul este cu tunel complet, iar orice așteptare ca navigarea obișnuită să rămână în afara lui este greșită. Mai bine descoperiți asta înainte de călătorie decât în timpul unui apel.

DNS urmează aceeași logică. Rezolvitorul impus de tunel decide unde merg numele, iar o configurație divizată poate trimite numele interne către companie și tot restul către rezolvitorul local, sau invers, în funcție de modul în care a fost construită. Verificați ce rezolvitor folosește de fapt dispozitivul după conectare, nu pe cel promis de profil. O interogare a unui nume intern dintr-o rețea de hotel este cea mai rapidă cale de a vedea diferența.

Pregătiți calea de eșec înainte de a zbura

Presupuneți că tunelul nu se va conecta la prima încercare dintr-o rețea de hotel și decideți dinainte ce veți face. Asta înseamnă alternativa aprobată pe care o susține echipa dumneavoastră IT, contactul care poate ajuta în fusuri orare diferite și numărul local al dispozitivului dacă autentificarea depinde de un telefon. A scrie aceste trei lucruri este diferența dintre un plan și o intenție.

Testați pașii de autentificare și recuperare acceptați înainte de călătorie, inclusiv orice al doilea factor care necesită un dispozitiv înregistrat. Un factor care are nevoie de un număr de roaming pe care nu l-ați activat este o defecțiune pe care o puteți prevedea azi și nu o puteți remedia la aeroport. Testați și alternativa, nu doar calea principală, și faceți-o dintr-o rețea care nu este LAN-ul biroului dumneavoastră. O alternativă pe care nimeni nu a încercat-o este o speranță, nu un plan.

Țineți alternativa în limitele opțiunilor aprobate ale organizației. O ieșire publică improvizată nu este o cale de suport, și nu este o decizie de luat singur într-o cameră de hotel. Dacă și alternativa aprobată eșuează, următorul pas corect este contactul de suport, nu o altă ieșire.

Păstrați înregistrarea și verificați-o din nou

Salvați planul unde îl veți găsi: numele gateway-ului, contactul acceptat, sistemele de care aveați nevoie și data la care ați verificat orientările autorității. Orientările și politica organizațională se schimbă, iar o notă cu dată valorează mai mult decât o memorie. Face și planificarea următoarei călătorii mai ieftină.

Apoi revizuiți planul pentru părțile care nu au nimic de-a face cu tehnologia — ce veți face dacă un serviciu la care vă așteptați nu este disponibil și cine decide dacă călătoria continuă. Acele răspunsuri sunt de obicei deținute de o persoană, nu de o setare din client.