🥇Qaphela ukukhubazeka okuletha imijikelezo yomsebenzi. Ingxenye 1: I-FragmentSmack/SegmentSmack

Sanibonani nonke! Igama lami nginguDmitry Samsonov, ngisebenza njengomphathi wesistimu oholayo e-Odnoklassniki. Sinamaseva angaphezu kwezinkulungwane eziyisi-7, iziqukathi eziyizinkulungwane eziyi-11 efwini lethu kanye nezinhlelo zokusebenza ezingama-200, okuthi ngokulungiselelwa okuhlukahlukene kwakhe amaqoqo ahlukene angama-700. Iningi lamaseva asebenzisa i-CentOS 7.
Ngomhla ka-Agasti 14, 2018, ulwazi olumayelana nokuba sengozini kwe-FragmentSmack lushicilelwe
(I-CVE-2018-5391) kanye ne-SegmentSmack (I-CVE-2018-5390). Lokhu ubungozi obune-vector yokuhlasela kwenethiwekhi kanye nesikolo esiphezulu (7.5), esisongela ukwenqatshwa kwesevisi (DoS) ngenxa yokuphela kwensiza (CPU). Ukulungiswa kwe-kernel ye-FragmentSmack akuzange kuphakanyiswe ngaleso sikhathi; ngaphezu kwalokho, kuphume kamuva kakhulu kunokushicilelwa kolwazi mayelana nokuba sengozini. Ukuze kuqedwe i-SegmentSmack, kuphakanyiswe ukuthi kubuyekezwe i-kernel. Iphakheji yokuvuselela ngokwayo yakhululwa ngosuku olufanayo, okwakusele nje ukuyifaka.
Cha, asimelene nokubuyekeza i-kernel nhlobo! Nokho, kukhona ama-nuances ...

Siyibuyekeza kanjani i-kernel ekukhiqizeni

Ngokuvamile, akukho lutho oluyinkimbinkimbi:

Landa amaphakheji;
Zifake kumaseva amaningi (okuhlanganisa namaseva abamba ifu lethu);
Qinisekisa ukuthi akukho lutho oluphukile;
Qiniseka ukuthi zonke izilungiselelo ezijwayelekile ze-kernel zisetshenziswa ngaphandle kwamaphutha;
Linda izinsuku ezimbalwa;
Hlola ukusebenza kweseva;
Shintsha ukuthunyelwa kwamaseva amasha ku-kernel entsha;
Buyekeza wonke amaseva ngesikhungo sedatha (isikhungo sedatha esisodwa ngesikhathi ukuze unciphise umthelela kubasebenzisi uma kuba nezinkinga);
Qalisa kabusha wonke amaseva.

Phinda kuwo wonke amagatsha ezinhlamvu esinazo. Okwamanje ithi:

I-Stock CentOS 7 3.10 - kumaseva amaningi avamile;
I-Vanilla 4.19 - eyethu amafu anefu elilodwa, ngoba sidinga i-BFQ, i-BBR, njll.;
I-Elrepo kernel-ml 5.2 - ye abasabalalisi abagcwele kakhulu, ngoba i-4.19 yayivame ukuziphatha ngendlela engazinzile, kodwa izici ezifanayo ziyadingeka.

Njengoba ungase uqagele, ukuqalisa kabusha izinkulungwane zamaseva kuthatha isikhathi eside kakhulu. Njengoba kungebona bonke ubungozi obubalulekile kuwo wonke amaseva, siqalisa kuphela lawo afinyeleleka ngokuqondile ku-inthanethi. Efwini, ukuze singakhawuleli ukuguquguquka, asibophi iziqukathi ezifinyeleleka ngaphandle kumaseva angawodwana nge-kernel entsha, kodwa qalisa kabusha bonke abasingathi ngaphandle kokukhetha. Ngenhlanhla, inqubo lapho ilula kunamaseva avamile. Isibonelo, iziqukathi ezingenaso isimo zingavele zithuthele kwenye iseva ngesikhathi sokuqalisa kabusha.

