Mediu de laborator pentru studenții claselor de VMware (part II)

În prima parte a articolului am făcut o descriere generală pentru arhitectura enviroment-ului folosit de studenții claselor de VMware pentru executarea scenariilor practice de laborator. În partea a doua voi încerca să intru în detaliile legate de configurațiile pe serverele vCenter, VPN și Proxy. Urmează și o treia parte (ultima) în care voi descrie pas cu pas activități de bază pe mediul de laborator.

Configurație vCenter Server

Server-ul vCenter joacă rolul de aplicație de management pentru resursele server-ului fizic, este realizat ca și mașină virtuală și găzduit pe același server cu mediul de test. Server-ul vCenter va fi accesat de către studenți prin vSphere Client sau vSphere WEB Client pentru ași crea/gestiona propriile mașini virtuale potrivite scenariilor de laborator.

VM-ul pentru server-ul vCenter (LAB-vCenter-01s) are alocat 2x vCPU-uri, 12GB RAM și un spațiu de stocare pe disk de 60GB. Server-ul are două interfețe de rețea: una conectată în rețeaua de producție setată cu IP-ul 10.10.1.45/24 și alta conectată în rețeaua de laborator (izolată) setată cu IP-ul 172.16.0.4/16. Primul IP va fi folosit pentru accesul la vCenter din sălile de studiu DNT iar al doilea IP pentru access prin conexiune remote prin VPN.

Autentificarea pe server-ul vCenter are loc cu utilizatori creați în SSO pe domain-ul vsphere.local. Fiecare student își are propriul username și password. Username-ul e format din nume/prenume separat cu punct. Domain-ul vsphere.local este setat ca default așa că sufixul @vsphere.local poate fi omis la specificarea username-ului in căsuța de autentificare. Password-ul inițial, generat de instructor poate fi schimbat mai târziu de către student prin procedura de change password din interfața web client – mai multe detalii vedeți in partea a 3-a a articolului.

Networking-ul virtual, în laborator, este realizat pe un switch distribuit (dvSwitch-LAB) cu două grupuri de port-uri pre-configurate: (a) dvPortgroup-PRODUCTION și (b) dvPortgroup-STUDENTS, primul cu uplink-uri in rețeaua de producție și al doilea izolat pentru VM-urile din scenariile de laborator. Tehnic, din rețeaua STUDENTS (de laborator) nu ai cum să ajungi în PRODUCTION. Din două grupuri, studenții au dreptul să atașeze VM-uri doar pe grupul STUDENTS, orice tentativă de a accesa grupul de porturi de producție va genera un mesaj de eroare cu access denied. Grupul de porturi STUDENTS este configurat cu Promiscous Mode, MAC Address Changes și Forget Transmis ca Accept – configurație obligatorie pentru ESXi-urile nested conectate pe acel grup de porturi.

Rețeaua de producție are asociat subnet-ul 10.10.1.0/24 și cea de laborator 172.16.0.0/16. Spațiul de adrese /16 în rețeaua de laborator nu este controlată în nici un fel, studenții fiind liberi să utilizeze orice IP le este comod. Totuși, pentru comoditate, am împărțit intervalul în grupe de /24, fiecărui student revenindu-i un spațiu din acestea. Regula e simplă, un POD are asociat un interval 172.16.2X.0/24, unde x e numărul podului (de la 1 la 9), fiecare student cu POD-ul lui. Segregarea pe spații de adrese separate va reduce situațiile cu conflicte de adrese IP. Chiar dacă legați de spații /24 studenții vor continua să folosească mască de 16 biți în configurațiile proprii de rețea.

In laborator, folosim următoarea distribuție de adrese IP: 

dnt_vmware_lab_enviroment_p2_IP_addresses

Pentru a accesa pe mediul de laborator, studenții vor iniția o conexiune VPN prin care vor ajunge să fie conectați în rețeaua STUDENTS și auto-configurați cu un IP din intervalul VPN DHCP. În continuare se poate de mers fie cu conexiune direct de pe PC-ul de acasă prin vSphere Client la serverul vCenter fie printr-o sesiune RDP la VM-ul cu Windows 7 preinstalat și configurat cu toate necesare. Fiecare POD are configurat un VM cu Windows 7, configurat cu networking, remote desktop activat și cu aplicații necesare scenariilor de laborator pre-instalate. VM-urile respective au fost configurate cu al 10-lea IP din intervalul asociat POD-ului. In tabel mai sus, aceste IP-uri sunt prezentate in paranteze.

