🥇 Iska ilaali nuglaanshaha keena wareegyada shaqada. Qaybta 1: FragmentSmack/SegmentSmack

Salaamu caleykum Magacaygu waa Dmitry Samsonov, waxaan u shaqeeyaa sidii maamulaha nidaamka hormuudka ah ee Odnoklassniki. Waxaan haynaa in ka badan 7 kun oo adeegayaal jireed ah, 11 kun oo konteenar oo daruurteena ku jira iyo 200 oo codsi ah, kuwaas oo qaabayn kala duwan u sameeya 700 oo kooxo kala duwan ah. Inta badan server-yada ayaa maamula CentOS 7.
Agoosto 14, 2018, macluumaadka ku saabsan nuglaanta FragmentSmack ayaa la daabacay
(CVE-2018-5391iyo SegmentSmack (CVE-2018-5390). Kuwani waa baylahda leh vector weerar shabakad iyo dhibco cadaalad ah oo sarreeya (7.5), taas oo khatar gelinaysa diidmada adeegga (DoS) daalka kheyraadka (CPU). Hagaajinta kernel ee FragmentSmack lama soo jeedin wakhtigaas; waxaa intaa dheer, waxay soo baxday wax badan ka dib daabacaadda macluumaadka ku saabsan dayacanka. Si loo baabi'iyo SegmentSmack, waxaa la soo jeediyay in la cusboonaysiiyo kernel-ka. Xirmada cusboonaysiinta lafteeda ayaa la sii daayay isla maalintaas, waxa hadhay oo dhan waa in la rakibo.
Maya, kama soo horjeedo cusboonaysiinta kernel-ka gabi ahaanba! Si kastaba ha ahaatee, waxaa jira nuances ...

Sida aan u cusbooneysiinno kernel-ka wax soo saarka

Guud ahaan, ma jiraan wax adag:

Soo deji baakadaha;
Ku rakib tiro adeegayaal ah (oo ay ku jiraan adeegayaasha martigelinaya daruurteena);
Hubi in aan waxba jabin;
Hubi in dhammaan goobaha kernel-ka caadiga ah lagu dabaqay khaladaad la'aan;
Sug dhawr maalmood;
Hubi waxqabadka server-ka;
U beddelo dirida adeegayaasha cusub kernel-ka cusub;
Cusbooneysii dhammaan server-yada xarunta xogta (hal xarun xogta markiiba si loo yareeyo saameynta isticmaaleyaasha haddii ay dhacdo dhibaatooyin);
Dib u bilow dhammaan server-yada

Ku celi dhammaan laamaha kernels ee aan hayno. Hadda waa:

Stock CentOS 7 3.10 - inta badan adeegayaasha caadiga ah;
Vanilla 4.19 - annagaa leh daruur hal-daruur ah, sababtoo ah waxaan u baahanahay BFQ, BBR, iwm.
Elrepo kernel-ml 5.2 - loogu talagalay qaybiyayaal aad u raran, sababtoo ah 4.19 waxay u dhaqmi jirtay xasillooni darro, laakiin astaamo isku mid ah ayaa loo baahan yahay.

Sida aad qiyaasi lahayd, dib-u-kicinta kumanaan server waxay qaadataa wakhtiga ugu dheer. Maadaama aysan dhammaan baylahdu muhiim u yihiin dhammaan server-yada, waxaan dib u soo kicineynaa kuwa sida tooska ah looga heli karo internetka. Daruuraha, si aan loo xaddidin dabacsanaanta, kuma xidhno weelasha dibadda laga heli karo ee server-yada gaarka ah ee leh kernel cusub, laakiin dib u bilaw dhammaan martigeliyayaasha iyada oo aan laga reebin. Nasiib wanaag, nidaamka halkaas ka jira wuu ka fudud yahay server-yada caadiga ah. Tusaale ahaan, weelasha bilaa dal waxay si fudud ugu guuri karaan server kale inta lagu jiro dib u kicinta.

Si kastaba ha noqotee, weli waxaa jira shaqo badan, waxayna qaadan kartaa dhowr toddobaad, iyo haddii ay jiraan wax dhibaato ah oo ku saabsan nooca cusub, ilaa dhowr bilood. Weeraryahanadu si fiican ayay u fahmeen tan, marka waxay u baahan yihiin qorshe B.

FragmentSmack/SegmentSmack Habayn

Nasiib wanaag, dayacanka qaarkood qorshaha B ayaa jira, waxaana loo yaqaan Workaround. Inta badan, tani waa isbeddel ku yimaada kernel/application settings kaas oo yarayn kara saamaynta suurtogalka ah ama gebi ahaanba baabi'in kara ka faa'iidaysiga dayacanka.

Xaaladda FragmentSmack/SegmentSmack ayaa la soo jeediyay Hawshan:

«Waxaad bedeli kartaa qiimaha caadiga ah ee 4MB iyo 3MB gudaha net.ipv4.ipfrag_high_thresh iyo net.ipv4.ipfrag_low_thresh (iyo dhiggooda ipv6 net.ipv6.ipfrag_high_thresh iyo net.ipv6.ipfrag_low_thresh) iyo 256kB hoose. Tijaabooyinku waxay muujinayaan hoos u dhac yar ama hoos u dhac weyn oo isticmaalka CPU ah inta lagu jiro weerarka iyadoo ku xiran qalabka, goobaha, iyo xaaladaha. Si kastaba ha ahaatee, waxaa jiri kara saameyn waxqabad oo ay ugu wacan tahay ipfrag_high_thresh=192 bytes, maadaama laba jajab oo 262144K ah ay hal mar geli karaan safka dib-u-ururinta. Tusaale ahaan, waxaa jirta khatar ah in codsiyada ku shaqeeya baakadaha waaweyn ee UDP ay jebi doonaan".

Halbeegyada laftooda dukumentiyada kernel-ka lagu tilmaamay sida soo socota:

ipfrag_high_thresh - LONG INTEGER Maximum memory used to reassemble IP fragments.

ipfrag_low_thresh - LONG INTEGER Maximum memory used to reassemble IP fragments before the kernel begins to remove incomplete fragment queues to free up resources. The kernel still accepts new fragments for defragmentation.

Ma hayno UDPs waaweyn oo ku saabsan adeegyada wax soo saarka. Ma jiro taraafikada LAN ee kala qaybsan; waxaa jira taraafikada WAN, laakiin maaha mid muhiim ah. Ma jiraan calaamado - waxaad soo rogi kartaa Workaround!

FragmentSmack/SegmentSmack Dhiiga koowaad

Dhibaatadii ugu horeysay ee aan la kulannay waxay ahayd in weelasha daruuraha ay mararka qaarkood ku dabaqaan goobaha cusub qayb ahaan kaliya (kaliya ipfrag_low_thresh), mararka qaarkoodna maba adeegsanin - waxay si fudud u burbureen bilawga. Suurtagal ma ahayn in dhibaatada si deggan loo soo saaro (dhammaan goobaha waxa lagu dabaqay gacanta iyada oo aan wax dhib ah jirin). Fahamka sababta uu weelku u burburo bilawga sidoo kale maaha mid sahlan: wax qalad ah lama helin. Hal shay ayaa la hubaa: dib-u-celinta dejinta waxay xallisaa dhibaatada shilalka weelka.

Waa maxay sababta aysan ugu filneyn in Sysctl lagu dabaqo martida loo yahay? Weelku wuxuu ku nool yahay shabakad u gaar ah Namespace, markaa ugu yaraan qayb ka mid ah shabakadaha Sysctl weelka ku jira wuu ka duwanaan karaa kan martida loo yahay.

Sidee saxda ah ee Sysctl loogu dabaqay weelka? Maadaama weelashayadu ay yihiin kuwo aan faa'iido lahayn, ma awoodi doontid inaad bedesho wax kasta oo Sysctl ah adiga oo galaya weelka laftiisa - kaliya ma lihid xuquuq ku filan. Si loo socodsiiyo weelasha, daruurteena wakhtigaas waxay isticmaashay Docker (hadda podman). Halbeegyada weelka cusub waxaa loo gudbiyay Docker iyada oo loo sii marayo API, oo ay ku jiraan goobaha loo baahan yahay ee Sysctl.
Markii la raadinayo noocyada, waxaa soo baxday in Docker API uusan soo celin dhammaan khaladaadka (ugu yaraan nooca 1.10). Markii aan isku daynay inaan ku bilowno weelka anagoo adeegsanayna "Docker run", waxaan ugu dambeyntii aragnay ugu yaraan wax:

write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.

Qiimaha halbeeggu ma shaqaynayo. Laakiin waa maxay sababtu? Maxayse mararka qaarkood u shaqayn la'dahay? Waxaa soo baxday in Docker uusan dammaanad qaadin nidaamka Sysctl loo isticmaalo (nooca ugu dambeeyay ee la tijaabiyay waa 1.13.1), markaa mararka qaarkood ipfrag_high_thresh ayaa isku dayay in loo dhigo 256K markii ipfrag_low_thresh uu weli ahaa 3M, taas oo ah, xadka sare wuxuu ahaa mid hoose. marka loo eego xadka hoose, taas oo keentay qaladka.

Waqtigaas, waxaan horay u isticmaalnay habkayaga dib-u-habeynta weelka ka dib bilawga (qaboojinta weelka ka dib qaboojiyaha kooxda iyo fulinta awaamiirta meesha magaca weelka iyada oo loo marayo shabakada ip), sidoo kale waxaan ku darnay qoraalka Sysctl qaybtan. Dhibkii waa la xaliyay.

FragmentSmack/SegmentSmack Dhiiga Koowaad 2

Kahor intaanan helin wakhti aan ku fahanno isticmaalka Workaround ee daruuraha, cabashooyinkii ugu horreeyay ee naadir ah ee isticmaalayaasha ayaa bilaabay inay yimaadaan. Waqtigaas, dhowr toddobaad ayaa ka soo wareegay bilawga isticmaalka Workaround ee adeegayaasha ugu horreeya. Baaritaankii ugu horreeyay wuxuu muujiyay in cabashooyinka laga helay adeegyada gaarka ah, oo aan ahayn dhammaan server-yada adeegyadan. Dhibaatadu waxay mar kale noqotay mid aan la hubin.

Ugu horreyntii, waxaan, dabcan, isku daynay inaan dib u soo celinno goobaha Sysctl, laakiin taasi wax saameyn ah kuma yeelan. Wax-is-daba-marinno kala duwan oo lagu sameeyay serferka iyo habaynta arjiga midkoodna ma caawin. Dib u kicinta ayaa caawisay Dib-u-kicinta Linux waa wax aan dabiici ahayn sidii ay caadi ugu ahayd Windows waagii hore. Si kastaba ha ahaatee, way caawisay, waxaanan u nisbaynnay ilaa "khalad kernel" markii la adeegsanaayo goobaha cusub ee Sysctl. Sidee bay u fududayd...

Saddex toddobaad ka dib dhibaatadu waa soo noqnoqotay. Qaabaynta serferadani aad bay u fududayd: Nginx in proxy/balancer mode. Ma badna gaadiidka Qoraal hordhac ah oo cusub: tirada 504 khaladaadka macaamiisha ayaa sii kordhaya maalin kasta (Wakhtiga kadinka). Garaafku wuxuu muujinayaa tirada 504 khalad maalintii adeegan:

Khaladaadka oo dhan waxay ku saabsan yihiin dhabarka dambe - oo ku saabsan midka daruuraha ku jira. Garaafka isticmaalka xusuusta ee jajabyada xirmada ee dhabarkan ayaa u ekaa sidan:

Tani waa mid ka mid ah calaamadaha ugu cad cad ee dhibaatada ee garaafyada nidaamka hawlgalka. Daruuraha dhexdiisa, isla waqti isku mid ah, dhibaato shabakad kale oo leh QoS (Xakamaynta Taraafikada) ayaa la hagaajiyay. Marka la eego garaafka isticmaalka xusuusta ee jajabyada baakadaha, waxay u muuqatay isku mid:

Malaha waxay ahayd mid fudud: haddii ay isku mid u eegaan garaafyada, markaa waxay leeyihiin sabab isku mid ah. Waxaa intaa dheer, dhibaato kasta oo ku dhacda xusuusta noocan ah aad bay dhif u tahay.

Nuxurka dhibaatada go'an waxay ahayd inaan isticmaalnay jadwalka xirmada fq oo leh jaangooyooyin aan caadi ahayn oo ku yaal QoS. Marka la eego, hal xiriir, waxay kuu ogolaaneysaa inaad ku darto 100 xirmo safka, iyo xiriirada qaarkood, xaaladaha yaraanta kanaalka, waxay bilaabeen inay xiraan safka awoodda. Xaaladdan oo kale, baakadaha waa la tuuray. Marka la eego tirakoobka tc (tc -s qdisc) waxaa lagu arki karaa sidan:

qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0) backlog 0b 0p requeues 0 1024 flows (1021 inactive, 0 throttled) 0 gc, 0 highprio, 0 throttled, 464545 flows_plimit