Nokho, kusenomsebenzi omningi, futhi kungathatha amasonto ambalwa, futhi uma kukhona izinkinga ngenguqulo entsha, kuze kufike ezinyangeni ezimbalwa. Abahlaseli bakuqonda kahle lokhu, ngakho badinga icebo B.

I-FragmentSmack/SegmentSmack. Indlela yokusebenza

Ngenhlanhla, kokunye ubungozi uhlelo olunjalo B lukhona, futhi lubizwa ngokuthi i-Workaround. Ezikhathini eziningi, lolu wushintsho kuzilungiselelo ze-kernel/uhlelo lokusebenza olunganciphisa umphumela ongaba khona noma lususe ngokuphelele ukuxhashazwa kobungozi.

Esimeni se-FragmentSmack/SegmentSmack kwahlongozwa Ukusebenza kanjena:

«Ungashintsha amanani azenzakalelayo we-4MB kanye ne-3MB ku-net.ipv4.ipfrag_high_thresh naku-net.ipv4.ipfrag_low_thresh (kanye nozakwabo be-ipv6 net.ipv6.ipfrag_high_thresh kanye net.ipv6.ipv256.ipfrag_ipfrag192 ukuya ku-262144 kBlow64 noma XNUMXkBlow) ngokulandelana) ngaphansi. Ukuhlola kubonisa ukwehla okuncane kuya kokubalulekile ekusetshenzisweni kwe-CPU ngesikhathi sokuhlasela kuye ngehadiwe, izilungiselelo, nezimo. Nokho, kungase kube nomthelela othile wokusebenza ngenxa ye-ipfrag_high_thresh=XNUMX bytes, njengoba izingcezu ezimbili kuphela ze-XNUMXK ezingangena kulayini wokuhlanganisa kabusha ngesikhathi. Isibonelo, kunobungozi bokuthi izinhlelo zokusebenza ezisebenza ngamaphakethe amakhulu e-UDP zizophuka".

Amapharamitha ngokwawo kumadokhumenti e-kernel kuchazwe kanje:

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.

Asinawo ama-UDP amakhulu ezinsizeni zokukhiqiza. Ayikho ithrafikhi ehlukanisiwe ku-LAN; kunethrafikhi ehlukanisiwe ku-WAN, kodwa ayibalulekile. Azikho izimpawu - ungakhipha i-Workaround!

I-FragmentSmack/SegmentSmack. Igazi lokuqala

Inkinga yokuqala esihlangabezane nayo ukuthi iziqukathi zamafu kwesinye isikhathi zisebenzisa izilungiselelo ezintsha kancane (kuphela ipfrag_low_thresh), futhi kwesinye isikhathi azizange ziwasebenzise nhlobo - avele aphahlazeka ekuqaleni. Akukwazanga ukukhiqiza kabusha inkinga ngokuzinza (zonke izilungiselelo zisetshenziswe mathupha ngaphandle kobunzima). Ukuqonda ukuthi kungani isiqukathi siphahlazeka ekuqaleni nakho akulula kangako: awekho amaphutha atholakele. Into eyodwa ibiqinisekile: ukubuyisela emuva izilungiselelo kuxazulula inkinga ngokuphahlazeka kwesiqukathi.

Kungani kunganele ukusebenzisa i-Sysctl kumsingathi? Isiqukathi sihlala kunethiwekhi yaso ezinikele ye-Namespace, ngakho-ke okungenani ingxenye yenethiwekhi ye-Systll parameters esitsheni kungase kuhluke kumsingathi.

Ngabe izilungiselelo ze-Systl zisetshenziswa kanjani ngempela esitsheni? Njengoba iziqukathi zethu zingenalo ilungelo, ngeke ukwazi ukushintsha noma yisiphi isilungiselelo se-Sysctl ngokungena esitsheni ngokwaso - awunawo amalungelo anele. Ukuze usebenzise iziqukathi, ifu lethu ngaleso sikhathi lalisebenzisa i-Docker (manje I-Podman). Amapharamitha esiqukathi esisha adluliselwe ku-Docker nge-API, okuhlanganisa nezilungiselelo ezidingekayo ze-Sysctl.
Ngenkathi kuseshwa izinguqulo, kwavela ukuthi i-Docker API ayizange ibuyise wonke amaphutha (okungenani kunguqulo 1.10). Lapho sizama ukuqala isitsha nge-"docker run", ekugcineni sibone okungenani okuthile:

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.

