តោះរាប់ភ្នាក់ងារ "អធិការ"

វាមិនមែនជារឿងសម្ងាត់ទេដែលការគ្រប់គ្រងការទប់ស្កាត់នៅក្នុងបញ្ជីព័ត៌មានហាមឃាត់នៅក្នុងប្រទេសរុស្ស៊ីត្រូវបានត្រួតពិនិត្យដោយប្រព័ន្ធស្វ័យប្រវត្តិ "អធិការ" ។ របៀបដែលវាដំណើរការត្រូវបានសរសេរយ៉ាងល្អនៅទីនេះ អត្ថបទនៅលើ Habrរូបភាពពីកន្លែងតែមួយ៖

បានដំឡើងដោយផ្ទាល់នៅឯអ្នកផ្តល់សេវា ម៉ូឌុល "ភ្នាក់ងារអធិការកិច្ច":

ម៉ូឌុល "ភ្នាក់ងារអធិការកិច្ច" គឺជាធាតុរចនាសម្ព័ន្ធនៃប្រព័ន្ធស្វ័យប្រវត្តិ "អធិការ" (AS "អធិការ") ។ ប្រព័ន្ធនេះត្រូវបានរចនាឡើងដើម្បីត្រួតពិនិត្យការអនុលោមតាមប្រតិបត្តិករទូរគមនាគមន៍ជាមួយនឹងតម្រូវការរឹតបន្តឹងការចូលប្រើក្នុងក្របខ័ណ្ឌនៃបទប្បញ្ញត្តិដែលបានបង្កើតឡើងដោយមាត្រា 15.1-15.4 នៃច្បាប់សហព័ន្ធថ្ងៃទី 27 ខែកក្កដា ឆ្នាំ 2006 លេខ 149-FZ "ស្តីពីព័ត៌មាន បច្ចេកវិទ្យាព័ត៌មាន និងការការពារព័ត៌មាន។ ”

គោលបំណងសំខាន់នៃការបង្កើត AS "Revizor" គឺដើម្បីធានាឱ្យមានការត្រួតពិនិត្យការអនុលោមតាមប្រតិបត្តិករទូរគមនាគមន៍ជាមួយនឹងតម្រូវការដែលបានបង្កើតឡើងដោយមាត្រា 15.1-15.4 នៃច្បាប់សហព័ន្ធថ្ងៃទី 27 ខែកក្កដាឆ្នាំ 2006 លេខ 149-FZ "ស្តីពីព័ត៌មាន បច្ចេកវិទ្យាព័ត៌មាន និងការការពារព័ត៌មាន។ " នៅក្នុងលក្ខខណ្ឌនៃការកំណត់អត្តសញ្ញាណការពិតនៃការចូលប្រើព័ត៌មានហាមឃាត់ និងការទទួលបានសម្ភារៈគាំទ្រ (ទិន្នន័យ) អំពីការរំលោភដើម្បីរឹតបន្តឹងការចូលប្រើព័ត៌មានហាមឃាត់។

ដោយគិតពីការពិតដែលថាប្រសិនបើមិនមែនទាំងអស់ទេនោះអ្នកផ្តល់សេវាជាច្រើនបានដំឡើងឧបករណ៍នេះគួរតែមានបណ្តាញដ៏ធំនៃការស៊ើបអង្កេត beacon ដូចជា RIPE Atlas និងសូម្បីតែច្រើនទៀត ប៉ុន្តែជាមួយនឹងការចូលដំណើរការបិទ។ ទោះជាយ៉ាងណាក៏ដោយ beacon គឺជា beacon សម្រាប់បញ្ជូនសញ្ញាទៅគ្រប់ទិសទី ប៉ុន្តែចុះយ៉ាងណាបើយើងចាប់វាហើយឃើញអ្វីដែលយើងចាប់បានហើយតើមានប៉ុន្មាន?

មុននឹងយើងរាប់ សូមមើលថាហេតុអ្វីបានជាវាអាចទៅរួច។

បន្តិចនៃទ្រឹស្តីមួយ

ភ្នាក់ងារពិនិត្យមើលភាពអាចរកបាននៃធនធាន រួមទាំងតាមរយៈសំណើ HTTP(S) ដូចជាវា៖

TCP, 14678  >  80, "[SYN] Seq=0"
TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

HTTP, "GET /somepage HTTP/1.1"
TCP, 80  >  14678, "[ACK] Seq=1 Ack=71"
HTTP, "HTTP/1.1 302 Found"

TCP, 14678  >  80, "[FIN, ACK] Seq=71 Ack=479"
TCP, 80  >  14678, "[FIN, ACK] Seq=479 Ack=72"
TCP, 14678  >  80, "[ACK] Seq=72 Ack=480"

