2017 m. liepos 30 d.

Virtualizacijos įtaka pfSense tinklo užkardos sistemai: našumo analizė [3 dalis - Firewall mode]

Prieš pradedant analizuoti pfSense sistemos veikimą įprastu įsimenamosios užkardos {stateful firewall} režimu, naudinga apžvelgti pralaidos pokyčius pfSense sistemoje tarp tik maršrutizatoriaus ir įsimenamosios užkardos režimų (be virtualizacijos sluoksnio).

pfSense sistemos našumas maršrutizatoriaus ir užkardos režimu

Kaip matyti iš diagramos, įjungus duomenų srauto filtravimą mažiausių paketų apdorojimo našumas pfSense sistemoje ženkliai krito: maždaug 38-40 proc. Taip yra todėl, jog užkardos sistema turi sužiūrėti ne tik paketų maršrutų lentelę, bet ir filtravimo. Kiekvienas paketas kertantis tinklo mazgą turi būti sutikrintas su paketų filtravimo lentele, o tai reikalauja papildomo procesoriaus laiko ir gali gerokai sulėtinti pfSense pralaidumą jei filtravimo lentelės sąrašas ilgas.
Iš teisų, įsimenamosios užkarda {stateful firewall} turi dar vieną lentelę – būsenos {state table}, kurią peržiūri pirmiausiai. Iki tam tikros ribos ji paspartina užkardos taisyklių peržiūrą greitąja grandine tiems tinklo paketams, kurie žinomi užkardai t.y. priklauso jau užmegztai ryšio sesijai.
Vis dėlto, reiktų stengtis filtravimo taisyklių užkardoje taikyti kuo mažiau, bei kiekviena iš jų būtų pasverta kitų atžvilgiu, parenkant jų eiliškumo tvarką. Tuo tikslu rekomenduojama taikyti tinklo saugos praktiką su strategija – viską blokuoti {default deny} ir praleisti tik tai kas būtina.
Kaip minėta metodikos skyrelyje, remiantis RFC 2544 rekomendacijomis, pfSense užkarda per grafinę vartotojo sąsają sukonfigūruota su 25 vartotojo apibrėžtomis taisyklėmis, kurias sistema nuosekliai visas patikrina prieš užmezgant naują ryšio sesiją per pfSense tinklo mazgą. Taip siekiama imituoti vartotojo sukonfigūruotą ir praktikoje naudojamą užkardos sistemą.
Iš teisų, kadangi pfSense yra sofistiška tinklo apsaugos sistema, ji jau turi maždaug 80 įkoduotų {hardcoded} filtravimo taisyklių, kurios matomos tik per komandinės eilutės sąsają. Jų redagavimas per komandinę eilutę gali pažeisti pfSense sistemos vientisumą ir sutrikdyti normalų jos darbą. Jos kūrėjų palaikomas ir vienintelis teisingas pfSense sistemos konfigūracijos būdas yra per saityno tinklalapį prieinama grafinę vartotojo sąsają.
Nors į šio darbo testavimus neįtraukti testai skirtumui tarp 0 ir 25 vartojo apibrėžtų taisyklių ištirti, darbo autorius nepastebėjo jokio praktiškai reikšmingo skirtumo tarp šių pfSense sistemos konfigūracijų. Tačiau kaip jau apžvelgta, akivaizdus skirtumas atsiranda pilnai išjungus paketų filtravimą, kai pfSense dirba tik maršrutizatoriaus režimu.

Šiame darbe nenagrinėjama, bet autoriaus pastebėjimais pfSense užkardos sistemoje yra didelis našumo skirtumas kaip paketų filtravimo taisyklės apibrėžtos. Pastebėta, jog naudojant specialią užkardos taisyklę apibrėžiančią vienu vardu keletą IP adresų {alias}, eikvojama daugiau sistemos išteklių, nei dvi įprastos su tais pačiais IP adresais. Vis dėlto tai yra tik autoriaus pastebėjimai, nepatenkantis į virtualizacijos tyrimo sritį ir reikalauja atskiro tiriamojo darbo.

Toliau pateikta susistemintų testavimo duomenų vizualizacija diagramose, kai KVM virtualiųjų mašinų tinklo sąsajos realizuojamos trimis skirtingais būdais. Analizuojamas jų našumas tinklo mazgo pralaidumo, paketų delsos ir drebėjimo atžvilgiu, kai pfSense sistema dirba normaliu įsimenamuoju tinklo užkardos režimu {stateful firewall} + 25 vartotojo apibrėžtos taisyklės.