"464545flows_plimit" waa xirmooyinka la tuuray sababtoo ah xad dhaafka safka hal xiriir, iyo "tuuray 464545" waa wadarta dhammaan baakooyinka la tuuray ee jadwalahan. Ka dib markii la kordhiyay dhererka safka ilaa 1 kun oo dib loo bilaabay haamaha, dhibaatadu way joogsatay inay dhacdo. Waad fadhiisan kartaa oo cabbi kartaa smoothie.

FragmentSmack/SegmentSmack Dhiiggii u dambeeyay

Ugu horreyntii, dhowr bilood ka dib markii lagu dhawaaqay dayacanka kernel-ka, hagaajinta FragmentSmack ayaa ugu dambeyntii soo muuqatay (aan ku xasuusiyo in iyada oo la socota ku dhawaaqista Agoosto, hagaajin kaliya oo loogu talagalay SegmentSmack ayaa la sii daayay), taas oo na siisay fursad aan kaga tagno Workaround, taasoo nagu keentay dhibaato aad u badan. Inta lagu jiro wakhtigan, waxaan mar hore ku guuleysanay inaan u wareejino qaar ka mid ah server-yada kernel-ka cusub, oo hadda waxay ahayd inaan bilowno bilawga. Maxaynu u cusboonaysiinnay kernel-ka anagoo sugin hagaajinta FragmentSmack? Xaqiiqdu waxay tahay in geeddi-socodka ka-hortagga dayacan-darradan ay ku beegmeen (oo ay ku biireen) habka cusboonaysiinta CentOS lafteeda (taas oo qaadanaysa xitaa waqti ka badan cusboonaysiinta kaliya kernel-ka). Intaa waxaa dheer, SegmentSmack waa u nuglaanshaha khatar badan, oo hagaajinteeda isla markiiba u muuqatay, sidaas darteed macno ayey samaysay. Si kastaba ha ahaatee, si fudud uma cusbooneysiin karno kernel-ka CentOS sababtoo ah nuglaanta FragmentSmack, oo soo muuqatay intii lagu jiray CentOS 7.5, ayaa kaliya lagu hagaajiyay nooca 7.6, marka waa inaan joojino cusboonaysiinta 7.5 oo aan ku bilowno mar kale cusbooneysiinta 7.6. Tani waxay sidoo kale dhacdaa.

