រឿងអំពីការបាត់កញ្ចប់ DNS ពីជំនួយបច្ចេកទេស Google Cloud

ពី Google Blog Editor៖ តើអ្នកធ្លាប់ឆ្ងល់ថាតើវិស្វករ Google Cloud Technical Solutions (TSE) ដោះស្រាយសំណើជំនួយរបស់អ្នកយ៉ាងដូចម្តេច? វិស្វករជំនួយបច្ចេកទេស TSE ទទួលខុសត្រូវក្នុងការកំណត់អត្តសញ្ញាណ និងកែតម្រូវប្រភពនៃបញ្ហាដែលរាយការណ៍ដោយអ្នកប្រើប្រាស់។ បញ្ហាទាំងនេះមួយចំនួនគឺសាមញ្ញណាស់ ប៉ុន្តែពេលខ្លះអ្នកជួបប្រទះសំបុត្រដែលទាមទារការយកចិត្តទុកដាក់ពីវិស្វករជាច្រើននាក់ក្នុងពេលតែមួយ។ នៅក្នុងអត្ថបទនេះ បុគ្គលិក TSE ម្នាក់នឹងប្រាប់យើងអំពីបញ្ហាដ៏លំបាកមួយពីការអនុវត្តថ្មីៗនេះរបស់គាត់ - ករណីបាត់កញ្ចប់ DNS. នៅក្នុងរឿងនេះ យើងនឹងឃើញពីរបៀបដែលវិស្វករគ្រប់គ្រងដើម្បីដោះស្រាយស្ថានការណ៍ និងអ្វីដែលថ្មីដែលពួកគេរៀននៅពេលជួសជុលកំហុស។ យើងសង្ឃឹមថារឿងនេះមិនត្រឹមតែអប់រំអ្នកអំពីបញ្ហាដែលស៊ីជម្រៅប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងផ្តល់ឱ្យអ្នកនូវការយល់ដឹងអំពីដំណើរការដែលចូលទៅក្នុងការដាក់ពាក្យសុំជំនួយជាមួយ Google Cloud ផងដែរ។

ការដោះស្រាយបញ្ហាគឺជាវិទ្យាសាស្ត្រ និងសិល្បៈ។ វាទាំងអស់ចាប់ផ្តើមជាមួយនឹងការកសាងសម្មតិកម្មអំពីហេតុផលសម្រាប់ឥរិយាបថមិនស្តង់ដារនៃប្រព័ន្ធបន្ទាប់ពីនោះវាត្រូវបានសាកល្បងសម្រាប់កម្លាំង។ ទោះយ៉ាងណាក៏ដោយ មុននឹងយើងបង្កើតសម្មតិកម្ម យើងត្រូវកំណត់ឲ្យបានច្បាស់លាស់ និងកំណត់បញ្ហាឲ្យបានច្បាស់លាស់។ ប្រសិនបើសំណួរស្តាប់ទៅមិនច្បាស់លាស់ នោះអ្នកនឹងត្រូវវិភាគគ្រប់យ៉ាងដោយប្រុងប្រយ័ត្ន។ នេះគឺជា "សិល្បៈ" នៃការដោះស្រាយបញ្ហា។

នៅក្រោម Google Cloud ដំណើរការបែបនេះកាន់តែស្មុគ្រស្មាញជាងមុន ដោយសារ Google Cloud ព្យាយាមអស់ពីសមត្ថភាពដើម្បីធានាភាពឯកជនរបស់អ្នកប្រើប្រាស់របស់វា។ ដោយសារតែនេះ វិស្វករ TSE មិនមានសិទ្ធិចូលប្រើដើម្បីកែសម្រួលប្រព័ន្ធរបស់អ្នក ហើយក៏មិនអាចមើលការកំណត់បានទូលំទូលាយដូចអ្នកប្រើប្រាស់ដែរ។ ដូច្នេះ ដើម្បីសាកល្បងសម្មតិកម្មណាមួយរបស់យើង យើង (វិស្វករ) មិនអាចកែប្រែប្រព័ន្ធបានឆាប់រហ័សនោះទេ។

