Përshëndetje, dhe fillimisht disa lirika. Njëherë e kam zili kolegët që punojnë në distancë - është e mrekullueshme të kesh mundësinë të punosh nga çdo skaj i botës që është i lidhur me Internetin, mund të kesh 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 praktikisht e përjashtojnë mundësinë e një mungese të gjatë në dataqendër. Megjithatë - herë pas here ndodhin raste interesante, të ngjashme me atë të përshkruar 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ë disklamer i vogël - në momentin kur po shkruhet ky artikull, rasti nuk është zgjidhur plotësisht, por duke marrë parasysh shpejtësinë e përgjigjeve nga distributorët, një zgjidhje e plotë mund të kërkojë edhe muaj, dhe doja të ndaja gjetjet e mia tashmë. Shpresoj, lexues të respektuar, që do të më falni për këtë ngutje. Por mjaft me ujë - çfarë ndodh me rastin?
Fillimisht një hyrje: ka një kompani (ku punoj si inxhinier rrjeti), e cila hoston zgjidhje të klientëve në një cloud privat VMWare. Shumica e zgjidhjeve të reja lidhen me VXLAN-segmente, të cilat menaxhohen nga NSX-V - nuk do të vlerësoj se sa kohë më ka dhënë kjo zgjidhje, për ta thënë shkurt - shumë. Kam arritur të mësoj edhe kolegët për konfigurimin e NSX ESG dhe zgjidhjet e vogla të klientëve ndërtohen pa pjesëmarrjen time. Një vërejtje e rëndësishme - plani i kontrollit është me replikim unicast. Hypervizorët janë lidhur me dy lidhje të tejdukshme me switch-e fizike Juniper QFX5100 (të bashkuara në Virtual Chassis) dhe politikën e përcaktimit të rrugëve të bazuara në portin virtual të origjinës - kjo është për plotësinë e pamjes.
Zgjidhjet e klientëve janë shumë të larmishme: nga Windows IIS, ku të gjithë komponentët e serverit web janë të instaluar në një makinë, deri në zgjidhje shumë të mëdha - për shembull, Apache web-frontet me load balancing + LB MariaDB në Galera + servera skedarësh, të sinkronizuar me GlusterFS. Praktikisht çdo server duhet të monitorohet ndaras, dhe adresat publike nuk i ka të gjithë komponentët - nëse e keni përjetuar këtë detyrë dhe keni një zgjidhje më elegante, do të isha i lumtur për këshillën.
Zgjidhja ime pĂ«r monitorimin pĂ«rfshin "lidhen" firewallin (Fortigate) me çdo rrjet tĂ« brendshĂ«m klientĂ«sh (+SNAT dhe, sigurisht, kufizime tĂ« rrepta nĂ« lidhje me llojin e trafikut tĂ« lejuar) dhe vĂ«zhgimin e adresave tĂ« brendshme â nĂ« kĂ«tĂ« mĂ«nyrĂ« arrijmĂ« njĂ« farĂ« unifikimi dhe thjeshtimi tĂ« monitorimit. Monitorimi kryhet nga njĂ« grumbull serverash PRTG. Skema e monitorimit duket kĂ«shtu:
Derisa po operonim vetĂ«m me VLAN, gjithçka ishte mjaft normale dhe parashikueshme, si orĂ«t. Pas shpalosjes sĂ« NSX-V dhe VXLAN, u pĂ«rballĂ«m me pyetjen â a mund tĂ« vazhdojmĂ« monitorimin si mĂ« parĂ«? NĂ« momentin e kĂ«saj pyetje, zgjidhja mĂ« "tĂ« shpejtĂ«" ishte tĂ« vendosnim NSX ESG dhe tĂ« lidhnim ndĂ«rfaqen VXLAN trunk nĂ« rrjetin VTEP. E shpejtĂ« nĂ« kuotat â sepse pĂ«rdorimi i GUI pĂ«r konfigurimin e rrjeteve tĂ« klientĂ«ve, SNAT dhe rregullave tĂ« firewall-it mund tĂ« unifikojĂ« menaxhimin nĂ« njĂ« ndĂ«rfaqe tĂ« vetme vSphere, por sipas mendimit tim Ă«shtĂ« mjaft e ngjeshur dhe pĂ«r mĂ« tepĂ«r kufizon grupin e mjeteve pĂ«r troubleshooting. Ata qĂ« e kanĂ« pĂ«rdorur NSX ESG si zĂ«vendĂ«sim pĂ«r njĂ« firewall "tĂ« vĂ«rtetĂ«", mendoj se do tĂ« bien dakord. MegjithĂ«se, ndoshta, njĂ« zgjidhje e tillĂ« do tĂ« ishte mĂ« stabilja â sepse gjithçka ndodh brenda njĂ« ofruesi.
NjĂ« zgjidhje tjetĂ«r Ă«shtĂ« tĂ« pĂ«rdorni NSX DLR nĂ« modalitetin bridge midis VLAN dhe VXLAN. KĂ«tu mendoj se gjithçka Ă«shtĂ« e qartĂ« - thjesht humb fitimi nga pĂ«rdorimi i VXLAN - sepse nĂ« kĂ«tĂ« rast edhe duhet tĂ« tĂ«rheqim VLAN nĂ« instalimin e monitorimit. PĂ«rveç kĂ«saj, gjatĂ« pĂ«rpunimit tĂ« kĂ«saj zgjidhjeje, u pĂ«rballa me njĂ« problem, kur DLR bridge nuk dĂ«rgonte paketa nĂ« makinat virtuale me tĂ« cilat ndodhej nĂ« njĂ« host. E di, e di - nĂ« libra dhe nĂ« udhĂ«zues pĂ«r NSX-V thuhet qartĂ« se pĂ«r NSX Edge duhet tĂ« jetĂ« caktuar njĂ« klasĂ«r i veçantĂ«, por kĂ«to janĂ« nĂ« libra... ĂfarĂ«do qoftĂ«, pas disa muajve me suportin nuk arritĂ«m tĂ« zgjidhnim problemin. NĂ« parim, logjika e veprimit e kuptova - moduli i bĂ«rthamĂ«s sĂ« hipervizorit, pĂ«rgjegjĂ«s pĂ«r inkuadrimin e VXLAN-sĂ«, nuk aktivizohej nĂ«se DLR dhe serveri i monitoruar ndodheshin nĂ« njĂ« host, pasi trafiku nuk largohet nga hosti dhe logjikisht duhet tĂ« lidhet me segmentin VXLAN - inkuadrimi nuk nevojitet. Ne me suportin u ndalĂ«m nĂ« ndĂ«rfaqen virtuale vdrPort, e cila logjikisht bashkon uplinks dhe njĂ«kohĂ«sisht realizon bridge/integrimin - atje u vĂ«rejt njĂ« mosakordim nĂ« trafikun e ardhshĂ«m, qĂ« e mora pĂ«r pĂ«rpunimin nĂ« kĂ«tĂ« rast. Por siç u tha, deri nĂ« fund nuk e çova kĂ«tĂ« rast, pasi u kalova nĂ« njĂ« projekt tjetĂ«r dhe kjo degĂ« ishte fillimisht njĂ« rrugĂ« e mbyllur dhe nuk kisha dĂ«shirĂ« ta zhvilloja shumĂ«. NĂ«se nuk gaboj, problemi vĂ«rehej nĂ« versionet NSX 6.1.4 dhe 6.2.
Dhe kĂ«tu - bingo! Fortinet shpall mbĂ«shtetje . Dhe jo vetĂ«m point-to-point ose VXLAN-over-IPSec, jo bridging softuerik VLAN-VXLAN - tĂ« gjitha kĂ«to filluan tĂ« implementoheshin qĂ« me versionin 5.4 (dhe janĂ« paraqitur tek tĂ« tjera ), dhe mbĂ«shtetje e vĂ«rtetĂ« pĂ«r unicast control plane. GjatĂ« implementimit tĂ« zgjidhjes, u pĂ«rballa me njĂ« tjetĂ«r problem â serverat e verifikuar herĂ« pas here âshfaqninâ e herĂ« pas hĂ«rĂ« âzhdukeshinâ nga monitorimi, megjithĂ«se makina virtuale ishte ende aktive. Arsyetimi, siç u duk, ishte se kisha harruar tĂ« lejoj Ping nĂ« ndĂ«rfaqen VXLAN. GjatĂ« procesit tĂ« ribalancimit tĂ« klastereve, makinat virtuale u lĂ«vizĂ«n dhe Pingâu pĂ«rfundonte vMotion-in, pĂ«r tĂ« shĂ«nuar hostin e ri ESXI, nĂ« tĂ« cilin ishte transferuar makina. NjĂ« budallĂ«k nga ana ime, por ky problem edhe njĂ« herĂ« e minoi besimin nĂ« mbĂ«shtetje tĂ« prodhuesit â nĂ« kĂ«tĂ« rast Fortinet. Nuk po flas pĂ«r faktin se çdo rast qĂ« ka lidhje me VXLAN fillon me pyetjen âku e keni nĂ« konfigurimet e softswitch VLAN-VXLAN?â. KĂ«tĂ« herĂ« mĂ« kĂ«shilluan tĂ« ndryshoja MTU â kjo Ă«shtĂ« pĂ«r Ping-un, i cili Ă«shtĂ« 32 byte. Pastaj âluaj meâ tcp-send-mss dhe tcp-receive-mss nĂ« politikĂ« â pĂ«r VXLAN, i cili inkapsulohet nĂ« UDP. Uf, mĂ« falni â mĂ« Ă«shtĂ« grumbulluar. NĂ« pĂ«rgjithĂ«si, kĂ«tĂ« problem e zgjodha vetĂ«.
Pasi kalova trafikun testues me sukses, u vendos tĂ« implementohej kjo zgjidhje. Dhe nĂ« prodhim u zbulua se pas njĂ« apo dy ditĂ«sh gradualisht tĂ« gjitha gjĂ«rat qĂ« monitoroheshin pĂ«rmes VXLAN shuheshin. Ăaktivizimi/aktivizimi i ndĂ«rfaqes ndihmonte, por vetĂ«m pĂ«r njĂ« kohĂ«. Duke pasur parasysh ngadalĂ«sinĂ« e mbĂ«shtetjes sĂ« prodhuesit, fillova tĂ« merrem me zgjidhjen e problemeve nga ana ime â pasi nĂ« fund tĂ« fundit kompania ime, rrjeti im â pĂ«rgjegjĂ«sia ime.
N under spojlerin e procesit tĂ« zgjidhjes sĂ« problemeve. Kush Ă«shtĂ« lodhur nga shkronjat dhe mburrjet â kaloni dhe shkoni tek analiza post.
Procesi i zgjidhjes sĂ« problemeveFaleminderit qĂ« vazhdoni tĂ« lexoni â le tĂ« vazhdojmĂ«!
Pra, monitorimi funksionon pĂ«r njĂ« farĂ« kohe, pastaj shuhen vetĂ«. Do tĂ« thotĂ«, ndoshta nuk ka probleme nĂ« politikat e firewall-it. MegjithatĂ«, pasi kam pasur probleme me procese tĂ« sistemit qĂ« ngrihen nĂ« Fortigate versionet 5.6+, fillimisht shohim âdiagnose debug flowâ â siç pritej, trafiku lejohet dhe largohet nga ndĂ«rfaqja dhe siç pritej, nuk merr asnjĂ« pĂ«rgjigje. Pjesa tjetĂ«r do tĂ« kĂ«rkojmĂ« mĂ« thellĂ« nĂ« stak. Do tĂ« kem fatkeqĂ«sisht pĂ«r tĂ« fshehur adresat, edhe nĂ«se janĂ« RFC1918, por shpresoj tĂ« siguroj procesin me njĂ« pĂ«rshkrim tĂ« mjaftueshĂ«m pĂ«r ta kuptuar. Serveri brenda VXLAN ka adresĂ«n x.x.x.15, ndĂ«rfaqja e fortigate x.x.x.254, tĂ« gjitha adresat e tjera i pĂ«rkasin rrjetit VTEP.
Për një transmetim të suksesshëm të pakove të inkapsuluara VXLAN, është e nevojshme që informatat të jenë të sakta në disa tabela. Për overlay, këto janë ARP dhe OVSDB, ndërsa për underlay, janë ARP dhe CAM. Në rastin e Fortigate, VXLAN FDB është OVSDB. Atje 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=Ń.Ń.Ń.47 port=4789 vni=5008 ifindex=7
KĂ«tu gjithçka Ă«shtĂ« mjaft e thjeshtĂ« â adresa MAC e makinerisĂ« virtuale duhet tĂ« ndodhet nĂ« VTEP me adresĂ« Ń.Ń.Ń.47. Duke parĂ« pĂ«rmbajtjen dhe konfigurimet e klasterit ESXI, gjej se MAC i makinerisĂ« virtuale Ă«shtĂ« i saktĂ«, adresa VTEP gjithashtu. Kontrolloj tabelĂ«n CAM/ARP nĂ« Fortigate â pĂ«rsĂ«ri gjithçka pĂ«rputhet me konfigurimet e hostit ESXI:
fortigate (root) #get sys arp | grep Ń.Ń.Ń.47
Ń.Ń.Ń.47 0 00:50:56:65:f6:2c dmz
Tabelat janĂ« tĂ« sakta dhe trafiku po shkon â ndoshta problemi nuk Ă«shtĂ« te Fortigate? QĂ«llimisht kam anashkaluar analizĂ«n e komunikimit tĂ« trafikut nĂ« Juniper â logjikisht, hapi tjetĂ«r i troublshutingu duhet tĂ« bĂ«het atje, por rrjeti im Ă«shtĂ« i thjeshtĂ« â njĂ« VLAN pĂ«r VTEP dhe tĂ« gjithĂ« komponentĂ«t janĂ« tĂ« lidhur drejtpĂ«rdrejt. Po ashtu, kujtoj rastin me DLR-bridgin, VDR dhe trafik qĂ« po humb â po shkoj tĂ« sniff nĂ« hostin ESXI, ndĂ«rkohĂ« krijoj njĂ« rast pĂ«r VMWare. MĂ« poshtĂ«, MAC «97:6e» pĂ«rket Fortigate, vmnic1 â kjo Ă«shtĂ« ndĂ«rfaqja qĂ« ka VTEP me adresĂ« Ń.Ń.Ń.47, po shikoj nĂ« tĂ« dy drejtimet "âdir 2":
pktcap-uw --uplink vmnic1 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap
PĂ«rparimi â nĂ« sniff shoh njĂ« kĂ«rkesĂ« ARP dhe pĂ«rgjigjen qĂ« po vjen. Po sjell vetĂ«m pĂ«rgjigjen ARP dhe aty gjithçka Ă«shtĂ« e saktĂ«. Nuk e pĂ«rmenda, por gjatĂ« gjithĂ« kĂ«saj kohe serveri i monitorimit Ă«shtĂ« pinguar adresĂ«n Ń
.Ń
.Ń
.15 â ku Ă«shtĂ« trafiku ICMP? Kujtoj se kam dy uplinkĂ«. KĂ«tu mund tĂ« diskutohet dhe tĂ« thuhet se porta virtyale e burimit Ă«shtĂ« e njĂ«jtĂ« (politika ime e lidhjes), pra pĂ«r tĂ« njĂ«jtĂ«n vNIC duhet tĂ« zgjidhet tĂ« njĂ«jtin uplink, por pĂ«rderisa jam nĂ« host, kontrollimi i uplinkut tjetĂ«r nuk Ă«shtĂ« problem:
pktcap-uw --uplink vmnic4 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap
VijnĂ« kĂ«rkesa nga Fortigate, por nuk ka pĂ«rgjigje. KĂ«shtu qĂ« problemi nuk Ă«shtĂ« te Fortigate. Epo gjithçka â mendoj unĂ« â pĂ«rsĂ«ri e njĂ«jta problem me humbjen e trafikut nĂ« VDR, pĂ«rsĂ«ri disa muaj pĂ«r tĂ« drejtuar rastin nĂ« drejtimin e duhur. Pas disa ditĂ«sh duke u qetĂ«suar, dhe pa dĂ«shiruar tĂ« pajtohem me ngĂ«rçin, vendosa tĂ« mbledh mĂ« shumĂ« sniffers pĂ«r suportin, pĂ«r tĂ« gjithĂ« procesin. Dhe kĂ«tu,
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Ă« trafik nĂ« VTEP nga (tĂ« saktĂ«) VXLAN FDB, por pĂ«rdor MAC tĂ« gabuar DST dhe trafiku ndjerĂ« e hedhur nga interfaci qĂ« e merr atĂ« tĂ« hipervizorit. NĂ« njĂ« rast nga katĂ«r, ky 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 si tĂ« gĂ«zohem ose tĂ« qaj: nga njĂ«ra anĂ« â problemi nuk Ă«shtĂ« nĂ« konfigurim, nga ana tjetĂ«r â rregulli do tĂ« vijĂ« vetĂ«m me pĂ«rditĂ«simin e firmuerit, nĂ« rastin mĂ« tĂ« mirĂ« tĂ« ardhshĂ«m. EGO e nxehtĂ«suar gjithashtu njĂ« tjetĂ«r bug qĂ« identifikova muajin e kaluar, ndonĂ«se kĂ«tĂ« herĂ« nĂ« HTML5 GUI vSphere. E vĂ«rtetĂ« njĂ« departament lokal QA i shitĂ«sve...
Mund tëRiskoj të supozojë se:
1 â plani i kontrollit tĂ« multicast, me siguri nuk do t'i nĂ«nshtrohet problemit tĂ« pĂ«rshkruar â sepse MAC adresat VTEP merren nga adresa IP e grupit, nĂ« tĂ« cilin Ă«shtĂ« i regjistruar interfaci.
2 â me shumĂ« gjasa problemi i Fortigate Ă«shtĂ« nĂ« ngarkesĂ«n e seancave nĂ« Procesorin e Rrjetit (pĂ«r afro tĂ« ngjashĂ«m CEF) â nĂ«se kalon çdo paketĂ« pĂ«rmes CPU, do tĂ« pĂ«rdoren tabelat qĂ« pĂ«rmbajnĂ« informacion tĂ« saktĂ« â tĂ« paktĂ«n vizualisht. NĂ« favor tĂ« kĂ«tij supozimi Ă«shtĂ« se ndihmon tĂ« mbyllĂ«sh/hapĂ«sh interfacin ose tĂ« presĂ«sh pak kohĂ« â mĂ« shumĂ« se 5 minuta.
3 â ndryshimi i politikĂ«s sĂ« ekipit, p.sh. nĂ« dĂ«shtim tĂ« qartĂ«, ose implementimi i LAG nuk do tĂ« zgjidhĂ« problemin, sepse Ă«shtĂ« vĂ«rejtur "ngĂ«rçi" i MAC tĂ« hipervizorit origjinal nĂ« paketat e inkapsuluara.
Në dritën e kësaj mund të ndaj se kohët e fundit kam zbuluar për vete , ku në njërën nga artikujt u tha se firewall-et stetfull dhe metodat e transferimit të të dhënave të caching janë justifikime. Mirë, nuk kam aq shumë përvojë në IT sa të them diçka të tillë, për më tepër nuk pajtohem menjëherë me të gjitha deklaratat e artikujve të blogut. Megjithatë, diçka më thotë se ka një grimcë të vërtete në fjalët e Ivanit.
Faleminderit për vëmendjen! Do të jem i lumtur të përgjigjem në pyetje dhe të dëgjoj kritikën konstruktive.
Burimi: habr.com
