வேலை சுற்றுகளை கொண்டு வரும் பாதிப்புகள் குறித்து ஜாக்கிரதை. பகுதி 1: FragmentSmack/SegmentSmack

அனைவருக்கும் வணக்கம்! எனது பெயர் டிமிட்ரி சாம்சோனோவ், நான் ஒட்னோக்ளாஸ்னிகியில் முன்னணி கணினி நிர்வாகியாக பணிபுரிகிறேன். எங்களிடம் 7 ஆயிரத்துக்கும் மேற்பட்ட இயற்பியல் சேவையகங்கள், எங்கள் கிளவுட்டில் 11 ஆயிரம் கொள்கலன்கள் மற்றும் 200 பயன்பாடுகள் உள்ளன, அவை பல்வேறு கட்டமைப்புகளில் 700 வெவ்வேறு கிளஸ்டர்களை உருவாக்குகின்றன. பெரும்பாலான சேவையகங்கள் CentOS 7 ஐ இயக்குகின்றன.
ஆகஸ்ட் 14, 2018 அன்று, FragmentSmack பாதிப்பு பற்றிய தகவல் வெளியிடப்பட்டது
(CVE-2018-5391) மற்றும் SegmentSmack (CVE-2018-5390) இவை நெட்வொர்க் தாக்குதல் திசையன் மற்றும் அதிக மதிப்பெண் (7.5) கொண்ட பாதிப்புகள் ஆகும், இது வள சோர்வு (CPU) காரணமாக சேவை மறுப்பு (DoS) அச்சுறுத்தலை ஏற்படுத்துகிறது. அந்த நேரத்தில் FragmentSmack க்கான கர்னல் பிழைத்திருத்தம் முன்மொழியப்படவில்லை; மேலும், பாதிப்பு பற்றிய தகவல் வெளியிடப்பட்டதை விட இது மிகவும் தாமதமாக வெளிவந்தது. SegmentSmack ஐ அகற்ற, கர்னலை புதுப்பிக்க பரிந்துரைக்கப்பட்டது. புதுப்பிப்பு தொகுப்பு அதே நாளில் வெளியிடப்பட்டது, அதை நிறுவுவது மட்டுமே மீதமுள்ளது.
இல்லை, கர்னலைப் புதுப்பிப்பதற்கு நாங்கள் எதிரானவர்கள் அல்ல! இருப்பினும், நுணுக்கங்கள் உள்ளன ...

உற்பத்தியில் கர்னலை எவ்வாறு புதுப்பிப்பது

பொதுவாக, சிக்கலான எதுவும் இல்லை:

1. தொகுப்புகளைப் பதிவிறக்கவும்;
2. பல சேவையகங்களில் அவற்றை நிறுவவும் (எங்கள் கிளவுட் ஹோஸ்ட் செய்யும் சேவையகங்கள் உட்பட);
3. எதுவும் உடைக்கப்படவில்லை என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள்;
4. அனைத்து நிலையான கர்னல் அமைப்புகளும் பிழைகள் இல்லாமல் பயன்படுத்தப்படுகின்றன என்பதை உறுதிப்படுத்தவும்;
5. சில நாட்கள் காத்திருங்கள்;
6. சேவையக செயல்திறனை சரிபார்க்கவும்;
7. புதிய சேவையகங்களின் வரிசைப்படுத்தலை புதிய கர்னலுக்கு மாற்றவும்;
8. தரவு மையம் மூலம் அனைத்து சேவையகங்களையும் புதுப்பிக்கவும் (சிக்கல்கள் ஏற்பட்டால் பயனர்களுக்கு ஏற்படும் விளைவைக் குறைக்க ஒரு நேரத்தில் ஒரு தரவு மையம்);
9. அனைத்து சேவையகங்களையும் மீண்டும் துவக்கவும்.

எங்களிடம் உள்ள கர்னல்களின் அனைத்து கிளைகளுக்கும் மீண்டும் செய்யவும். தற்போது அது:

• Stock CentOS 7 3.10 - பெரும்பாலான வழக்கமான சேவையகங்களுக்கு;
• வெண்ணிலா 4.19 - நமக்காக ஒரு மேக மேகங்கள், ஏனெனில் நமக்கு BFQ, BBR போன்றவை தேவை;
• Elrepo kernel-ml 5.2 -க்கு அதிக ஏற்றப்பட்ட விநியோகஸ்தர்கள், ஏனெனில் 4.19 நிலையற்றதாக செயல்படும், ஆனால் அதே அம்சங்கள் தேவை.

நீங்கள் யூகித்தபடி, ஆயிரக்கணக்கான சேவையகங்களை மறுதொடக்கம் செய்வது அதிக நேரம் எடுக்கும். எல்லாப் பாதிப்புகளும் அனைத்து சேவையகங்களுக்கும் முக்கியமானவை அல்ல என்பதால், இணையத்திலிருந்து நேரடியாக அணுகக்கூடியவற்றை மட்டுமே நாங்கள் மறுதொடக்கம் செய்கிறோம். மேகக்கணியில், நெகிழ்வுத்தன்மையைக் கட்டுப்படுத்தாமல் இருக்க, வெளிப்புறமாக அணுகக்கூடிய கொள்கலன்களை புதிய கர்னலுடன் தனிப்பட்ட சேவையகங்களுடன் இணைக்க மாட்டோம், ஆனால் விதிவிலக்கு இல்லாமல் அனைத்து ஹோஸ்ட்களையும் மறுதொடக்கம் செய்கிறோம். அதிர்ஷ்டவசமாக, அங்குள்ள செயல்முறை வழக்கமான சர்வர்களை விட எளிமையானது. எடுத்துக்காட்டாக, நிலையற்ற கொள்கலன்கள் மறுதொடக்கம் செய்யும் போது மற்றொரு சேவையகத்திற்கு நகர்த்தலாம்.

இருப்பினும், இன்னும் நிறைய வேலைகள் உள்ளன, அதற்கு பல வாரங்கள் ஆகலாம், மேலும் புதிய பதிப்பில் ஏதேனும் சிக்கல்கள் இருந்தால், பல மாதங்கள் வரை. தாக்குபவர்கள் இதை நன்றாக புரிந்துகொள்கிறார்கள், எனவே அவர்களுக்கு ஒரு திட்டம் B தேவை.

FragmentSmack/SegmentSmack. தீர்வு

அதிர்ஷ்டவசமாக, சில பாதிப்புகளுக்கு, அத்தகைய திட்டம் B உள்ளது, மேலும் இது பணிச்சூழல் என்று அழைக்கப்படுகிறது. பெரும்பாலும், இது கர்னல்/பயன்பாட்டு அமைப்புகளில் ஏற்படும் மாற்றமாகும், இது சாத்தியமான விளைவைக் குறைக்கலாம் அல்லது பாதிப்புகளின் சுரண்டலை முற்றிலுமாக அகற்றலாம்.

FragmentSmack/SegmentSmack விஷயத்தில் முன்மொழியப்பட்டது இந்த தீர்வு:

«நீங்கள் net.ipv4.ipfrag_high_thresh மற்றும் net.ipv3.ipfrag_low_thresh (மற்றும் ipv4 net.ipv4.ipfrag_high_thresh மற்றும் net.ipv6.ipfrag_low_thresh மற்றும் net.ipv6.ipfrag_low_thresh ஆகியவற்றுக்கான அவற்றின் இணைகள்) 6MB மற்றும் 256MB இன் இயல்புநிலை மதிப்புகளை முறையே kB மற்றும் 192 kB ஆக மாற்றலாம். குறைந்த. வன்பொருள், அமைப்புகள் மற்றும் நிபந்தனைகளைப் பொறுத்து தாக்குதலின் போது CPU பயன்பாட்டில் சிறியது முதல் குறிப்பிடத்தக்க அளவு குறைவதை சோதனைகள் காட்டுகின்றன. இருப்பினும், ipfrag_high_thresh=262144 பைட்டுகள் காரணமாக சில செயல்திறன் தாக்கம் இருக்கலாம், ஏனெனில் ஒரே நேரத்தில் இரண்டு 64K துண்டுகள் மட்டுமே மறுசீரமைப்பு வரிசையில் பொருந்தும். எடுத்துக்காட்டாக, பெரிய UDP பாக்கெட்டுகளுடன் வேலை செய்யும் பயன்பாடுகள் உடைந்து போகும் அபாயம் உள்ளது".

அளவுருக்கள் தங்களை கர்னல் ஆவணத்தில் பின்வருமாறு விவரிக்கப்பட்டுள்ளது:

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.

உற்பத்திச் சேவைகளில் பெரிய UDPகள் எங்களிடம் இல்லை. LAN இல் துண்டு துண்டான போக்குவரத்து இல்லை; WAN இல் துண்டு துண்டான போக்குவரத்து உள்ளது, ஆனால் குறிப்பிடத்தக்கதாக இல்லை. எந்த அறிகுறியும் இல்லை - நீங்கள் தீர்வுகளை உருவாக்கலாம்!

FragmentSmack/SegmentSmack. முதல் இரத்த

நாங்கள் எதிர்கொண்ட முதல் சிக்கல் என்னவென்றால், கிளவுட் கொள்கலன்கள் சில நேரங்களில் புதிய அமைப்புகளை ஓரளவு மட்டுமே (ipfrag_low_thresh) பயன்படுத்துகின்றன, சில சமயங்களில் அவற்றைப் பயன்படுத்தவில்லை - அவை ஆரம்பத்தில் செயலிழந்தன. சிக்கலை நிலையான முறையில் மீண்டும் உருவாக்குவது சாத்தியமில்லை (அனைத்து அமைப்புகளும் எந்த சிரமமும் இல்லாமல் கைமுறையாகப் பயன்படுத்தப்பட்டன). தொடக்கத்தில் கொள்கலன் ஏன் செயலிழக்கிறது என்பதைப் புரிந்துகொள்வது அவ்வளவு எளிதானது அல்ல: பிழைகள் எதுவும் கண்டறியப்படவில்லை. ஒன்று உறுதியாக இருந்தது: அமைப்புகளைத் திரும்பப் பெறுவது கொள்கலன் செயலிழப்புகளில் சிக்கலைத் தீர்க்கிறது.

ஹோஸ்டில் Sysctl ஐ ஏன் பயன்படுத்தினால் போதாது? கொள்கலன் அதன் சொந்த பிரத்யேக நெட்வொர்க் நேம்ஸ்பேஸில் வாழ்கிறது, குறைந்தபட்சம் நெட்வொர்க் Sysctl அளவுருக்களின் ஒரு பகுதி கொள்கலனில் ஹோஸ்டில் இருந்து வேறுபடலாம்.

கண்டெய்னரில் Sysctl அமைப்புகள் எவ்வாறு சரியாகப் பயன்படுத்தப்படுகின்றன? எங்கள் கொள்கலன்கள் சலுகை பெறாதவை என்பதால், கொள்கலனுக்குள் சென்று எந்த Sysctl அமைப்பையும் உங்களால் மாற்ற முடியாது - உங்களிடம் போதுமான உரிமைகள் இல்லை. கொள்கலன்களை இயக்க, அந்த நேரத்தில் எங்கள் மேகம் டோக்கரைப் பயன்படுத்தியது (இப்போது போட்மேன்) புதிய கொள்கலனின் அளவுருக்கள் தேவையான Sysctl அமைப்புகள் உட்பட, API வழியாக டோக்கருக்கு அனுப்பப்பட்டன.
பதிப்புகளைத் தேடும் போது, ​​Docker API எல்லாப் பிழைகளையும் (குறைந்தபட்சம் பதிப்பு 1.10 இல்) வழங்கவில்லை என்பது தெரியவந்தது. "டாக்கர் ரன்" வழியாக கொள்கலனைத் தொடங்க முயற்சித்தபோது, ​​​​கடைசியாக எதையாவது பார்த்தோம்:

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.

அளவுரு மதிப்பு தவறானது. ஆனால் ஏன்? அது ஏன் சில நேரங்களில் மட்டும் செல்லுபடியாகாது? Sysctl அளவுருக்கள் பயன்படுத்தப்படும் வரிசைக்கு Docker உத்தரவாதம் அளிக்கவில்லை (சமீபத்திய சோதனை பதிப்பு 1.13.1), எனவே ipfrag_low_thresh இன்னும் 256M ஆக இருக்கும் போது ipfrag_high_thresh 3K ஆக அமைக்க முயற்சித்தது, அதாவது, மேல் வரம்பு குறைவாக இருந்தது. குறைந்த வரம்பை விட, இது பிழைக்கு வழிவகுத்தது.

அந்த நேரத்தில், தொடக்கத்திற்குப் பிறகு கொள்கலனை மறுகட்டமைக்க நாங்கள் ஏற்கனவே எங்கள் சொந்த பொறிமுறையைப் பயன்படுத்தினோம் (பின்னர் கொள்கலனை உறைய வைப்போம் குழு உறைவிப்பான் மற்றும் வழியாக கொள்கலனின் பெயர்வெளியில் கட்டளைகளை செயல்படுத்துதல் ip netns), மேலும் இந்த பகுதியில் Sysctl அளவுருக்களை எழுதுவதையும் சேர்த்துள்ளோம். பிரச்சனை தீர்ந்தது.

FragmentSmack/SegmentSmack. முதல் இரத்தம் 2

மேகக்கணியில் பணிச்சூழலின் பயன்பாட்டைப் புரிந்துகொள்வதற்கு நேரம் கிடைப்பதற்கு முன்பே, பயனர்களிடமிருந்து முதல் அரிய புகார்கள் வரத் தொடங்கின. அந்த நேரத்தில், முதல் சேவையகங்களில் பணிச்சூழலைப் பயன்படுத்தத் தொடங்கி பல வாரங்கள் கடந்துவிட்டன. ஆரம்ப விசாரணையில், தனிப்பட்ட சேவைகளுக்கு எதிராக புகார்கள் வந்துள்ளன, இந்த சேவைகளின் அனைத்து சர்வர்களும் அல்ல. பிரச்சனை மீண்டும் மிகவும் நிச்சயமற்றதாகிவிட்டது.

முதலில், நாங்கள், நிச்சயமாக, Sysctl அமைப்புகளைத் திரும்பப் பெற முயற்சித்தோம், ஆனால் இது எந்த விளைவையும் ஏற்படுத்தவில்லை. சேவையகம் மற்றும் பயன்பாட்டு அமைப்புகளுடன் பல்வேறு கையாளுதல்களும் உதவவில்லை. மறுதொடக்கம் உதவியது. லினக்ஸை மறுதொடக்கம் செய்வது பழைய நாட்களில் விண்டோஸுக்கு இயல்பானது போலவே இயற்கைக்கு மாறானது. இருப்பினும், இது உதவியது, மேலும் Sysctl இல் புதிய அமைப்புகளைப் பயன்படுத்தும்போது அதை "கர்னல் தடுமாற்றம்" என்று மாற்றினோம். எவ்வளவு அற்பமாக இருந்தது...

மூன்று வாரங்களுக்குப் பிறகு பிரச்சனை மீண்டும் வந்தது. இந்த சேவையகங்களின் உள்ளமைவு மிகவும் எளிமையானது: Nginx in proxy/balancer முறையில். போக்குவரத்து அதிகம் இல்லை. புதிய அறிமுகக் குறிப்பு: வாடிக்கையாளர்களின் 504 பிழைகளின் எண்ணிக்கை ஒவ்வொரு நாளும் அதிகரித்து வருகிறது (நுழைவாயில் நேரம் முடிந்தது) இந்தச் சேவைக்காக ஒரு நாளைக்கு 504 பிழைகளின் எண்ணிக்கையை வரைபடம் காட்டுகிறது:

எல்லா பிழைகளும் ஒரே பின்தளத்தில் உள்ளன - கிளவுட்டில் உள்ளதைப் பற்றியது. இந்த பின்தளத்தில் தொகுப்பு துண்டுகளுக்கான நினைவக நுகர்வு வரைபடம் இப்படி இருந்தது:

இயக்க முறைமை வரைபடங்களில் உள்ள சிக்கலின் மிகத் தெளிவான வெளிப்பாடுகளில் இதுவும் ஒன்றாகும். கிளவுட்டில், அதே நேரத்தில், QoS (போக்குவரத்து கட்டுப்பாடு) அமைப்புகளில் மற்றொரு பிணைய சிக்கல் சரி செய்யப்பட்டது. பாக்கெட் துண்டுகளுக்கான நினைவக நுகர்வு வரைபடத்தில், அது சரியாகவே இருந்தது:

அனுமானம் எளிமையானது: வரைபடங்களில் அவை ஒரே மாதிரியாக இருந்தால், அவர்களுக்கும் அதே காரணம் இருக்கும். மேலும், இந்த வகை நினைவகத்தில் ஏதேனும் சிக்கல்கள் மிகவும் அரிதானவை.

நிலையான சிக்கலின் சாராம்சம் என்னவென்றால், QoS இல் இயல்புநிலை அமைப்புகளுடன் fq பாக்கெட் திட்டமிடலைப் பயன்படுத்தினோம். இயல்பாக, ஒரு இணைப்பிற்கு, இது 100 பாக்கெட்டுகளை வரிசையில் சேர்க்க உங்களை அனுமதிக்கிறது, மேலும் சில இணைப்புகள், சேனல் பற்றாக்குறையின் சூழ்நிலைகளில், வரிசையை திறனுடன் அடைக்கத் தொடங்கியது. இந்த வழக்கில், பாக்கெட்டுகள் கைவிடப்படுகின்றன. tc புள்ளிவிபரங்களில் (tc -s qdisc) இதை இப்படிக் காணலாம்:

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” என்பது ஒரு இணைப்பின் வரிசை வரம்பை மீறுவதால் கைவிடப்பட்ட பாக்கெட்டுகள் ஆகும், மேலும் “464545 கைவிடப்பட்டது” என்பது இந்த அட்டவணையாளரின் கைவிடப்பட்ட அனைத்து பாக்கெட்டுகளின் கூட்டுத்தொகையாகும். வரிசை நீளத்தை 1 ஆயிரமாக அதிகரித்து, கன்டெய்னர்களை மீண்டும் துவக்கிய பின், பிரச்னை ஏற்படுவது நின்றது. நீங்கள் உட்கார்ந்து ஒரு ஸ்மூத்தி குடிக்கலாம்.

FragmentSmack/SegmentSmack. கடைசி இரத்தம்

முதலாவதாக, கர்னலில் உள்ள பாதிப்புகள் அறிவிக்கப்பட்ட பல மாதங்களுக்குப் பிறகு, FragmentSmack க்கான ஒரு பிழைத்திருத்தம் இறுதியாக தோன்றியது (ஆகஸ்ட் மாத அறிவிப்புடன், SegmentSmack க்கு மட்டும் ஒரு பிழைத்திருத்தம் வெளியிடப்பட்டது என்பதை நினைவூட்டுகிறேன்), இது எங்களுக்கு பணியை கைவிட வாய்ப்பளித்தது, இது எங்களுக்கு மிகவும் சிரமத்தை ஏற்படுத்தியது. இந்த நேரத்தில், நாங்கள் ஏற்கனவே சில சேவையகங்களை புதிய கர்னலுக்கு மாற்ற முடிந்தது, இப்போது நாம் ஆரம்பத்தில் இருந்து தொடங்க வேண்டும். FragmentSmack திருத்தத்திற்காக காத்திருக்காமல் கர்னலை ஏன் புதுப்பித்தோம்? உண்மை என்னவென்றால், இந்த பாதிப்புகளிலிருந்து பாதுகாக்கும் செயல்முறையானது CentOS ஐப் புதுப்பிக்கும் செயல்முறையுடன் ஒத்துப்போனது (மற்றும் ஒன்றிணைந்தது) (இது கர்னலை மட்டும் புதுப்பிப்பதை விட அதிக நேரம் எடுக்கும்). கூடுதலாக, SegmentSmack மிகவும் ஆபத்தான பாதிப்பாகும், மேலும் அதற்கான தீர்வு உடனடியாக தோன்றியது, எனவே அது எப்படியும் அர்த்தமுள்ளதாக இருந்தது. இருப்பினும், CentOS 7.5 இன் போது தோன்றிய FragmentSmack பாதிப்பு, பதிப்பு 7.6 இல் மட்டுமே சரிசெய்யப்பட்டதால், CentOS இல் கர்னலைப் புதுப்பிக்க முடியவில்லை, எனவே புதுப்பிப்பை 7.5 க்கு நிறுத்திவிட்டு, 7.6 க்கு புதுப்பித்தலுடன் மீண்டும் தொடங்க வேண்டியிருந்தது. மேலும் இதுவும் நடக்கும்.

இரண்டாவதாக, சிக்கல்கள் பற்றிய அரிய பயனர் புகார்கள் எங்களிடம் திரும்பியுள்ளன. அவை அனைத்தும் கிளையண்டுகளிடமிருந்து எங்களின் சில சர்வர்களில் கோப்புகளைப் பதிவேற்றுவது தொடர்பானவை என்பதை நாங்கள் ஏற்கனவே அறிந்திருக்கிறோம். மேலும், மொத்த வெகுஜனத்திலிருந்து மிகக் குறைந்த எண்ணிக்கையிலான பதிவேற்றங்கள் இந்த சேவையகங்கள் வழியாக சென்றன.

மேலே உள்ள கதையில் இருந்து நாம் நினைவில் வைத்திருப்பது போல், Sysctl ஐப் பின்னுக்குத் தள்ளுவது உதவவில்லை. மறுதொடக்கம் உதவியது, ஆனால் தற்காலிகமாக.
Sysctl தொடர்பான சந்தேகங்கள் நீக்கப்படவில்லை, ஆனால் இம்முறை முடிந்தவரை தகவல்களைச் சேகரிப்பது அவசியம். என்ன நடக்கிறது என்பதை இன்னும் துல்லியமாக ஆய்வு செய்வதற்காக கிளையண்டில் பதிவேற்ற சிக்கலை மீண்டும் உருவாக்கும் திறனின் மிகப்பெரிய பற்றாக்குறையும் இருந்தது.

கிடைக்கக்கூடிய அனைத்து புள்ளிவிவரங்கள் மற்றும் பதிவுகளின் பகுப்பாய்வு என்ன நடக்கிறது என்பதைப் புரிந்துகொள்வதற்கு எங்களை நெருக்கமாக கொண்டு வரவில்லை. ஒரு குறிப்பிட்ட இணைப்பை "உணர்வதற்காக" சிக்கலை மீண்டும் உருவாக்கும் திறனின் கடுமையான பற்றாக்குறை இருந்தது. இறுதியாக, டெவலப்பர்கள், பயன்பாட்டின் சிறப்புப் பதிப்பைப் பயன்படுத்தி, Wi-Fi வழியாக இணைக்கப்படும்போது சோதனைச் சாதனத்தில் சிக்கல்களின் நிலையான இனப்பெருக்கத்தை அடைய முடிந்தது. இது விசாரணையில் திருப்புமுனையாக அமைந்தது. கிளையன்ட் Nginx உடன் இணைக்கப்பட்டுள்ளது, இது எங்கள் ஜாவா பயன்பாடான பின்தளத்திற்கு ப்ராக்ஸி செய்யப்பட்டது.

சிக்கல்களுக்கான உரையாடல் இப்படி இருந்தது (Nginx ப்ராக்ஸி பக்கத்தில் சரி செய்யப்பட்டது):

1. கிளையண்ட்: கோப்பைப் பதிவிறக்குவது பற்றிய தகவலைப் பெறுவதற்கான கோரிக்கை.
2. ஜாவா சர்வர்: பதில்.
3. கிளையண்ட்: கோப்புடன் POST.
4. ஜாவா சர்வர்: பிழை.

அதே நேரத்தில், ஜாவா சேவையகம் கிளையண்டிலிருந்து 0 பைட்டுகள் தரவு பெறப்பட்டதாக பதிவில் எழுதுகிறது, மேலும் கோரிக்கை 30 வினாடிகளுக்கு மேல் எடுத்ததாக Nginx ப்ராக்ஸி எழுதுகிறது (30 வினாடிகள் கிளையன்ட் பயன்பாட்டின் நேரம் முடிந்தது). ஏன் காலக்கெடு மற்றும் ஏன் 0 பைட்டுகள்? ஒரு HTTP கண்ணோட்டத்தில், எல்லாம் சரியாக வேலை செய்யும், ஆனால் கோப்புடன் கூடிய POST பிணையத்திலிருந்து மறைந்துவிடும். மேலும், இது கிளையன்ட் மற்றும் Nginx இடையே மறைந்துவிடும். Tcpdump மூலம் உங்களை ஆயுதபாணியாக்கும் நேரம் இது! ஆனால் முதலில் நீங்கள் பிணைய கட்டமைப்பை புரிந்து கொள்ள வேண்டும். Nginx ப்ராக்ஸி L3 பேலன்சருக்குப் பின்னால் உள்ளது NFware. L3 பேலன்சரிலிருந்து சேவையகத்திற்கு பாக்கெட்டுகளை வழங்க டன்னலிங் பயன்படுத்தப்படுகிறது, இது அதன் தலைப்புகளை பாக்கெட்டுகளில் சேர்க்கிறது:

இந்த வழக்கில், நெட்வொர்க் இந்த சேவையகத்திற்கு Vlan-குறியிடப்பட்ட ட்ராஃபிக் வடிவத்தில் வருகிறது, இது பாக்கெட்டுகளில் அதன் சொந்த புலங்களையும் சேர்க்கிறது:

மேலும் இந்த ட்ராஃபிக்கையும் துண்டு துண்டாக மாற்றலாம் (ஒர்க்கரவுண்டில் இருந்து ஆபத்துக்களை மதிப்பிடும் போது நாங்கள் பேசிய உள்வரும் துண்டு துண்டான போக்குவரத்தின் அதே சிறிய சதவீதம்), இது தலைப்புகளின் உள்ளடக்கத்தையும் மாற்றுகிறது:

மீண்டும்: பாக்கெட்டுகள் ஒரு Vlan குறிச்சொல்லுடன் இணைக்கப்பட்டு, ஒரு சுரங்கப்பாதையுடன் இணைக்கப்பட்டு, துண்டு துண்டாக உள்ளன. இது எவ்வாறு நிகழ்கிறது என்பதை நன்கு புரிந்து கொள்ள, கிளையண்டிலிருந்து Nginx ப்ராக்ஸிக்கான பாக்கெட் வழியைக் கண்டுபிடிப்போம்.

1. பாக்கெட் L3 பேலன்சரை அடைகிறது. தரவு மையத்திற்குள் சரியான திசைதிருப்பலுக்கு, பாக்கெட் ஒரு சுரங்கப்பாதையில் இணைக்கப்பட்டு பிணைய அட்டைக்கு அனுப்பப்படும்.
2. பாக்கெட் + சுரங்கப்பாதை தலைப்புகள் MTU இல் பொருந்தாததால், பாக்கெட் துண்டுகளாக வெட்டப்பட்டு பிணையத்திற்கு அனுப்பப்படுகிறது.
3. L3 பேலன்சருக்குப் பின் உள்ள சுவிட்ச், ஒரு பாக்கெட்டைப் பெறும்போது, ​​அதில் ஒரு Vlan குறியைச் சேர்த்து, அதை அனுப்புகிறது.
4. Nginx ப்ராக்ஸிக்கு முன்னால் உள்ள ஸ்விட்ச், சர்வர் Vlan-இணைக்கப்பட்ட பாக்கெட்டை எதிர்பார்க்கிறது என்பதை (போர்ட் அமைப்புகளின் அடிப்படையில்) பார்க்கிறது, எனவே அது Vlan குறிச்சொல்லை அகற்றாமல் அப்படியே அனுப்புகிறது.
5. லினக்ஸ் தனிப்பட்ட தொகுப்புகளின் துண்டுகளை எடுத்து அவற்றை ஒரு பெரிய தொகுப்பாக இணைக்கிறது.
6. அடுத்து, பாக்கெட் Vlan இடைமுகத்தை அடைகிறது, அங்கு முதல் அடுக்கு அதிலிருந்து அகற்றப்படுகிறது - Vlan encapsulation.
7. லினக்ஸ் அதை சுரங்கப்பாதை இடைமுகத்திற்கு அனுப்புகிறது, அதிலிருந்து மற்றொரு அடுக்கு அகற்றப்படும் - டன்னல் என்காப்சுலேஷன்.

இவை அனைத்தையும் tcpdump க்கு அளவுருக்களாக அனுப்புவதே சிரமம்.
முடிவில் இருந்து ஆரம்பிக்கலாம்: கிளையண்ட்களிடமிருந்து சுத்தமான (தேவையற்ற தலைப்புகள் இல்லாமல்) IP பாக்கெட்டுகள் உள்ளன, vlan மற்றும் டன்னல் என்காப்சுலேஷன் அகற்றப்பட்டதா?

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

இல்லை, சர்வரில் அத்தகைய தொகுப்புகள் எதுவும் இல்லை. எனவே பிரச்சனை முன்பே இருக்க வேண்டும். Vlan என்காப்சுலேஷன் மட்டும் அகற்றப்பட்ட பாக்கெட்டுகள் உள்ளதா?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx என்பது ஹெக்ஸ் வடிவத்தில் கிளையன்ட் ஐபி முகவரி.
32:4 — டன்னல் பாக்கெட்டில் SCR IP எழுதப்பட்ட புலத்தின் முகவரி மற்றும் நீளம்.

புல முகவரியை முரட்டுத்தனமாகத் தேர்ந்தெடுக்க வேண்டியிருந்தது, ஏனெனில் இணையத்தில் அவர்கள் 40, 44, 50, 54 என்று எழுதுகிறார்கள், ஆனால் அங்கு ஐபி முகவரி இல்லை. நீங்கள் ஹெக்ஸில் உள்ள பாக்கெட்டுகளில் ஒன்றைப் பார்க்கலாம் (tcpdump இல் -xx அல்லது -XX அளவுரு) மற்றும் உங்களுக்குத் தெரிந்த ஐபி முகவரியைக் கணக்கிடலாம்.

Vlan மற்றும் Tunnel encapsulation அகற்றப்படாத பாக்கெட் துண்டுகள் உள்ளதா?

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))

இந்த மந்திரம் கடைசியாக உள்ள அனைத்து துண்டுகளையும் நமக்குக் காண்பிக்கும். அநேகமாக, அதே விஷயத்தை ஐபி மூலம் வடிகட்டலாம், ஆனால் நான் முயற்சிக்கவில்லை, ஏனென்றால் இதுபோன்ற பல பாக்கெட்டுகள் இல்லை, மேலும் எனக்குத் தேவையானவை பொது ஓட்டத்தில் எளிதாகக் காணப்பட்டன. இங்கே அவர்கள்:

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

இவை ஒரு தொகுப்பின் இரண்டு துண்டுகள் (அதே ஐடி 53652) ஒரு புகைப்படத்துடன் (எக்ஸிஃப் என்ற சொல் முதல் தொகுப்பில் தெரியும்). இந்த மட்டத்தில் தொகுப்புகள் உள்ளன, ஆனால் டம்ப்களில் இணைக்கப்பட்ட வடிவத்தில் இல்லை என்ற உண்மையின் காரணமாக, பிரச்சனை தெளிவாக சட்டசபையில் உள்ளது. இறுதியாக இதற்கான ஆவண ஆதாரம் உள்ளது!

பாக்கெட் டிகோடர் உருவாக்கத்தைத் தடுக்கும் எந்தச் சிக்கலையும் வெளிப்படுத்தவில்லை. இங்கே முயற்சித்தேன்: hpd.gasmi.net. முதலில், நீங்கள் அங்கு எதையாவது நிரப்ப முயற்சிக்கும்போது, ​​டிகோடர் பாக்கெட் வடிவமைப்பை விரும்பவில்லை. Srcmac மற்றும் Ethertype (துண்டு தகவலுடன் தொடர்புடையது அல்ல) இடையே சில கூடுதல் இரண்டு ஆக்டெட்டுகள் இருப்பது தெரியவந்தது. அவற்றை அகற்றிய பிறகு, குறிவிலக்கி வேலை செய்யத் தொடங்கியது. இருப்பினும், அது எந்த பிரச்சனையும் காட்டவில்லை.
ஒருவர் என்ன சொன்னாலும், அந்த Sysctlகளைத் தவிர வேறு எதுவும் கிடைக்கவில்லை. அளவைப் புரிந்துகொள்வதற்கும் மேலும் செயல்களைத் தீர்மானிப்பதற்கும் சிக்கல் சேவையகங்களைக் கண்டறிவதற்கான வழியைக் கண்டுபிடிப்பதே எஞ்சியிருந்தது. தேவையான கவுண்டர் விரைவாக கண்டுபிடிக்கப்பட்டது:

netstat -s | grep "packet reassembles failed”

இது OID=1.3.6.1.2.1.4.31.1.1.16.1 இன் கீழ் snmpd இல் உள்ளது (ipSystemStatsReasmFails).

"ஐபி ரீ-அசெம்பிளி அல்காரிதம் மூலம் கண்டறியப்பட்ட தோல்விகளின் எண்ணிக்கை (எந்த காரணத்திற்காகவும்: நேரம் முடிந்தது, பிழைகள் போன்றவை)."

சிக்கல் ஆய்வு செய்யப்பட்ட சேவையகங்களின் குழுவில், இரண்டில் இந்த கவுண்டர் வேகமாகவும், இரண்டில் மெதுவாகவும், மேலும் இரண்டில் அது அதிகரிக்கவில்லை. இந்த கவுண்டரின் இயக்கவியலை ஜாவா சர்வரில் உள்ள HTTP பிழைகளின் இயக்கவியலுடன் ஒப்பிட்டுப் பார்த்ததில் ஒரு தொடர்பு உள்ளது. அதாவது, மீட்டர் கண்காணிக்க முடியும்.

சிக்கல்களின் நம்பகமான குறிகாட்டியைக் கொண்டிருப்பது மிகவும் முக்கியமானது, இதன் மூலம் Sysctl திரும்பப் பெறுவது உதவுகிறதா என்பதை நீங்கள் துல்லியமாக தீர்மானிக்க முடியும், ஏனெனில் முந்தைய கதையிலிருந்து இதை பயன்பாட்டிலிருந்து உடனடியாக புரிந்து கொள்ள முடியாது என்பதை நாங்கள் அறிவோம். பயனர்கள் கண்டுபிடிப்பதற்கு முன், உற்பத்தியில் உள்ள அனைத்து சிக்கல் பகுதிகளையும் அடையாளம் காண இந்த காட்டி நம்மை அனுமதிக்கும்.
Sysctl ஐத் திரும்பப் பெற்ற பிறகு, கண்காணிப்பு பிழைகள் நிறுத்தப்பட்டன, இதனால் சிக்கல்களுக்கான காரணம் நிரூபிக்கப்பட்டது, அதே போல் ரோல்பேக் உதவுகிறது.

புதிய கண்காணிப்பு செயல்பாட்டிற்கு வந்த பிற சேவையகங்களில் துண்டு துண்டான அமைப்புகளை நாங்கள் திரும்பப் பெற்றோம், மேலும் எங்கோ முந்தைய இயல்புநிலையை விட அதிக நினைவகத்தை துண்டுகளுக்கு ஒதுக்கினோம் (இது UDP புள்ளிவிவரங்கள், இதன் பகுதி இழப்பு பொதுவான பின்னணியில் கவனிக்கப்படவில்லை) .

மிக முக்கியமான கேள்விகள்

எங்கள் L3 பேலன்சரில் ஏன் பாக்கெட்டுகள் துண்டு துண்டாக உள்ளன? பயனர்களிடமிருந்து பேலன்சர்களுக்கு வரும் பெரும்பாலான பாக்கெட்டுகள் SYN மற்றும் ACK ஆகும். இந்த தொகுப்புகளின் அளவுகள் சிறியவை. ஆனால் அத்தகைய பாக்கெட்டுகளின் பங்கு மிகப் பெரியது என்பதால், அவற்றின் பின்னணியில் துண்டு துண்டாகத் தொடங்கிய பெரிய பாக்கெட்டுகள் இருப்பதை நாங்கள் கவனிக்கவில்லை.

காரணம் உடைந்த கட்டமைப்பு ஸ்கிரிப்ட் advmss Vlan இடைமுகங்களைக் கொண்ட சேவையகங்களில் (அந்த நேரத்தில் உற்பத்தியில் குறியிடப்பட்ட ட்ராஃபிக்கைக் கொண்ட மிகக் குறைவான சேவையகங்கள் இருந்தன). Advmss ஆனது, எங்கள் திசையில் உள்ள பாக்கெட்டுகள் அளவு சிறியதாக இருக்க வேண்டும் என்ற தகவலை வாடிக்கையாளருக்கு தெரிவிக்க அனுமதிக்கிறது, இதனால் சுரங்கப்பாதை தலைப்புகளை இணைத்த பிறகு அவை துண்டு துண்டாக இருக்க வேண்டியதில்லை.

Sysctl ரோல்பேக் ஏன் உதவவில்லை, ஆனால் மறுதொடக்கம் செய்தது ஏன்? Sysctl ஐ ரோல் பேக் செய்வது தொகுப்புகளை இணைப்பதற்கான நினைவகத்தின் அளவை மாற்றியது. அதே நேரத்தில், துண்டுகளுக்கான நினைவகம் வழிதல் என்பது இணைப்புகளின் வேகத்தை குறைக்க வழிவகுத்தது, இது துண்டுகள் வரிசையில் நீண்ட நேரம் தாமதப்படுத்தப்படுவதற்கு வழிவகுத்தது. அதாவது, செயல்முறை சுழற்சியில் சென்றது.
மறுதொடக்கம் நினைவகத்தை அழித்தது மற்றும் எல்லாம் ஒழுங்காகத் திரும்பியது.

தீர்வு இல்லாமல் செய்ய முடியுமா? ஆம், ஆனால் தாக்குதலின் போது பயனர்கள் சேவை இல்லாமல் போகும் அபாயம் அதிகம். நிச்சயமாக, பணிச்சூழலின் பயன்பாடு பயனர்களுக்கான சேவைகளில் ஒன்றின் மந்தநிலை உட்பட பல்வேறு சிக்கல்களை விளைவித்தது, இருப்பினும் செயல்கள் நியாயமானவை என்று நாங்கள் நம்புகிறோம்.

Andrey Timofeev அவர்களுக்கு மிக்க நன்றி (atomofeyev) விசாரணை நடத்துவதில் உதவிக்காக, அலெக்ஸி கிரெனேவ் (devicex) - சேவையகங்களில் சென்டோஸ் மற்றும் கர்னல்களைப் புதுப்பிக்கும் டைட்டானிக் வேலைக்காக. இந்த வழக்கில் ஆரம்பத்தில் இருந்து பல முறை தொடங்க வேண்டிய ஒரு செயல்முறை, அது பல மாதங்கள் இழுத்து ஏன்.

ஆதாரம்: www.habr.com