អ្នកប្រើប្រាស់មួយចំនួនជឿថា យើងនឹងជួសជុលអ្វីៗគ្រប់យ៉ាងដូចជាមេកានិចនៅក្នុងសេវាកម្មរថយន្ត ហើយគ្រាន់តែផ្ញើលេខសម្គាល់ម៉ាស៊ីននិម្មិតមកយើង ចំណែកឯការពិត ដំណើរការកើតឡើងក្នុងទម្រង់សន្ទនា៖ ការប្រមូលព័ត៌មាន បង្កើត និងបញ្ជាក់ (ឬបដិសេធ) សម្មតិកម្ម។ ហើយនៅទីបញ្ចប់ បញ្ហាការសម្រេចចិត្តគឺផ្អែកលើការប្រាស្រ័យទាក់ទងជាមួយអតិថិជន។

បញ្ហានៅក្នុងសំណួរ

ថ្ងៃនេះយើងមានរឿងមួយដែលមានការបញ្ចប់ដ៏ល្អ។ ហេតុផលមួយក្នុងចំណោមហេតុផលសម្រាប់ការដោះស្រាយដោយជោគជ័យនៃករណីដែលបានស្នើឡើងគឺជាការពិពណ៌នាលម្អិត និងត្រឹមត្រូវនៃបញ្ហា។ ខាងក្រោមអ្នកអាចឃើញច្បាប់ចម្លងនៃសំបុត្រទីមួយ (កែសម្រួលដើម្បីលាក់ព័ត៌មានសម្ងាត់)៖

សារនេះមានព័ត៌មានមានប្រយោជន៍ជាច្រើនសម្រាប់យើង៖

• បញ្ជាក់ VM ជាក់លាក់
• បញ្ហាខ្លួនឯងត្រូវបានចង្អុលបង្ហាញ - DNS មិនដំណើរការទេ។
• វាត្រូវបានចង្អុលបង្ហាញកន្លែងដែលបញ្ហាបង្ហាញដោយខ្លួនវា - VM និងកុងតឺន័រ
• ជំហានដែលអ្នកប្រើប្រាស់បានធ្វើដើម្បីកំណត់បញ្ហាត្រូវបានចង្អុលបង្ហាញ។

សំណើនេះត្រូវបានចុះបញ្ជីជា "P1: ផលប៉ះពាល់សំខាន់ - សេវាកម្មមិនអាចប្រើប្រាស់បានក្នុងផលិតកម្ម" ដែលមានន័យថាការត្រួតពិនិត្យជាប្រចាំនៃស្ថានភាព 24/7 យោងតាមគ្រោងការណ៍ "ធ្វើតាមព្រះអាទិត្យ" (អ្នកអាចអានបន្ថែមអំពី អាទិភាពនៃសំណើរបស់អ្នកប្រើ) ជាមួយនឹងការផ្ទេរពីក្រុមជំនួយបច្ចេកទេសមួយទៅក្រុមមួយទៀត ជាមួយនឹងការផ្លាស់ប្តូរតំបន់ពេលវេលានីមួយៗ។ តាមពិតទៅ នៅពេលដែលបញ្ហាបានទៅដល់ក្រុមរបស់យើងនៅទីក្រុង Zurich វាបានជុំវិញពិភពលោករួចហើយ។ មកដល់ពេលនេះ អ្នកប្រើប្រាស់បានចាត់វិធានការកាត់បន្ថយ ប៉ុន្តែមានការភ័យខ្លាចចំពោះស្ថានភាពនៃការផលិតឡើងវិញ ដោយសារមូលហេតុឫសគល់មិនទាន់ត្រូវបានរកឃើញនៅឡើយ។

នៅ​ពេល​សំបុត្រ​ទៅ​ដល់ Zurich យើង​មាន​ព័ត៌មាន​ខាង​ក្រោម​រួច​ហើយ៖

• មាតិកា /etc/hosts
• មាតិកា /etc/resolv.conf
• សេចក្តីសន្និដ្ឋាន iptables-save
• ប្រមូលផ្តុំដោយក្រុម ngrep ឯកសារ pcap

ជាមួយនឹងទិន្នន័យនេះ យើងបានត្រៀមខ្លួនរួចជាស្រេចដើម្បីចាប់ផ្តើម "ការស៊ើបអង្កេត" និងដំណាក់កាលដោះស្រាយបញ្ហា។

ជំហានដំបូងរបស់យើង។

ជាដំបូង យើងបានពិនិត្យកំណត់ហេតុ និងស្ថានភាពរបស់ម៉ាស៊ីនមេទិន្នន័យមេតា ហើយត្រូវប្រាកដថាវាដំណើរការបានត្រឹមត្រូវ។ ម៉ាស៊ីនមេទិន្នន័យមេតាឆ្លើយតបទៅនឹងអាសយដ្ឋាន IP 169.254.169.254 ហើយក្នុងចំណោមរបស់ផ្សេងទៀត ទទួលខុសត្រូវចំពោះការគ្រប់គ្រងឈ្មោះដែន។ យើងក៏បានពិនិត្យពីរដងថាជញ្ជាំងភ្លើងដំណើរការត្រឹមត្រូវជាមួយ VM និងមិនទប់ស្កាត់កញ្ចប់ព័ត៌មាន។

វាជាប្រភេទនៃបញ្ហាចំលែកមួយចំនួន៖ ការត្រួតពិនិត្យ nmap បានបដិសេធសម្មតិកម្មចម្បងរបស់យើងអំពីការបាត់បង់កញ្ចប់ព័ត៌មាន UDP ដូច្នេះយើងបានបង្កើតជម្រើស និងវិធីជាច្រើនទៀតដើម្បីពិនិត្យពួកវាដោយបញ្ញាស្មារតី៖

• តើកញ្ចប់ត្រូវបានទម្លាក់ដោយជ្រើសរើសទេ? => ពិនិត្យមើលច្បាប់ iptables
• តូចពេកអត់? បុគ្គល? => ពិនិត្យលទ្ធផល ip a show
• តើបញ្ហាប៉ះពាល់ដល់តែកញ្ចប់ UDP ឬ TCP ដែរឬទេ? => បើកឡានទៅឆ្ងាយ dig +tcp
• តើ​កញ្ចប់​ឯកសារ​ដែល​បង្កើត​ឡើង​បាន​ត្រឡប់​មក​វិញ​ទេ? => បើកឡានទៅឆ្ងាយ tcpdump
• តើ libdns ដំណើរការត្រឹមត្រូវទេ? => បើកឡានទៅឆ្ងាយ strace ដើម្បីពិនិត្យមើលការបញ្ជូនកញ្ចប់ព័ត៌មានក្នុងទិសដៅទាំងពីរ

នៅទីនេះយើងសម្រេចចិត្តហៅអ្នកប្រើប្រាស់ដើម្បីដោះស្រាយបញ្ហាផ្ទាល់។

ក្នុងអំឡុងពេលហៅទូរសព្ទ យើងអាចពិនិត្យមើលរឿងជាច្រើន៖

• បន្ទាប់ពីការត្រួតពិនិត្យជាច្រើនដង យើងដកច្បាប់ iptables ចេញពីបញ្ជីមូលហេតុ
• យើងពិនិត្យមើលចំណុចប្រទាក់បណ្តាញ និងតារាងនាំផ្លូវ ហើយពិនិត្យពីរដងថា MTU ត្រឹមត្រូវ។
• យើងរកឃើញនោះ។ dig +tcp google.com (TCP) ដំណើរការដូចដែលវាគួរតែ ប៉ុន្តែ dig google.com (UDP) មិនដំណើរការទេ។
• ដោយបានបើកឡានទៅឆ្ងាយ tcpdump វានៅតែដំណើរការ digយើងរកឃើញថាកញ្ចប់ UDP កំពុងត្រូវបានបញ្ជូនមកវិញ
• យើងបើកឡានទៅឆ្ងាយ strace dig google.com ហើយយើងឃើញពីរបៀបជីកបានត្រឹមត្រូវ។ sendmsg() и recvms()ទោះយ៉ាងណាក៏ដោយ ទីពីរត្រូវបានរំខានដោយការអស់ពេល

ជាអកុសល ចុងបញ្ចប់នៃការផ្លាស់ប្តូរបានមកដល់ ហើយយើងត្រូវបានគេបង្ខំឱ្យបង្កើនបញ្ហាទៅតំបន់ពេលវេលាបន្ទាប់។ ទោះជាយ៉ាងណាក៏ដោយ សំណើនេះបានធ្វើឱ្យមានការចាប់អារម្មណ៍នៅក្នុងក្រុមរបស់យើង ហើយសហសេវិកម្នាក់បានស្នើឱ្យបង្កើតកញ្ចប់ DNS ដំបូងដោយប្រើម៉ូឌុល Python ដែលខូច។

from scapy.all import *

answer = sr1(IP(dst="169.254.169.254")/UDP(dport=53)/DNS(rd=1,qd=DNSQR(qname="google.com")),verbose=0)
print ("169.254.169.254", answer[DNS].summary())

បំណែកនេះបង្កើតកញ្ចប់ DNS ហើយផ្ញើសំណើទៅម៉ាស៊ីនមេទិន្នន័យមេតា។

អ្នកប្រើប្រាស់ដំណើរការកូដ ការឆ្លើយតប DNS ត្រូវបានត្រលប់មកវិញ ហើយកម្មវិធីទទួលបានវា ដោយបញ្ជាក់ថាមិនមានបញ្ហានៅកម្រិតបណ្តាញទេ។

បន្ទាប់ពី "ដំណើរកម្សាន្តជុំវិញពិភពលោក" មួយផ្សេងទៀត សំណើត្រឡប់ទៅក្រុមរបស់យើង ហើយខ្ញុំផ្ទេរវាទាំងស្រុងទៅខ្លួនខ្ញុំ ដោយគិតថាវានឹងកាន់តែងាយស្រួលសម្រាប់អ្នកប្រើប្រាស់ ប្រសិនបើសំណើឈប់ធ្វើរង្វង់ពីកន្លែងមួយទៅកន្លែងមួយ។

ក្នុងពេលជាមួយគ្នានេះ អ្នកប្រើប្រាស់យល់ព្រមផ្តល់រូបភាពនៃរូបភាពប្រព័ន្ធ។ នេះគឺជាដំណឹងល្អណាស់៖ សមត្ថភាពក្នុងការសាកល្បងប្រព័ន្ធដោយខ្លួនឯងធ្វើឱ្យការដោះស្រាយបញ្ហាលឿនជាងមុនព្រោះខ្ញុំលែងត្រូវការឱ្យអ្នកប្រើប្រាស់ដំណើរការពាក្យបញ្ជាផ្ញើលទ្ធផលឱ្យខ្ញុំហើយវិភាគវាខ្ញុំអាចធ្វើអ្វីៗគ្រប់យ៉ាងដោយខ្លួនឯង!

មិត្តរួមការងាររបស់ខ្ញុំចាប់ផ្តើមច្រណែនខ្ញុំបន្តិច។ ពេលអាហារថ្ងៃត្រង់ យើងពិភាក្សាអំពីការប្រែចិត្ត ប៉ុន្តែគ្មាននរណាម្នាក់ដឹងថាមានអ្វីកើតឡើងនោះទេ។ ជាសំណាងល្អ អ្នកប្រើប្រាស់ខ្លួនឯងបានចាត់វិធានការកាត់បន្ថយផលវិបាករួចហើយ និងមិនប្រញាប់ ដូច្នេះយើងមានពេលដើម្បីស្រាយបញ្ហា។ ហើយ​ដោយសារ​យើង​មាន​រូបភាព យើង​អាច​ដំណើរការ​ការ​សាកល្បង​ណា​មួយ​ដែល​យើង​ចាប់អារម្មណ៍។ អស្ចារ្យ!

បោះជំហានថយក្រោយ

សំណួរសម្ភាសន៍ដ៏ពេញនិយមបំផុតមួយសម្រាប់មុខតំណែងវិស្វករប្រព័ន្ធគឺ៖ “តើមានអ្វីកើតឡើងនៅពេលអ្នក ping www.google.com? សំណួរគឺអស្ចារ្យណាស់ ចាប់តាំងពីបេក្ខជនត្រូវពណ៌នាអ្វីៗគ្រប់យ៉ាងពីសែលទៅទំហំអ្នកប្រើប្រាស់ រហូតដល់ខឺណែលប្រព័ន្ធ ហើយបន្ទាប់មកទៅកាន់បណ្តាញ។ ខ្ញុំញញឹម៖ ពេលខ្លះសំណួរសម្ភាសន៍ប្រែជាមានប្រយោជន៍ក្នុងជីវិតពិត...

ខ្ញុំសម្រេចចិត្តអនុវត្តសំណួរធនធានមនុស្សនេះទៅនឹងបញ្ហាបច្ចុប្បន្ន។ និយាយជារួម នៅពេលអ្នកព្យាយាមកំណត់ឈ្មោះ DNS នោះនឹងកើតឡើងដូចខាងក្រោម៖

1. កម្មវិធីហៅបណ្ណាល័យប្រព័ន្ធដូចជា libdns
2. libdns ពិនិត្យមើលការកំណត់ប្រព័ន្ធដែលម៉ាស៊ីនមេ DNS ដែលវាគួរតែទាក់ទង (ក្នុងដ្យាក្រាមនេះគឺ 169.254.169.254 ម៉ាស៊ីនមេទិន្នន័យមេតា)
3. libdns ប្រើការហៅតាមប្រព័ន្ធដើម្បីបង្កើតរន្ធ UDP (SOKET_DGRAM) ហើយផ្ញើកញ្ចប់ UDP ជាមួយនឹងសំណួរ DNS ក្នុងទិសដៅទាំងពីរ
4. តាមរយៈ sysctl interface អ្នកអាចកំណត់រចនាសម្ព័ន្ធ UDP stack នៅកម្រិតខឺណែល
5. ខឺណែលធ្វើអន្តរកម្មជាមួយផ្នែករឹង ដើម្បីបញ្ជូនកញ្ចប់ព័ត៌មានតាមបណ្តាញតាមរយៈចំណុចប្រទាក់បណ្តាញ
6. Hypervisor ចាប់ និងបញ្ជូនកញ្ចប់ព័ត៌មានទៅម៉ាស៊ីនមេទិន្នន័យមេតា នៅពេលទំនាក់ទំនងជាមួយវា។
7. ម៉ាស៊ីនមេទិន្នន័យមេតា តាមវេទមន្តរបស់វាកំណត់ឈ្មោះ DNS និងត្រឡប់ការឆ្លើយតបដោយប្រើវិធីសាស្ត្រដូចគ្នា។

ខ្ញុំសូមរំលឹកអ្នកថា សម្មតិកម្មអ្វីដែលយើងបានពិចារណារួចហើយ៖

សម្មតិកម្ម៖ បណ្ណាល័យខូច

• តេស្តទី 1៖ រត់ខ្សែរនៅក្នុងប្រព័ន្ធ ពិនិត្យមើលថា dig ហៅការហៅប្រព័ន្ធត្រឹមត្រូវ។
• លទ្ធផល៖ ការហៅប្រព័ន្ធត្រឹមត្រូវត្រូវបានហៅ
• ការធ្វើតេស្តទី 2: ដោយប្រើ srapy ដើម្បីពិនិត្យមើលថាតើយើងអាចកំណត់ឈ្មោះដោយឆ្លងកាត់បណ្ណាល័យប្រព័ន្ធ
• លទ្ធផល៖ យើងអាចធ្វើបាន
• តេស្តទី 3៖ ដំណើរការ rpm –V នៅលើកញ្ចប់ libdns និងឯកសារបណ្ណាល័យ md5sum
• លទ្ធផល៖ លេខកូដបណ្ណាល័យគឺដូចគ្នាបេះបិទទាំងស្រុងទៅនឹងកូដនៅក្នុងប្រព័ន្ធប្រតិបត្តិការ
• តេស្តទី 4៖ ម៉ោនរូបភាពប្រព័ន្ធ root របស់អ្នកប្រើនៅលើ VM ដោយគ្មានឥរិយាបថនេះ ដំណើរការ chroot មើលថាតើ DNS ដំណើរការឬអត់
• លទ្ធផល៖ DNS ដំណើរការបានត្រឹមត្រូវ។

សេចក្តីសន្និដ្ឋានផ្អែកលើការធ្វើតេស្ត៖ បញ្ហាគឺមិនមាននៅក្នុងបណ្ណាល័យទេ។

សម្មតិកម្ម៖ មានកំហុសនៅក្នុងការកំណត់ DNS

• តេស្តទី 1៖ ពិនិត្យមើល tcpdump ហើយមើលថាតើកញ្ចប់ DNS ត្រូវបានផ្ញើ និងត្រឡប់ត្រឹមត្រូវដែរឬទេ បន្ទាប់ពីដំណើរការជីក
• លទ្ធផល៖ កញ្ចប់ត្រូវបានបញ្ជូនយ៉ាងត្រឹមត្រូវ។
• តេស្តទី ២៖ ពិនិត្យពីរដងលើម៉ាស៊ីនមេ /etc/nsswitch.conf и /etc/resolv.conf
• លទ្ធផល៖ អ្វីៗគឺត្រឹមត្រូវ។

សេចក្តីសន្និដ្ឋានផ្អែកលើការធ្វើតេស្ត៖ បញ្ហាគឺមិនមែនជាមួយការកំណត់ DNS ទេ។

សម្មតិកម្ម៖ ស្នូលខូច

• សាកល្បង៖ ដំឡើងខឺណែលថ្មី ពិនិត្យហត្ថលេខា ចាប់ផ្ដើមឡើងវិញ
• លទ្ធផល៖ អាកប្បកិរិយាស្រដៀងគ្នា

សេចក្តីសន្និដ្ឋានផ្អែកលើការធ្វើតេស្ត៖ ខឺណែលមិនខូចទេ។

សម្មតិកម្ម៖ ឥរិយាបថមិនត្រឹមត្រូវនៃបណ្តាញអ្នកប្រើប្រាស់ (ឬចំណុចប្រទាក់បណ្តាញ hypervisor)

• តេស្តទី 1៖ ពិនិត្យមើលការកំណត់ជញ្ជាំងភ្លើងរបស់អ្នក។
• លទ្ធផល៖ ជញ្ជាំងភ្លើងឆ្លងកាត់កញ្ចប់ DNS ទាំងនៅលើម៉ាស៊ីន និង GCP
• តេស្តទី 2៖ ស្ទាក់ចាប់ចរាចរណ៍ និងត្រួតពិនិត្យភាពត្រឹមត្រូវនៃការបញ្ជូន និងការបញ្ជូនសំណើ DNS មកវិញ
• លទ្ធផល៖ tcpdump បញ្ជាក់ថាម៉ាស៊ីនបានទទួលកញ្ចប់ព័ត៌មានត្រឡប់មកវិញ

សេចក្តីសន្និដ្ឋានផ្អែកលើការធ្វើតេស្ត៖ បញ្ហាគឺមិនមាននៅក្នុងបណ្តាញទេ។

សម្មតិកម្ម៖ ម៉ាស៊ីនមេទិន្នន័យមេតាមិនដំណើរការទេ។

• តេស្តទី 1៖ ពិនិត្យមើលកំណត់ហេតុម៉ាស៊ីនមេទិន្នន័យមេតាសម្រាប់ភាពមិនប្រក្រតី
• លទ្ធផល៖ មិនមានភាពមិនប្រក្រតីនៅក្នុងកំណត់ហេតុទេ។
• តេស្តទី 2៖ ឆ្លងកាត់ម៉ាស៊ីនមេទិន្នន័យមេតាតាមរយៈ dig @8.8.8.8
• លទ្ធផល៖ ដំណោះស្រាយត្រូវបានខូច ទោះបីជាមិនប្រើម៉ាស៊ីនមេទិន្នន័យមេតាក៏ដោយ។

សេចក្តីសន្និដ្ឋានផ្អែកលើការធ្វើតេស្ត៖ បញ្ហាគឺមិនមែនជាមួយម៉ាស៊ីនមេទិន្នន័យមេតាទេ។

បន្ទាត់ខាងក្រោម: យើងបានសាកល្បងប្រព័ន្ធរងទាំងអស់ លើកលែងតែ ការកំណត់ពេលដំណើរការ!

ចូលទៅក្នុងការកំណត់ពេលដំណើរការខឺណែល។

ដើម្បីកំណត់រចនាសម្ព័ន្ធដំណើរការខឺណែល អ្នកអាចប្រើជម្រើសបន្ទាត់ពាក្យបញ្ជា (grub) ឬចំណុចប្រទាក់ sysctl ។ ខ្ញុំបានមើលចូល /etc/sysctl.conf ហើយគ្រាន់តែគិត ខ្ញុំបានរកឃើញការកំណត់ផ្ទាល់ខ្លួនជាច្រើន។ ដោយមានអារម្មណ៍ថាខ្ញុំបានចាប់យកអ្វីមួយ ខ្ញុំបានបោះបង់ការកំណត់មិនមែនបណ្តាញ ឬមិនមែន tcp ទាំងអស់ ដោយនៅសល់ជាមួយការកំណត់ភ្នំ net.core. បន្ទាប់មកខ្ញុំបានទៅកន្លែងដែលការអនុញ្ញាតម៉ាស៊ីនស្ថិតនៅក្នុង VM ហើយចាប់ផ្តើមអនុវត្តការកំណត់ម្តងមួយៗ ម្តងមួយៗជាមួយ VM ដែលខូច រហូតដល់ខ្ញុំរកឃើញពិរុទ្ធជន៖

net.core.rmem_default = 2147483647

នេះគឺជាការកំណត់រចនាសម្ព័ន្ធបំបែក DNS! ខ្ញុំបានរកឃើញអាវុធឃាតកម្ម។ ប៉ុន្តែហេតុអ្វីបានជារឿងនេះកើតឡើង? ខ្ញុំនៅតែត្រូវការការជម្រុញ។

ទំហំសតិបណ្ដោះអាសន្នកញ្ចប់ DNS មូលដ្ឋានត្រូវបានកំណត់រចនាសម្ព័ន្ធតាមរយៈ net.core.rmem_default. តម្លៃធម្មតាគឺនៅកន្លែងណាមួយប្រហែល 200KiB ប៉ុន្តែប្រសិនបើម៉ាស៊ីនមេរបស់អ្នកទទួលបានកញ្ចប់ DNS ច្រើន អ្នកប្រហែលជាចង់បង្កើនទំហំផ្ទុក។ ប្រសិនបើសតិបណ្ដោះអាសន្នពេញ នៅពេលដែលកញ្ចប់ព័ត៌មានថ្មីមកដល់ ឧទាហរណ៍ ដោយសារកម្មវិធីមិនដំណើរការវាលឿនគ្រប់គ្រាន់ នោះអ្នកនឹងចាប់ផ្តើមបាត់បង់កញ្ចប់ព័ត៌មាន។ អតិថិជនរបស់យើងបានបង្កើនទំហំផ្ទុកទិន្នន័យឱ្យបានត្រឹមត្រូវ ដោយសារគាត់ខ្លាចបាត់បង់ទិន្នន័យ ដោយសារគាត់កំពុងប្រើកម្មវិធីសម្រាប់ប្រមូលម៉ែត្រតាមរយៈកញ្ចប់ DNS ។ តម្លៃដែលគាត់បានកំណត់គឺអតិបរមាដែលអាចធ្វើទៅបាន៖ 231-1 (ប្រសិនបើកំណត់ទៅ 231 ខឺណែលនឹងត្រឡប់ "ការប្រកែកមិនត្រឹមត្រូវ")។

ភ្លាមៗនោះខ្ញុំបានដឹងថាហេតុអ្វីបានជា nmap និង scapy ដំណើរការបានត្រឹមត្រូវ៖ ពួកគេកំពុងប្រើរន្ធឆៅ! រន្ធឆៅគឺខុសពីរន្ធធម្មតា៖ ពួកវាឆ្លងកាត់ iptables ហើយវាមិនជាប់ទេ!

ប៉ុន្តែហេតុអ្វីបានជា "សតិបណ្ដោះអាសន្នធំពេក" បង្កបញ្ហា? វាច្បាស់ណាស់ថាមិនដំណើរការដូចបំណងទេ។

នៅចំណុចនេះខ្ញុំអាចបង្កើតបញ្ហានៅលើខឺណែលច្រើន និងការចែកចាយច្រើន។ បញ្ហាបានលេចឡើងនៅលើខឺណែល 3.x រួចហើយ ហើយឥឡូវនេះវាក៏បានលេចឡើងនៅលើខឺណែល 5.x ផងដែរ។

ជាការពិតនៅពេលចាប់ផ្តើម

sysctl -w net.core.rmem_default=$((2**31-1))

DNS បានឈប់ដំណើរការ។

ខ្ញុំចាប់ផ្តើមស្វែងរកតម្លៃការងារតាមរយៈក្បួនដោះស្រាយការស្វែងរកប្រព័ន្ធគោលពីរសាមញ្ញ ហើយបានរកឃើញថាប្រព័ន្ធដំណើរការជាមួយ 2147481343 ប៉ុន្តែលេខនេះគឺជាសំណុំលេខដែលគ្មានន័យសម្រាប់ខ្ញុំ។ ខ្ញុំបានស្នើឱ្យអតិថិជនសាកល្បងលេខនេះ ហើយគាត់បានឆ្លើយតបថាប្រព័ន្ធដំណើរការជាមួយ google.com ប៉ុន្តែនៅតែផ្តល់កំហុសជាមួយដែនផ្សេងទៀត ដូច្នេះខ្ញុំបានបន្តការស៊ើបអង្កេតរបស់ខ្ញុំ។