Stateful Firewall mode


Tinklo mazgo pralaidumas


Kaip jau buvo pastebėta, perjungus pfSense sistemą į normalųjį užkardos režimą jos pralaidumas apdorojamų paketų skaičiumi per sekundę krito beveik 40 proc. lyginant su plika aparatinės įranga paremta pfSense sistema – be virtualizacijos sluoksnio. Saugos mokestis palietė ir virtualizuotų pfSense sistemų našumą.
Procesoriaus ištekliams reikli IOMMU virtualizacija tik maršrutizatoriaus režimu savo našumu su aparatinės įrangos susilygino ties 512 baitų ilgio paketais, perjungus pfSense sistemą į užkardos režimą ši riba pasistūmė perpus toliau – iki 1024 baitų ilgio paketų.
VirtIO pralaida taip pat krito. Jei tik maršrutizatoriaus pfSense sistemoje su paravirtualizuotų tinklo tvarkyklių sąsaja savo pralaida tarp didesnių paketų prilygdavo aparatinei įrangai, šiai aptarnaujant pfSense užkardos sistemą nebepakanka fizinių išteklių spartos.
Tačiau kokia prasmė turėti užkardos sistemą kompiuterių tinkle su išjungtu paketų filtravimu. Šiuos nuostolius reikia priimti kaip natūralų motyvą – saugos kainą. Be to, nereikia pamiršti, jog šiame tiriamajame darbe pfSense sistema testuojama su senu ir ekonomiškos klasės serveriu. Nūdienos x86 architektūros serverių aparatinė įranga apginkluota tinklo funkcijas spartinančiomis posistemis, todėl tikėtina su analogiškomis užduotimis susidorotų geriau.

pfSense stateful užkardos režimu: dvikryptis paketų apdorojimo skaičius per sekundę

Nors iš stulpelinės pralaidos diagramos sunku įžvelgti, bet VirtIO ir E1000 tinklo sąsajos pralaida šiek tiek nukrenta pereinant nuo 1518 baitų ilgio kadrų prie 4K paketų: atitinkamai iš 79 į 73 kkps ir iš 28 į 24 kkps.
Tuo tarpu pfSense užkardos sistema su IOMMU dedikuotomis tinklo plokštėmis ir be virtualizacijos sluoksnio rodo nedidelį kardų pralaidos prieaugį pereinant iš 1518 baitų ilgio kadrų prie 4K paketų: abiem atvejais didėja nuo 81 iki 88 kkps.
Tai rodo, jog pfSense užkardos sistema su programine įranga imituojamomis tinklo plokštėmis turi sunkumų apdorojant fragmentuojamus tinklo paketus. Tą patvirtina ir testavimo metu su pastarosiomis tinklo sąsajomis prie įprastų tiems dydžiams pralaidos parametrų pradeda masiškai pametinėti tinklo paketus, ir informuoti apie fragmentuojamų paketų perpildymą pfSense sistemoje.

pfSense stateful užkardos režimu: dvikryptė tinklo mazgo greitaveika

Jei krenta kadrų pralaida, būtinai kris ir bitų pralaida per sekundę. Iš greitaveikos diagramos sunku įžvelgti skirtumus, bet remiantis testų duomenimis: pfSense užkardos be virtualizacijos sluoksnio sveikoji maksimali naudingoji dvikryptė pralaida su 64 baitų ilgio kadrais siekia 28 Mbps (bendrai 58 Mbps); IOMMU to pačio ilgio kadrus apdoroja 34 Mbps sparta, o VirtIO ir E1000 tinklo sąsajos tik 22 Mbps ir 8 Mbps atitinkamai.
Tokios tinko mazgo pralaidos išties nedžiugina, vis dėlto, vidutinis paketų dydis internete arčiau 256 baitų ilgio, o tai padidina pfSense tinklo užkardos sveikąją pralaidą su E1000 tinklo sąsajos tvarkyklėmis iki 104 Mbps duomenų srauto (52 Mbps abiem kryptimis). VirtIO tą ribą pakelia du kartus, iki 220 Mbps (110 Mbps abiem kryptimis), tai paknakamai solidi pralaida Fast Ethernet tinklui aptarnauti. IOMMU ir nevirtualizuota pfSense užkardos sistema su turima aparatine įranga gali pasiekti atitinkamai 452 ir 670 Mbps suminę greitaveiką per dvikryptį duomenų srautą.