បន្ថែមពីលើបន្ទុក សំណើក៏មានដំណាក់កាលបង្កើតការតភ្ជាប់ផងដែរ៖ ការផ្លាស់ប្តូរ SYN и SYN-ACKនិងដំណាក់កាលនៃការបញ្ចប់ការតភ្ជាប់៖ FIN-ACK.

ការចុះឈ្មោះព័ត៌មានហាមឃាត់មានប្រភេទជាច្រើននៃការទប់ស្កាត់។ ជាក់ស្តែង ប្រសិនបើធនធានត្រូវបានរារាំងដោយអាសយដ្ឋាន IP ឬឈ្មោះដែន នោះយើងនឹងមិនឃើញសំណើណាមួយឡើយ។ ទាំងនេះគឺជាប្រភេទការទប់ស្កាត់ដែលបំផ្លិចបំផ្លាញបំផុត ដែលនាំទៅដល់ភាពមិនអាចចូលដំណើរការបាននៃធនធានទាំងអស់នៅលើអាសយដ្ឋាន IP មួយ ឬព័ត៌មានទាំងអស់នៅលើដែន។ វាក៏មានប្រភេទ "តាម URL" នៃការទប់ស្កាត់ផងដែរ។ ក្នុងករណីនេះ ប្រព័ន្ធចម្រោះត្រូវតែញែកបឋមកថាសំណើ HTTP ដើម្បីកំណត់ច្បាស់នូវអ្វីដែលត្រូវទប់ស្កាត់។ ហើយមុនពេលវា ដូចដែលអាចមើលឃើញខាងលើ គួរតែមានដំណាក់កាលបង្កើតការតភ្ជាប់ ដែលអ្នកអាចព្យាយាមតាមដាន ព្រោះភាគច្រើនទំនងជាតម្រងនឹងខកខានវា។

ដើម្បីធ្វើដូច្នេះ អ្នកត្រូវជ្រើសរើសដែនឥតគិតថ្លៃដែលសមស្របជាមួយនឹងប្រភេទ "URL" និង HTTP ដើម្បីជួយសម្រួលដល់ការងាររបស់ប្រព័ន្ធចម្រោះ ដែលគេបោះបង់ចោលជាយូរមកហើយ ដើម្បីកាត់បន្ថយការចូលនៃចរាចរណ៍បន្ថែមលើកលែងតែភ្នាក់ងារ។ កិច្ចការនេះបានប្រែក្លាយទៅជាមិនពិបាកទាល់តែសោះ វាមានដែនឥតគិតថ្លៃជាច្រើននៅក្នុងការចុះឈ្មោះព័ត៌មានហាមឃាត់ និងសម្រាប់គ្រប់រសជាតិ។ ដូច្នេះ ដែនត្រូវបានទិញ និងភ្ជាប់ទៅអាសយដ្ឋាន IP នៅលើ VPS ដែលកំពុងដំណើរការ tcpdump ហើយការរាប់បានចាប់ផ្តើម។

សវនកម្ម "សវនករ"

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

ដែលមិនមែនជារឿងគួរឱ្យភ្ញាក់ផ្អើលនោះទេ សូម្បីតែនៅលើដែនដែលគ្មាននរណាម្នាក់ត្រូវការ និងនៅលើ IP ដែលមិនធ្លាប់ប្រើ វានឹងមានព័ត៌មានជាច្រើនដែលមិនបានស្នើសុំ ដូចជាអ៊ីនធឺណិតទំនើប។ ប៉ុន្តែជាសំណាងល្អ ខ្ញុំគ្រាន់តែត្រូវការសំណើសម្រាប់ URL ជាក់លាក់មួយ ដូច្នេះម៉ាស៊ីនស្កេន និងឧបករណ៍បំបែកពាក្យសម្ងាត់ទាំងអស់ត្រូវបានរកឃើញយ៉ាងឆាប់រហ័ស។ ដូចគ្នានេះផងដែរ វាងាយស្រួលយល់ណាស់ កន្លែងដែលទឹកជំនន់គឺផ្អែកលើការស្នើសុំស្រដៀងគ្នា។ បន្ទាប់មក ខ្ញុំបានចងក្រងភាពញឹកញាប់នៃការកើតឡើងនៃអាសយដ្ឋាន IP ហើយបានឆ្លងកាត់ផ្នែកខាងលើទាំងមូលដោយដៃ ដោយបំបែកអ្នកដែលខកខានវានៅដំណាក់កាលមុន។ លើសពីនេះ ខ្ញុំបានកាត់ចេញនូវប្រភពទាំងអស់ដែលត្រូវបានផ្ញើក្នុងកញ្ចប់តែមួយ មិនមានច្រើននៃពួកគេទៀតទេ។ ហើយនេះជាអ្វីដែលបានកើតឡើង៖

