"පරීක්ෂක" නියෝජිතයන් ගණන් කරමු

රුසියාවේ තහනම් තොරතුරු ලැයිස්තුවේ අවහිර කිරීම පාලනය කිරීම ස්වයංක්රීය පද්ධතිය "පරීක්ෂක" විසින් නිරීක්ෂණය කරන බව රහසක් නොවේ. එය ක්‍රියාත්මක වන ආකාරය මෙහි හොඳින් ලියා ඇත Habr පිළිබඳ ලිපිය, පින්තූරය එකම ස්ථානයේ සිට:

සපයන්නා වෙත සෘජුවම ස්ථාපනය කර ඇත මොඩියුලය "නියෝජිත පරීක්ෂක":

"නියෝජිත පරීක්ෂක" මොඩියුලය ස්වයංක්රීය පද්ධතිය "පරීක්ෂක" (AS "පරීක්ෂක") හි ව්යුහාත්මක මූලද්රව්යයකි. 15.1 ජූලි 15.4 දිනැති ෆෙඩරල් නීතියේ 27-2006 වගන්ති මගින් ස්ථාපිත කර ඇති විධිවිධාන රාමුව තුළ ටෙලිකොම් ක්‍රියාකරුවන් විසින් ප්‍රවේශ සීමා කිරීමේ අවශ්‍යතා සමඟ අනුකූල වීම අධීක්ෂණය කිරීම සඳහා මෙම පද්ධතිය සැලසුම් කර ඇත. ”

AS "Revizor" නිර්මාණය කිරීමේ ප්‍රධාන අරමුණ වන්නේ 15.1 ජූලි 15.4 දිනැති ෆෙඩරල් නීතියේ 27-2006 වගන්ති මගින් ස්ථාපිත කර ඇති අවශ්‍යතා සමඟ ටෙලිකොම් ක්‍රියාකරුවන්ගේ අනුකූලතාවය අධීක්ෂණය කිරීම සහතික කිරීමයි අංක 149-FZ "තොරතුරු, තොරතුරු තාක්ෂණ සහ තොරතුරු ආරක්ෂණය පිළිබඳ "තහනම් තොරතුරු සඳහා ප්රවේශය පිළිබඳ කරුණු හඳුනා ගැනීම සහ තහනම් තොරතුරු වෙත ප්රවේශය සීමා කිරීම සඳහා උල්ලංඝනය කිරීම් පිළිබඳ උපකාරක ද්රව්ය (දත්ත) ලබා ගැනීම සම්බන්ධයෙන්.

සියල්ලම නොවේ නම්, බොහෝ සැපයුම්කරුවන් මෙම උපාංගය ස්ථාපනය කර ඇති බව සැලකිල්ලට ගනිමින්, විශාල බීකන් පරීක්ෂණ ජාලයක් තිබිය යුතුය. RIPE Atlas සහ ඊටත් වඩා, නමුත් සංවෘත ප්රවේශය සමඟ. කෙසේ වෙතත්, බීකන් එකක් යනු සෑම දිශාවකටම සංඥා යැවීමට ප්‍රදීපාගාරයකි, නමුත් අපි ඒවා අල්ලාගෙන අප අල්ලා ගත් දේ සහ කොපමණ ප්‍රමාණයක් බැලුවහොත් කුමක් කළ යුතුද?

අපි ගණන් කිරීමට පෙර, මෙය සිදුවිය හැක්කේ මන්දැයි බලමු.

න්යායන් ටිකක්

නියෝජිතයන් මෙවැනි 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 අවහිර කිරීමේ වර්ගය සහිත සුදුසු නිදහස් වසමක් තෝරා ගැනීමට අවශ්‍ය වේ, පෙරහන් පද්ධතියේ ක්‍රියාකාරිත්වය පහසු කිරීම සඳහා, දිගු කාලයක් අතහැර දමා, නියෝජිතයන්ගෙන් හැර බාහිර ගමනාගමනයට ඇතුළුවීම අවම කිරීම. මෙම කාර්යය කිසිසේත් අපහසු නොවන බව පෙනී ගියේය; තහනම් තොරතුරු ලේඛනයේ සහ සෑම රසය සඳහාම නොමිලේ වසම් විශාල ප්‍රමාණයක් ඇත. එබැවින්, වසම මිලදී ගෙන VPS ධාවනය වන IP ලිපිනවලට සම්බන්ධ කර ඇත tcpdump සහ ගණන් කිරීම ආරම්භ විය.