Marka labaad, cabashooyinka isticmaale ee dhifka ah ee ku saabsan dhibaatooyinka ayaa nagu soo noqday. Hadda waxaan si dhab ah u ogaanay inay dhammaantood la xiriiraan gelinta faylasha macaamiisha qaar ka mid ah server-yadayada. Waxaa intaa dheer, tiro aad u yar oo la soo galiyay oo laga soo qaaday tirada guud ayaa dhex maray adeegayaashan.

Sida aan ka xasuusanay sheekada kore, dib-u-celinta Sysctl ma caawin. Dib u kicinta ayaa caawisay, laakiin si ku meel gaar ah.
Tuhunnada ku saabsan Sysctl lama saarin, laakiin markan waxay ahayd lagama maarmaan in la ururiyo macluumaadka ugu badan ee suurtogalka ah. Waxa kale oo jirtay awood la'aan aad u weyn oo lagu soo saari karo dhibaatada gelinta macmiilka si loo barto si sax ah waxa dhacaya.

Falanqaynta dhammaan tirakoobyada la heli karo iyo diiwaannada nooma soo dhawaynin fahamka waxa dhacaya. Waxaa jirtay awood la'aan ba'an oo lagu soo saari karo dhibaatada si "loo dareemo" xiriir gaar ah. Ugu dambeyntii, horumariyayaashu, iyagoo isticmaalaya nooc gaar ah oo codsiga ah, waxay ku guuleysteen inay gaaraan dhalmo deggan oo dhibaatooyinka qalabka tijaabada ah marka lagu xiro Wi-Fi. Tani waxay ahayd horumar laga gaaray baaritaanka. Macmiilku wuxuu ku xidhan yahay Nginx, kaas oo wakiil u ahaa dhabarka, kaas oo ahaa codsigeena Java.

