Sveiki, un vispirms nedaudz lirikas. Dažreiz es skaudÄ«gi raugos uz kolÄÄ£iem, kas strÄdÄ attÄlinÄti ā jo tas ir lieliski, ka ir iespÄja strÄdÄt no jebkuras pasaules vietas, kas savienota ar internetu, brÄ«vdienas jebkurÄ laikÄ, atbildÄ«ba par projektiem un termiÅiem, nevis sÄdÄÅ”ana birojÄ no 8 lÄ«dz 17. Manas pozÄ«cijas un darba pienÄkumi praktiski izslÄdz ilgu prombÅ«tni datu centrÄ. TomÄr periodiski notiek interesanti gadÄ«jumi, lÄ«dzÄ«gi aprakstÄ«tajam zemÄk ā un es saprotu, ka ir maz pozÄ«ciju, kur ir tÄda brÄ«vÄ«ba radoÅ”Ä izteiksmÄ iekÅ”ÄjÄ troubleshooter'a.
Neliels disklejms ā raksta brÄ«dÄ« gadÄ«jums vÄl nav pilnÄ«bÄ atrisinÄts, bet Åemot vÄrÄ piegÄdÄtÄju atbildes Ätrumu, pilnÄ«ga risinÄjuma iegÅ«Å”ana var aizÅemt vÄl mÄneÅ”us, bet es vÄlos dalÄ«ties savÄs atziÅÄs jau tagad. Ceru, cienÄ«jamie lasÄ«tÄji, jÅ«s piedosiet man Å”o steigÅ”anu. Bet pietiek atvÄrta Å«dens ā kÄ tur ir ar gadÄ«jumu?
SÄkumÄ ievads: ir uzÅÄmums (kur es strÄdÄju kÄ tÄ«kla inženieris), kas hostÄ klientu risinÄjumus privÄtajÄ VMWare mÄkoÅÄ. LielÄkÄ daļa jauno risinÄjumu pieslÄdzas VXLAN segmentiem, kurus pÄrvalda NSX-V ā nenovÄrtÄÅ”u, cik daudz laika man Å”is risinÄjums ir devis, Ä«si sakot ā daudz. Pat izdevÄs apmÄcÄ«t kolÄÄ£us NSX ESG konfigurÄÅ”anÄ, un daži mazie klientu risinÄjumi tiek izvÄrsti bez manas iejaukÅ”anÄs. SvarÄ«gs piezÄ«mÄ ā kontrolÄjoÅ”Ä sistÄma mums ir ar unicast replikÄciju. HiperizvÄlÄtÄji ir pieslÄgti lieki ar divÄm saskarnÄm pie dažÄdiem fiziskiem Juniper QFX5100 slÄdžiem (salikti Virtual Chassis) un route based on originating virtual port timinga politiku ā tas ir, lai sniegtu pilnÄ«gu ainu.
Klientu risinÄjumi ir ļoti dažÄdi: no Windows IIS, kur visi komponents web-servera ir uz viena datora, lÄ«dz diezgan lieliem ā piemÄram, load-balanced Apache web frontiem + LB MariaDB Galera + koplietoÅ”anas serveriem, kas sinhronizÄti ar GlusterFS. Praktiski katru serveri ir jÄmonitorÄ atseviŔķi, un ne visiem komponentiem ir publiskie adreses ā ja jÅ«s esat saskÄruÅ”ies ar Å”o uzdevumu un jums ir elegantÄks risinÄjums, bÅ«Å”u priecÄ«gs par padomu.
Mans uzraudzÄ«bas risinÄjums sastÄv no ugunsmÅ«ra (Fortigate) 'pievienojuma' katrai iekÅ”Äjai klienta tÄ«klam (+SNAT un, protams, stingri ierobežojumi attiecÄ«bÄ uz atļauto trafiku) un iekÅ”Äjo adresu uzraudzÄ«bas ā tÄdÄjÄdi tiek panÄkta zinÄma vienveidÄ«ba un uzraudzÄ«bas vienkÄrÅ”oÅ”ana. Pats uzraudzÄ«bas process notiek no PRTG serveru klastera. UzraudzÄ«bas shÄma ir aptuveni Å”Äda:
KamÄr mÄs strÄdÄjÄm tikai ar VLAN, viss bija pilnÄ«gi parasts un paredzami darbojÄs, kÄ pulkstenis. PÄc NSX-V un VXLAN ievieÅ”anas saskÄrÄmies ar jautÄjumu ā vai var turpinÄt uzraudzÄ«bu pa vecam? Uz Ŕī jautÄjuma brÄ«di visÄtrÄkÄ risinÄjuma bija NSX ESG izsniegÅ”ana un VXLAN trunk saskarnes pieslÄgÅ”ana VTEP tÄ«klam. Ätri ar '''' ā jo izmantot GUI klientu tÄ«klu, SNAT un ugunsmÅ«ra noteikumu konfigurÄÅ”anai varbÅ«t vienkÄrÅ”o pÄrvaldÄ«bu vienÄ vSphere saskarnÄ, bet manuprÄt, tas ir diezgan smagnÄjs un ierobežo rÄ«ku klÄstu, kas pieejams problÄmu risinÄÅ”anai. Tie, kas izmantoja NSX ESG kÄ 'Ä«stÄ' ugunsmÅ«ra aizstÄjÄju, domÄju, piekritÄ«s. Lai gan, jÄdomÄ, Å”Äds risinÄjums bÅ«tu stabilÄks ā galu galÄ viss norisinÄs viena piegÄdÄtÄja ietvaros.
VÄl viens risinÄjums ir izmantot NSX DLR bridža režīmÄ starp VLAN un VXLAN. Å eit viss ir saprotams - vienkÄrÅ”i tiek zaudÄta VXLAN izmantoÅ”anas jÄga, jo Å”ajÄ gadÄ«jumÄ tomÄr jÄvelk VLAN uz uzraudzÄ«bas instalÄciju. Starp citu, strÄdÄjot pie Ŕī risinÄjuma, es saskÄros ar problÄmu, kad DLR tilts nesÅ«tÄ«ja paketes virtuÄlajai maŔīnai, kura atradÄs uz viena hosta. Zinu, zinu - grÄmatÄs un vadlÄ«nijÄs par NSX-V tieÅ”i ir teikts, ka NSX Edge ir jÄizveido atseviŔķs klasteris, bet tas ir grÄmatÄs... TomÄr pÄc pÄris mÄneÅ”iem ar atbalsta dienestu mÄs problÄmu neatrisinÄjÄm. PrincipÄ es sapratu darbÄ«bas loÄ£iku - hipervizora kodola modulis, kas atbild par VXLAN iepakoÅ”anu, netika aktivizÄts, ja DLR un novÄrotais serveris atradÄs uz viena hosta, jo satiksme nepameta hostu un loÄ£iski bÅ«tu jÄpieslÄdzas VXLAN segmentam - iepakoÅ”ana nav nepiecieÅ”ama. Ar atbalsta dienestu mÄs apstÄjÄmies pie virtuÄlÄ interfeisa vdrPort, kurÅ” loÄ£iski apvieno uplinkus un veic bridžoÅ”anu/iepakoÅ”anu - tur tika pamanÄ«ts neatbilstÄ«ba ienÄkoÅ”ajÄ satiksmÄ, kuru es ÅÄmu uz apstrÄdi Å”ajÄ gadÄ«jumÄ. Bet, kÄ tika teikts, lÄ«dz galam es Å”o gadÄ«jumu nenovedu, jo tiku pÄrcelts uz citu projektu, un arÄ« filiÄle sÄkotnÄji bija bezizejas un Ä«paÅ”i nebija vÄlmes to attÄ«stÄ«t. Ja nemaldos, problÄma novÄrota NSX versijÄs 6.1.4 un 6.2.
Un Å”eit - bingo! Fortinet paziÅo par natÄ«vu . Un ne tikai point-to-point vai VXLAN-over-IPSec, ne programmatÅ«ras tiltu VLAN-VXLAN - tas viss sÄka tikt ieviests vÄl no versijas 5.4 (un piedÄvÄts pie citiem ), unicast kontrolÄÅ”anas plÄna Ä«stenoÅ”anu. IevieÅ”ot risinÄjumu, es saskÄros ar vÄl vienu problÄmu ā monitorÄÅ”anas procesÄ pÄrbaudÄ«tie serveri periodiski pazuda vai atkal parÄdÄ«jÄs, lai gan pati virtuÄlÄ maŔīna bija dzÄ«va. IzrÄdÄ«jÄs, ka iemesls bija tas, ka es aizmirsu atļaut Ping VXLAN interfeisÄ. Klasteru pÄrbaloÅ”anas procesÄ virtuÄlÄs maŔīnas tika pÄrvietotas, un vMotion tika pabeigts ar Ping, lai norÄdÄ«tu jauno ESXI hostu, uz kuru maŔīna bija pÄrvietota. Mana muļķība, taÄu Ŕī problÄma vÄlreiz apturÄja uzticÄ«bu ražotÄja atbalstam ā Å”ajÄ gadÄ«jumÄ Fortinet. Es pat nerunÄÅ”u par to, ka katrs gadÄ«jums, kas saistÄ«ts ar VXLAN, sÄkas ar jautÄjumu
VeiksmÄ«gi testÄjot trafiku, tika nolemts ieviest Å”o risinÄjumu. Un ražoÅ”anÄ izrÄdÄ«jÄs, ka pÄc dienas vai divÄm pakÄpeniski atslÄdzas viss, kas monitorÄts caur VXLAN. Interfeisa deaktivizÄcija/aktivizÄcija bija noderÄ«ga, taÄu tikai uz brÄ«di. Atceroties ražotÄja atbalsta lÄnÄ«gumu, es Ä·Äros pie problÄmu novÄrÅ”anas no savas puses ā galu galÄ, mana uzÅÄmuma, mana tÄ«kla ā mana atbildÄ«ba.
ProblÄmu novÄrÅ”anas gaita. Ja jÅ«s esat noguruÅ”i no burtiem un lepnÄ«bas ā izlaižiet un pÄrejiet pie pÄcapstrÄdes.
ProblÄmu novÄrÅ”anas gaitaPaldies, ka turpinÄjÄt lasÄ«t ā turpinÄsim!
TÄtad, monitorings darbojas kÄdu laiku, pÄc tam pats sevi atslÄdz. Tas nozÄ«mÄ, ka ugunsmÅ«ri politikÄs, visticamÄk, nav problÄmu. TomÄr, tÄ kÄ esmu pieredzÄjis ar problÄmÄm, kas saistÄ«tas ar iesaldÄtÄm sistÄmas procesu Fortigate versijÄs 5.6+, vispirms skatÄmies 'diagnose debug flow' ā kÄ sagaidÄms, trafiks tiek atļauts un iznÄk caur interfeisu, un sagaidÄms, ka nekas neatnÄk atpakaļ. TÄtad, turpinÄm izpÄti tÄlÄk pa steku. DiemžÄl, bÅ«s jÄslÄpj pat RFC1918 adreses, bet es ceru sniegt procesam pietiekamu aprakstu izpratnei. Serveris iekÅ”Ä VXLAN ir ar adresi Ń .Ń .Ń .15, Fortigate interfeiss Ń .Ń .Ń .254, visas pÄrÄjÄs adreses pieder VTEP tÄ«klam.
Lai veiksmÄ«gi pÄrsÅ«tÄ«tu VXLAN iesaiÅotos paketus, ir nepiecieÅ”ama pareiza informÄcija vairÄkÄs tabulÄs. Overlay gadÄ«jumÄ tas ir ARP un OVSDB, bet underlay gadÄ«jumÄ tas ir ARP un CAM. Fortigate gadÄ«jumÄ VXLAN FDB ir OVSDB. SÄksim tur:
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
Å eit viss ir pietiekami vienkÄrÅ”i ā virtuÄla datora MAC adrese jÄatrodas uz VTEP ar adresi u.u.u.47. PÄrbaudot ESXI klastera saturu un iestatÄ«jumus, es redzu, ka virtuÄla datora MAC adrese ir pareiza, arÄ« VTEP adrese. PÄrbaudu CAM/ARP tabulu fortigate ā atkal viss sakrÄ«t ar ESXI hosta iestatÄ«jumiem:
fortigate (root) #get sys arp | grep u.u.u.47
u.u.u.47 0 00:50:56:65:f6:2c dmz
Tabulas ir pareizas un trafiks iznÄk ā varbÅ«t problÄma nav fortigate? Es apzinÄti neesmu analizÄjis trafika komutÄciju uz Juniper ā loÄ£iski nÄkamais solis troublÅ”utÄ«ngÄ bÅ«tu jÄveic tur, bet mana tÄ«kla struktÅ«ra ir vienkÄrÅ”a ā tikai viens VLAN VTEP un visi komponenti ir pieslÄgti tieÅ”i. Plus, atceros gadÄ«jumu ar DLR tiltu, VDR un iznÄ«kstoÅ”u trafiku ā dodos snifferÄt uz ESXI hosta, blakus izveidoju jau gadÄ«jumu uzÅÄmumam VMware. ZemÄkÄ MAC ā97:6eā pieder fortigate, vmnic1 ir interfeiss, kuram ir VTEP ar adresi u.u.u.47, snifferÄjam abos virzienos "ādir 2":
pktcap-uw --uplink vmnic1 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap
Progress ā sniffÄ redzu ARP pieprasÄ«jumu un nÄkoÅ”o atbildi. IzvÄlos tikai ARP atbildi, un tur viss ir pareizi. Neesmu pieminÄjis, bet visu Å”o laiku uzraudzÄ«bas serveris pingÄ adresi h.h.h.15 ā kur palika ICMP trafiks? Atceros, ka man ir divi uplinÄ·i. Å eit varÄtu diskutÄt un teikt, ka virtuÄlais avota ports ir viens un tas pats (mÄjas tÄ«kla politika), tÄtad vienai un tai paÅ”ai vNIC jÄizvÄlas viens un tas pats uplink, bet, ja jau esmu hostÄ, pÄrbaudÄ«t citu uplink nav problÄma:
pktcap-uw --uplink vmnic4 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap
SaÅem pieprasÄ«jumus no Fortigate, bet atbildes nav. TÄtad problÄma nav Fortigate. Nu, viss ā es domÄju ā atkal tÄ pati problÄma ar pazuduÅ”o satiksmi uz VDR, atkal pÄris mÄneÅ”i jÄvirza gadÄ«jums pareizajÄ virzienÄ. PÄris dienu laikÄ atdziestot un nevÄloties samierinÄties ar kavÄÅ”anos, nolÄmu savÄkt vÄl sniffus atbalstam, lai paÄtrinÄtu procesu. Un te ānejauÅ”iā mans skatiens uzkrÄ«toÅ”i krÄ«t uz Ethernet kapsulÄciju underlay. ĶÄniÅÅ” nav Ä«sts, un VTEP MAC adrese nesakrÄ«t ar tÄ IP. NollÄju, sniffoju, izpÄtu ā pareizi, kas nav pareizi. PriekÅ”Ä blakus ierakstu ARP tabulu, lai bÅ«tu ÄrtÄk salÄ«dzinÄt. PievÄrsiet uzmanÄ«bu pirmajai Ethernet kapsulÄcijai attÄlÄ augÅ”Ä:
fortigate (root) #get sys arp | grep Ń.Ń.Ń.47
Ń.Ń.Ń.47 0 00:50:56:65:f6:2c dmz
fortigate (root) #get sys arp | grep Ń.Ń.Ń.42
Ń.Ń.Ń.42 0 00:50:56:6a:78:86 dmz
TÄtad, ko mÄs beigu beigÄs iegÅ«stam ā pÄc virtuÄlÄs maŔīnas migrÄcijas, Fortigate mÄÄ£ina nosÅ«tÄ«t satiksmi uz VTEP no (pareizÄs) VXLAN FDB, bet izmanto nepareizu DST MAC un satiksme, kÄ gaidÄ«ts, tiek noraidÄ«ta no hipervizora saÅemoÅ”Ä saskarnes. TurklÄt vienÄ no Äetriem gadÄ«jumiem Å”is MAC piederÄja sÄkotnÄjam hipervizoram, no kura sÄka migrÄciju.
Vakar saÅÄmu vÄstuli no Fortinet tehniskÄ atbalsta ā manÄ gadÄ«jumÄ tika atklÄts kļūda 615586. TieÅ”Äm nezinu, vai priecÄties vai skumt: no vienas puses ā problÄma nav iestatÄ«jumos, no otras ā labojums nÄks tikai ar programmatÅ«ras atjauninÄjumu, vislabÄkajÄ gadÄ«jumÄ nÄkamajÄ. PaÅ”apziÅu arÄ« uztur vÄl viena kļūda, kuru es atklÄju pagÄjuÅ”Ä mÄnesÄ«, tomÄr tajÄ reizÄ HTML5 GUI vSphere. TieÅ”Äm, tieÅ”i vietÄjais QA nodaļa piegÄdÄtÄjiem...
Risks pieÅemt sekojoÅ”o:
1 ā multicast kontrolsistÄma, visticamÄk, nebÅ«s pakļauta aprakstÄ«tajai problÄmai ā jo VTEP MAC adreses tiek iegÅ«tas no grupas IP adreses, uz kuru pievienojas saskarne.
2 ā visticamÄk, problÄma ir Fortigate sÄrijas samazinÄjumÄ uz TÄ«kla Procesoru (aptuveni lÄ«dzÄ«gs CEF) ā ja katrs pakets tiek nosÅ«tÄ«ts caur CPU, tiks izmantotas tabulas, kuras satur pareizu ā vismaz vizuÄli ā informÄciju. Å Ä«s pieÅÄmuma labÄ runÄ tas, ka palÄ«dz aizvÄrt/atvÄrt saskarni vai gaidÄ«t zinÄmu laiku ā vairÄk nekÄ 5 minÅ«tes.
3 ā izmaiÅas komandas politikÄ, piemÄram, uz explicit failover, vai LAG ievieÅ”ana problÄmu neatrisinÄs, jo tika novÄrota āiestrÄgÅ”anaā MAC no sÄkotnÄjÄ hipervizora inkapsulÄtajos pakotnÄs.
Å Ä« kontekstÄ varu dalÄ«ties, ka nesen atklÄju, ka , kur vienÄ no rakstiem tika apgalvots, ka stetfull ugunsmÅ«ri un keÅ”otÄji datu pÄrsÅ«tÄ«Å”anas veidi ir tikai pagaidu risinÄjumi. Nu, es neesmu tik pieredzÄjis IT jomÄ, lai apgalvotu ko tÄdu, turklÄt ne visiem emuÄra rakstu apgalvojumiem es piekrÄ«tu uzreiz. TomÄr kaut kas man liek domÄt, ka Ivanam ir daļa taisnÄ«bas.
Paldies par uzmanÄ«bu! BÅ«Å”u priecÄ«gs atbildÄt uz jautÄjumiem un uzklausÄ«t konstruktÄ«vu kritiku.
Avots: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish