🥇 Hattara da raunin da ke kawo zagayen aiki. Kashi na 1: FragmentSmack/SegmentSmack

Sannu duka! Sunana Dmitry Samsonov, Ina aiki a matsayin babban mai kula da tsarin a Odnoklassniki. Muna da sabobin jiki sama da dubu 7, kwantena dubu 11 a cikin gajimarenmu da aikace-aikacen 200, waɗanda a cikin tsari daban-daban suna samar da gungu daban-daban na 700. Yawancin sabobin suna gudanar da CentOS 7.
A kan Agusta 14, 2018, an buga bayani game da raunin FragmentSmack
(CVE-2018-5391da SegmentSmack (CVE-2018-5390). Waɗannan lahani ne tare da vector harin cibiyar sadarwa da babban maki (7.5), wanda ke barazanar kin sabis (DoS) saboda gajiyar albarkatu (CPU). Ba a gabatar da gyaran kernel don FragmentSmack ba a wancan lokacin; haka ma, ya fito da yawa fiye da buga bayanai game da raunin. Don kawar da SegmentSmack, an ba da shawarar sabunta kwaya. Kunshin sabuntawa da kansa an sake shi a wannan rana, abin da ya rage shine shigar da shi.
A'a, ba ma adawa da sabunta kwaya kwata-kwata! Duk da haka, akwai nuances ...

Yadda muke sabunta kwaya akan samarwa

Gabaɗaya, babu wani abu mai rikitarwa:

Zazzage fakitin;
Shigar da su a kan adadin sabobin (ciki har da sabar da ke ɗaukar girgijenmu);
Tabbatar cewa babu abin da ya karye;
Tabbatar cewa ana amfani da duk daidaitattun saitunan kwaya ba tare da kurakurai ba;
Jira 'yan kwanaki;
Duba aikin uwar garken;
Canja tura sabbin sabobin zuwa sabuwar kwaya;
Sabunta duk sabar ta cibiyar bayanai (cibiyar bayanai ɗaya lokaci guda don rage tasirin masu amfani idan akwai matsaloli);
Sake kunna duk sabobin.

Maimaita duk rassan kernels da muke da su. A halin yanzu shi ne:

Stock CentOS 7 3.10 - don yawancin sabobin yau da kullun;
Vanilla 4.19 - don namu gizagizai guda daya, saboda muna buƙatar BFQ, BBR, da dai sauransu;
Elrepo kwaya-ml 5.2 - don masu rabawa masu kayatarwa sosai, saboda 4.19 ya kasance yana nuna rashin kwanciyar hankali, amma ana buƙatar fasali iri ɗaya.

Kamar yadda kuke tsammani, sake kunna dubban sabobin yana ɗaukar lokaci mafi tsayi. Tun da ba duk rashin lahani ne ke da mahimmanci ga duk sabar ba, muna sake kunna waɗanda ke kai tsaye daga Intanet. A cikin gajimare, don kar a iyakance sassauci, ba mu ɗaure kwantena masu isa zuwa waje zuwa sabobin kowane mutum tare da sabon kernel, amma sake kunna duk runduna ba tare da togiya ba. Abin farin ciki, hanyar da ke akwai ya fi sauƙi fiye da sabobin na yau da kullum. Misali, kwantena marasa jiha suna iya matsawa kawai zuwa wani uwar garken yayin sake yi.

Koyaya, har yanzu akwai aiki da yawa, kuma yana iya ɗaukar makonni da yawa, kuma idan akwai wasu matsaloli tare da sabon sigar, har zuwa watanni da yawa. Maharan sun fahimci wannan sosai, don haka suna buƙatar shirin B.

FragmentSmack/SegmentSmack. Aiki

Abin farin ciki, ga wasu raunin irin wannan shirin B yana wanzu, kuma ana kiran shi Workaround. Mafi sau da yawa, wannan canji ne a cikin saitunan kwaya/ aikace-aikace wanda zai iya rage tasirin yiwuwar ko kawar da cin gajiyar rashin ƙarfi gaba ɗaya.

A cikin yanayin FragmentSmack/SegmentSmack aka gabatar wannan Aiki:

«Kuna iya canza tsoffin dabi'u na 4MB da 3MB a cikin net.ipv4.ipfrag_high_thresh da net.ipv4.ipfrag_low_thresh (da takwarorinsu na ipv6 net.ipv6.ipfrag_high_thresh da net.ipv6.ipfrag_low_thresh) zuwa 256 kB192 kB kasa. Gwaje-gwaje suna nuna ƙanƙanta zuwa mahimmin faɗuwa a cikin amfani da CPU yayin harin ya danganta da hardware, saituna, da yanayi. Koyaya, ana iya samun wasu tasirin aiki saboda ipfrag_high_thresh=262144 bytes, tun da gutsuttsura 64K guda biyu kawai zasu iya shiga jerin gwano a lokaci guda. Misali, akwai haɗarin cewa aikace-aikacen da ke aiki tare da manyan fakitin UDP zasu karye".

Siffofin da kansu a cikin takardun kernel ya bayyana kamar haka:

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.

Ba mu da manyan UDPs akan ayyukan samarwa. Babu rarrabuwar zirga-zirga akan LAN; akwai rarrabuwar zirga-zirga akan WAN, amma ba mahimmanci ba. Babu alamun - zaku iya fitar da Workaround!

FragmentSmack/SegmentSmack. Jini na farko

Matsala ta farko da muka ci karo da ita ita ce, akwatunan gajimare wasu lokuta suna amfani da sabbin saitunan kawai a wani bangare (kawai ipfrag_low_thresh), kuma wani lokacin ba sa amfani da su kwata-kwata - kawai sun fadi a farkon. Ba zai yiwu a sake haifar da matsalar ba (duk saituna an yi amfani da su da hannu ba tare da wata wahala ba). Fahimtar dalilin da yasa kwantena ya yi karo a farkon kuma ba shi da sauƙi: ba a sami kurakurai ba. Abu ɗaya ya tabbata: mayar da saitunan yana warware matsalar tare da faɗuwar akwati.

Me yasa bai isa a yi amfani da Sysctl akan mai watsa shiri ba? Kwantena yana zaune a cikin sadaukarwar cibiyar sadarwar Namespace, don haka aƙalla wani ɓangare na saitunan Sysctl na cibiyar sadarwa a cikin akwati na iya bambanta da mai gida.

Yaya daidai ake amfani da saitunan Sysctl a cikin akwati? Tunda kwantenanmu ba su da gata, ba za ku iya canza kowane saitin Sysctl ta shiga cikin kwantena da kanta ba - kawai ba ku da isassun haƙƙoƙi. Don gudanar da kwantena, girgijen mu a wancan lokacin yana amfani da Docker (yanzu podman). An wuce sigogin sabon akwati zuwa Docker ta API, gami da saitunan Sysctl masu mahimmanci.
Yayin binciken nau'ikan, ya juya cewa Docker API bai dawo da duk kurakurai ba (aƙalla a cikin sigar 1.10). Lokacin da muka yi ƙoƙarin fara kwandon ta hanyar "docker run", a ƙarshe mun ga aƙalla wani abu:

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.

Ƙimar siga ba ta aiki. Amma me ya sa? Kuma me yasa ba ya aiki kawai wani lokaci? Ya bayyana cewa Docker baya bada garantin tsarin da ake amfani da sigogi na Sysctl (sabuwar sigar da aka gwada ita ce 1.13.1), don haka wani lokacin ipfrag_high_thresh yayi ƙoƙarin saita shi zuwa 256K lokacin da ipfrag_low_thresh ya kasance 3M, wato, babban iyaka ya kasance ƙasa. fiye da ƙananan iyaka, wanda ya haifar da kuskure.

A wancan lokacin, mun riga mun yi amfani da namu tsarin don sake saita akwati bayan farawa (daskare akwati bayan kungiyar injin daskarewa da aiwatar da umarni a cikin sunan wurin kwantena ta hanyar ip netns), kuma mun ƙara rubuta sigogin Sysctl zuwa wannan ɓangaren. An magance matsalar.

FragmentSmack/SegmentSmack. Jinin Farko 2

Kafin mu sami lokaci don fahimtar amfani da Workaround a cikin gajimare, ƙananan gunaguni na farko daga masu amfani sun fara isa. A wancan lokacin, makonni da yawa sun shude tun farkon amfani da Workaround akan sabar farko. Binciken farko ya nuna cewa an karɓi korafe-korafe game da sabis na ɗaiɗaikun, kuma ba duka sabobin waɗannan ayyukan ba. Matsalar ta sake zama marar tabbas.

Da farko, ba shakka, mun yi ƙoƙarin mayar da saitunan Sysctl, amma wannan bai yi wani tasiri ba. Hanyoyi daban-daban tare da uwar garken da saitunan aikace-aikacen ba su taimaka ba. Sake yi ya taimaka. Sake kunna Linux bai dace ba kamar yadda aka saba don Windows a zamanin da. Duk da haka, ya taimaka, kuma mun lissafta shi har zuwa "kyakkyawan kernel" lokacin amfani da sababbin saituna a Sysctl. Yadda abin ya kasance mai ban tsoro...

Bayan makonni uku matsalar ta sake faruwa. Tsarin waɗannan sabobin ya kasance mai sauqi qwarai: Nginx a cikin yanayin wakili/ma'auni. Babu yawan zirga-zirga. Sabuwar bayanin gabatarwa: adadin kurakurai 504 akan abokan ciniki yana karuwa kowace rana (Lokacin Ƙofar Ƙofar). Hoton yana nuna adadin kurakurai 504 kowace rana don wannan sabis ɗin:

Duk kurakuran sun kasance kusan ƙarshen baya ɗaya - game da wanda ke cikin gajimare. Jadawalin amfani da ƙwaƙwalwar ajiya don guntuwar fakitin akan wannan bangon baya yayi kama da haka:

Wannan yana ɗaya daga cikin fitattun abubuwan da ke bayyana matsala a cikin jadawali na tsarin aiki. A cikin gajimare, kawai a lokaci guda, an gyara wata matsalar hanyar sadarwa tare da saitunan QoS (Ikon Traffic). A kan jadawali na amfani da ƙwaƙwalwar ajiya don guntun fakiti, yayi kama da haka:

Zaton ya kasance mai sauƙi: idan sun dubi iri ɗaya akan jadawali, to suna da dalili guda. Bugu da ƙari, duk wata matsala tare da irin wannan ƙwaƙwalwar ajiya ba ta da yawa.

Ma'anar ƙayyadaddun matsalar ita ce mun yi amfani da tsarin fakitin fq tare da saitunan tsoho a cikin QoS. Ta hanyar tsoho, don haɗi ɗaya, yana ba ku damar ƙara fakiti 100 zuwa jerin gwano, kuma wasu haɗin gwiwa, a cikin yanayin ƙarancin tashar, sun fara toshe layin zuwa iya aiki. A wannan yanayin, ana jefa fakiti. A cikin ƙididdigar tc (tc -s qdisc) ana iya gani kamar haka:

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

"464545 flows_plimit" shine fakitin da aka sauke saboda wuce iyaka na haɗin haɗin gwiwa, kuma "saukar da 464545" shine jimlar duk fakitin da aka sauke na wannan tsararru. Bayan ƙara tsawon layin zuwa dubu 1 kuma an sake kunna kwantena, matsalar ta daina faruwa. Kuna iya komawa baya ku sha mai santsi.

FragmentSmack/SegmentSmack. Jinin Karshe

Da fari dai, watanni da yawa bayan sanarwar rashin ƙarfi a cikin kwaya, gyara don FragmentSmack a ƙarshe ya bayyana (bari in tunatar da ku cewa tare da sanarwar a watan Agusta, an sake gyara kawai don SegmentSmack), wanda ya ba mu damar barin Workaround. wanda ya jawo mana matsala sosai. A wannan lokacin, mun riga mun sami damar canja wurin wasu sabobin zuwa sabon kernel, kuma yanzu dole ne mu fara daga farko. Me yasa muka sabunta kwaya ba tare da jiran gyaran FragmentSmack ba? Gaskiyar ita ce, tsarin kariya daga waɗannan raunin ya zo daidai (da kuma haɗuwa) tare da tsarin sabunta CentOS kanta (wanda ke ɗaukar lokaci fiye da sabunta kwaya kawai). Bugu da ƙari, SegmentSmack shine mafi haɗari mai haɗari, kuma gyara shi ya bayyana nan da nan, don haka yana da ma'ana ta wata hanya. Koyaya, ba za mu iya kawai sabunta kwaya akan CentOS ba saboda raunin FragmentSmack, wanda ya bayyana yayin CentOS 7.5, an daidaita shi a cikin sigar 7.6 kawai, don haka dole ne mu dakatar da sabuntawa zuwa 7.5 kuma mu sake farawa tare da sabuntawa zuwa 7.6. Kuma wannan ma yana faruwa.

Na biyu, korafe-korafen masu amfani game da matsaloli sun dawo mana. Yanzu mun riga mun san tabbas cewa duk suna da alaƙa da loda fayiloli daga abokan ciniki zuwa wasu sabar mu. Bugu da ƙari, ƙananan adadin abubuwan da aka ɗorawa daga jimlar taro sun shiga cikin waɗannan sabobin.

Kamar yadda muke tunawa daga labarin da ke sama, juya baya Sysctl bai taimaka ba. Sake yi ya taimaka, amma na ɗan lokaci.
Ba a cire zato game da Sysctl ba, amma wannan lokacin ya zama dole don tattara bayanai da yawa kamar yadda zai yiwu. Haka kuma an sami ƙarancin ikon sake haifar da matsalar ɗorawa akan abokin ciniki don yin nazarin ainihin abin da ke faruwa.

Binciken duk kididdigar da ake da su da kuma gundumomi bai kawo mana kusa da fahimtar abin da ke faruwa ba. Akwai ƙarancin ikon sake haifar da matsalar don "ji" takamammen haɗin gwiwa. A ƙarshe, masu haɓakawa, ta yin amfani da sigar musamman ta aikace-aikacen, sun sami damar cimma daidaiton haifuwa na matsaloli akan na'urar gwaji lokacin da aka haɗa ta Wi-Fi. Wannan ci gaba ne a cikin binciken. Abokin ciniki ya haɗa da Nginx, wanda ke wakiltar baya, wanda shine aikace-aikacen mu na Java.

Tattaunawar don matsalolin ta kasance kamar haka (kafaffen a gefen wakili na Nginx):

Abokin ciniki: buƙatar karɓar bayani game da zazzage fayil.
Sabar Java: amsawa.
Abokin ciniki: POST tare da fayil.
uwar garken Java: kuskure.

A lokaci guda, uwar garken Java ta rubuta wa log ɗin cewa an karɓi 0 bytes na bayanai daga abokin ciniki, kuma wakilin Nginx ya rubuta cewa buƙatar ta ɗauki fiye da daƙiƙa 30 (daƙiƙa 30 shine lokacin ƙarewar aikace-aikacen abokin ciniki). Me yasa lokaci ya ƙare kuma me yasa 0 bytes? Daga mahallin HTTP, komai yana aiki kamar yadda ya kamata, amma POST tare da fayil ɗin da alama yana ɓacewa daga hanyar sadarwar. Bugu da ƙari, yana ɓacewa tsakanin abokin ciniki da Nginx. Lokaci ya yi da za ku ɗora wa kanku da Tcpdump! Amma da farko kuna buƙatar fahimtar tsarin hanyar sadarwa. Nginx wakili yana bayan ma'auni na L3 NFware. Ana amfani da tunneling don sadar da fakiti daga ma'auni na L3 zuwa uwar garken, wanda ke ƙara masu kai zuwa fakiti:

A wannan yanayin, hanyar sadarwar ta zo zuwa wannan uwar garke a cikin hanyar zirga-zirgar Vlan-tagged, wanda kuma yana ƙara filayen nasa zuwa fakiti:

Hakanan ana iya rarraba wannan zirga-zirgar (waɗannan ƙananan kaso na ɓarkewar zirga-zirgar ababen hawa waɗanda muka yi magana game da su lokacin tantance haɗari daga Workaround), wanda kuma yana canza abun cikin masu kai:

Har yanzu: fakiti an lullube su da alamar Vlan, an lullube su da rami, rarrabuwa. Don ƙarin fahimtar yadda hakan ke faruwa, bari mu nemo hanyar fakiti daga abokin ciniki zuwa wakili na Nginx.

Fakitin ya kai madaidaicin L3. Don ingantacciyar hanya tsakanin cibiyar bayanai, fakitin an lullube shi a cikin rami kuma a aika zuwa katin sadarwar.
Tun da fakitin + tunnel headers ba su dace da MTU ba, an yanke fakitin zuwa guntu kuma a aika zuwa cibiyar sadarwa.
Sauyawa bayan ma'aunin L3, lokacin karɓar fakiti, yana ƙara alamar Vlan zuwa gare shi kuma ya aika shi.
Canjin da ke gaban wakili na Nginx yana gani (dangane da saitunan tashar jiragen ruwa) cewa uwar garken yana tsammanin fakitin Vlan-encapsulated, don haka yana aika shi kamar yadda yake, ba tare da cire alamar Vlan ba.
Linux yana ɗaukar guntuwar fakiti guda ɗaya yana haɗa su cikin babban fakiti ɗaya.
Bayan haka, fakitin ya isa wurin dubawa na Vlan, inda aka cire Layer na farko daga gare ta - Vlan encapsulation.
Linux sai ta aika da shi zuwa ga Tunnel interface, inda aka cire wani Layer daga gare ta - Tunnel encapsulation.

Wahalar ita ce wuce duk wannan azaman sigogi zuwa tcpdump.
Bari mu fara daga ƙarshe: shin akwai tsabta (ba tare da buƙatun kai ba) fakitin IP daga abokan ciniki, tare da cire ɓoyayyen vlan da rami?

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

A'a, babu irin waɗannan fakiti akan sabar. Don haka dole ne matsalar ta kasance a baya. Shin akwai fakiti waɗanda aka cire murfin Vlan kawai?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx shine adireshin IP na abokin ciniki a tsarin hex.
32:4 - adireshi da tsawon filin da aka rubuta SCR IP a cikin fakitin Tunnel.

Dole ne a zaɓi adireshin filin da ƙarfi, tunda akan Intanet suna rubuta kusan 40, 44, 50, 54, amma babu adireshin IP a wurin. Hakanan zaka iya duba ɗaya daga cikin fakiti a hex (madaidaicin -xx ko -XX a tcpdump) kuma ƙididdige adireshin IP ɗin da kuka sani.

Shin akwai guntun fakiti ba tare da cire murfin Vlan da Tunnel ba?

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Wannan sihirin zai nuna mana dukkan ɓangarorin, gami da na ƙarshe. Wataƙila, ana iya tace abu iri ɗaya ta hanyar IP, amma ban gwada ba, saboda babu irin waɗannan fakiti masu yawa, kuma waɗanda nake buƙata ana samun sauƙin samu a cikin gabaɗaya. Ga su:

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 ..............

Waɗannan gutsure guda biyu ne na fakiti ɗaya (ID guda 53652) tare da hoto (kalmar Exif tana bayyane a fakitin farko). Saboda gaskiyar cewa akwai fakiti a wannan matakin, amma ba a cikin hanyar da aka haɗa a cikin jujjuya ba, matsalar ta fito fili tare da taron. A ƙarshe akwai shaidun shaida na wannan!

Mai rikodin fakitin bai bayyana kowace matsala da za ta hana ginin ba. Gwada shi a nan: hpd.gasmi.net. Da farko, lokacin da kuke ƙoƙarin cusa wani abu a wurin, mai gyara ba ya son tsarin fakiti. Ya juya cewa akwai wasu karin octets biyu tsakanin Srcmac da Ethertype (ba su da alaƙa da bayanin guntu). Bayan cire su, dikodi ya fara aiki. Duk da haka, bai nuna matsala ba.
Duk abin da mutum zai iya faɗi, ba a sami wani abu ba sai waɗannan Sysctl. Abin da ya rage shi ne nemo hanyar gano uwar garken matsala don fahimtar ma'auni da yanke shawara kan ƙarin ayyuka. An gano ma'aunin da ake buƙata cikin sauri:

netstat -s | grep "packet reassembles failed”

Hakanan yana cikin snmpd ƙarƙashin OID=1.3.6.1.2.1.4.31.1.1.16.1 (ipSystemStatsReasmFails).

"Yawancin gazawar da aka gano ta hanyar haɗin gwiwar IP na algorithm (saboda kowane dalili: lokacin da ya ƙare, kurakurai, da sauransu)."

Daga cikin rukunin uwar garken da aka yi nazarin matsalar a kansu, a kan biyu wannan na'ura ya karu da sauri, a kan biyu kuma a hankali, kuma a kan wasu biyu bai karu ba ko kadan. Kwatanta sauye-sauye na wannan ma'aunin tare da kuzarin kurakuran HTTP akan uwar garken Java ya nuna alaƙa. Wato ana iya sa ido akan mita.

Samun tabbataccen alamar matsalolin yana da matukar mahimmanci don ku iya tantance daidai ko mirgina Sysctl yana taimakawa, tunda daga labarin da ya gabata mun san cewa ba za a iya fahimtar hakan nan da nan daga aikace-aikacen ba. Wannan alamar za ta ba mu damar gano duk wuraren matsala a cikin samarwa kafin masu amfani su gano shi.
Bayan jujjuya baya Sysctl, kurakurai na saka idanu sun tsaya, don haka an tabbatar da dalilin matsalolin, da kuma gaskiyar cewa juyawa yana taimakawa.

Mun mayar da saitunan rarrabuwar kawuna akan wasu sabobin, inda sabon sa ido ya shigo cikin wasa, kuma wani wuri mun ba da ƙarin ƙwaƙwalwar ajiya don gutsuttsura fiye da yadda aka saba a baya (wannan ƙididdigar UDP ce, asarar ɓangaren wanda ba a san shi ba gaba ɗaya). .

Tambayoyi mafi mahimmanci

Me yasa fakiti suka rabu akan ma'aunin mu na L3? Yawancin fakitin da ke zuwa daga masu amfani zuwa masu daidaitawa sune SYN da ACK. Girman waɗannan fakiti ƙanana ne. Amma da yake rabon irin waɗannan fakitin yana da girma sosai, ba mu lura da kasancewar manyan fakitin da suka fara wargajewa ba.

Dalili kuwa shi ne karyewar rubutun sanyi advmss akan sabobin masu mu'amalar Vlan (akwai 'yan sabobin da ke da alamar zirga-zirga a cikin samarwa a wancan lokacin). Advmss yana ba mu damar isar da wa abokin ciniki bayanin cewa fakitin da ke cikin hanyarmu yakamata su kasance ƙanƙanta da girmansu ta yadda bayan liƙa maƙallan rami zuwa gare su ba sai an wargaje su ba.