Wadahadalka mashaakilku wuxuu ahaa sidan (oo lagu hagaajiyay dhinaca wakiilka Nginx):

Macmiil: codso in la helo macluumaadka ku saabsan soo dejinta faylka.
Java server: jawaab.
Macmiil: POST oo wata fayl
Java server: qalad.

Isla mar ahaantaana, server-ka Java wuxuu u qorayaa log in 0 bytes oo xog ah laga helay macmiilka, iyo Nginx proxy wuxuu qorayaa in codsigu qaatay in ka badan 30 ilbiriqsi (30 ilbiriqsi waa wakhtiga codsiga macmiilka). Waa maxay sababta wakhtiga loo dhaafay iyo sababta 0 bytes? Marka laga eego dhinaca HTTP, wax walbaa waxay u shaqeeyaan sidii la rabay, laakiin POST ee faylka wata ayaa u muuqda inuu ka lumay shabakada. Waxaa intaa dheer, waxay ka baaba'aysaa inta u dhaxaysa macmiilka iyo Nginx. Waa markii aad isku hubayn lahayd Tcpdump! Laakiin marka hore waxaad u baahan tahay inaad fahamto qaabeynta shabakadda. Wakiilka Nginx ayaa ka dambeeya dheelitiriyaha L3 NFware. Tunneling waxaa loo isticmaalaa in lagu keeno baakadaha dheelli-tirka L3 ee server-ka, kaas oo ku dara madaxeeda xirmooyinka:

Xaaladdan oo kale, shabakadu waxay u timaadaa server-kan qaab Vlan-tagged taraafikada, kaas oo sidoo kale ku daraya beertiisa xirmooyinka:

Taraafikadan sidoo kale waa la kala qaybin karaa (isla isla boqolkiiba yar ee taraafikada soo socota ee jajaban ee aan ka hadalnay markii aan qiimeynay khataraha Workaround), kaas oo sidoo kale beddelaya nuxurka madaxyada:

Mar labaad: baakidhooyinku waxay ku duuban yihiin sumadda Vlan, oo lagu daboolay tunnel, jajaban. Si aad si fiican u fahamto sida tani u dhacdo, aynu ka raadino dariiqa xidhmada ee macmiilka ilaa Nginx proxy.

Baakidhku waxa uu gaadhay dheelli-hayaha L3. Si loo maro marin sax ah gudaha xarunta xogta, baqshadda waxaa lagu duubay tunnel waxaana loo diraa kaarka shabakadda.
Maadaama baakidhka + tunnel-ka madaxyada aysan ku habooneyn MTU, baakidhka waa la gooyaa jajab waxaana loo diraa shabakada.
Bedelka ka dambeeya dheelitiriyaha L3, marka la helayo xirmo, wuxuu ku daraa summada Vlan oo u soo diraa.
Beddelka hore ee wakiilka Nginx wuxuu arkayaa (oo ku saleysan goobaha dekedaha) in server-ku uu filayo xirmo Vlan-xiran, sidaa darteed waxay u dirtaa sida ay tahay, iyada oo aan meesha laga saarin Vlan tag.
Linux waxay qaadataa jajabyo baakado gaar ah waxayna ku daraa hal xirmo oo weyn.
Marka xigta, baakidhku wuxuu gaaraa Vlan interface, halkaas oo lakabka ugu horreeya laga saaro - Vlan encapsulation.
Linux ka dib waxay u dirtaa interface Tunnel, halkaasoo lakab kale laga saaray - Tunnel encapsulation.

Dhibtu waa in waxaas oo dhan loo gudbiyo tcpdump.
Aan ka bilowno dhamaadka: ma jiraan nadiif ah (aan lahayn madax aan loo baahnayn) xirmooyinka IP ee macaamiisha, oo leh vlan iyo tunnel-ka daboolka laga saaray?