Inani lepharamitha alivumelekile. Kodwa kungani? Futhi kungani ingasebenzi ngezinye izikhathi kuphela? Kuvele ukuthi i-Docker ayiqinisekisi i-oda okusetshenziswa ngalo amapharamitha e-Sysctl (inguqulo yakamuva ehloliwe ngu-1.13.1), ngakho-ke ngezinye izikhathi i-ipfrag_high_thresh izame ukusethelwa ku-256K ngenkathi i-ipfrag_low_thresh isengu-3M, okungukuthi, umkhawulo ophezulu wawuphansi. kunomkhawulo ophansi, okuholele ephutheni.

Ngaleso sikhathi, sase sivele sasebenzisa indlela yethu yokulungisa kabusha isiqukathi ngemva kokuqala (ukuqandisa isiqukathi ngemva kwalokho ifriji yeqembu kanye nokwenza imiyalo endaweni yegama lesiqukathi nge ip inetha), futhi sengeze nemingcele yokubhala ye-Systl kule ngxenye. Inkinga yaxazululeka.

I-FragmentSmack/SegmentSmack. Igazi lokuqala 2

Ngaphambi kokuthi sibe nesikhathi sokuqonda ukusetshenziswa kwe-Workaround efwini, izikhalazo zokuqala ezingavamile ezivela kubasebenzisi zaqala ukufika. Ngaleso sikhathi, kwase kudlule amasonto ambalwa kusukela kuqale ukusebenzisa i-Workaround kumaseva okuqala. Uphenyo lokuqala lubonise ukuthi izikhalazo zatholwa ngamasevisi angawodwana, hhayi wonke amaseva alezi zinsizakalo. Inkinga isiphinde yaba nokungaqiniseki ngokwedlulele.

Okokuqala, thina, vele, sizamile ukuhlehlisa izilungiselelo ze-Systl, kodwa lokhu akuzange kube namphumela. Ukukhohlisa okuhlukahlukene ngeseva kanye nezilungiselelo zohlelo lokusebenza nazo azisizanga. Ukuqalisa kabusha kusizile. Ukuqalisa kabusha i-Linux akukhona okwemvelo njengoba kwakuvamile ku-Windows ezinsukwini zakudala. Kodwa-ke, isizile, futhi sayihlanganisa “ne-kernel glitch” lapho sisebenzisa izilungiselelo ezintsha ku-Sysctl. Kwakuwubuwula kanjani...

Ngemva kwamasonto amathathu inkinga yaphinda. Ukucushwa kwalawa maseva bekulula kakhulu: i-Nginx kumodi yommeleli/yebhalansi. Ithrafikhi eningi. Inothi elisha lesingeniso: inani lamaphutha angama-504 kumakhasimende liyanda nsuku zonke (I-Gateway Timeout). Igrafu ibonisa inani lamaphutha angu-504 ngosuku kule sevisi:

Wonke amaphutha amayelana ne-backend efanayo - mayelana nalelo esefwini. Igrafu yokusetshenziswa kwenkumbulo yezingcezwana zephakheji kulesi siphetho esingemuva ibukeke kanje:

Lokhu kungenye yezibonakaliso ezisobala kakhulu zenkinga kumagrafu wesistimu yokusebenza. Efwini, ngesikhathi esifanayo, enye inkinga yenethiwekhi enezilungiselelo ze-QoS (Traffic Control) yalungiswa. Kugrafu yokusetshenziswa kwenkumbulo yezingcezu zephakethe, ibukeke ifana ncamashi:

Ukucatshangelwa kwakulula: uma bebukeka befana kumagrafu, khona-ke banesizathu esifanayo. Ngaphezu kwalokho, noma yiziphi izinkinga ngalolu hlobo lwenkumbulo azivamile kakhulu.