Accesele la resursele server-ului fizic și pe obiectele vCenter-ului au fost configurate în așa fel încât studenții să fie limitați doar la acțiuni necesare sarcinilor de laborator fără a putea influința configurația globală a mediului de laborator. Mai mult, fiecare student își are propriul container in care poate crea/gestiona VM-uri ne-având privilegii pe containere vecine și alte obiecte in vCenter. 

Configurația accesului pe vCenter se bazează pe:

  • roluri de utilizator custom: (a) Power Users for DNT Students (b) Read Only for DNT Students, primul moștenit din  rolul embedded Virtual Machine Power Users (sample) și respectiv al doilea moștenit din rolul Read-Only.
  • rolul de  Power Users for DNT Students a fost augmentat cu privilegii specifice pentru obiectele Datastore, Virtual Machine și Networking. Privilegiile respective au fost găsite empiric pe parcursul primei săptămâni de exploatare a mediului de laborator.
  • pe SSO-ul vCenter-ului este definită grupa de utilizatori vmware-class-std care include toată lista de utilizatori studenți.
  • pe ierarhie, la nivel de vCenter, grupul vmware-class-std a fost configurat cu rolul de Read Only for DNT Students fapt ce va permite accesul la inventarul vCenter și va asigura vizibilitate read-only peste toate obiectele vCenter.
  • pentru a putea executa activități legate de creare/gestionare VM-uri fiecare student a fost configurat ca Power Users for DNT Students pe container-ul vAPP cu care a fost asociat (un POD per student)
  • pentru avea acces la datastore-ul host-ului ESXi, grupul de utilizatori vmware-class-std a fost configurat ca Power Users for DNT Students pe containerul datastore-ului (Raid10-Store).
  • pentru a putea anexa VM-urile din laborator la networking-ul izolat de lab, grupul de utilizator vmware-class-std a fost configurat ca Power Users for DNT Students pe grupul de porturi dvPortgroup-STUDENTS. Atenție, doar pe grupul de porturi STUDENTS nu și PRODUCTION.
  • pentru a putea re-utiliza template-uri de VM-uri, a fost creat folderul TEMPLATES in view-ul VMs and Templates pe care sa configurat accesul ca Power Users for DNT Students pentru grupul de utilizatori vmware-class-std. Pentru a re-utiliza template-uri, studenții vor copia cu drag-and-drop template-ul nou creat din root-ul arborelui in folder-ul TEMPLATES. După această mișcare template-ul devine disponibil a fi utilizat – mai multe detalii vedeți in partea a 3-a a articolului.

Vedeți mai jos configurația privind alocarea de drepturi pe obiectele vCenter-ului: 

dnt_vmware_lab_enviroment_p2_permissions

Configurație Server VPN

Server-ul VPN permite accesul  remote la mediul de laborator, este realizat ca și mașină virtuală și se bazează pe o soluție SoftEther VPN (Windows). Ca și vCenter, VM-ul cu VPN are două interfețe, una public conectată in rețeaua de producție și configurată cu IP-ul 10.10.1.10 și a alta conectată în rețeaua studenților și configurată cu 172.16.0.1. Pe router-ul DNT-ului la Internet avem configurat un port-mapping de pe IP-ul public 178.168.50.194 pe IP-ul serverului VPN 10.10.1.10 pe port-ul 443. Serverul VPN funcționează pe deasupra și ca server DHCP pentru segmentul STUDENTS cu distribuire de IP-uri din intervalul 172.16.0.100-172.16.0.200. Pe stația remote pentru acces la VPN se instalează SoftEther VPN Client care poate fi descărcat gratuit pe site-ul SoftEther (click aici)