ការបំប្លែងសារជាអក្សរតូច។ ជាងមួយថ្ងៃក្រោយមក អ្នកផ្តល់សេវាបង្ហោះរបស់ខ្ញុំបានផ្ញើលិខិតមួយដែលមានខ្លឹមសារដែលសម្រួលដោយនិយាយថាកន្លែងរបស់អ្នកមានធនធានពីបញ្ជីហាមឃាត់ RKN ដូច្នេះវាត្រូវបានរារាំង។ ដំបូងខ្ញុំគិតថាគណនីរបស់ខ្ញុំត្រូវបានបិទ នេះមិនមែនជាករណីនោះទេ។ បន្ទាប់មក ខ្ញុំគិតថាពួកគេគ្រាន់តែព្រមានខ្ញុំអំពីអ្វីមួយដែលខ្ញុំបានដឹងរួចហើយ។ ប៉ុន្តែវាបានប្រែក្លាយថា hoster បានបើកតម្រងរបស់វានៅពីមុខដែនរបស់ខ្ញុំ ហើយជាលទ្ធផលខ្ញុំបានស្ថិតនៅក្រោមការត្រងពីរដង៖ ពីអ្នកផ្តល់សេវា និងពី hoster ។ តម្រង​បាន​ឆ្លង​ផុត​តែ​ការ​បញ្ចប់​នៃ​សំណើ​ប៉ុណ្ណោះ៖ FIN-ACK и RST កាត់ HTTP ទាំងអស់នៅ URL ហាមឃាត់។ ដូចដែលអ្នកអាចមើលឃើញពីក្រាហ្វខាងលើ បន្ទាប់ពីថ្ងៃដំបូងដែលខ្ញុំចាប់ផ្តើមទទួលបានទិន្នន័យតិចជាងមុន ប៉ុន្តែខ្ញុំនៅតែទទួលបានវា ដែលវាគ្រប់គ្រាន់សម្រាប់កិច្ចការរាប់ប្រភពសំណើ។

ឈានដល់ចំណុច។ តាមគំនិតរបស់ខ្ញុំ ការផ្ទុះពីរអាចមើលឃើញយ៉ាងច្បាស់ជារៀងរាល់ថ្ងៃ ទីមួយតូចជាងបន្ទាប់ពីពាក់កណ្តាលអធ្រាត្រម៉ោងនៅទីក្រុងមូស្គូ ទីពីរជិតដល់ម៉ោង 6 ព្រឹកដោយមានកន្ទុយរហូតដល់ម៉ោង 12 ថ្ងៃត្រង់។ កំពូលមិនកើតឡើងក្នុងពេលតែមួយទេ។ ដំបូងខ្ញុំចង់ជ្រើសរើសអាសយដ្ឋាន IP ដែលធ្លាក់ចុះតែក្នុងរយៈពេលទាំងនេះ និងគ្រប់អំឡុងពេលទាំងអស់ ដោយផ្អែកលើការសន្មត់ថាការត្រួតពិនិត្យដោយភ្នាក់ងារត្រូវបានអនុវត្តតាមកាលកំណត់។ ប៉ុន្តែនៅពេលពិនិត្យដោយប្រុងប្រយ័ត្ន ខ្ញុំបានរកឃើញរយៈពេលធ្លាក់ចូលទៅក្នុងចន្លោះពេលផ្សេងទៀត ដោយមានប្រេកង់ផ្សេងទៀតរហូតដល់មួយសំណើរៀងរាល់ម៉ោង។ បន្ទាប់មក ខ្ញុំបានគិតអំពីតំបន់ពេលវេលា ហើយប្រហែលជាវាមានអ្វីដែលត្រូវធ្វើជាមួយពួកគេ បន្ទាប់មកខ្ញុំគិតថា ជាទូទៅប្រព័ន្ធប្រហែលជាមិនត្រូវបានធ្វើសមកាលកម្មជាសកលទេ។ លើសពីនេះ NAT ប្រហែលជានឹងដើរតួ ហើយភ្នាក់ងារដូចគ្នាអាចធ្វើការស្នើសុំពី IP សាធារណៈផ្សេងៗ។