Me yasa Sysctl rollback bai taimaka ba, amma sake yi ya yi? Juyawa baya Sysctl ya canza adadin ƙwaƙwalwar ajiya don haɗa fakiti. A lokaci guda kuma, a fili ainihin gaskiyar ƙwaƙwalwar ajiya don ɓarke ya haifar da raguwar haɗin gwiwa, wanda ya haifar da jinkirin guntuwar na dogon lokaci a cikin jerin gwano. Wato, tsarin ya tafi cikin hawan keke.
Sake yi ya share ƙwaƙwalwar kuma komai ya koma kan tsari.

Shin zai yiwu a yi ba tare da Workaround ba? Ee, amma akwai babban haɗari na barin masu amfani ba tare da sabis ba a yayin harin. Tabbas, yin amfani da Workaround ya haifar da matsaloli daban-daban, gami da raguwar ɗayan sabis don masu amfani, amma duk da haka mun yi imanin cewa ayyukan sun dace.

Godiya ga Andrey Timofeev (atimofeyev) don taimakawa wajen gudanar da bincike, da kuma Alexey Krenev (na'urax) - don aikin titanic na sabunta Centos da kernels akan sabobin. Tsarin da a cikin wannan yanayin dole ne a fara shi daga farkon sau da yawa, wanda shine dalilin da ya sa ya ci gaba har tsawon watanni.

source: www.habr.com

Yi hankali da raunin da ke kawo zagaye na aiki. Kashi na 1: FragmentSmack/SegmentSmack