tcpdump host <ip клиента>

Maya, ma jiraan baakadahan oo kale server-ka Markaa dhibaatadu waa inay mar hore jirtaa. Ma jiraan wax baakado ah oo la saaray Vlan oo keliya?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx waa cinwaanka IP macmiilka oo qaab hex ah.
32:4 - cinwaanka iyo dhererka goobta uu SCR IP ku qoran yahay xirmada Tunnel-ka.

Ciwaanka goobta waa in lagu doortaa si xoog ah, maadaama internetka ay ku qoraan 40, 44, 50, 54, laakiin ma jirin ciwaanka IP-ga halkaas. Waxaad sidoo kale eegi kartaa mid ka mid ah xirmooyinka hex (-xx ama -XX parameter in tcpdump) oo aad xisaabi kartaa ciwaanka IP-ga ee aad taqaano.

Ma jiraan jajabyo baakidh ah oo aan Vlan iyo Tunnel-ka-xidhka laga saarin?

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Sixirkani wuxuu ina tusi doonaa dhammaan jajabyada, oo uu ku jiro kan ugu dambeeya. Malaha, wax la mid ah waxaa lagu sifeyn karaa IP, laakiin ma isku dayin, sababtoo ah ma jiraan baakado badan oo noocaas ah, iyo kuwa aan u baahanahay ayaa si fudud loo helay socodka guud. Waa kuwan:

14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0, flags [+], proto IPIP (4), length 1500) 11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 1500) 33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], length 1448 0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A.... 0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8} 0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 [email protected]. 0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@.. 0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W....... 0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....jEx 0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if..MM.*........

14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480, flags [none], proto IPIP (4), length 40) 11.11.11.11 > 22.22.22.22: ip-proto-4 0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A.... 0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8} 0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C 0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q 0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............

Kuwani waa laba jajab oo hal xirmo ah (isku aqoonsi 53652) oo sawir leh (ereyga Exif ayaa ka muuqda xirmada koowaad). Sababtoo ah xaqiiqda ah in ay jiraan baakado heerkan ah, laakiin aan ku jirin qaabka la isku daray ee qashinka, dhibaatadu waxay si cad u tahay golaha. Ugu dambeyntii waxaa jira caddayn dokumenti ah oo tan ah!

Furaha baakaduhu ma muujin wax dhibaato ah oo ka hortagaysa dhismaha. Isku day halkan: hpd.gasmi.net. Marka hore, marka aad isku daydo inaad wax ku shubto halkaas, furaha ma jecla qaabka xirmada. Waxaa soo baxday in ay jiraan xoogaa laba octets dheeraad ah oo u dhexeeya Srcmac iyo Ethertype (aan la xiriirin macluumaadka jajabka). Ka dib markii ay ka saareen, furaha ayaa bilaabay inuu shaqeeyo. Si kastaba ha ahaatee, ma muujin wax dhibaato ah.
Wax kasta oo la odhan karo, wax kale lama helin marka laga reebo kuwa Sysctl. Waxa hadhay oo dhan waxay ahayd in la helo hab lagu aqoonsado server-yada dhibka leh si loo fahmo miisaanka oo go'aan looga gaadho tallaabooyin dheeraad ah. Miisaanka loo baahan yahay si dhakhso leh ayaa loo helay:

netstat -s | grep "packet reassembles failed”

Sidoo kale waxay ku jirtaa snmpd ee hoos timaada OID=1.3.6.1.2.1.4.31.1.1.16.1 (ipSystemStatsReasmFails).

"Tirada guuldarrooyinka uu ogaaday IP-ga dib-u-ururinta algorithm (sabab kasta ha noqotee: waqti go'an, khaladaad, iwm.)."

Kooxda server-yada ah ee dhibaatada lagu daraaseeyay, laba ka mid ah miiskan ayaa si degdeg ah u kordhay, laba si tartiib ah, iyo laba kale oo aan kor u qaadin innaba. Isbarbardhigga dhaq-dhaqaaqa counter-gan iyo firfircoonida khaladaadka HTTP ee server-ka Java ayaa daaha ka qaaday xiriir. Taasi waa, mitirka waa la ilaalin karaa.