"විගණක" විගණනය

මගේ මතය අනුව පාලිත ක්‍රියාවක් පෙන්නුම් කරන ඉල්ලීම් වරින් වර පිපිරීම් දැකීමට මම අපේක්ෂා කළෙමි. මම එය කිසිසේත් නොදුටු බව පැවසිය නොහැක, නමුත් නිසැකවම පැහැදිලි පින්තූරයක් නොතිබුණි:

කිසිවෙකුට අවශ්‍ය නොවන වසමක සහ කිසිදා භාවිතා නොකරන ලද IP එකක වුවද, අනවශ්‍ය තොරතුරු ටොන් ගණනක් තිබීම පුදුමයට කරුණක් නොවේ, එවැනි නවීන අන්තර්ජාලයයි. නමුත් වාසනාවකට මෙන්, මට විශේෂිත URL එකක් සඳහා ඉල්ලීම් පමණක් අවශ්‍ය විය, එබැවින් සියලුම ස්කෑනර් සහ මුරපද ක්‍රැකර් ඉක්මනින් සොයා ගන්නා ලදී. එසේම, සමාන ඉල්ලීම් සමූහය මත ගංවතුර ඇති ස්ථානය තේරුම් ගැනීම තරමක් පහසු විය. ඊළඟට, මම IP ලිපින ඇතිවීමේ සංඛ්‍යාතය සම්පාදනය කර මුළු ඉහළම අතින්ම ගියෙමි, පෙර අවස්ථා වලදී එය මඟ හැරුණු අය වෙන් කළෙමි. මීට අමතරව, මම එක් පැකේජයක් තුළ යවන ලද සියලුම මූලාශ්ර කපා හැරියෙමි, ඒවායින් බොහොමයක් තවදුරටත් නොතිබුණි. සහ සිදු වූයේ මෙයයි:

කුඩා ගීතමය අපගමනයකි. දිනකට මඳ වේලාවකට පසුව, මගේ සත්කාරක සපයන්නා තරමක් විධිමත් අන්තර්ගතයක් සහිත ලිපියක් යවා, ඔබේ පහසුකම්වල RKN තහනම් ලැයිස්තුවෙන් සම්පතක් ඇති බව පවසමින් එය අවහිර කර ඇත. මම මුලින්ම හිතුවේ මගේ ගිණුම අවහිර කර ඇති බවයි, මෙය එසේ නොවේ. එතකොට මට හිතුනා එයාලා මට කලින්ම දන්න දෙයක් ගැන අනතුරු අඟවනවා කියලා. නමුත් හොස්ටර් මගේ වසම ඉදිරිපිට එහි පෙරහන ක්‍රියාත්මක කර ඇති අතර එහි ප්‍රතිඵලයක් ලෙස මම ද්විත්ව පෙරීමකට යටත් විය: සපයන්නන්ගෙන් සහ සත්කාරක සමාගමෙන්. පෙරහන ඉල්ලීම්වල කෙළවර පමණක් සම්මත කර ඇත: FIN-ACK и RST තහනම් URL එකකින් සියලුම HTTP කපා හැරීම. ඉහත ප්‍රස්ථාරයෙන් ඔබට පෙනෙන පරිදි, පළමු දිනට පසු මට අඩු දත්ත ලැබීමට පටන් ගත් නමුත් මට එය තවමත් ලැබී ඇති අතර එය ඉල්ලීම් ප්‍රභවයන් ගණනය කිරීමේ කාර්යයට ප්‍රමාණවත් විය.