Ingqikithi yenkinga elungisiwe yayiwukuthi sisebenzise isihleli sephakethe le-fq ngezilungiselelo ezizenzakalelayo ku-QoS. Ngokuzenzakalelayo, ekuxhumekeni okukodwa, kukuvumela ukuthi wengeze amaphakethe ayi-100 kulayini, futhi okunye ukuxhumana, ezimeni zokushoda kwesiteshi, kwaqala ukuvala ulayini kumthamo. Kulokhu, amaphakethe ayalahlwa. Kuzibalo ze-tc (tc -s qdisc) kungabonakala kanje:

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

I-“464545 flows_plimit” amaphakethe ehlisiwe ngenxa yokweqa umkhawulo womugqa woxhumano olulodwa, futhi “ukwehla okungu-464545” kuyisamba sawo wonke amaphakethe awisiwe alesi sihleli. Ngemva kokwandisa ubude bomugqa bufike ku-1 XNUMX futhi kuqalwe kabusha iziqukathi, inkinga yayeka ukwenzeka. Ungahlala uphuze i-smoothie.

I-FragmentSmack/SegmentSmack. Igazi Lokugcina

Okokuqala, ezinyangeni ezimbalwa ngemuva kokumenyezelwa kobungozi ku-kernel, ekugcineni kwavela ukulungiswa kwe-FragmentSmack (ake ngikukhumbuze ukuthi kanye nesimemezelo sika-Agasti, kwakhululwa ukulungiswa kwe-SegmentSmack kuphela), okusinikeze ithuba lokushiya i-Workaround, okwasibangela izinkinga eziningi. Ngalesi sikhathi, sase sikwazile ukudlulisa amanye amaseva ku-kernel entsha, futhi manje kwakudingeka siqale kusukela ekuqaleni. Kungani sibuyekeze i-kernel ngaphandle kokulinda ukulungiswa kwe-FragmentSmack? Iqiniso liwukuthi inqubo yokuvikela kulobu buthakathaka yaqondana (futhi yahlanganiswa) nenqubo yokubuyekeza i-CentOS ngokwayo (ethatha isikhathi esithe xaxa kunokubuyekeza i-kernel kuphela). Ngaphezu kwalokho, i-SegmentSmack iyingozi kakhulu, futhi ukulungiswa kwayo kwavela ngokushesha, ngakho kwaba nengqondo noma kunjalo. Kodwa-ke, asikwazanga ukumane sibuyekeze i-kernel ku-CentOS ngoba ukuba sengozini kwe-FragmentSmack, okuvele ngesikhathi se-CentOS 7.5, kwakulungiswe kuphela kunguqulo 7.6, ngakho-ke kudingeke ukuthi simise isibuyekezo ku-7.5 futhi siqale kabusha ngesibuyekezo ku-7.6. Futhi lokhu kuyenzeka.

Okwesibili, izikhalazo zabasebenzisi ezingavamile ngezinkinga zibuyele kithi. Manje sesiyazi ngokuqinisekile ukuthi zonke zihlobene nokulayishwa kwamafayela kusuka kumakhasimende kuya kwamanye amaseva ethu. Ngaphezu kwalokho, inani elincane kakhulu lokulayishwa kwesamba esiphelele lidlule kulawa maseva.

Njengoba sikhumbula endabeni engenhla, ukuhlehlisa i-Systll akuzange kusize. Ukuqalisa kabusha kusizile, kodwa okwesikhashana.
Izinsolo eziphathelene ne-Sysctl azizange zisuswe, kodwa kulokhu bekudingeka ukuthi kuqoqwe ulwazi oluningi ngangokunokwenzeka. Kuphinde kwaba nokuntula okukhulu kwekhono lokukhiqiza kabusha inkinga yokulayisha eklayentini ukuze lifunde ngokunembile ukuthi kwenzekani.