ដោយសារគោលដៅដំបូងរបស់ខ្ញុំមិនពិតប្រាកដ ខ្ញុំបានរាប់អាសយដ្ឋានទាំងអស់ដែលខ្ញុំបានឆ្លងកាត់ក្នុងមួយសប្តាហ៍ ហើយទទួលបាន - 2791. ចំនួនវគ្គ TCP ដែលបានបង្កើតឡើងពីអាសយដ្ឋានមួយគឺជាមធ្យម 4 ជាមួយនឹងមធ្យមភាគ 2។ វគ្គកំពូលក្នុងមួយអាសយដ្ឋាន៖ 464, 231, 149, 83, 77 ។ អតិបរមាពី 95% នៃគំរូគឺ 8 វគ្គក្នុងមួយអាសយដ្ឋាន។ មធ្យមភាគមិនខ្ពស់ទេ ខ្ញុំសូមរំលឹកអ្នកថា ក្រាហ្វបង្ហាញពីភាពទៀងទាត់ប្រចាំថ្ងៃច្បាស់លាស់ ដូច្នេះគេអាចរំពឹងថានឹងមានអ្វីមួយនៅជុំវិញ 4 ទៅ 8 ក្នុងរយៈពេល 7 ថ្ងៃ។ ប្រសិនបើយើងបោះចោលវគ្គទាំងអស់ដែលកើតឡើងម្តង នោះយើងនឹងទទួលបានមធ្យមភាគស្មើនឹង 5។ ប៉ុន្តែខ្ញុំមិនអាចដកចេញបានដោយផ្អែកលើលក្ខណៈវិនិច្ឆ័យច្បាស់លាស់នោះទេ។ ផ្ទុយទៅវិញ ការត្រួតពិនិត្យដោយចៃដន្យបានបង្ហាញថាពួកគេពាក់ព័ន្ធនឹងសំណើសម្រាប់ធនធានហាមឃាត់។

អាស័យដ្ឋានគឺជាអាសយដ្ឋានប៉ុន្តែនៅលើអ៊ីនធឺណិត ប្រព័ន្ធស្វយ័ត - អេអេសដែលប្រែទៅជាសំខាន់ជាង 1510ជាមធ្យម 2 អាសយដ្ឋានក្នុងមួយ AS ដែលមានមធ្យមភាគ 1. អាសយដ្ឋានកំពូលក្នុងមួយ AS: 288, 77, 66, 39, 27. អតិបរមានៃ 95% នៃគំរូគឺ 4 អាសយដ្ឋានក្នុងមួយ AS ។ នៅទីនេះជាមធ្យមត្រូវបានរំពឹងទុក - ភ្នាក់ងារមួយក្នុងមួយអ្នកផ្តល់សេវា។ យើងក៏រំពឹងលើកំពូលដែរ - មានអ្នកលេងធំៗនៅក្នុងនោះ។ នៅក្នុងបណ្តាញដ៏ធំមួយ ភ្នាក់ងារប្រហែលជាមានទីតាំងនៅក្នុងតំបន់នីមួយៗនៃវត្តមានរបស់ប្រតិបត្តិករ ហើយកុំភ្លេចអំពី NAT។ ប្រសិនបើយើងយកវាតាមប្រទេស អតិបរមានឹងមានៈ 1409 - RU, 42 - UA, 23 - CZ, 36 ពីតំបន់ផ្សេងទៀត មិនមែន RIPE NCC ទេ។ សំណើពីខាងក្រៅរុស្ស៊ីទាក់ទាញការចាប់អារម្មណ៍។ នេះប្រហែលជាអាចត្រូវបានពន្យល់ដោយកំហុសទីតាំងភូមិសាស្ត្រ ឬកំហុសអ្នកចុះឈ្មោះនៅពេលបំពេញទិន្នន័យ។ ឬការពិតដែលថាក្រុមហ៊ុនរុស្ស៊ីប្រហែលជាមិនមានឫសរុស្ស៊ីឬមានការិយាល័យតំណាងបរទេសព្រោះវាងាយស្រួលជាងដែលជាធម្មជាតិនៅពេលទំនាក់ទំនងជាមួយអង្គការបរទេស RIPE NCC ។ ផ្នែកខ្លះពិតជាហួសហេតុពេក ប៉ុន្តែវាពិបាកក្នុងការបំបែកវាដោយភាពជឿជាក់ ដោយសារធនធានស្ថិតនៅក្រោមការទប់ស្កាត់ ហើយចាប់ពីថ្ងៃទីពីរក្រោមការទប់ស្កាត់ពីរដង ហើយវគ្គភាគច្រើនគ្រាន់តែជាការផ្លាស់ប្តូរកញ្ចប់សេវាកម្មមួយចំនួនប៉ុណ្ណោះ។ ចូរយើងយល់ស្របថានេះគឺជាផ្នែកតូចមួយ។

លេខទាំងនេះអាចត្រូវបានប្រៀបធៀបជាមួយនឹងចំនួនអ្នកផ្តល់សេវានៅក្នុងប្រទេសរុស្ស៊ីរួចហើយ។ នេះ​បើ​តាម RKN អាជ្ញាប័ណ្ណសម្រាប់ "សេវាកម្មទំនាក់ទំនងសម្រាប់ការបញ្ជូនទិន្នន័យ ដោយមិនរាប់បញ្ចូលសំឡេង" - 6387 ប៉ុន្តែនេះគឺជាការប៉ាន់ស្មានខ្ពស់ពីខាងលើ មិនមែនអាជ្ញាប័ណ្ណទាំងអស់នេះអនុវត្តជាពិសេសចំពោះអ្នកផ្តល់សេវាអ៊ីនធឺណិតដែលត្រូវការដំឡើងភ្នាក់ងារទេ។ នៅក្នុងតំបន់ RIPE NCC មានចំនួនស្រដៀងគ្នានៃ ASEs ដែលបានចុះបញ្ជីនៅក្នុងប្រទេសរុស្ស៊ី - 6230 ដែលមិនមែនទាំងអស់ជាអ្នកផ្តល់សេវានោះទេ។ UserSide បានធ្វើការគណនាដ៏តឹងរ៉ឹងជាងមុន និងបានទទួលក្រុមហ៊ុនចំនួន 3940 ក្នុងឆ្នាំ 2017 ហើយនេះគឺជាការប៉ាន់ស្មានពីខាងលើ។ ក្នុងករណីណាក៏ដោយ យើងមានចំនួនតិចជាង XNUMX ដងកន្លះនៃ ASs ដែលត្រូវបានបំភ្លឺ។ ប៉ុន្តែនៅទីនេះវាមានតម្លៃយល់ថា AS មិនស្មើយ៉ាងតឹងរ៉ឹងជាមួយអ្នកផ្តល់សេវានោះទេ។ អ្នកផ្តល់សេវាខ្លះមិនមាន AS ផ្ទាល់ខ្លួនទេ ខ្លះមានច្រើនជាងមួយ។ ប្រសិនបើយើងសន្មត់ថាអ្នកគ្រប់គ្នានៅតែមានភ្នាក់ងារ នោះមាននរណាម្នាក់ត្រងខ្លាំងជាងអ្នកផ្សេងទៀត ដូច្នេះសំណើរបស់ពួកគេមិនអាចបែងចែកពីសំរាមបានទេ ប្រសិនបើពួកគេទៅដល់ពួកគេទាំងអស់។ ប៉ុន្តែ​សម្រាប់​ការ​វាយ​តម្លៃ​រដុប​វា​អាច​អត់ឱន​បាន​បើ​ទោះ​ជា​មាន​អ្វី​មួយ​បាន​បាត់​បង់​ដោយ​សារ​ការ​ត្រួត​ពិនិត្យ​របស់​ខ្ញុំ​ក៏​ដោយ។

អំពី DPI

ទោះបីជាការពិតដែលថាអ្នកផ្តល់សេវាបង្ហោះរបស់ខ្ញុំបានបើកតម្រងរបស់វាចាប់ផ្តើមពីថ្ងៃទី 4 ដោយផ្អែកលើព័ត៌មានពីថ្ងៃដំបូង យើងអាចសន្និដ្ឋានថាការទប់ស្កាត់កំពុងដំណើរការដោយជោគជ័យ។ មានតែប្រភព 460 ប៉ុណ្ណោះដែលអាចឆ្លងកាត់ និងបានបញ្ចប់វគ្គ HTTP និង TCP ទាំងស្រុង (ដូចក្នុងឧទាហរណ៍ខាងលើ)។ XNUMX ផ្សេងទៀតអាចត្រូវបានផ្ញើ GETប៉ុន្តែវគ្គនេះត្រូវបានបញ្ចប់ភ្លាមៗដោយ RST. យកចិត្តទុកដាក់ TTL:

TTL 50, TCP, 14678  >  80, "[SYN] Seq=0"
TTL 64, TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TTL 50, TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

HTTP, "GET /filteredpage HTTP/1.1"
TTL 64, TCP, 80  >  14678, "[ACK] Seq=1 Ack=294"

#Вот это прислал фильтр
TTL 53, TCP, 14678  >  80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678  >  80, "[RST] Seq=3458729893"

HTTP, "HTTP/1.1 302 Found"

#А это попытка исходного узла получить потерю
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[ACK] Seq=294 Ack=145"

TTL 50, TCP, 14678  >  80, "[FIN, ACK] Seq=294 Ack=145"
TTL 64, TCP, 80  >  14678, "[FIN, ACK] Seq=171 Ack=295"