Fiecare student are propria pereche nume utilizator/password cu care se autentifică pe serverul VPN. Username-ul se formează din numele/prenumele studentului separat prin punct. Parola inițială este distribuită de instructor și poate fi oricând schimbată de utilizator. Despre cum de configurat o conexiune nouă pe client și cum de schimbat parola inițială aflați în partea a 3-a articolului.

Pe serverul VPN avem realizate următoarele configurații:

  • virtual HUB (default) configurat în bridge (prin Local Bridge Settings) cu a interfața ce pleacă in rețeaua STUDENTS. Implicit, bridge-ul e format cu interfața în PRODUCTION. Schimbarea bridge-ului pe altă interfață garantează ca conexiunea de VPN să va termina în rețeaua izolată de laborator și nu cea de producție.  

De remarcat că pentru a funcționa corect, interfața bridged a serverului VPAN (partea STUDENTS) trebuie conectată într-un grup de port-uri pe switch-ul virtual în care Promiscous Mode este in Accept or acest requirement în cazul nostru este asigurat automat. Așa cum menționasem mai sus grupul de porturi STUDENTS are configurat Promiscous Mode împreună cu celelalte două politici în Accept.

  • VPN-ul este configurat cu Split Tunneling astfel încât, odată conectat pe VPN, utilizatorul continuă să acceseze rețelele proprii și Internet-ul prin propria conexiune Internet și nu prin link-ul de VPN – pe client, apare o singură rută: cea spre rețeaua 172.16.0.0/16 ca directly connected prin interfața VPN-ului.
  • restul configurațiilor pe serverul SoftEther VPN rămân în condiția lor implicită

Configurație Proxy Server

Destinația inițială a server-ului Proxy a fost in a asigura accesul la WEB-ul (http, https) Internet-ului din rețeaua izolată de laborator. In lab, poți avea nevoie de Internet atunci când de exemplu dorești să aplici actualizări pe un ESXi nested or să descarci un tool sau orice altceva. În astfel de cazuri, pentru a accesa Internet-ul trebuie doar de configurat în proxy settings adresa private a server-ului proxy 172.16.0.39 cu portul 8080. Ca remarcă, toate VM-urile cu Win7 pe care studenții intră prin RDP au deja pre-configurate proxy server (tot aici, bifat bypass proxy server for local addresses și adăugat ca excepție network-ul 172.16.*.*).

Pe parcurs, ca workaround la o problema reachability, serverul Proxy a fost configurat și ca port mapping cu scopul de a permite accesul din rețeaua izolată de laborator la IP-ul de management vmk0 a host-ului ESXi aflat in rețeaua de producție. Mapping-ul e făcut doar pentru câteva porturi necesare funcționarii consolei la VM-uri din vSphere Client (TCP: 902, 9443, 443).

Problema de reachability menționată se descrie simplu: din moment ce deschizi din vSphere Client consola la un VM, client-ul inițiază o conexiune TCP pe portul 902 direct pe vmk0 a host-ului ESXi chiar daca vSphere Client este conectat pe IP-ului serverului vCenter. Consola folosește un path direct de la client la ESXi ocolind serverul vCenter. Așa cum, în arhitectura mediului de laborator vmk0 (interfața de management ESXi) este configurată pentru rețeaua de producție (cu IP-ul 10.10.1.120) rezultă că orice tentativă de a deschide o consolă la un VM din rețeaua de laborator duce într-o consolă failed și un mesaj cu reachability issues .. unable to connect.

Pentru a explica soluția realizată prin proxy, vedeți pentru început următoarea reprezentare grafică (errata: in desen numărul portului 903 trebuie inlocuit cu 902): 

dnt_vmware_lab_enviroment_p2_port_proxy_conf

In schemă avem 2x VM-uri, primul e VM-ul cu PROXY și al doilea un VM cu Win7. Serverul PROXY este conectat în același timp și in rețeaua de producție (PRODUCTION) împreună cu management-ul ESXi (vmk0) și în rețeaua de laborator (STUDENTS). VM-ul cu Win7 e conectat doar in rețeaua de laborator. In momentul in care se încearcă a deschide consola la un VM, aplicația vSphere Client inițiază o conexiune directă la managementul ESXi ocolind serverul vCenter. Așa conexiune nu are cum să aibă loc pentru că clientul și managementul ESXi se află în rețele diferite.