Ukuhlaziywa kwazo zonke izibalo ezitholakalayo namalogi akuzange kusisondeze ekuqondeni okwakwenzeka. Kube khona ukuntula okukhulu kwekhono lokukhiqiza kabusha inkinga ukuze "uzwe" uxhumano oluthile. Ekugcineni, abathuthukisi, besebenzisa inguqulo ekhethekile yohlelo lokusebenza, bakwazile ukuzuza ukukhiqiza kabusha okuzinzile kwezinkinga kudivayisi yokuhlola lapho kuxhunywe nge-Wi-Fi. Lokhu kube impumelelo ophenyweni. Iklayenti lixhumeke ku-Nginx, ebambele ku-backend, obekuwuhlelo lwethu lokusebenza lwe-Java.

Ingxoxo yezinkinga ibinjena (ilungiswe ohlangothini lommeleli we-Nginx):

Iklayenti: isicelo sokuthola ulwazi mayelana nokulanda ifayela.
Iseva ye-Java: impendulo.
Iklayenti: THUMELA ngefayela.
Iseva ye-Java: iphutha.

Ngesikhathi esifanayo, iseva ye-Java ibhalela ilogi ukuthi amabhayithi angu-0 edatha atholwe kuklayenti, futhi ummeleli we-Nginx ubhala ukuthi isicelo sithathe imizuzwana engaphezu kwe-30 (imizuzwana engu-30 yisikhathi sokuphelelwa yisikhathi sohlelo lokusebenza lweklayenti). Kungani isikhathi siphelile futhi kungani amabhayithi angu-0? Ngokombono we-HTTP, yonke into isebenza njengoba kufanele, kodwa i-POST enefayela ibonakala inyamalala kunethiwekhi. Ngaphezu kwalokho, iyanyamalala phakathi kweklayenti ne-Nginx. Isikhathi sokuzihlomisa nge-Tcpdump! Kodwa okokuqala udinga ukuqonda ukucushwa kwenethiwekhi. Ummeleli we-Nginx ungemuva kwesilinganisi se-L3 I-NFware. I-Tunneling isetshenziselwa ukuletha amaphakethe kusuka kusilinganisi se-L3 kuya kuseva, okwengeza izihloko zayo emaphaketheni:

Kulokhu, inethiwekhi iza kule seva ngendlela yethrafikhi ye-Vlan-tagged, engeza izinkambu zayo emaphaketheni:

Futhi le thrafikhi ingabuye ihlukaniswe (lelo phesenti elincane elifanayo lethrafikhi engenayo ehlukanisiwe esikhulume ngayo lapho sihlola ubungozi obuvela ku-Workaround), ebuye iguqule okuqukethwe kwezihloko:

Nakulokhu: amaphakethe ahlanganiswe nethegi ye-Vlan, ehlanganiswe nomhubhe, ahlukaniswe. Ukuze uqonde kangcono ukuthi lokhu kwenzeka kanjani, ake silandele umzila wephakethe ukusuka kuklayenti ukuya kummeleli we-Nginx.

Iphakethe lifinyelela ibhalansi ye-L3. Ukuze uthole umzila olungile phakathi kwesikhungo sedatha, iphakethe lifakwa emhubheni bese lithunyelwa ekhadini lenethiwekhi.
Njengoba izihloko zephakethe + zomhubhe zingangeni ku-MTU, iphakethe linqunywa libe yizicucu futhi lithunyelwe kunethiwekhi.
Iswishi ngemva kwe-balancer ye-L3, lapho ithola iphakethe, ingeza ithegi ye-Vlan kuyo futhi iyithumele.
Iswishi ephambi kommeleli we-Nginx ibona (ngokusekelwe kuzilungiselelo zembobo) ukuthi iseva ilindele iphakethe le-Vlan-encapsulated, ngakho-ke ilithumela njengoba linjalo, ngaphandle kokususa ithegi ye-Vlan.
I-Linux ithatha izingcezu zamaphakheji ngamanye futhi iwahlanganise abe yiphakheji elikhulu.
Okulandelayo, iphakethe lifinyelela ku-interface ye-Vlan, lapho ungqimba lokuqala lususwa khona - i-Vlan encapsulation.
I-Linux ibe isithumela ku-interface ye-Tunnel, lapho esinye isendlalelo sisuswa kuso - I-Tunnel encapsulation.