TTL 50, TCP Dup ACK 14678 > 80 "[ACK] Seq=295 Ack=145"

#Исходный узел понимает что сессия разрушена
TTL 50, TCP, 14678  >  80, "[RST] Seq=294"
TTL 50, TCP, 14678  >  80, "[RST] Seq=295"

ការប្រែប្រួលនេះអាចខុសគ្នា៖ តិច RST ឬការបញ្ជូនឡើងវិញកាន់តែច្រើន - ក៏អាស្រ័យលើអ្វីដែលតម្រងផ្ញើទៅថ្នាំងប្រភព។ ក្នុងករណីណាក៏ដោយ នេះគឺជាគំរូដែលអាចទុកចិត្តបំផុត ដែលវាច្បាស់ណាស់ថាវាជាធនធានហាមឃាត់ដែលត្រូវបានស្នើសុំ។ បូកគឺតែងតែមានចម្លើយដែលបង្ហាញនៅក្នុងវគ្គជាមួយ TTL ធំជាងកញ្ចប់មុន និងបន្ទាប់។

អ្នកមិនអាចមើលឃើញវាពីអ្នកផ្សេងទៀតទេ។ GET:

TTL 50, TCP, 14678  >  80, "[SYN] Seq=0"
TTL 64, TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"

#Вот это прислал фильтр
TTL 53, TCP, 14678  >  80, "[RST] Seq=1"

ឬអញ្ចឹង៖

TTL 50, TCP, 14678  >  80, "[SYN] Seq=0"
TTL 64, TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TTL 50, TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

#Вот это прислал фильтр
TTL 53, TCP, 14678  >  80, "[RST, PSH] Seq=1"

TTL 50, TCP ACKed unseen segment, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"

#Опять фильтр, много раз
TTL 53, TCP, 14678  >  80, "[RST, PSH] Seq=1"
...

ភាពខុសគ្នាគឺពិតជាអាចមើលឃើញ TTL ប្រសិនបើមានអ្វីមួយមកពីតម្រង។ ប៉ុន្តែជារឿយៗ គ្មានអ្វីអាចមកដល់បានឡើយ៖

TCP, 14678  >  80, "[SYN] Seq=0"
TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TCP Retransmission, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
...

ឬអញ្ចឹង៖

TCP, 14678  >  80, "[SYN] Seq=0"
TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

#Прошло несколько секунд без трафика

TCP, 80  >  14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...

ហើយអ្វីៗទាំងអស់នេះត្រូវបានធ្វើម្តងទៀតហើយម្តងហើយម្តងទៀតដូចដែលអាចមើលឃើញនៅលើក្រាហ្វច្រើនជាងម្តងជារៀងរាល់ថ្ងៃ។

អំពី IPv6

ដំណឹងល្អគឺថាវាមាន។ ខ្ញុំអាចនិយាយបានថាសំណើតាមកាលកំណត់ចំពោះធនធានហាមឃាត់កើតឡើងពីអាសយដ្ឋាន IPv5 ចំនួន 6 ផ្សេងគ្នា ដែលនេះជាអាកប្បកិរិយារបស់ភ្នាក់ងារដែលខ្ញុំរំពឹងទុក។ លើសពីនេះទៅទៀត អាសយដ្ឋាន IPv6 មួយក្នុងចំណោមអាសយដ្ឋាន IPvXNUMX មិនស្ថិតនៅក្រោមការត្រងទេ ហើយខ្ញុំឃើញវគ្គពេញ។ ពីពីរទៀតខ្ញុំឃើញតែវគ្គដែលមិនទាន់បញ្ចប់មួយប៉ុណ្ណោះ វគ្គមួយត្រូវបានរំខានដោយ RST ពីតម្រងទីពីរនៅក្នុងពេលវេលា។ ចំនួន​សរុប 7.

ដោយសារមានអាស័យដ្ឋានតិចតួច ខ្ញុំបានសិក្សាលម្អិតទាំងអស់ ហើយវាបង្ហាញថាមានអ្នកផ្តល់សេវាតែ 3 នាក់ប៉ុណ្ណោះនៅទីនោះ ពួកគេអាចត្រូវបានគេផ្តល់ជាអត្ថប្រយោជន៏! អាស័យដ្ឋានមួយទៀតគឺការបង្ហោះពពកនៅក្នុងប្រទេសរុស្ស៊ី (មិនត្រង) មួយទៀតគឺជាមជ្ឈមណ្ឌលស្រាវជ្រាវនៅប្រទេសអាឡឺម៉ង់ (មានតម្រងនៅឯណា?) ប៉ុន្តែហេតុអ្វីបានជាពួកគេពិនិត្យមើលភាពអាចរកបាននៃធនធានហាមឃាត់នៅលើកាលវិភាគគឺជាសំណួរដ៏ល្អ។ ពីរដែលនៅសេសសល់បានធ្វើសំណើមួយហើយមានទីតាំងនៅខាងក្រៅប្រទេសរុស្ស៊ីហើយមួយក្នុងចំណោមពួកគេត្រូវបានត្រង (នៅក្នុងការដឹកជញ្ជូនបន្ទាប់ពីទាំងអស់?)

ការទប់ស្កាត់ និងភ្នាក់ងារគឺជាឧបសគ្គដ៏ធំមួយចំពោះ IPv6 ដែលការអនុវត្តមិនលឿនទេ។ វា​ជា​ការ​ក្រៀមក្រំ។ អ្នកដែលដោះស្រាយបញ្ហានេះអាចមានមោទនភាពចំពោះខ្លួនឯងទាំងស្រុង។

នៅក្នុងសេចក្តីសន្និដ្ឋាន

ខ្ញុំមិនបានព្យាយាមរកភាពត្រឹមត្រូវ 100% ទេ សូមអភ័យទោសចំពោះបញ្ហានេះ ខ្ញុំសង្ឃឹមថាមាននរណាម្នាក់ចង់ធ្វើកិច្ចការនេះឡើងវិញជាមួយនឹងភាពត្រឹមត្រូវជាងមុន។ វាមានសារៈសំខាន់សម្រាប់ខ្ញុំក្នុងការយល់ថាតើវិធីសាស្រ្តនេះនឹងដំណើរការជាគោលការណ៍ឬយ៉ាងណា។ ចម្លើយគឺបាទ។ តួលេខដែលទទួលបាន តាមការប៉ាន់ស្មានដំបូង ខ្ញុំគិតថាអាចទុកចិត្តបាន។

តើមានអ្វីទៀតដែលអាចធ្វើបាន ហើយអ្វីដែលខ្ញុំខ្ជិលធ្វើគឺរាប់សំណើ DNS ។ ពួកវាមិនត្រូវបានត្រងទេ ប៉ុន្តែពួកវាក៏មិនផ្តល់ភាពត្រឹមត្រូវច្រើនដែរ ដោយសារពួកគេធ្វើការសម្រាប់តែដែន និងមិនមែនសម្រាប់ URL ទាំងមូលនោះទេ។ ប្រេកង់គួរតែអាចមើលឃើញ។ ប្រសិនបើអ្នកបញ្ចូលវាជាមួយអ្វីដែលអាចមើលឃើញដោយផ្ទាល់នៅក្នុងសំណួរ វានឹងអនុញ្ញាតឱ្យអ្នកបំបែកចេញពីអ្វីដែលមិនចាំបាច់ និងទទួលបានព័ត៌មានបន្ថែម។ វាថែមទាំងអាចកំណត់អ្នកអភិវឌ្ឍន៍ DNS ដែលប្រើដោយអ្នកផ្តល់សេវា និងច្រើនទៀត។

ខ្ញុំពិតជាមិននឹកស្មានថា hoster នឹងរួមបញ្ចូលតម្រងផ្ទាល់ខ្លួនរបស់វាសម្រាប់ VPS របស់ខ្ញុំទេ។ ប្រហែលជានេះជាការអនុវត្តធម្មតា។ នៅទីបញ្ចប់ RKN ផ្ញើសំណើដើម្បីលុបធនធានទៅ hoster ។ ប៉ុន្តែ​នេះ​មិន​បាន​ធ្វើ​ឱ្យ​ខ្ញុំ​ភ្ញាក់​ផ្អើល​ទេ ហើយ​តាម​វិធី​ខ្លះ​ថែម​ទាំង​បាន​ផល​ប្រយោជន៍​ដល់​ខ្ញុំ​ទៀត​ផង។ តម្រងនេះដំណើរការយ៉ាងមានប្រសិទ្ធភាព ដោយកាត់ចេញរាល់សំណើ HTTP ត្រឹមត្រូវទាំងអស់ទៅកាន់ URL ដែលត្រូវបានហាមឃាត់ ប៉ុន្តែមិនត្រឹមត្រូវ ដែលពីមុនបានឆ្លងកាត់តម្រងរបស់អ្នកផ្តល់សេវាបានទៅដល់ពួកគេ ទោះបីជាមានទម្រង់នៃការបញ្ចប់ក៏ដោយ៖ FIN-ACK и RST - ដកសម្រាប់ដក ហើយវាស្ទើរតែប្រែទៅជាបូក។ ដោយវិធីនេះ IPv6 មិនត្រូវបានត្រងដោយ hoster ទេ។ ជាការពិតណាស់នេះប៉ះពាល់ដល់គុណភាពនៃសម្ភារៈដែលប្រមូលបានប៉ុន្តែវានៅតែធ្វើឱ្យវាអាចឃើញប្រេកង់។ វាបានប្រែក្លាយថានេះគឺជាចំណុចសំខាន់នៅពេលជ្រើសរើសគេហទំព័រសម្រាប់ដាក់ធនធាន កុំភ្លេចចាប់អារម្មណ៍លើបញ្ហានៃការរៀបចំការងារជាមួយនឹងបញ្ជីនៃគេហទំព័រហាមឃាត់ និងសំណើពី RKN ។