කාරණයට එන්න. මගේ මතය අනුව, සෑම දිනකම පිපිරුම් දෙකක් පැහැදිලිව දැකගත හැකිය, පළමු කුඩා, මධ්‍යම රාත්‍රියේ මොස්කව් වේලාවෙන් පසු, දෙවැන්න උදේ 6 ට ආසන්නව වලිගයක් සමඟ දහවල් 12 දක්වා. උච්චය හරියටම එකම වේලාවක සිදු නොවේ. මුලදී, නියෝජිතයින් විසින් පරීක්ෂා කිරීම් වරින් වර සිදු කරනු ලැබේ යන උපකල්පනය මත පදනම්ව, මෙම කාල පරිච්ඡේදවල සහ සෑම කාල පරිච්ඡේදයකම පමණක් වැටෙන IP ලිපින තෝරා ගැනීමට මට අවශ්‍ය විය. නමුත් ප්‍රවේශමෙන් සමාලෝචනය කළ විට, සෑම පැයකටම එක ඉල්ලීමක් දක්වා වෙනත් සංඛ්‍යාත සමඟ කාල පරිච්ඡේදවලට වැටීම මම ඉක්මනින් සොයා ගත්තෙමි. එවිට මම කාල කලාප ගැන සිතුවෙමි, සමහර විට එය ඒවාට සම්බන්ධයක් ඇති බව, එවිට මම සිතුවේ පොදුවේ පද්ධතිය ගෝලීය වශයෙන් සමමුහුර්ත නොවිය හැකි බවයි. මීට අමතරව, NAT බොහෝ විට භූමිකාවක් ඉටු කරනු ඇති අතර එකම නියෝජිතයාට විවිධ පොදු IP වලින් ඉල්ලීම් කළ හැකිය.

මගේ ආරම්භක ඉලක්කය හරියටම නොවූ නිසා, මම සතියක් තුළ මට හමු වූ සියලුම ලිපින ගණන් කළෙමි - 2791. එක් ලිපිනයකින් පිහිටුවා ඇති TCP සැසි සංඛ්‍යාව සාමාන්‍යයෙන් 4ක් වන අතර මධ්‍යස්ථ 2. ලිපිනයකට ඉහළම සැසි: 464, 231, 149, 83, 77. නියැදියේ 95% සිට උපරිමය ලිපිනයකට සැසි 8කි. මධ්‍යස්ථය ඉතා ඉහළ නැත, ප්‍රස්ථාරයේ පැහැදිලි දෛනික ආවර්තිතා පෙන්නුම් කරන බව මම ඔබට මතක් කරමි, එබැවින් කෙනෙකුට දින 4 කින් 8 සිට 7 දක්වා දෙයක් අපේක්ෂා කළ හැකිය. අපි එක් වරක් සිදු වන සියලුම සැසි ඉවතට විසි කළහොත්, අපට 5 ට සමාන මධ්යන්යයක් ලැබෙනු ඇත. නමුත් පැහැදිලි නිර්ණායකයක් මත පදනම්ව මට ඒවා බැහැර කළ නොහැකි විය. ඊට පටහැනිව, අහඹු පරීක්ෂාවකින් පෙන්නුම් කළේ ඒවා තහනම් සම්පතක් සඳහා වන ඉල්ලීම්වලට සම්බන්ධ බවයි.

ලිපින ලිපින වේ, නමුත් අන්තර්ජාලයේ, ස්වයංක්‍රීය පද්ධති - ඒඑස්, එය වඩාත් වැදගත් විය 1510, සාමාන්‍යයෙන් AS සඳහා ලිපින 2ක් මධ්‍යස්ථ 1. AS සඳහා ඉහළ ලිපින: 288, 77, 66, 39, 27. නියැදියේ උපරිම 95% AS එකකට ලිපින 4කි. මෙහි මධ්‍ය අගය අපේක්ෂා කෙරේ - එක් සැපයුම්කරුවෙකුට එක් නියෝජිතයෙක්. අපිත් ඉහළම බලාපොරොත්තු වෙනවා - ඒකේ ලොකු ක්‍රීඩකයෝ ඉන්නවා. විශාල ජාලයක් තුළ, නියෝජිතයන් බොහෝ විට ක්රියාකරුගේ පැමිණීමේ සෑම කලාපයකම පිහිටා තිබිය යුතු අතර, NAT ගැන අමතක නොකරන්න. අපි එය රට අනුව ගත්තොත්, උපරිමය වනුයේ: 1409 - RU, 42 - UA, 23 - CZ, 36 වෙනත් ප්‍රදේශවලින් මිස RIPE NCC නොවේ. රුසියාවෙන් පිටත ඉල්ලීම් අවධානය ආකර්ෂණය කරයි. දත්ත පිරවීමේදී භූ ස්ථානගත කිරීමේ දෝෂ හෝ රෙජිස්ට්‍රාර් දෝෂ මගින් මෙය බොහෝ විට පැහැදිලි කළ හැක. එසේත් නැතිනම් රුසියානු සමාගමකට රුසියානු මූලයන් නොතිබිය හැකිය, නැතහොත් විදේශ නියෝජිත කාර්යාලයක් ඇති බැවින් එය පහසු වන අතර එය විදේශීය සංවිධානයක් RIPE NCC සමඟ කටයුතු කිරීමේදී ස්වාභාවිකය. සමහර කොටස් නිසැකව ම අතිරික්ත ය, නමුත් එය වෙන් කිරීම විශ්වාසදායක ලෙස දුෂ්කර ය, මන්ද සම්පත අවහිර කිරීම සහ දෙවන දින සිට ද්විත්ව අවහිර කිරීම යටතේ වන අතර බොහෝ සැසි යනු සේවා පැකට් කිහිපයක හුවමාරුවක් පමණි. මෙය කුඩා කොටසක් බව අපි එකඟ වෙමු.