Paketų delsa


pfSense užkardos sistemai filtruojant ją kertančius paketus tenka apdoroti pagal kelias duomenų struktūras: maršrutizavimo, būsenos ir filtravimo lenteles. Teoriškai toks paketų apdorojimas itin neigiamai atsiliepia pfSense tinklo mazgą kertančių paketų delsos laikui.
Laisvosios pfSense tinklo užkardos sukeltos delsos diagrama primena maršrutizatoriaus laisvosios delsos diagramą.
Blankiau, bet vis dar matoma maršrutizatoriaus režimu veikiančios pfSense sistemos anomalija su didesniais paketais: pfSense veikiant užkardos režimu ties 8K baitų ilgio paketu užfiksuota aparatinės įrangos delsa didesnė nei su IOMMU atvaizduotos tinklo sąsajos sprendimu.
Kaip jau minėta, delsą šiuo atveju gali lemti tinklo plokštės dėklą aptarnaujančio proceso konteksto perjungimas (plačiau apie tai rašyta pfSense tik maršrutizatoriaus platformos analizėje).

pfSense stateful užkardos režimu: laisvoji paketų delsa

Įjungus pfSense sistemoje paketų filtravimą, laisvosios delsos rezultatai bendrai nežymiai padidėjo. Tačiau skirtumas tarp tos pačios tinklo plokštės, kai ši priskirta pfSense užkardos sistemai be virtualizacijos sluoksnio ir kai ji priskirta VM per IOMMU virtualizaciją su tos pačios konfigūracijos pfSense sistema, niekur nedingo. Pastarosios laisvoji delsa vidutiniškai net apie 39% didesnė, imant kadrų ilgius nuo 64 iki 1518 baitų.
Įsimenamosios užkardos režimu dirbančios pfSense sistemos apkrautosios delsos diagrama gerokai skiriasi nuo laisvosios delsos, bet turi akivaizdžių panašumų lyginant ją su pfSense maršrutizatoriaus platforma.

pfSense stateful užkardos režimu: apkrautoji paketų delsa

Kaip ir maršrutizatoriaus režimu, pfSense užkardos laisvoji tinklo delsa linkusi sumažėti ją apkrovus sveikąja pralaida virtualiose mašinose kurios turi tiesioginę prieigą prie fizinės tinklo plokštės. Tai vaizdžiai matoma iš jų suartėjusių delsos kreivių delsos diagramose. Didžiausias sumažėjimas vėl fiksuojamas su VirtIO tinklo sąsajos tvarkyklėmis, kiek mažesnis IOMMU atveju, o nevirtualizuotos pfSense tinklo užkardos sistemos atžvilgiu ji šiek tiek padidėjo. Kaip ir maršrutizatoriaus režimu, tikėtina to priežastis VM tinklo plokštės dėklą aptarnaujančio proceso konteksto perjunginėjimas procesoriuje.
Virtualios mašinos su programine įranga paremtomis E1000 ir VirtIO tinklo sąsajomis testų metu demonstravo nestabilius rezultatus, todėl ir jų kreivės labai nenuoseklios. Tuo tarpu nevirtualizuota pfSense sistema ir VM su realiomis tinklo sąsajomis atvaizduojamas {re-mapped} per IOMMU virtualizacijos palaikymą aparatinėje įrangoje, išlaiko paketų apdorojimo stabilumą pfSense sistemai veikiant įsimenamosios užkardos režimu.
Imituojamos tinklo plokštės su E1000 tvarkyklėmis, kaip ir pfSense maršrutizatoriaus platformos atveju, apkrautoji delsa visiškai nenuosekli ir nenuspėjama, vidutiniškai 2297% didesnė nei aparatinės įrangos, nuo 64 iki 1518 baitų ilgio kadrams.
Apkrautosios delsos skirtumas tarp atvaizduojamos tinklo plokštės pfSense virtualioje mašinoje per IOMMU ir tos pačios tinklo plokštės pfSense užkardos sistemoje be virtualizacijos sluoksnio, vidutiniškai didesnis kiek daugiau nei 15%, tarp 64 ir 1518 baitų ilgio kadrų.

Paketų drebėjimas