ខ្ញុំបានដំឡើង នាឡិការទម្លាក់ឧបករណ៍ដែលគួរត្រូវបានប្រើប្រាស់ពីមុន៖ វាបង្ហាញយ៉ាងច្បាស់ពីកន្លែងដែលកញ្ចប់ព័ត៌មានបញ្ចប់នៅក្នុងខឺណែល។ ពិរុទ្ធជនគឺជាមុខងារ udp_queue_rcv_skb. ខ្ញុំបានទាញយកប្រភពខឺណែល ហើយបន្ថែមមួយចំនួន មុខងារ។ printk ដើម្បីតាមដានកន្លែងដែលកញ្ចប់ព័ត៌មានបញ្ចប់។ ខ្ញុំបានរកឃើញស្ថានភាពត្រឹមត្រូវ។ ifហើយគ្រាន់តែសម្លឹងមើលវាមួយរយៈ ព្រោះវាជាពេលដែលអ្វីៗទាំងអស់បានមកជាមួយគ្នាជារូបភាពទាំងមូល៖ 231-1 ជាលេខគ្មានន័យ ដែនមិនដំណើរការ... វាជាបំណែកនៃកូដនៅក្នុង __udp_enqueue_schedule_skb:

if (rmem > (size + sk->sk_rcvbuf))
		goto uncharge_drop;

សូមចំណាំ:

• rmem ជាប្រភេទ int
• size ជាប្រភេទ u16 (unsigned sixteen-bit int) និងរក្សាទុកទំហំកញ្ចប់
• sk->sk_rcybuf ជាប្រភេទ int និងរក្សាទុកទំហំសតិបណ្ដោះអាសន្ន ដែលតាមនិយមន័យគឺស្មើនឹងតម្លៃនៅក្នុង net.core.rmem_default

នៅពេល sk_rcvbuf ខិតទៅជិតលេខ 231 ការបូកសរុបទំហំកញ្ចប់ព័ត៌មានអាចទទួលបានលទ្ធផល ចំនួនគត់លើស. ហើយដោយសារវាជា int តម្លៃរបស់វាក្លាយជាអវិជ្ជមាន ដូច្នេះលក្ខខណ្ឌក្លាយជាពិត នៅពេលដែលវាគួរតែមិនពិត (អ្នកអាចអានបន្ថែមអំពីបញ្ហានេះនៅ តំណភ្ជាប់).

កំហុស​អាច​ត្រូវ​បាន​កែ​តម្រូវ​តាម​វិធី​តូចតាច៖ ដោយ​ការ​ចាក់ unsigned int. ខ្ញុំបានអនុវត្តការជួសជុល ហើយចាប់ផ្ដើមប្រព័ន្ធឡើងវិញ ហើយ DNS ដំណើរការម្តងទៀត។

រសជាតិនៃជ័យជំនះ

ខ្ញុំបានបញ្ជូនការរកឃើញរបស់ខ្ញុំទៅអតិថិជន ហើយផ្ញើ អិលខេអិល បំណះខឺណែល ខ្ញុំរីករាយ៖ រាល់រូបផ្គុំទាំងអស់ត្រូវគ្នា ខ្ញុំអាចពន្យល់បានច្បាស់ពីមូលហេតុដែលយើងសង្កេតឃើញនូវអ្វីដែលយើងសង្កេត ហើយសំខាន់បំផុតនោះ យើងអាចស្វែងរកដំណោះស្រាយចំពោះបញ្ហាបាន ដោយសារក្រុមការងាររបស់យើង!

វាមានតម្លៃក្នុងការទទួលស្គាល់ថាករណីនេះប្រែទៅជាកម្រ ហើយជាសំណាងល្អយើងកម្រទទួលបានសំណើស្មុគស្មាញបែបនេះពីអ្នកប្រើប្រាស់ណាស់។

ប្រភព: www.habr.com