Am început să lucrăm la un proiect în care este necesar să oferim o soluție de încredere pentru partajarea ecranului la distanță - Remote Screen Sharing - RDP (Remote Desktop Protocol). Din fericire, toate dispozitivele funcționează pe sistem de operare Windows și noi putem folosi cu succes suportul de la Windows.
Deoarece toate dispozitivele sunt împrăștiate în întreaga lume, avem nevoie de o soluție care să facă un liant între toate acestea. Întregul conținut care este trimis prin cablu trebuie să fie codat. În teorie, am avea nevoie de niște servere releu care să fie "persoana de la mijloc" între dispozitive și persoanele care doresc să acceseze acea pute de legătură a dispozitivelor.
Există câteva soluții pe piață pentru Relay Servers (servere releu) și Tunneling. Unele dintre ele sunt open-source și gratis, altele sunt scumpe și foarte exotice. Pentru că soluția noastră ar rula pe Azure, noi dorim să reducem costul sarcinilor operaționale și de mentenanță cât mai mult posibil. Dacă am avea câteva servere releu ar necesita costuri de mentenanță suplimentare pentru acele aparate virtuale. În final, intenționăm să fim cât mai flexibili și să creștem sau descreștem în funcție de nevoile clientului.
Deși în mod normal noi susținem 30-50 sesiuni RDP, trebuie să fim capabili să susținem 500 de sesiuni RDP.
Din momentul în care un client ne înștiințează că dorește să deschidă o sesiune RDP până în momentul în care el are nevoie de fapt să deschidă sesiunea, avem opt secunde ca să facem toată magia. În aceste secunde, noi trebuie să notificăm dispozitivul, să deschidem canalul de comunicare cu serverul releu și să stabilim o conexiune sigură.
Am încercat să găsesc o soluție care este scalabilă, deoarece acum putem avea un vârf de 500 de sesiuni RDP, dar trebuie să fim pregătiți să susținem mai mult decât atât. Nu doresc să devirusez și să repar probleme dintr-o soluție care face tunneling și care nu funcționează conform așteptărilor. Aceasta ar necesita timp suplimentar pentru a înțelege cum funcționează sistemul, cum este făcută implementarea și așa mai departe. În final, aceasta înseamnă cheltuieli în plus precum și prezența a cel puțin unei persoane care să cunoască foarte bine soluția de tunneling și problemele care vin odată cu ea.
Service Bus Relay este un serviciu care a fost construit pentru aplicațiile hibride, care funcționează în Azure și în locație. Acesta ne permite să expunem servicii WCF din sistemele din locație care pot fi accesate din Azure, fără a trebui să ne ocupăm de reguli firewall și să deschidem porturi sau alte lucruri. Ne ajută să expunem un canal sigur (port bridge) între două puncte finale (endpoints) într-un mod sigur și de încredere. Întreaga comunicare cu Service Bus Relay se face prin HTTPS.
Service Bus Relay ne-ar putea ajuta mult. În acest caz pare a fi soluția perfectă. Dacă am putea redirecționa traficul generat de conexiunea RDP prin Service Bus Relay către celălalt endpoint… Spre norocul nostru, aceasta se poate face cu ușurință. Există un cod model foarte bun scris de Clemens Vasters care funcționează foarte bine.
Încă nu este gata pentru producție, dar este un bun punct de plecare, în special pentru un PoC, atunci când vrei să validezi dacă o soluție funcționează sau nu.
Nu voi descrie în detaliu soluția oferită de Clemens Vasters, deoarece este descrisă în amănunt în postarea sa pe blog. Soluția include un agent numit Port Bridge Agent care va rula pe dispozitivele noastre. Agentul va redirecționa traficul dintr-un port specific către Service Bus Relay. În cazul nostru, vom redirecționa întregul trafic generat de sesiunea RDP către Service Bus Relay.
Pe aparatul clientului care dorește să acceseze dispozitivul, noi vom porni o altă aplicație (serviciu) care va face un lucru similar - va pune pe hartă un port standard către același releu de la Service Bus Relay. În momentul în care pornim conexiunea desktop la distanță (Remote Desktop Connection) cu clientul, noi vom specifica portul în care Service Bus Relay este configurat pentru a expune datele.
În acest mod, vom avea o soluție de tunneling între aceste două aparate, prin Service Bus Relay, fără a fi nevoiți să deschidem porturi firewall, să avem confirmări IP complexe sau să ne ocupăm de servere releu. Dacă doriți ca modelul să funcționeze cu simbolul Shared Access Policy, veți modifica configurația TransportClientEndpointBehaviour. Furnizorul de simbol trebuie să fie specificat utilizând Shared Access Signature - vezi codul de mai jos.
relayCreds = new TransportClien
tEndpointBehavior
{
TokenProvider = TokenProvider.
CreateSharedAccessSignatureTokenProvider(
sharedAccessKeyName,sharedAccessKey)
};În acest moment, Service Bus Relay este singurul serviciu de la Service Bus care nu are suport pentru Shared Access Signature (SAS). Din această cauză, trebuie să creăm și să lucrăm cu Shared Access Policies. Acestea sunt destul de asemănătoare cu SAS, dar noi nu putem controla accesul la nivelul releului, ci numai la nivelul spațiului de nume (name space).
Din această cauză, am putea avea o problemă de securitate acolo. Dacă același spațiu de nume este utilizat în comun în două sesiuni de tunneling diferite, atunci ambele conținuturi ale sesiunilor ar putea fi accesate de ambii clienți, lucru care este posibil .
O altă problemă cu acestea este numărul politicilor care pot fi definite pe un Service Bus Namespace. Putem avea maxim 12 (Shared Access Policies). Cea mai simplă soluție este să creăm și să utilizăm un namespace diferit pentru fiecare sesiune tunneling. În acest fel, din perspectiva securității, putem gestiona accesul într-un mod sigur și de încredere. Mai multe despre acest aspect vom discuta în partea următoare.
Putem crea un fond comun de spații de nume (namespaces) Service Bus care sunt gestionate de o componentă a serverului. Putem avea tot timpul 30 namespaces disponibile în fondul comun, spre exemplu. Serviciul poate spori sau diminua numărul de namespaces disponibile în fondul comun, în funcție de solicitare sau de oră. Crearea unui spațiu de nume Service Bus nu necesită mult timp. Chiar dacă nu există vreun SLA în legătură cu timpul cât durează, noi am observat că în mod normal nu durează mai mult de 20 de secunde. Acest fond comun poate conține spații de nume din diferite subscripții Azure.
Costul unui spațiu de nume (namespace) este de ~7€ pe lună. Dacă se creează un spațiu de nume doar pentru două zile, vom plăti numai pentru acele două zile.
Mai sus putem vedea serviciul care va putea să aloce spații de nume din fondul comun. După aceea, serviciul va putea să le recicleze. Când o sesiune se încheie, sistemul va invalida cheia de acces și va genera chei noi. În acest fel, vechile chei nu mai pot fi utilizate.
În acest moment, prețul pentru 100 de ore de releu este 0,10$. 100.000 de mesaje trimise printr-un releu ne-ar costa 0,01$.
Am calculat cât trafic generează o sesiune RDP pentru o dimensiune de ecran de 1920x1080 (32b culori), utilizând RDP 6.1. Pentru o utilizare normală, am observat că, în general, pentru fiecare 5 minute de conexiune consumăm:
18MB trafic de date,
Pe baza acestor estimări, într-o oră vom consuma:
106.800 mesaje,
204MB trafic de date (expediate),
Costul total pentru o oră de RDP este 0,21\$, pentru utilizare normală la o rezoluție a ecranului de 1920x1080. Un preț foarte bun pentru o soluție care funcționează imediat și nu necesită mentenanță și cod special sau configurare pe serverul releu.
Numărul maxim de spații de nume (namespaces) sub o subscripție Azure este de 100. Pentru a putea să avem mai mult de 100 de spații de nume disponibile, putem cere ca limitarea să fie modificată pentru abonamentul nostru Azure sau să utilizăm și să gestionăm mai mult decât o singură subscripție Azure.
Din când în când, utilizând protocolul implicit Windows RDP, primim mesajul : "Din cauza unei erori în codarea datelor, această sesiune va fi încheiată." Nu ne este clar care este cauza de la rădăcina acestei probleme. Problema apare mai ales în momentul în care conținutul ecranului este actualizat și o cantitate mare de conținut este trimisă prin RDP. Suspectăm că problema are legătură cu dimensiunea pachetului. Se pare că, dacă schimbăm nivelul de securitate la SSL (TLS 1.0), problema dispare în totalitate. Este necesară o cercetare suplimentară.
Ultimul aspect nu constituie o problemă reală, dar ar trebui să ținem cont de el. Pentru a putea să utilizăm RDP pe Service Bus Relay, noi trebuie să dezactivăm certificatul de securitate de la Remote Desktop Connection. Clientul se află în spatele unui tunel (Service Bus Relay)care nu va putea să virtualizeze certificatul clientului. Luați în considerare faptul că noi deja utilizăm o conexiune sigură, oferită de tunel.
Service Bus Relay este un serviciu extrem de interesant, care este foarte capabil și scalabil. Acesta funcționează minunat ca un mecanism tunel pentru RDP - o soluție care poate fi utilizată imediat. Fără a trebui să ne ocupăm de configurarea specială, servere releu sau alte componente speciale, putem spune că este o opțiune extraordinară pentru a realiza un tunel. De asemenea, este grozav că nu trebuie să utilizăm o soluție Remote Desktop de la Microsoft. În final, putem utiliza orice tip de protocol; Service Bus Relay este doar soluția port bridge pentru a realiza un tunel. Codul model pentru port bridge nu este un cod de producție, dar este un bun punct de plecare pe care vi-l recomand cu căldură.
de Ovidiu Mățan
de Vlad Ciurca
de Ștefan Bălan
de Ioana Varga , Ioana Costea