Kaip matyti iš paketų drebėjimo diagramos, visų skirtingų tinklo sąsajų kreivės sugeneruotos pfSense užkardos sistemos testavimu metu, pasižymi nuoseklumu ir stabilumu.

pfSense stateful užkardos režimu: paketų drebėjimas

Prie paveldėtos maršrutizatoriaus platformos anomalijos prisidėjo dar viena, taip pat programine įranga paremta tinklo sąsajos tvarkyklė.
Iš tiesų, abi anomalijos jau buvo pastebėtos pralaidos diagramoje ir ją sudarančių lentelių analizėje, kurią sukėlė sumažėjusi pfSense užkardos kadrų pralaida apdorojant fragmentuojamus paketus. Panašu, jog ir VirtIO banguojanti kreivė protestuoja prieš fragmentuotus tinklo paketus pfSense užkardos sistemoje, todėl reiktų vengti didesnių nei 1518 baitų ilgio kadrų kompiuterių tinkle su virtualizuota pfSense užkarda, arba naudoti IOMMU virtualizaciją.
Iš paketų drebėjimo diagramos matyti, jog su 64-256 baitų ilgio kadrais VirtIO paketų drebėjimas mažesnis už IOMMU. Tačiau IOMMU pralaida taip pat didesnė. Jei jos pralaidą sumažinti iki VirtIO, sumažėtų ir paketų drebėjimas, kurį šiuo atveju lemia itin aukšta pfSense sistemos centrinio procesoriaus apkrova.
Kaip ir pfSense maršrutizatoriaus platformos atveju, prie mažiausių tinklo kadro dydžių matyti ryškus skirtumas tarp IOMMU atvaizduojamos tinklo plokštės VM ir tos pačios tinklo plokštės nevirtualizuotoje pfSense užkardos sistemoje. Paketų drebėjimo skirtumas, kaip ir maršrutizatoriaus platformos atveju, išnyksta su didesniais nei 512 baitų ilgio paketais.

pfSense sistemos centrinio vidutinė apkrova


Kaip ir tikėtasi, vidutinės pfSense sistemos apkrovos diagramoje ryškus skirtumas tarp jos veikimo tik maršrutizatoriaus režimu ir įsimenamosios užkardos režimu.

pfSense sistemos vidutinė procesoriaus apkrova stateful užkardos režimu

Padidėjusi pfSense užkardos sistemos vidutinė apkrova lėmė didesnį rezultatų nuokrypį bei šio poskyrio diagramų kreivių netolygumą. Skirtingai nei maršrutizatoriaus režimu, įjungtas paketų filtravimas maksimaliai apkrauna ir nevirtualizuotą pfSense užkardos sistemą.
Kaip minėta pfSense maršrutizatoriaus vidutinės apkrovos analizėje, pfSense vidutinė apkrova sustoja ties 50 proc. riba, nes geba pilnai išnaudoti tik 2 iš 4 procesoriaus branduolių. Po vieną branduolį WAN ir LAN tinklo sąsajas kertančiam duomenų srautui apdoroti.
Testavimų metu pastebėta, jog nepriklausomai nuo turimų laisvų branduolių, pfSense sistemos įvesties/išvesties operacijų kamštis – vieno procesoriaus branduolio sparta. Jei dėl gausaus tinklo duomenų srauto vieno procesoriaus branduolio apkrova viršija 100%, nes nebespėja aptarnauti jam paskirtos tinklo plokštės generuojamas tiesiogines pertraukčių užklausas {interrupt requests}, pfSense (FreeBSD) operacinės sistema persijungia į programinį pavėlintą pertraukčių apdorojimą, tam sistemos branduolyje perkrautai tinklo plokštei sukuriama eilė {queue}, kurios aptarnavimas ne toks dažnas kaip tiesioginių procesoriaus pertraukčių. Nors tai ir sumažina tinklo sąsajos pertraukčių skaičių į procesorių, stipriai padidėja paketų apdorojimo delsos laikas ir duomenų srauto nuostoliai.

Stateless Firewall mode