នៅដើមដំបូងខ្ញុំបានប្រៀបធៀប AS "អធិការ" ជាមួយ RIPE Atlas. ការប្រៀបធៀបនេះគឺសមហេតុផលណាស់ ហើយបណ្តាញភ្នាក់ងារដ៏ធំមួយអាចមានប្រយោជន៍។ ឧទាហរណ៍ ការកំណត់គុណភាពនៃធនធានដែលអាចរកបានពីអ្នកផ្តល់សេវាផ្សេងៗគ្នានៅក្នុងផ្នែកផ្សេងៗនៃប្រទេស។ អ្នកអាចគណនាការពន្យារពេល អ្នកអាចបង្កើតក្រាហ្វ អ្នកអាចវិភាគវាទាំងអស់ និងឃើញការផ្លាស់ប្តូរដែលកើតឡើងទាំងក្នុងស្រុក និងជាសកល។ នេះ​មិន​មែន​ជា​វិធី​ផ្ទាល់​បំផុត​ទេ ប៉ុន្តែ​តារា​វិទូ​ប្រើ​ "ទៀន​ស្តង់ដារ​" ហេតុ​អ្វី​មិន​ប្រើ​ភ្នាក់ងារ? ដោយដឹង (បានរកឃើញ) អាកប្បកិរិយាស្តង់ដាររបស់ពួកគេ អ្នកអាចកំណត់ការផ្លាស់ប្តូរដែលកើតឡើងនៅជុំវិញពួកគេ និងរបៀបដែលវាប៉ះពាល់ដល់គុណភាពនៃសេវាកម្មដែលបានផ្តល់។ ហើយក្នុងពេលជាមួយគ្នានេះ អ្នកមិនចាំបាច់ដាក់ការស៊ើបអង្កេតដោយឯករាជ្យនៅលើបណ្តាញនោះទេ Roskomnadzor បានដំឡើងពួកវារួចហើយ។

ចំណុចមួយទៀតដែលខ្ញុំចង់ប៉ះគឺថា រាល់ឧបករណ៍អាចជាអាវុធ។ AS "Inspector" គឺជាបណ្តាញបិទ ប៉ុន្តែភ្នាក់ងារប្រគល់អ្នកគ្រប់គ្នាដោយផ្ញើសំណើសម្រាប់ធនធានទាំងអស់ពីបញ្ជីហាមឃាត់។ ការមានធនធានបែបនេះមិនបង្ហាញពីបញ្ហាអ្វីទាំងអស់។ សរុបមក អ្នកផ្តល់សេវាតាមរយៈភ្នាក់ងារដោយមិនដឹងខ្លួន ប្រាប់ច្រើនអំពីបណ្តាញរបស់ពួកគេជាងប្រហែលជាមានតម្លៃវា៖ ប្រភេទ DPI និង DNS ទីតាំងរបស់ភ្នាក់ងារ (ថ្នាំងកណ្តាល និងបណ្តាញសេវា?) សញ្ញាសម្គាល់បណ្តាញនៃការពន្យារពេល និងការខាតបង់ - ហើយនេះគឺជា មានតែច្បាស់បំផុតប៉ុណ្ណោះ។ ដូចគ្នានឹងនរណាម្នាក់អាចតាមដានសកម្មភាពរបស់ភ្នាក់ងារ ដើម្បីបង្កើនលទ្ធភាពនៃធនធានរបស់ពួកគេ នរណាម្នាក់អាចធ្វើវាសម្រាប់គោលបំណងផ្សេងទៀត ហើយមិនមានឧបសគ្គចំពោះបញ្ហានេះទេ។ លទ្ធផល​គឺ​ជា​ឧបករណ៍​ដែល​មាន​គែម​ពីរ និង​ច្រើន​មុខ​យ៉ាង​ខ្លាំង អ្នក​ណា​ក៏​អាច​ឃើញ​វា​ដែរ។

ប្រភព: www.habr.com