Ubunzima ukudlulisa konke lokhu njengamapharamitha ku-tcpdump.
Ake siqale kusukela ekugcineni: ingabe akhona ahlanzekile (ngaphandle kwezihloko ezingadingekile) amaphakethe e-IP avela kumakhasimende, ane-vlan ne-tunnel encapsulation esusiwe?

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

Cha, awekho amaphakheji anjalo kuseva. Ngakho-ke inkinga kufanele ibe khona kusenesikhathi. Ingabe akhona amaphakethe ane-Vlan encapsulation kuphela asusiwe?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx ikheli le-IP leklayenti ngefomethi ye-hex.
32:4 — ikheli nobude benkambu lapho i-SCR IP ibhalwe khona ephaketheni Lomhubhe.

Ikheli lensimu kwakudingeka likhethwe ngamandla anonya, ngoba ku-inthanethi babhala mayelana ne-40, 44, 50, 54, kodwa lalingekho ikheli le-IP lapho. Ungaphinda ubheke elinye lamaphakethe ku-hex (ipharamitha -xx noma -XX ku-tcpdump) futhi ubale ikheli le-IP olaziyo.

Ingabe zikhona izingcezu zephakethe ngaphandle kwe-Vlan ne-Tunnel encapsulation esusiwe?

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Lo mlingo uzosibonisa zonke izingcezu, kuhlanganisa neyokugcina. Mhlawumbe, into efanayo ingahlungwa nge-IP, kodwa angizange ngizame, ngoba awekho amaphakethe anjalo amaningi, futhi lawo engangiwadinga atholakala kalula ekugelezeni okujwayelekile. Nazi:

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

Lezi izingcezu ezimbili zephakheji elilodwa (i-ID efanayo 53652) enesithombe (igama elithi Exif liyabonakala ephaketheni lokuqala). Ngenxa yokuthi kukhona amaphakheji kuleli zinga, kodwa hhayi efomini elihlanganisiwe ezindaweni zokulahla, inkinga ngokucacile ngomhlangano. Ekugcineni kunobufakazi obubhalwe phansi balokhu!

Idekhoda yephakethe ayizange iveze izinkinga ezingavimba ukwakhiwa. Kuzame lapha: hpd.gasmi.net. Ekuqaleni, uma uzama ukufaka okuthile lapho, isikhiphikhoda asithandi ifomethi yephakethe. Kuvele ukuthi kukhona ama-octet amabili engeziwe phakathi kwe-Srcmac ne-Ethertype (ayihlobene nolwazi lwesiqephu). Ngemva kokuzikhipha, isiqophi saqala ukusebenza. Nokho, ayizange ibonise izinkinga.
Noma ngabe umuntu angathini, akukho okunye okwatholakala ngaphandle kwalezo Sysctl. Okwakusele kwakuwukuthola indlela yokuhlonza amaseva ayinkinga ukuze kuqondwe isikali futhi kunqunywe ngezenzo ezengeziwe. Ikhawunta edingekayo itholwe ngokushesha ngokwanele:

netstat -s | grep "packet reassembles failed”

Iphinde ibe ku-snmpd ngaphansi kwe-OID=1.3.6.1.2.1.4.31.1.1.16.1 (ipSystemStatsReasmFails).

"Inombolo yokwehluleka okutholwe i-algorithm yokuhlanganisa kabusha i-IP (nganoma yisiphi isizathu: kuphelelwe yisikhathi, amaphutha, njll.)."

Phakathi kweqembu lamaseva lapho inkinga ifundwe khona, kokubili lesi sibali sikhule ngokushesha, kokubili kancane kancane, futhi kokubili akuzange kukhule nhlobo. Ukuqhathanisa amandla alesi sibali namandla amaphutha e-HTTP kuseva ye-Java kuveza ukuhlobana. Okusho ukuthi, imitha ingagadwa.