pfSense buvo sukonfigūruota ir darbui neįsimenamuoju užkardos režimu {stateless firewall}, kai užkarda filtruoja kiekvieną ją kertantį paketą nepriklausomai nuo jo kilmės ir paskirties – kaip naują, net jei tik ką iš tos pačios ryšio sesijos tokį pat paketą apdorojo. Todėl kiekvienas tinklo paketas priverstas patikrinti visą užkardos taisyklių sąrašą + 25 vartotojo apibrėžtas taisykles.
Nepaisant šio tinklo užkardos režimo neefektyvumo praktikoje, šis testas atliktas su siekiu patikrinti kiek nežinomų/naujų paketų geba apdoroti pfSense užkardos sistema per vienetinį laiko tarpą. Taip sudarant apytikrį vaizdą, kiek lygiagrečių tarptinklinio ryšio kanalų pfSense užkarda su turima aparatine įranga gali apdoroti per vieną sekundę, bei įvertinti nuostolius lyginant su virtualizuota pfSense sistema. Testo rezultatai teoriškai turėtų atspindėti tuos kurie būtų gaunami praktikoje, priklausomai nuo kokio tipo ryšio sesijos užmezgamos:
  • Geresni jei ryšio sesijos užmezgamos tarp žinomų, vienodų tinklo adresų, kuriuos normaliu įsimenamuoju režimu dirbanti pfSense sistema įsimena ir apdoroja sparčiau.
  • Blogesni, jei ryšio sesijos užmezgamos tarp nežinomų, skirtingų tinklo adresų, kuriuos normaliu užkardos režimu dirbanti pfSense sistema turi apdoroti kiekvieną atskirai prieš nusprendžiant blokuoti, atmesti ar praleisti. Tokia situacija gali susidaryti kai pfSense kertančio duomenų srauto tinklo paketai daugumoje priklauso TCP protokolui ir siuntėjai nežinomi užkardos sistemai (pvz., DDoS atakos atveju).

Grynasis tinklo mazgo pralaidumas


Šiame darbe, pfSense sistemos veikiančios neįsimenamosios užkardos {stateless firewall} režimu ir apdorojančios maksimalų dvikryptį UDP duomenų srautą, kurio nuostoliai paketo dydžiui nedidesni už 0,1% šiame darbe vadinama grynąja tinklo mazgo pralaida.
Lyginant pfSense maršrutizatoriaus ir įsimenamosios užkardos režimų kadrų pralaidos diagramas akivaizdžiai matyti, jog kiekvieno pfSense tinklo mazgą kertančio paketo tikrinimas sukuria didžiules sąnaudas ir smarkiai sumažina pfSense užkardos našumą: grynoji pfSense mazgo pralaida beveik du kartus mažesnė už įsimenamosios užkardos sveikąją, ir net apie tris kartus už pfSense maršrutizatoriaus platformos pralaidą.

pfSense stateless užkardos režimu: dvikryptis paketų apdorojimo skaičius per sekundę

Jei tarsim, jog vidutinio tinklo vidutinio paketo ilgis apie 256 baitai, tai nevirtualizuota pfSense užkarda su turima aparatine įranga, gebanti apdoroti be žymių nuostolių 214 tūkst. nežinomų/naujų paketų per sekundę – galėtų teoriškai aptarnauti maždaug 214 tūkstančių lygiagrečių tarptinklinių ryšio kanalų per vieną sekundę; tuo tarpu virtualizuota pfSense užkarda geriausiu atveju (su IOMMU palaikymu) apdorotų apie 168 tūkstančius ryšio sesijų per vieną sekundę; o VirtIO ir E1000 atitinkamai po 80 ir 48 tūkstančių.

pfSense stateless užkardos režimu: dvikryptė tinklo mazgo greitaveika

Kaip įprasta, visapusiškai analizei verta į pralaidą pažvelgti ir bitais per sekundę. Jei vėl tarsim, jog vidutinio tinklo duomenų srauto vidutinis paketo ilgis yra apie 256 baitai, tai nevirtualizuota pfSense užkarda su turima aparatine įranga be virtualizacijos sluoksnio sugebės išfiltruoti 180 Mbps dvikryptį duomenų srautą (bendrai 360 Mbps). Virtualizacija geriausiu atveju be reikšmingų nuostolių sugebėtų apdoroti 141 Mbps dvikryptį duomenų srautą (bendrai 282 Mbps). VirtIO ir E1000 sąsajos atitinkamai po 134 Mbps ir 80 Mbps, nežinomos kilmės ir paskirties paketų srauto.



"Virtualizacijos įtaka pfSense tinklo užkardos sistemai: našumo analizė" Turinys:

Komentarų nėra:

Rašyti komentarą