Lahaanshaha tilmaame lagu kalsoonaan karo oo dhibaatooyinka aad ayay muhiim u tahay si aad si sax ah u go'aamin karto in dib-u-soo-celinta Sysctl ay ku caawinayso, maadaama sheekadii hore aan ognahay inaan tan isla markiiba laga fahmi karin codsiga. Tilmaamahani wuxuu noo ogolaanayaa inaan aqoonsanno dhammaan meelaha dhibaatooyinka ah ee wax soo saarka ka hor intaan isticmaalayaashu ogaanin.
Ka dib markii dib loo rogo Sysctl, khaladaadka la socodka ayaa istaagay, sidaas darteed sababta dhibaatooyinka ayaa la xaqiijiyay, iyo sidoo kale xaqiiqda ah in dib-u-celinta ay caawiso.

Waxaan dib u soo celinay jaangooyooyinkii kala qaybinta ee server-yada kale, halkaas oo kormeer cusub uu soo galay, iyo meel aan u qoondeynay xitaa xasuus ka badan jajabkii markii hore (tani waxay ahayd tirakoobka UDP, khasaaraha qayb ka mid ah kaas oo aan laga dareemin asalka guud) .

Su'aalaha ugu muhiimsan

Waa maxay sababta baakidhyadu u kala qaybsan yihiin miisaan-hayahayada L3? Badi xirmooyinka ka yimaada isticmaalayaasha ilaa xisaabiyeyaasha waa SYN iyo ACK. Cabbirrada xirmooyinkani waa yar yihiin. Laakiin tan iyo saamiga xirmooyinka noocan oo kale ah waa mid aad u ballaaran, oo ka soo horjeeda asalkooda ma aanan ogaanin joogitaanka baakidhyo waaweyn oo bilaabay inay jajabaan.

Sababtu waxay ahayd qoraalka qaabeynta oo jabay advmss server-yada leh Vlan interfaces (waxaa jiray adeegayaal aad u yar oo leh taraafikada wax soo saarka wakhtigaas). Advmss waxa ay noo ogolanaysaa in aan u gudbino macmiilka macluumaadka baakooyinka jihadayada ku jira waa in ay ahaadaan kuwo ka yar cabbirkooda si ka dib marka lagu xidho madaxyada tunnel-ka iyaga oo aan u baahnayn in la kala qaybiyo.

Waa maxay sababta dib-u-soo-celinta Sysctl ay u caawin weyday, laakiin dib-u-billowgu u sameeyay? Dib-u-soo-celinta Sysctl waxay beddeshay qaddarka xusuusta ee loo heli karo isku-darka xirmooyinka. Isla mar ahaantaana, sida muuqata xaqiiqda dhabta ah ee xusuusta xad dhaafka ah ee jajabku waxay keentay hoos u dhaca isku xirka, taas oo keentay in jajabku dib u dhigo wakhti dheer oo safka ah. Taasi waa, geeddi-socodku wuxuu ku socday wareegyo.
Dib-u-bilaabista ayaa nadiifisay xusuusta wax walbana waxay ku soo noqdeen nidaam.

Suurtagal ma ahayd in la sameeyo Workaround la'aan? Haa, laakiin waxaa jirta khatar sare oo ah in laga tago isticmaalayaasha adeeg la'aan haddii ay dhacdo weerar. Dabcan, isticmaalka Workaround waxay keentay dhibaatooyin kala duwan, oo ay ku jiraan hoos u dhaca mid ka mid ah adeegyada loogu talagalay dadka isticmaala, laakiin si kastaba ha ahaatee, waxaan aaminsanahay in ficilladu ay ahaayeen kuwo xaq ah.

Waad ku mahadsan tahay Andrey Timofeev (atimofeyevCaawinta samaynta baaritaanka, iyo sidoo kale Alexey Krenev (qalabx) - shaqada titanic ee cusboonaysiinta Centos iyo kernels ee server-yada. Hannaan ay xaaladdan oo kale ahayd in laga bilaabo bilawga dhawr jeer, taasina waa sababta ay soo jiitamaysay bilo badan.

Source: www.habr.com

Ka digtoonow baylahda keenaysa wareegyada shaqada. Qaybta 1: FragmentSmack/SegmentSmack