PĂ«rshĂ«ndetje, dhe fillimisht pak lirizĂ«m. NganjĂ«herĂ« kam zili pĂ«r kolegĂ«t qĂ« punojnĂ« nga distanca â sepse Ă«shtĂ« e mrekullueshme tĂ« kesh mundĂ«sinĂ« tĂ« punosh nga çdo cep i botĂ«s me qasje nĂ« Internet, pushime nĂ« çdo kohĂ«, pĂ«rgjegjĂ«si pĂ«r projektet dhe afatet, e jo tĂ« qĂ«ndrosh nĂ« zyrĂ« nga ora 8 deri nĂ« 5. Pozita ime dhe detyrat e punĂ«s pothuajse pĂ«rjashtojnĂ« mundĂ«sinĂ« e mungesĂ«s sĂ« gjatĂ« nĂ« datacenter. MegjithatĂ« â ndodhin herĂ« pas here raste interesante, si ai qĂ« po pĂ«rshkruaj mĂ« poshtĂ« â dhe kuptoj qĂ« ekzistojnĂ« pak pozita ku ka kaq shumĂ« hapĂ«sirĂ« pĂ«r shprehjen krijuese tĂ« njĂ« troubleshooter-i tĂ« brendshĂ«m.
NjĂ« parathĂ«nie e vogĂ«l â nĂ« momentin e shkrimit tĂ« artikullit, rasti nuk Ă«shtĂ« zgjidhur plotĂ«sisht, por duke marrĂ« parasysh shpejtĂ«sinĂ« e pĂ«rgjigjeve nga ofruesit, zgjidhja e plotĂ« mund tĂ« marrĂ« edhe muaj. DĂ«shiroj tĂ« ndaj zbulimet e mia qĂ« tani. Shpresoj se ju, lexues tĂ« nderuar, do tĂ« mĂ« falni kĂ«tĂ« nxitim. Por mjaft me fjalĂ« â çfarĂ« ndodhi me rastin?
Fillimisht njĂ« hyrje: ekziston njĂ« kompani (ku unĂ« punoj si inxhinier rrjeti) qĂ« hoston zgjidhje pĂ«r klientĂ«t nĂ« njĂ« cloud privat VMware. Shumica e zgjidhjeve tĂ« reja lidhen me segmente VXLAN, tĂ« cilat menaxhohen nga NSX-V â nuk do tĂ« vlerĂ«soj se sa kohĂ« mĂ« ka kursyer kjo zgjidhje; pĂ«r tĂ« thĂ«nĂ« shkurt, shumĂ«. MĂ« ka arritur edhe tĂ« shpjegoj kolegĂ«ve konfiguroj NSX ESG dhe zgjidhjet e vogla pĂ«r klientĂ«t vendosen pa pĂ«rfshirjen time. NjĂ« shĂ«nim i rĂ«ndĂ«sishĂ«m â plani i kontrollit nĂ« ne kemi replikim unicast. HipervizorĂ«t janĂ« lidhur me dy interfecesh tĂ« dyfishta nĂ« switch-e fizike Juniper QFX5100 (tĂ« ndĂ«rtuar nĂ« Virtual Chassis) dhe politika e tĂ« kohĂ«s sĂ« rregullit nĂ« bazĂ« tĂ« portit virtual qĂ« krijon â kjo pĂ«r njĂ« pasqyrĂ« tĂ« plotĂ«.
Zgjidhjet pĂ«r klientĂ«t janĂ« shumĂ« homogjene: nga Windows IIS, ku tĂ« gjitha komponentĂ«t e serverit web janĂ« instaluar nĂ« njĂ« makinĂ«, deri te zgjidhje tĂ« mĂ«dha â pĂ«r shembull, Apache web-front-e tĂ« balancuar me ngarkesĂ« + LB MariaDB nĂ« Galera + serverat ndarĂ«s shtesĂ«, tĂ« sinkronizuar me GlusterFS. Praktikisht çdo server duhet tĂ« monitorohet veçmas, dhe adresat publike nuk janĂ« tĂ« gjithĂ« komponentĂ«ve â nĂ«se keni pĂ«rjetuar kĂ«tĂ« sfidĂ« dhe keni njĂ« zgjidhje mĂ« tĂ« elegantĂ«, do tĂ« isha i lumtur pĂ«r kĂ«shillat tuaj.
Zgjidhja ime pĂ«r monitorimin pĂ«rfshin "lidhninĂ«" e firewall-it (Fortigate) nĂ« çdo rrjetin e brendshĂ«m tĂ« klientĂ«ve (+SNAT dhe sigurisht, kufizime tĂ« forta pĂ«r llojin e trafikut tĂ« lejuar) dhe mbikqyrjen e adresave tĂ« brendshme â kĂ«shtu arrihet njĂ« unifikim dhe thjeshtim nĂ« monitorim. Monitorimi vetĂ« ndodh nga njĂ« klaster serverash PRTG. Skema e monitorimit Ă«shtĂ« diçka si kjo:
PĂ«rsa kohĂ« qĂ« vepronim vetĂ«m me VLAN, gjithçka ishte mjaft e zakonshme dhe parashikueshĂ«m punonte si orĂ«t. Pas zbatimit tĂ« NSX-V dhe VXLAN, u ndeshĂ«m me pyetjen â a mund tĂ« vazhdojmĂ« monitorimin si mĂ« parĂ«? NĂ« atĂ« moment, zgjidhja "mĂ« e shpejtĂ«" ishte ndĂ«rmarrja e NSX ESG dhe lidhja e interficit trunk VXLAN nĂ« rrjetin VTEP. E shpejtĂ« nĂ« kuotat â pasi pĂ«rdorimi i GUI pĂ«r konfigurimin e rrjeteve tĂ« klientĂ«ve, SNAT dhe rregullave tĂ« firewall-it mund ta unifikojĂ« menaxhimin nĂ« njĂ« ndĂ«rfaqe vSphere, por sipas mendimit tim, Ă«shtĂ« mjaft i dĂ«shtuar dhe pĂ«rveç tĂ« gjitha, kufizon setin e mjeteve pĂ«r troubleshooting. Ata qĂ« kanĂ« pĂ«rdorur NSX ESG si njĂ« zĂ«vendĂ«sim pĂ«r njĂ« âmplakâ firewall, mendoj se do tĂ« bien dakord. MegjithatĂ«, ndoshta njĂ« zgjidhje e tillĂ« do tĂ« ishte mĂ« e qĂ«ndrueshme â sepse gjithçka ndodh brenda njĂ« ofruesi.
NjĂ« zgjidhje tjetĂ«r â pĂ«rdorimi i NSX DLR nĂ« modin bridge midis VLAN dhe VXLAN. KĂ«tu mendoj se gjithçka Ă«shtĂ« e qartĂ« â thjesht humbet pĂ«rfitimi i pĂ«rdorimit tĂ« VXLAN â sepse nĂ« kĂ«tĂ« rast, çdoherĂ« duhet tĂ« tĂ«rheqim VLAN nĂ« instalimin e monitorimit. PĂ«r shembull, nĂ« procesin e punĂ«s me kĂ«tĂ« zgjidhje, u ndesha me njĂ« problem, kur DLR-bridge nuk dĂ«rgonte paketa nĂ« makinat virtuale me tĂ« cilat ishte nĂ« tĂ« njĂ«jtin host. E di, e di â nĂ« librat dhe udhĂ«zimet pĂ«r NSX-V Ă«shtĂ« thĂ«nĂ« qartĂ« se pĂ«r NSX Edge duhet tĂ« caktohet njĂ« klaster i veçantĂ«, por kjo Ă«shtĂ« nĂ« libra... MegjithatĂ«, mbas disa muajsh me mbĂ«shtetje, problemin nuk e zgjidhĂ«m. NĂ« parim, logjika e veprimit e kuptova â moduli i bĂ«rthamĂ«s sĂ« hipervizorit, pĂ«rgjegjĂ«s pĂ«r encapsulimin e VXLAN nuk u aktivizua, nĂ«se DLR dhe serveri i mbikqyrur ishin nĂ« tĂ« njĂ«jtin host, pasi trafiqi nuk e lĂ« host-in dhe logjikisht duhet tĂ« jetĂ« i lidhur me segmentin VXLAN â encapsulimi nuk Ă«shtĂ« e nevojshme. Me mbĂ«shtetje, ne u ndalĂ«m te interfaci virtual vdrPort, i cili logjikisht bashkon uplinks dhe ai gjithashtu bĂ«n bridge-in / encapsulation â aty u vĂ«rejt njĂ« mos pĂ«rputhje nĂ« trafikun e hyrĂ«s, tĂ« cilĂ«n e mora pĂ«r punĂ« nĂ« kĂ«tĂ« rast. Por siç u tha, nuk e pĂ«rfundova kĂ«tĂ« rast, pasi u kalova nĂ« njĂ« projekt tjetĂ«r dhe dega nĂ« tĂ« cilĂ«n fillimisht isha ishte njĂ« rrugĂ« e panjohur dhe nuk kisha dĂ«shirĂ« ta zhvilloj veçanĂ«risht. NĂ«se nuk gaboj, problemi u vĂ«rejt nĂ« versionet NSX 6.1.4 dhe 6.2.
Dhe kĂ«tu â bingo! Fortinet njofton mbĂ«shtetje natyrale . Dhe jo thjesht point-to-point ose VXLAN-over-IPSec, as softuer bridge VLAN-VXLAN â tĂ« gjithĂ« kĂ«to filluan tĂ« implementohen qĂ« me versionin 5.4 (dhe janĂ« paraqitur nga tĂ« tjerĂ« ), por mbĂ«shtetje e vĂ«rtetĂ« pĂ«r unicast control plane. GjatĂ« implementimit tĂ« zgjidhjes unĂ« u pĂ«rballa me njĂ« problem tjetĂ«r â serverĂ«t e verifikuar herĂ« pas here "shkarkoheshin" e herĂ« pas here shfaqeshin nĂ« monitorim, ndonĂ«se vetĂ« virtualka ishte aktive. Arsyeja, siç duket ishte se unĂ« harrova tĂ« lejoja Ping nĂ« ndĂ«rfaqen VXLAN. GjatĂ« procesit tĂ« ribalancimit tĂ« grupeve, virtualkat ishin tĂ« zhvendosura, dhe vMotion pĂ«rfundonte me Ping, pĂ«r tĂ« treguar hostin e ri ESXI, nĂ« tĂ« cilin ishte zhvendosur makina. NjĂ« gabim im, por ky problem pĂ«rsĂ«ri goditi besimin ndaj mbĂ«shtetjes sĂ« prodhuesit â nĂ« kĂ«tĂ« rast Fortinet. Nuk do tĂ« flas pĂ«r faktin se çdo rast i lidhur me VXLAN fillon me pyetje "ku e keni nĂ« parametrat tuaj softswitch VLAN-VXLAN?" KĂ«tĂ« herĂ« mĂ« kĂ«shilluan tĂ« ndryshoja MTU â kjo pĂ«r Ping qĂ« Ă«shtĂ« 32 bytes. Pastaj "luaj" me tcp-send-mss dhe tcp-receive-mss nĂ« politikĂ« â pĂ«r VXLAN, qĂ« inkapsulohet nĂ« UDP. Uf, mĂ« falni â Ă«shtĂ« ngarkuar. NĂ« pĂ«rfundim, kĂ«tĂ« problem e zgjida vet.
Pas njĂ« testi tĂ« suksesshĂ«m tĂ« trafikut, u vendos tĂ« implementohej kjo zgjidhje. Dhe nĂ« prodhim doli se pas njĂ« ose dy ditĂ«sh gradualisht po hiqeshin tĂ« gjitha qĂ« monitoroheshin pĂ«rmes VXLAN. Aktivizimi/çaktivizimi i ndĂ«rfaqes ndihmonte, por vetĂ«m pĂ«r njĂ« kohĂ«. Duke mbajtur mend ngadalĂ«sinĂ« e mbĂ«shtetjes sĂ« prodhuesit, mora pĂ«rsipĂ«r zgjidhjen e problemeve nga ana ime â nĂ« fund tĂ« fundit kompania ime, rrjeti im â pĂ«rgjegjĂ«sia ime.
NĂ«n spoilerin e trajektoreve tĂ« zgjidhjes sĂ« problemeve. Kush Ă«shtĂ« lodhur nga shkronjat dhe lavdĂ«rimet â kaloni dhe vazhdoni nĂ« pas-analizĂ«n.
Hodhi trajektore e zgjidhjes sĂ« problemeveFaleminderit qĂ« vazhdoni tĂ« lexoni â le tĂ« vazhdojmĂ«!
Pra, monitorimi punon pĂ«r njĂ« kohĂ«, pastaj hiqet vetvetiu. Pra, ndoshta nĂ« politikat e firewall-it nuk ka probleme. MegjithatĂ«, duke marrĂ« parasysh se unĂ« kam hasur probleme me procese sistemike tĂ« ngadaltĂ« nĂ« Fortigate versionet 5.6+, fillojmĂ« me "diagnose debug flow" â siç pritej, trafiku lejohet dhe largohet nga ndĂ«rfaqja dhe siç pritej, nuk ka asnjĂ« pĂ«rgjigje. Pra, hulumtojmĂ« mĂ« tej pĂ«rmes milionĂ«ve. Do tĂ« duhet, fatkeqĂ«sisht, tĂ« fsheh adresat, edhe pse tĂ« RFC1918, por shpresoj t'i jap procesit njĂ« pĂ«rshkrim tĂ« mjaftueshĂ«m pĂ«r mirĂ«kuptim. Serveri brenda VXLAN ka adresĂ«n x.x.x.15, ndĂ«rfaqja e fortigate ka adresĂ«n x.x.x.254, tĂ« gjitha adresat e tjera i pĂ«rkasin rrjetit VTEP.
Për një transmetim të suksesshëm të paketeve të inkapsuluara VXLAN, nevojitet informacioni i saktë në disa tabela. Për overlay këto janë ARP dhe OVSDB, për underlay janë ARP dhe CAM. Në rastin e Fortigate VXLAN, FDB është dhe OVSDB. Atje dhe do të fillojmë:
fortigate (root) #diag sys vxlan fdb list vxlan-LS
mac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=u.u.u.47 port=4789 vni=5008 ifindex=7
KĂ«tu gjithçka Ă«shtĂ« mjaft e thjeshtĂ« â adresa MAC e virtualkĂ«s duhet tĂ« jetĂ« nĂ« VTEP me adresĂ«n u.u.u.47. Duke parĂ« pĂ«rmbajtjen dhe parametrat e grupeve ESXI, unĂ« gjej se MAC i virtualkĂ«s Ă«shtĂ« i saktĂ«, adresa e VTEP gjithashtu. Kontrolloj tabelĂ«n CAM/ARP nĂ« fortigate â sĂ«rish gjithçka pĂ«rputhet me parametrat e hostit ESXI:
fortigate (root) #get sys arp | grep u.u.u.47
u.u.u.47 0 00:50:56:65:f6:2c dmz
Tabelat janĂ« tĂ« sakta dhe trafiku largohet â ndoshta problemi nuk Ă«shtĂ« nĂ« fortigate? UnĂ« e kam anashkaluar qĂ«llimisht analizimin e komutacionit tĂ« trafikut nĂ« Juniper â logjikisht duhet tĂ« kryejmĂ« hapin e ardhshĂ«m tĂ« zgjidhjes sĂ« problemeve atje, por rrjeti im Ă«shtĂ« i thjeshtĂ« â vetĂ«m njĂ« VLAN pĂ«r VTEP dhe tĂ« gjithĂ« komponentĂ«t janĂ« tĂ« lidhur drejtpĂ«rdrejt. Plus, mĂ« kujtohet rasti me DLR-bridge, VDR dhe trafikun qĂ« zhdukej â shkoj pĂ«r tĂ« analizuar nĂ« hostin ESXI, ndĂ«rkohĂ« krijoj njĂ« rast tashmĂ« pĂ«r VMWare. MĂ« poshtĂ«, MAC "97:6e" i pĂ«rket fortigate, vmnic1 â kjo Ă«shtĂ« ndĂ«rfaqja qĂ« ka VTEP me adresĂ«n u.u.u.47, do tĂ« analizoj nĂ« tĂ« dyja drejtimet "âdir 2":
pktcap-uw --uplink vmnic1 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap
Progres â nĂ« analizĂ« shoh kĂ«rkesĂ«n ARP dhe pĂ«rgjigjen e pranuar. TĂ« jap vetĂ«m pĂ«rgjigjen ARP dhe aty Ă«shtĂ« gjithçka e saktĂ«. Nuk e pĂ«rmenda, por gjithĂ« kĂ«tĂ« kohĂ«, serveri i monitorimit pingon adresĂ«n x.x.x.15 â ku Ă«shtĂ« trafiku ICMP? MĂ« kujtohet se kam dy uplink. KĂ«tu mund tĂ« diskutohet dhe tĂ« thuhet se porta virtuale e burimit Ă«shtĂ« e njĂ«jtĂ« (politika ime e bashkimit), dmth pĂ«r tĂ« njĂ«jtĂ«n vNIC duhet tĂ« zgjidhet uplinku i njĂ«jtĂ«, por qĂ«ndruar nĂ« host, tĂ« kontrolloj njĂ« uplink tjetĂ«r nuk Ă«shtĂ« problem:
pktcap-uw --uplink vmnic4 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap
Marrin kĂ«rkesa nga FortiGate, por nuk ka pĂ«rgjigje. KĂ«shtu qĂ« problemi nuk Ă«shtĂ« te FortiGate. Mendoj, sĂ«rish tĂ« njĂ«jtin problem me humbjen e trafikut nĂ« VDR, pĂ«rsĂ«ri disa muaj pĂ«r ta dĂ«rguar rastin nĂ« drejtimin e duhur. Pas disa ditĂ«sh, duke u qetĂ«suar dhe pa dĂ«shiruar tĂ« pajtohem me bllokimin, vendosa tĂ« mbledh disa sniffers pĂ«r mbĂ«shtetje, pĂ«r tĂ« pĂ«rshpejtuar procesin. Dhe kĂ«tu, ârastĂ«sishtâ, shikimi im bie mbi inkapsulimin Ethernet underlay. Mbreti nuk Ă«shtĂ« i vĂ«rtetĂ« dhe adresa MAC e VTEP nuk korrespondon me IP-nĂ« e tij. E rivendos nĂ« zero, snifoj, kĂ«rkoj - e vĂ«rteta Ă«shtĂ« atĂ« qĂ« Ă«shtĂ«. Do tâi jap tabelĂ«n ARP pranĂ«, qĂ« tĂ« jetĂ« mĂ« e lehtĂ« pĂ«r ta krahasuar. Vini re inkapsulimin e parĂ« Ethernet nĂ« figurĂ«n e sipĂ«rme:
fortigate (root) #get sys arp | grep u.u.u.47
u.u.u.47 0 00:50:56:65:f6:2c dmz
fortigate (root) #get sys arp | grep u.u.u.42
u.u.u.42 0 00:50:56:6a:78:86 dmz
Pra, çfarë kemi në fund - pas migrimit të makinës virtuale, FortiGate përpiqet të dërgojë trafikun në VTEP nga (e saktë) VXLAN FDB, por përdor DST MAC të gabuar dhe trafiku pritet të refuzohet nga ndërfaqja që e pranon atë të hipervizorit. Në një rast nga katër, kjo MAC i përkiste hipervizorit origjinal, nga i cili filluam migrimin e makinës.
Dje mora një email nga mbështetje teknike e Fortinet - për rastin tim hapën një bug 615586. Nuk di që të gëzohem apo të qaj: nga njëra anë - problemi nuk është te konfigurimet, nga ana tjetër - një rregullim do të vijë vetëm me përditësimin e firmware, në rastin më të mirë në përditësimin e ardhshëm. Egoja e lartë më ngroh edhe një bug tjetër, që e identifikova muajin e kaluar, megjithatë atëherë në HTML5 GUI vSphere. Si një departament lokal QA të ofruesve...
Marr risikun të supozoj sa vijon:
1 - plani i kontrollit multicast në të gjithë mund të mos jetë i prekur nga problemi i përshkruar - sepse adresat MAC të VTEP marrin nga adresa IP e grupit, në të cilin ndërfaqja është e abonuar.
2 - problemi i FortiGate me offloading e sesioneve në Network Processor (afërsisht analog me CEF) - nëse kaloni çdo paketë përmes CPU, do të përdoren tabelat që përmbajnë informacion të saktë - në çdo rast vizualisht. Në favor të këtij supozimi shkon se ndihmon të mbyllësh/hapësh ndërfaqen ose të presësh për një kohë të caktuar - më shumë se 5 minuta.
3 - ndryshimi i politikës së teaming, për shembull në explicit failover, ose implementimi i LAG nuk do ta zgjidhin problemin, pasi është vërejtur "ngërç" i MAC të hipervizorit origjinal në paketat e inkapsuluara.
Në këtë kuptim, mund të ndajem se së fundmi zbuluam , ku në një nga artikujt u tha se firewally që mbështeten në shtet dhe metodat e ruajtjes së të dhënave janë një zgjidhje e përkohshme. Mirë, unë nuk jam aq i përvojë në IT sa të bëj një përshtypje të tillë, për më tepër nuk jam në përputhje me të gjitha pohimet e artikujve të blogut menjëherë. Sidoqoftë, diçka më thotë se ka një pjesë të së vërtetës në fjalët e Ivanit.
Faleminderit për vëmendjen! Do të isha i lumtur të përgjigjem në pyetje dhe të dëgjoj kritikën konstruktive.
Burimi: habr.com