Ukuba nenkomba ethembekile yezinkinga kubaluleke kakhulu ukuze ukwazi ukunquma ngokunembile ukuthi ukuhlehlisa i-Sysctl kuyasiza, ngoba endabeni edlule siyazi ukuthi lokhu akukwazi ukuqondwa ngokushesha kusuka kuhlelo lokusebenza. Le nkomba izosivumela ukuthi sikhombe zonke izindawo eziyinkinga ekukhiqizeni ngaphambi kokuthi abasebenzisi bayithole.
Ngemva kokuhlehlisa i-Sysctl, amaphutha okuqapha ayeka, ngaleyo ndlela imbangela yezinkinga yafakazelwa, kanye neqiniso lokuthi i-rollback iyasiza.

Sibuyisele emuva izilungiselelo zokuhlukaniswa kwamanye amaseva, lapho ukuqapha okusha kwaqala khona ukusebenza, futhi ndawana thize sabela inkumbulo eyengeziwe yezingcezu kunalokho okwakuyikhona okuzenzakalelayo (lokhu kwakuyizibalo ze-UDP, ukulahlekelwa ingxenye yakho okwakungabonakali uma kuqhathaniswa nesizinda esivamile) .

Imibuzo ebaluleke kakhulu

Kungani amaphakethe ehlukaniswa kusilinganisi sethu se-L3? Iningi lamaphakethe afika esuka kubasebenzisi kuya kwababhalansi yi-SYN ne-ACK. Amasayizi alawa maphakheji mancane. Kodwa njengoba isabelo samaphakethe anjalo sikhulu kakhulu, ngokumelene nesizinda sabo asizange siqaphele ukuba khona kwamaphakethe amakhulu aqala ukuhlukana.

Isizathu bekuwumbhalo wokucushwa ophukile i-advmss kumaseva ane-Vlan interfaces (kwakunamaseva ambalwa kakhulu anethrafikhi emakiwe ekukhiqizeni ngaleso sikhathi). I-Advmss isivumela ukuthi sidlulisele eklayentini imininingwane yokuthi amaphakethe abheke ngakithi kufanele abe mancane ngosayizi ukuze ngemva kokunamathisela izihloko zomhubhe kuwo kungadingeki ukuba ahlukaniswe.

Kungani ukuhlehliswa kwe-Systll kungasizanga, kodwa ukuqalisa kabusha kwenza? Ukuhlehlisela emuva i-Systll iguqule inani lememori elitholakalayo lokuhlanganisa amaphakheji. Ngesikhathi esifanayo, ngokusobala lona kanye iqiniso lokuchichima kwenkumbulo yezingcezwana liholele ekuncipheni kokuxhumeka, okuholele ekutheni izingcezu zibambezeleke isikhathi eside kulayini. Okusho ukuthi, inqubo yahamba ngemijikelezo.
Ukuqalisa kabusha kusule inkumbulo futhi yonke into yabuyela ekuhlelekeni.

Ingabe kwakungenzeka ukwenza ngaphandle kwe-Workaround? Yebo, kodwa kunobungozi obukhulu bokushiya abasebenzisi ngaphandle kwesevisi uma kwenzeka ukuhlaselwa. Yebo, ukusetshenziswa kwe-Workaround kubangele izinkinga ezihlukahlukene, okuhlanganisa ukwehla kweyodwa yezinsizakalo zabasebenzisi, kodwa nokho sikholelwa ukuthi izenzo zazifanelekile.

Ngibonga kakhulu ku-Andrey Timofeev (i-atimofeyev) ukuze uthole usizo ekwenzeni uphenyo, kanye no-Alexey Krenev (idivayisix) - ngomsebenzi we-titanic wokubuyekeza ama-Centos nama-kernels kumaseva. Inqubo okwakumele iqalwe kusukela ekuqaleni izikhathi eziningana, yingakho idonse izinyanga eziningi.

Source: www.habr.com

Qaphela ukukhubazeka okuletha imijikelezo yomsebenzi. Ingxenye 1: I-FragmentSmack/SegmentSmack