Ca workaround la problema descrisă s-au făcut următoarele configurații:

  • pe VM-urile cu Win7 s-au creat interfețe Loopback pe care s-au setat IP-ul de management a host-ului ESXi 10.10.1.120/32. Așa cum, in rețeaua de laborator nu exista un default gateway, loopback-ul va permite un routing pentru IP-ul ESXi-ului. Comunicațiile pentru 10.10.1.120 se vor întoarce în stack-ul de networking.
  • pe VM-urile cu Win7 s-au configurat translări de adresă IP prin așa numite port proxy-uri, create cu netsh. Port proxy-ul se setează per port și face translarea adresei destinație dintr-un IP în alt IP. Minim pentru deschiderea consolei avem nevoie de translare pentru portul TCP 902, totuși pentru siguranță fiecare stație mai are translare și pentru porturile 9443 și 443. Următorul code batch a fost executat pentru crearea translărilor port proxy (primele 3x linii, ultimele 3x e codul care le distruge): 

dnt_vmware_lab_enviroment_p2_port_proxy_cmd

Efectul port proxy-ului este ca ori de câte ori întră în stack-ul de networking un pachet cu destinație 10.10.1.120 și port 902 acesta să fie translat intr-un pachet cu destinație 172.16.0.39 cu același port. Altfel spus, pentru cazul nostru, toate pachetele destinate comunicațiilor consolei de VM-uri din vSphere Client vor fi supuse translării respective.

  • pe server-ul proxy este configurat o translare cu efect invers și anume destinația pe 172.16.0.39 pe port-ul 902 va fi translată în 10.10.1.120 pe același port. Modul realizării configurației depinde de soluția serverului proxy, pentru cazul nostru unde am folosit un CCProxy, settings-ul arată așa:

dnt_vmware_lab_enviroment_p2_port_map_proxy_server

Așadar, dacă e să parcurgem acum calea comunicațiilor pentru consola pe VM aceasta ar trece prin următoarele faze:

  • consola inițiază o conexiune pe IP-ul de management a host-ului ESXi 10.10.1.120 pe portul 902.
  • pachetele cu destinație 10.10.1.120 ajung pe interfața Loopback după care sunt întoarse în stack-ul de networking
  • întoarse pachetele sunt translate din destinația 10.10.1.120 pe IP-ul server-ului proxy 172.16.0.39 (doar acele pachete ce au ca destinație 10.10.1.120 și port destinație 902)
  • pachetele translate sunt plasate pe cealaltă interfața din VM 172.16.21.10 și sunt livrate către VM-ul cu serverul Proxy.
  • ajunse pe server-ul Proxy pachetele inițiate de aplicația consolei sunt supuse unei translări repetate prin care IP-ul destinație 172.16.0.39 este translat la valoarea inițială de 10.10.1.120 astfel încât să fie posibilă livrarea către interfața de management ESXi. (vor fi translatate doar pachetele cu IP-ul destinație 172.16.0.29 și port 902)
  • pachetele translate repetat vor fi plasate pe stack-ul de networking unde vor fi rutate pe interfața legată în rețeaua de producție (10.10.0.39)
  • în final pachetele vor ajunge pe interfața de management ESXi vmk0 cu IP-ul 10.10.1.120.

Pe desenul de mai sus, path-ul cu translări de IP-uri este ilustrat cu săgeți linie continue albastre.  Path-ul logic este ilustrat cu linie orange întreruptă.

Trebuie să recunosc că există o soluție mai simplă la problemă, însuși studenții mi-au sugerat-o atunci când le povesteam de arhitectură. Adevărul e că se poate și fără de interfața de loopback, IP-ul 10.10.1.120 poate fi liber setat ca secondary IP pe prima interfață – verificat, funcționează. Cool, încântat de așa studenți.

Aici pun punct descrierii detaliilor de configurație la serviciile ce fac ca mediul de laborator să funcționeze. În partea a 3-a (ultima) am să descriu într-o manieră How To mai multe activități pe care le poate executa un student pe mediul de test.