මෙම සංඛ්යා දැනටමත් රුසියාවේ සපයන්නන් සංඛ්යාව සමඟ සැසඳිය හැක. RKN ට අනුව "හඬ හැර දත්ත සම්ප්රේෂණය සඳහා සන්නිවේදන සේවා" සඳහා බලපත්ර - 6387, නමුත් මෙය ඉහතින් ඉතා ඉහළ ඇස්තමේන්තුවකි, මෙම බලපත්ර සියල්ලම නියෝජිතයෙකු ස්ථාපනය කිරීමට අවශ්ය අන්තර්ජාල සපයන්නන් සඳහා විශේෂයෙන් අදාළ නොවේ. RIPE NCC කලාපයේ රුසියාවේ ලියාපදිංචි වී ඇති ඒඑස් සමාන සංඛ්‍යාවක් ඇත - 6230, ඒවායින් සියල්ල සපයන්නන් නොවේ. UserSide වඩාත් දැඩි ගණනය කිරීමක් කළේය සහ 3940 දී සමාගම් 2017 ක් ලැබී ඇති අතර මෙය ඉහතින් කරන ලද ඇස්තමේන්තුවකි. ඕනෑම අවස්ථාවක, අපට ආලෝකමත් AS සංඛ්‍යාව දෙකහමාරක් අඩුය. නමුත් මෙහිදී AS සපයන්නාට දැඩි ලෙස සමාන නොවන බව වටහා ගැනීම වටී. සමහර සපයන්නන්ට තමන්ගේම AS නැත, සමහර අයට එකකට වඩා තිබේ. සෑම කෙනෙකුටම තවමත් නියෝජිතයින් සිටින බව අපි උපකල්පනය කරන්නේ නම්, යමෙකු අනෙක් අයට වඩා දැඩි ලෙස පෙරහන් කරයි, එවිට ඔවුන්ගේ ඉල්ලීම් ඔවුන් වෙත ළඟා වුවහොත් කුණු වලින් වෙන්කර හඳුනාගත නොහැක. නමුත් දළ තක්සේරුවකට නම්, මගේ අතපසුවීම නිසා යමක් අහිමි වුවද එය තරමක් ඉවසිය හැකි ය.

DPI ගැන

මගේ සත්කාරක සැපයුම්කරු දෙවන දින සිට එහි පෙරහන ක්‍රියාත්මක කර ඇතත්, පළමු දිනයේ තොරතුරු මත පදනම්ව අවහිර කිරීම සාර්ථකව ක්‍රියාත්මක වන බව අපට නිගමනය කළ හැකිය. HTTP සහ TCP සැසි (ඉහත උදාහරණයේ මෙන්) සම්පූර්ණ කර සම්පූර්ණ කර ඇත්තේ මූලාශ්‍ර 4කට පමණි. තව 460ක් එවන්න පුළුවන් 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 ලිපින වලින් එකක් පෙරීමට යටත් නොවන අතර මම සම්පූර්ණ සැසියක් දකිමි. තවත් දෙකකින් මම දුටුවේ නිම නොකළ එක් සැසියක් පමණි, ඉන් එකකට බාධා විය RST ෆිල්ටරයෙන්, කාලයෙන් දෙවනුව. මුලු වටිනාකම 7.

