Hi uile! Is e m ’ainm Dmitry Samsonov, tha mi ag obair mar phrìomh rianadair siostam aig Odnoklassniki. Tha còrr air 7 mìle frithealaiche fiosaigeach againn, 11 mìle inneal anns an sgòth againn agus 200 tagradh, a tha ann an grunn rèiteachaidhean a’ dèanamh suas 700 diofar chlàran. Bidh a’ mhòr-chuid de luchd-frithealaidh a’ ruith CentOS 7.
Air 14 Lùnastal, 2018, chaidh fiosrachadh mu dheidhinn so-leòntachd FragmentSmack fhoillseachadh
() agus SegmentSmack (). Is iad sin so-leòntachd le vectar ionnsaigh lìonra agus sgòr gu math àrd (7.5), a tha a’ bagairt diùltadh seirbheis (DoS) mar thoradh air sgìths ghoireasan (CPU). Cha deach fuasgladh kernel airson FragmentSmack a mholadh aig an àm sin; a bharrachd air an sin, thàinig e a-mach fada nas fhaide na foillseachadh fiosrachadh mun so-leòntachd. Gus cuir às do SegmentSmack, chaidh moladh an kernel ùrachadh. Chaidh am pasgan ùrachaidh fhèin fhoillseachadh air an aon latha, cha robh air fhàgail ach a stàladh.
Chan e, chan eil sinn an aghaidh a bhith ag ùrachadh an kernel idir! Ach, tha nuances ann ...
Mar a bhios sinn ag ùrachadh an kernel air cinneasachadh
San fharsaingeachd, chan eil dad iom-fhillte:
- Luchdaich sìos pacaidean;
- Stàlaich iad air grunn luchd-frithealaidh (a’ gabhail a-steach frithealaichean a tha a’ toirt aoigheachd don sgòth againn);
- Dèan cinnteach nach eil dad briste;
- Dèan cinnteach gu bheil a h-uile suidheachadh kernel àbhaisteach air a chuir an sàs gun mhearachdan;
- Fuirich beagan làithean;
- Thoir sùil air coileanadh an fhrithealaiche;
- Atharraich cleachdadh frithealaichean ùra chun kernel ùr;
- Ùraich a h-uile seirbheisiche a rèir ionad dàta (aon ionad dàta aig an aon àm gus a ’bhuaidh air luchd-cleachdaidh a lughdachadh gun fhios nach bi duilgheadasan ann);
- Ath-thòisich a h-uile frithealaiche.
Dèan a-rithist airson a h-uile meur de na kernels a th 'againn. Aig an àm seo tha e:
- Stoc CentOS 7 3.10 - airson a’ mhòr-chuid de luchd-frithealaidh cunbhalach;
- Vanilla 4.19 - airson an fheadhainn againn , oir tha feum againn air BFQ, BBR, msaa;
- Elrepo kernel-ml 5.2 - airson , oir b 'àbhaist dha 4.19 a bhith a' giùlan neo-sheasmhach, ach tha feum air na h-aon fheartan.
Mar is dòcha gu robh thu air smaoineachadh, bheir ath-thòiseachadh mìltean de luchd-frithealaidh an ùine as fhaide. Leis nach eil a h-uile so-leòntachd deatamach airson a h-uile frithealaiche, cha bhith sinn ag ath-thòiseachadh ach an fheadhainn a tha ruigsinneach gu dìreach bhon eadar-lìn. Anns an sgòth, gus nach cuir sinn bacadh air sùbailteachd, cha bhith sinn a’ ceangal soithichean a tha ruigsinneach bhon taobh a-muigh gu frithealaichean fa-leth le kernel ùr, ach ag ath-thòiseachadh a h-uile neach-aoigheachd gun eisgeachd. Gu fortanach, tha am modh-obrach an sin nas sìmplidh na le frithealaichean àbhaisteach. Mar eisimpleir, faodaidh soithichean gun stàite gluasad gu frithealaiche eile aig àm ath-thòiseachadh.
Ach, tha tòrr obrach ann fhathast, agus faodaidh e grunn sheachdainean a thoirt, agus ma tha duilgheadas sam bith ann leis an dreach ùr, suas ri grunn mhìosan. Tha luchd-ionnsaigh a’ tuigsinn seo glè mhath, agus mar sin feumaidh iad plana B.
FragmentSmack/SegmentSmack. Obraich timcheall
Gu fortanach, airson cuid de chugallachd tha leithid de phlana B ann, agus canar Workaround ris. Mar as trice, is e atharrachadh a tha seo ann an suidheachaidhean kernel / tagraidh a dh’ fhaodadh a ’bhuaidh a dh’ fhaodadh a lughdachadh no cuir às gu tur cleachdadh so-leòntachd.
A thaobh FragmentSmack/SegmentSmack an dòigh-obrach seo:
«Faodaidh tu na luachan bunaiteach de 4MB agus 3MB atharrachadh ann an net.ipv4.ipfrag_high_thresh agus net.ipv4.ipfrag_low_thresh (agus an co-aoisean airson ipv6 net.ipv6.ipfrag_high_thresh agus net.ipv6.ipfrag_low_thresh) gu 256 kB no fa leth ìosal. Bidh deuchainnean a’ nochdadh crìonadh beag gu mòr ann an cleachdadh CPU aig àm ionnsaigh a rèir bathar-cruaidh, suidheachaidhean, agus suidheachaidhean. Ach, dh’ fhaodadh gum bi beagan buaidh dèanadais mar thoradh air ipfrag_high_thresh = 192 bytes, leis nach urrainn ach dà chriomag 262144K a dhol a-steach don ciudha ath-chruinneachaidh aig aon àm. Mar eisimpleir, tha cunnart ann gun tèid tagraidhean a tha ag obair le pacaidean mòra UDP a bhriseadh".
Na paramadairean fhèin air a mhìneachadh mar a leanas:
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.
Chan eil UDPan mòra againn air seirbheisean toraidh. Chan eil trafaic sgapte air an LAN; tha trafaic sgapte air an WAN, ach chan eil e cudromach. Chan eil comharran ann - faodaidh tu Workaround a sgaoileadh!
FragmentSmack/SegmentSmack. A 'chiad fhuil
B’ e a’ chiad dhuilgheadas a choinnich sinn nach robh soithichean sgòthan uaireannan a’ cleachdadh nan roghainnean ùra ach gu ìre (dìreach ipfrag_low_thresh), agus uaireannan cha do chuir iad an sàs iad idir - cha robh iad ach a’ tuiteam às a chèile aig an toiseach. Cha robh e comasach an duilgheadas ath-riochdachadh gu seasmhach (chaidh a h-uile suidheachadh a chuir an sàs le làimh gun duilgheadas sam bith). Chan eil e cho furasta a bhith a’ tuigsinn carson a tha an soitheach a’ tuiteam aig an toiseach: cha deach mearachdan a lorg. Bha aon rud cinnteach: le bhith a’ toirt air ais na roghainnean fuasgladh fhaighinn air an duilgheadas le tubaistean soithichean.
Carson nach eil e gu leòr Sysctl a chuir an sàs air an aoigh? Tha an soitheach a’ fuireach anns an lìonra sònraichte aige fhèin Namespace, mar sin co-dhiù anns an t-soitheach a dh'fhaodadh a bhith eadar-dhealaichte bhon aoigh.
Dè dìreach a tha roghainnean Sysctl air an cur an sàs anns a’ ghobhar? Leis gu bheil na soithichean againn gun bhuannachd, cha bhith e comasach dhut suidheachadh Sysctl atharrachadh le bhith a’ dol a-steach don ghobhar fhèin - dìreach chan eil còraichean gu leòr agad. Gus soithichean a ruith, chleachd an sgòth againn aig an àm sin Docker (a-nis ). Chaidh crìochan an t-soithich ùr a chuir gu Docker tron API, a’ toirt a-steach na roghainnean Sysctl riatanach.
Fhad ‘s a bha thu a’ sgrùdadh nan dreachan, thionndaidh e a-mach nach do thill an Docker API a h-uile mearachd (co-dhiù ann an dreach 1.10). Nuair a dh’ fheuch sinn ris a’ ghobhar a thòiseachadh tro “docker run”, chunnaic sinn mu dheireadh co-dhiù rudeigin:
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.
Chan eil luach paramadair dligheach. Ach carson? Agus carson nach eil e dligheach ach uaireannan? Thionndaidh e a-mach nach eil Docker a ’gealltainn an òrdugh anns a bheil paramadairean Sysctl air an cur an sàs (is e an dreach deuchainn as ùire 1.13.1), agus mar sin uaireannan dh’ fheuch ipfrag_high_thresh ri bhith air a shuidheachadh gu 256K nuair a bha ipfrag_low_thresh fhathast 3M, is e sin, bha an ìre as àirde nas ìsle na an ìre as ìsle, a dh’ adhbhraich a’ mhearachd.
Aig an àm sin, chleachd sinn an inneal againn fhèin mu thràth airson an soitheach ath-dhealbhadh às deidh tòiseachadh (reothadh an soitheach às deidh sin agus a’ cur an gnìomh òrdughan ann an ainm-àite a’ bhogsa tro ), agus chuir sinn cuideachd crìochan sgrìobhaidh Sysctl ris a’ phàirt seo. Chaidh an duilgheadas fhuasgladh.
FragmentSmack/SegmentSmack. A ' chiad blood 2 a-nuas
Mus robh ùine againn tuigse fhaighinn air cleachdadh Workaround san sgòth, thòisich a’ chiad ghearanan tearc bho luchd-cleachdaidh a’ ruighinn. Aig an àm sin, bha grunn sheachdainean air a dhol seachad bho thòisich cleachdadh Workaround air a’ chiad luchd-frithealaidh. Sheall a’ chiad sgrùdadh gun d’ fhuaireadh gearanan an aghaidh sheirbheisean fa-leth, agus nach e luchd-frithealaidh nan seirbheisean sin uile. Tha an duilgheadas air fàs gu math mì-chinnteach a-rithist.
An toiseach, dh'fheuch sinn, gu dearbh, ri na roghainnean Sysctl a thoirt air ais, ach cha robh buaidh sam bith aig seo. Cha do chuidich diofar làimhseachadh leis an t-seirbheisiche agus roghainnean an aplacaid nas motha. Chuidich ath-thòiseachadh. Tha ath-thòiseachadh Linux cho mì-nàdarrach ’s a bha e àbhaisteach dha Windows sna seann làithean. Ach, chuidich e, agus chuir sinn suas e gu “kernel glitch” nuair a chuir sinn na roghainnean ùra an sàs ann an Sysctl. Dè cho suarach ‘s a bha e...
Trì seachdainean às deidh sin thàinig an duilgheadas a-rithist. Bha rèiteachadh nan frithealaichean sin gu math sìmplidh: Nginx ann am modh neach-ionaid / cothromachadh. Chan eil mòran trafaic. Nota tòiseachaidh ùr: tha an àireamh de mhearachdan 504 air teachdaichean a’ dol am meud gach latha (). Tha an graf a’ sealltainn an àireamh de mhearachdan 504 gach latha airson na seirbheis seo:
Tha na mearachdan uile mun aon backend - mun fhear a tha san sgòth. Bha an graf caitheamh cuimhne airson pìosan pacaid air an backend seo a’ coimhead mar seo:
Is e seo aon de na taisbeanaidhean as follaisiche air an duilgheadas ann an grafaichean siostam obrachaidh. Anns an sgòth, dìreach aig an aon àm, chaidh duilgheadas lìonra eile le roghainnean QoS (Smachd Trafaic) a shocrachadh. Air graf caitheamh cuimhne airson pìosan pacaid, bha e a’ coimhead dìreach mar a leanas:
Bha am beachd sìmplidh: ma tha iad a 'coimhead mar an ceudna air na grafaichean, tha an aon adhbhar aca. A bharrachd air an sin, tha duilgheadasan sam bith leis an t-seòrsa cuimhne seo gu math tearc.
B’ e brìgh na trioblaid stèidhichte gun do chleachd sinn clàr-ama pacaid fq le roghainnean bunaiteach ann an QoS. Gu gnàthach, airson aon cheangal, leigidh e leat 100 pacaid a chuir ris a ’chiudha, agus thòisich cuid de cheanglaichean, ann an suidheachaidhean gainnead seanail, a’ dùnadh a ’chiudha gu comas. Anns a 'chùis seo, thèid pacaidean a leigeil sìos. Ann an staitistig tc (tc -s qdisc) chithear e mar seo:
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
Is e “464545 flows_plimit” na pacaidean a chaidh a leigeil sìos mar thoradh air a bhith nas àirde na crìoch ciudha aon cheangal, agus “air tuiteam 464545” is e suim a h-uile pacaid a chaidh a leigeil sìos den chlàr seo. Às deidh an ciudha a mheudachadh gu 1 mìle agus na soithichean ath-thòiseachadh, stad an duilgheadas. Faodaidh tu suidhe air ais agus smoothie òl.
FragmentSmack/SegmentSmack. Fuil mu dheireadh
An toiseach, grunn mhìosan às deidh dha so-leòntachd san kernel ainmeachadh, nochd fuasgladh airson FragmentSmack mu dheireadh (leig dhomh do chuimhneachadh, còmhla ris an naidheachd san Lùnastal, gun deach fuasgladh a-mhàin airson SegmentSmack a leigeil ma sgaoil), a thug cothrom dhuinn Workaround a thrèigsinn, rud a dh'adhbhraich tòrr trioblaid dhuinn. Rè na h-ùine seo, bha sinn mar-thà air cuid de na frithealaichean a ghluasad chun an kernel ùr, agus a-nis bha againn ri tòiseachadh bhon toiseach. Carson a dh’ ùraich sinn an kernel gun a bhith a’ feitheamh ris an rèiteachadh FragmentSmack? Is e an fhìrinn gu robh am pròiseas dìon an aghaidh nan so-leòntachd sin aig an aon àm (agus còmhla) leis a’ phròiseas airson CentOS fhèin ùrachadh (a bheir eadhon barrachd ùine na bhith ag ùrachadh an kernel a-mhàin). A bharrachd air an sin, tha SegmentSmack na so-leòntachd nas cunnartaiche, agus nochd fuasgladh air a shon sa bhad, agus mar sin bha e ciallach co-dhiù. Ach, cha b’ urrainn dhuinn dìreach an kernel air CentOS ùrachadh oir cha robh an so-leòntachd FragmentSmack, a nochd rè CentOS 7.5, stèidhichte ach ann an dreach 7.6, agus mar sin bha againn ri stad a chuir air an ùrachadh gu 7.5 agus tòiseachadh a-rithist leis an ùrachadh gu 7.6. Agus tha seo a’ tachairt cuideachd.
San dàrna h-àite, tha gearanan tearc luchd-cleachdaidh mu dhuilgheadasan air tilleadh thugainn. A-nis tha fios againn gu cinnteach gu bheil iad uile co-cheangailte ri luchdachadh suas faidhlichean bho luchd-dèiligidh gu cuid de na frithealaichean againn. A bharrachd air an sin, chaidh àireamh glè bheag de luchdachadh suas bhon tomad iomlan tro na frithealaichean sin.
Mar a tha cuimhne againn bhon sgeulachd gu h-àrd, cha do chuidich gluasad air ais Sysctl. Chuidich ath-thòiseachadh, ach airson ùine ghoirid.
Cha deach amharasan a thaobh Sysctl a thoirt air falbh, ach an turas seo bha e riatanach uiread de dh’ fhiosrachadh a chruinneachadh. Bha dìth comas mòr ann cuideachd an duilgheadas luchdachadh suas ath-riochdachadh air an neach-dèiligidh gus sgrùdadh nas mionaidiche a dhèanamh air na bha a’ tachairt.
Cha tug mion-sgrùdadh air a h-uile staitistig agus logaichean a bha rim faighinn sinn nas fhaisge air tuigse fhaighinn air na bha a’ tachairt. Bha fìor dhroch chomas ann an duilgheadas ath-riochdachadh gus “faireachdainn” ceangal sònraichte. Mu dheireadh, chaidh aig an luchd-leasachaidh, a 'cleachdadh dreach sònraichte den tagradh, air ath-riochdachadh seasmhach de dhuilgheadasan a choileanadh air inneal deuchainn nuair a bha iad ceangailte tro Wi-Fi. B’ e adhartas a bha seo san sgrùdadh. Cheangail an neach-dèiligidh ri Nginx, a bha na neach-ionaid don backend, a bha mar an tagradh Java againn.
Bha an conaltradh airson duilgheadasan mar seo (stèidhichte air taobh proxy Nginx):
- Client: iarrtas airson fiosrachadh fhaighinn mu bhith a’ luchdachadh sìos faidhle.
- Frithealaiche Java: freagairt.
- Client: POST le faidhle.
- Frithealaiche Java: mearachd.
Aig an aon àm, bidh am frithealaiche Java a’ sgrìobhadh chun log gun deach 0 bytes de dhàta fhaighinn bhon neach-dèiligidh, agus tha an neach-ionaid Nginx a’ sgrìobhadh gun tug an t-iarrtas barrachd air 30 diog (is e 30 diogan an ùine a-mach à tagradh teachdaiche). Carson a tha an ùine-ama agus carson 0 bytes? Bho shealladh HTTP, bidh a h-uile dad ag obair mar a bu chòir, ach tha coltas gu bheil am POST leis an fhaidhle a ’dol à sealladh bhon lìonra. A bharrachd air an sin, falbhaidh e eadar an neach-dèiligidh agus Nginx. Tha an t-àm ann thu fhèin a armachd le Tcpdump! Ach an toiseach feumaidh tu rèiteachadh an lìonraidh a thuigsinn. Tha neach-ionaid Nginx air cùl an cothromachadh L3 . Tha tunailing air a chleachdadh gus pacaidean a lìbhrigeadh bhon chothromachadh L3 chun an fhrithealaiche, a chuireas cinn-cinn ris na pacaidean:
Anns a ’chùis seo, thig an lìonra chun t-seirbheisiche seo ann an cruth trafaic le tag Vlan, a bhios cuideachd a’ cur a raointean fhèin ris na pacaidean:
Agus faodaidh an trafaic seo a bhith sgapte cuideachd (an aon cheudad beag sin de thrafaig sgapte a tha a’ tighinn a-steach air an do bhruidhinn sinn nuair a bha sinn a’ measadh nan cunnartan bho Workaround), a bhios cuideachd ag atharrachadh susbaint nan cinn:
A-rithist: tha pacaidean air an cuairteachadh le tag Vlan, air an cuairteachadh le tunail, sgapte. Gus tuigse nas fheàrr fhaighinn air mar a thachras seo, lorg sinn slighe a’ phacaid bhon neach-dèiligidh chun neach-ionaid Nginx.
- Bidh am pacaid a’ ruighinn cothromachadh L3. Airson slighe cheart taobh a-staigh an ionad dàta, tha am pasgan air a chuartachadh ann an tunail agus air a chuir chun chairt lìonra.
- Leis nach eil cinn a’ phacaid + tunail a’ freagairt air an MTU, tha am pacaid air a ghearradh ann am pìosan agus air a chuir chun lìonra.
- Bidh an tionndadh às deidh an cothromachadh L3, nuair a gheibh e pacaid, taga Vlan ris agus ga chuir air adhart.
- Tha an tionndadh air beulaibh neach-ionaid Nginx a’ faicinn (stèidhichte air roghainnean a’ phuirt) gu bheil am frithealaiche an dùil ri pasgan le Vlan-encapsulated, agus mar sin bidh e ga chuir mar a tha, gun a bhith a’ toirt air falbh an taga Vlan.
- Bidh Linux a’ toirt pìosan de phasgan fa leth agus gan cur còmhla ann an aon phasgan mòr.
- An uairsin, ruigidh am pasgan eadar-aghaidh Vlan, far a bheil a 'chiad sreath air a thoirt air falbh bhuaithe - Vlan encapsulation.
- Bidh Linux an uairsin ga chuir chun eadar-aghaidh Tunnel, far a bheil còmhdach eile air a thoirt air falbh bhuaithe - cuairteachadh tunail.
Is e an duilgheadas a th’ ann seo a thoirt seachad mar pharamadairean gu tcpdump.
Feuch an tòisich sinn bhon deireadh: a bheil pacaidean IP glan (às aonais cinn neo-riatanach) bho luchd-dèiligidh, le cuairteachadh vlan agus tunail air a thoirt air falbh?
tcpdump host <ip клиента>
Chan e, cha robh pacaidean mar sin air an fhrithealaiche. Mar sin feumaidh an duilgheadas a bhith ann nas tràithe. A bheil pacaidean ann le dìreach cuairteachadh Vlan air a thoirt air falbh?
tcpdump ip[32:4]=0xx390x2xx
Is e 0xx390x2xx an seòladh IP teachdaiche ann an cruth hex.
32: 4 - seòladh agus fad an raoin anns a bheil an SCR IP sgrìobhte ann am pasgan Tunnel.
Dh'fheumadh an seòladh achaidh a bhith air a thaghadh le feachd brùideil, oir air an eadar-lìon tha iad a 'sgrìobhadh mu 40, 44, 50, 54, ach cha robh seòladh IP ann. Faodaidh tu cuideachd coimhead air aon de na pacaidean ann an hex (am paramadair -xx no -XX ann an tcpdump) agus obrachadh a-mach an seòladh IP as aithne dhut.
A bheil mìrean pacaid ann às aonais cuairteachadh Vlan agus Tunail air a thoirt air falbh?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Seallaidh an draoidheachd seo dhuinn na criomagan gu lèir, am fear mu dheireadh nam measg. Is dòcha, faodar an aon rud a shìoladh le IP, ach cha do dh'fheuch mi, oir chan eil mòran phasgan mar sin ann, agus bha an fheadhainn a bha a dhìth orm furasta an lorg anns an t-sruth coitcheann. Seo iad:
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 ..............
Is e seo dà chriomag de aon phacaid (an aon ID 53652) le dealbh (tha am facal Exif ri fhaicinn sa chiad phacaid). Leis gu bheil pasganan aig an ìre seo, ach chan ann anns an fhoirm aonaichte anns na dumps, tha an duilgheadas gu soilleir leis a’ cho-chruinneachadh. Mu dheireadh tha fianais aithriseach air seo!
Cha do nochd an decoder pacaid duilgheadasan sam bith a chuireadh casg air an togail. Dh’ fheuch mi an seo e: . An toiseach, nuair a dh’ fheuchas tu ri rudeigin a lìonadh an sin, cha toil leis an decoder cruth a’ phacaid. Thionndaidh e a-mach gun robh dà octets a bharrachd eadar Srcmac agus Ethertype (nach eil co-cheangailte ri fiosrachadh criomag). Às deidh dhaibh an toirt air falbh, thòisich an decoder ag obair. Ach, cha do sheall e duilgheadasan sam bith.
Ge bith dè a chanas duine, cha deach dad eile a lorg ach an Sysctl sin. Cha robh air fhàgail ach dòigh a lorg gus frithealaichean trioblaideach a chomharrachadh gus an sgèile a thuigsinn agus co-dhùnadh a dhèanamh air tuilleadh ghnìomhan. Chaidh an cuntair riatanach a lorg luath gu leòr:
netstat -s | grep "packet reassembles failed”
Tha e cuideachd ann an snmpd fo OID = 1.3.6.1.2.1.4.31.1.1.16.1 ().
“An àireamh de fhàilligidhean a chaidh a lorg leis an algairim ath-chruinneachadh IP (airson adhbhar sam bith: ùine a-mach, mearachdan, msaa).
Am measg na buidhne de luchd-frithealaidh air an deach an duilgheadas a sgrùdadh, air dhà dh'àrdaich a 'chunntair seo nas luaithe, air dhà nas slaodaiche, agus air dhà eile cha do dh'àrdaich e idir. Le bhith a’ dèanamh coimeas eadar daineamaigs a’ chunntair seo le daineamaigs mhearachdan HTTP air frithealaiche Java nochd co-dhàimh. Is e sin, faodar sùil a chumail air a’ mheatair.
Tha e glè chudromach comharradh earbsach de dhuilgheadasan a bhith agad gus an urrainn dhut dearbhadh gu ceart a bheil gluasad air ais Sysctl na chuideachadh, oir bhon sgeulachd roimhe tha fios againn nach urrainn seo a thuigsinn sa bhad bhon tagradh. Leigidh an comharra seo leinn a h-uile raon duilgheadas ann an cinneasachadh a chomharrachadh mus lorg luchd-cleachdaidh e.
Às deidh dha Sysctl a thoirt air ais, stad na mearachdan sgrùdaidh, agus mar sin chaidh adhbhar nan duilgheadasan a dhearbhadh, a bharrachd air an fhìrinn gu bheil an roiligeadh air ais a’ cuideachadh.
Chuir sinn air ais na roghainnean brisidh air frithealaichean eile, far an tàinig sgrùdadh ùr a-steach, agus an àiteigin thug sinn seachad eadhon barrachd cuimhne airson pìosan na bha roimhe seo (b’ e staitistig UDP a bha seo, agus cha robh a chall ann am pàirt follaiseach an aghaidh cùl-raon coitcheann) .
Na ceistean as cudromaiche
Carson a tha pacaidean sgapte air ar cothromachadh L3? Is e SYN agus ACK a’ mhòr-chuid de na pacaidean a thig bho luchd-cleachdaidh gu luchd-cothromachaidh. Tha meudan nam pacaidean sin beag. Ach leis gu bheil an roinn de phasganan mar sin glè mhòr, an aghaidh an cùl-fhiosrachaidh cha do mhothaich sinn gu robh pacaidean mòra ann a thòisich a’ briseadh sìos.
B 'e an adhbhar sgriobt rèiteachaidh briste air frithealaichean le eadar-aghaidh Vlan (cha robh ach glè bheag de luchd-frithealaidh le trafaic tagaichean ann an cinneasachadh aig an àm sin). Leigidh Advmss leinn am fiosrachadh a thoirt don neach-dèiligidh gum bu chòir pacaidean nar stiùir a bhith nas lugha ann am meud gus nach fheum iad a bhith sgapte às deidh cinn tunail a cheangal riutha.
Carson nach do chuidich roiligeadh air ais Sysctl, ach rinn ath-thòiseachadh? Le bhith a’ gluasad air ais dh’atharraich Sysctl an ìre de chuimhne a bha ri fhaighinn airson pacaidean aonachaidh. Aig an aon àm, a rèir coltais, mar thoradh air fìor fhìrinn thar-shruth cuimhne airson pìosan chaidh ceanglaichean a dhèanamh nas slaodaiche, agus mar sin chaidh dàil a chuir air criomagan airson ùine mhòr anns a’ chiudha. Is e sin, chaidh am pròiseas ann an cearcallan.
Ghlan an ath-thòiseachadh an cuimhne agus thill a h-uile càil gu òrdugh.
An robh e comasach a dhèanamh às aonais Workaround? Tha, ach tha cunnart mòr ann luchd-cleachdaidh fhàgail gun seirbheis ma thig ionnsaigh. Gu dearbh, dh'adhbhraich cleachdadh Workaround grunn dhuilgheadasan, a 'gabhail a-steach slaodachadh aon de na seirbheisean do luchd-cleachdaidh, ach a dh' aindeoin sin tha sinn den bheachd gu robh na gnìomhan air am fìreanachadh.
Mòran taing do Andrey Timofeev () airson cuideachadh ann a bhith a’ dèanamh an sgrùdaidh, a bharrachd air Alexei Krenev () - airson obair titanic a bhith ag ùrachadh Centos agus kernels air frithealaichean. Pròiseas a dh'fheumadh a bhith air a thòiseachadh bhon toiseach grunn thursan sa chùis seo, agus is e sin as coireach gun do shlaod e air adhart airson grunn mhìosan.
Source: www.habr.com