ලිපින කිහිපයක් ඇති බැවින්, මම ඒවා සියල්ලම සවිස්තරාත්මකව අධ්‍යයනය කළ අතර එහි සිටින්නේ සපයන්නන් 3 දෙනෙකු පමණක් බව පෙනී ගියේය, ඔවුන්ට ප්‍රශංසා කළ හැකිය! තවත් ලිපිනයක් රුසියාවේ වලාකුළු සත්කාරකත්වය (පෙරහන්නේ නැත), තවත් එකක් ජර්මනියේ පර්යේෂණ මධ්යස්ථානයක් (පෙරහන තිබේ, කොහෙද?). නමුත් ඔවුන් කාලසටහනකට අනුව තහනම් සම්පත් තිබේදැයි පරීක්ෂා කරන්නේ ඇයිද යන්න හොඳ ප්‍රශ්නයකි. ඉතිරි දෙදෙනා එක් ඉල්ලීමක් කර ඇති අතර රුසියාවෙන් පිටත පිහිටා ඇති අතර, ඔවුන්ගෙන් එක් අයෙකු පෙරා ඇත (සංක්රමණයේදී, සියල්ලට පසු?).

අවහිර කිරීම සහ නියෝජිතයන් IPv6 සඳහා විශාල බාධාවක් වන අතර, එය ක්‍රියාත්මක කිරීම ඉතා ඉක්මනින් සිදු නොවේ. එය කනගාටුවට කරුණක්. මෙම ගැටලුව විසඳූ අයට තමන් ගැන සම්පූර්ණයෙන්ම ආඩම්බර විය හැකිය.

අවසාන වශයෙන්

මම 100% නිරවද්‍යතාවයක් සඳහා උත්සාහ කළේ නැත, කරුණාකර මට මේ සඳහා සමාව දෙන්න, යමෙකුට මෙම කාර්යය වඩා නිරවද්‍යතාවයකින් නැවත කිරීමට අවශ්‍ය යැයි මම බලාපොරොත්තු වෙමි. මෙම ප්‍රවේශය ප්‍රතිපත්තිමය වශයෙන් ක්‍රියාත්මක වේද යන්න තේරුම් ගැනීම මට වැදගත් විය. පිළිතුර ඔව් යන්නයි. පළමු ආසන්න වශයෙන්, ලබාගත් සංඛ්යා, මම හිතන්නේ, තරමක් විශ්වසනීය ය.

වෙන මොනවද කරන්න තිබ්බේ සහ මට කරන්න කම්මැලි වුනේ DNS රික්වෙස්ට් ගණන් කරන එක. ඒවා ෆිල්ටර් කර නැත, නමුත් ඒවා ක්‍රියා කරන්නේ වසම සඳහා පමණක් වන බැවින්, සම්පූර්ණ URL සඳහා නොවන බැවින් ඒවා වැඩි නිරවද්‍යතාවයක් ලබා නොදේ. සංඛ්යාතය දෘශ්යමාන විය යුතුය. විමසුම්වල සෘජුවම පෙනෙන දේ සමඟ ඔබ එය ඒකාබද්ධ කරන්නේ නම්, මෙය ඔබට අනවශ්‍ය දේ වෙන් කර වැඩි විස්තර ලබා ගැනීමට ඉඩ සලසයි. සැපයුම්කරුවන් විසින් භාවිතා කරන DNS හි සංවර්ධකයින් සහ තවත් බොහෝ දේ තීරණය කිරීමට පවා හැකිය.

මගේ VPS සඳහා සත්කාරක සමාගම තමන්ගේම පෙරහන ද ඇතුළත් කරනු ඇතැයි මම කිසිසේත්ම බලාපොරොත්තු නොවෙමි. සමහර විට මෙය පොදු භාවිතයක් විය හැකිය. අවසානයේදී, RKN විසින් සම්පත් මකා දැමීමට ඉල්ලීමක් සත්කාරක වෙත යවයි. නමුත් මෙය මා පුදුමයට පත් නොකළ අතර සමහර ආකාරවලින් මගේ වාසියට පවා ක්‍රියා කළේය. ෆිල්ටරය ඉතා ඵලදායි ලෙස ක්‍රියා කළ අතර, තහනම් URL එකකට ඇති සියලුම නිවැරදි HTTP ඉල්ලීම් කපා හැරියේය, නමුත් මීට පෙර සපයන්නන්ගේ පෙරහන හරහා ගිය නිවැරදි ඒවා ඔවුන් වෙත ළඟා වූයේ නැත, නමුත් අවසානයන් ආකාරයෙන් පමණි: FIN-ACK и RST - ඍණ සඳහා අඩු වන අතර එය බොහෝ දුරට ප්ලස් බවට පත් විය. මාර්ගය වන විට, IPv6 සත්කාරක විසින් පෙරහන් කර නැත. ඇත්ත වශයෙන්ම, මෙය එකතු කරන ලද ද්රව්යයේ ගුණාත්මක භාවයට බලපෑ නමුත් එය තවමත් සංඛ්යාතය දැකීමට හැකි විය. සම්පත් ස්ථානගත කිරීම සඳහා වෙබ් අඩවියක් තෝරාගැනීමේදී මෙය වැදගත් කරුණක් බව පෙනී ගියේය; RKN වෙතින් තහනම් අඩවි ලැයිස්තුව සහ ඉල්ලීම් සමඟ වැඩ සංවිධානය කිරීමේ ගැටලුව ගැන උනන්දුවක් දැක්වීමට අමතක නොකරන්න.

මුලදී, මම AS "පරීක්ෂක" සමඟ සංසන්දනය කළෙමි RIPE Atlas. මෙම සංසන්දනය බෙහෙවින් යුක්ති සහගත වන අතර විශාල නියෝජිත ජාලයක් ප්රයෝජනවත් විය හැකිය. උදාහරණයක් ලෙස, රටේ විවිධ ප්‍රදේශවල විවිධ සැපයුම්කරුවන්ගෙන් සම්පත් ලබා ගැනීමේ ගුණාත්මකභාවය තීරණය කිරීම. ඔබට ප්‍රමාදයන් ගණනය කළ හැකිය, ඔබට ප්‍රස්ථාර ගොඩනගා ගත හැකිය, ඔබට ඒ සියල්ල විශ්ලේෂණය කළ හැකි අතර දේශීය හා ගෝලීය වශයෙන් සිදුවන වෙනස්කම් දැකිය හැකිය. මෙය වඩාත්ම සෘජු මාර්ගය නොවේ, නමුත් තාරකා විද්යාඥයින් "සම්මත ඉටිපන්දම්" භාවිතා කරයි, නියෝජිතයන් භාවිතා නොකරන්නේ මන්ද? ඔවුන්ගේ සම්මත හැසිරීම දැන ගැනීමෙන් (සොයා ගැනීමෙන්), ඔවුන් වටා සිදුවන වෙනස්කම් සහ මෙය සපයනු ලබන සේවාවන්හි ගුණාත්මක භාවයට බලපාන ආකාරය තීරණය කළ හැකිය. ඒ සමඟම, ඔබට ස්වාධීනව ජාලයේ පරීක්ෂණ තැබීමට අවශ්‍ය නැත; Roskomnadzor දැනටමත් ඒවා ස්ථාපනය කර ඇත.

මට ස්පර්ශ කිරීමට අවශ්‍ය තවත් කරුණක් නම් සෑම මෙවලමක්ම ආයුධයක් විය හැකි බවයි. AS "පරීක්ෂක" යනු සංවෘත ජාලයකි, නමුත් තහනම් ලැයිස්තුවෙන් සියලුම සම්පත් සඳහා ඉල්ලීම් යැවීමෙන් නියෝජිතයින් සෑම කෙනෙකුටම භාර දෙයි. එවැනි සම්පතක් තිබීම කිසිදු ගැටළුවක් ඇති නොකරයි. සමස්තයක් වශයෙන්, නියෝජිතයින් හරහා සපයන්නන්, නොදැනුවත්වම, ඔවුන්ගේ ජාලය ගැන සමහර විට වටිනවාට වඩා බොහෝ දේ කියන්න: DPI සහ DNS වර්ග, නියෝජිතයාගේ පිහිටීම (මධ්‍යම නෝඩය සහ සේවා ජාලය?), ප්‍රමාදයන් සහ පාඩු පිළිබඳ ජාල සලකුණු - සහ මෙය වඩාත්ම පැහැදිලි පමණි. යමෙකුට ඔවුන්ගේ සම්පත් ලබා ගැනීමේ හැකියාව වැඩිදියුණු කිරීම සඳහා නියෝජිතයින්ගේ ක්‍රියා නිරීක්ෂණය කළ හැකි සේම, වෙනත් අරමුණු සඳහා යමෙකුට මෙය කළ හැකි අතර මේ සඳහා කිසිදු බාධාවක් නොමැත. එහි ප්‍රතිඵලය ද්විත්ව දාර සහිත ඉතා බහුවිධ උපකරණයකි, ඕනෑම කෙනෙකුට මෙය දැක ගත හැකිය.

මූලාශ්රය: www.habr.com