დავთვალოთ აგენტები "ინსპექტორი"

საიდუმლო არ არის, რომ რუსეთში აკრძალული ინფორმაციის სიაში დაბლოკვის კონტროლს აკონტროლებს ავტომატური სისტემა "ინსპექტორი". როგორ მუშაობს ეს კარგად არის დაწერილი აქ სტატია ჰაბრ, სურათი იმავე ადგილიდან:

დაინსტალირებულია პირდაპირ პროვაიდერთან მოდული "აგენტი ინსპექტორი":

მოდული "აგენტი ინსპექტორი" არის ავტომატური სისტემის "ინსპექტორის" (AS "ინსპექტორი") სტრუქტურული ელემენტი. ეს სისტემა შექმნილია ტელეკომის ოპერატორების მიერ წვდომის შეზღუდვის მოთხოვნებთან შესაბამისობის მონიტორინგისთვის, 15.1 წლის 15.4 ივლისის №27-FZ ფედერალური კანონის 2006-149 მუხლებით დადგენილი დებულებების ფარგლებში „ინფორმაციის, საინფორმაციო ტექნოლოგიებისა და ინფორმაციის დაცვის შესახებ“. ”

AS "Revizor"-ის შექმნის მთავარი მიზანია უზრუნველყოს ტელეკომის ოპერატორების შესაბამისობის მონიტორინგი 15.1 წლის 15.4 ივლისის 27-FZ ფედერალური კანონის 2006-149 მუხლებით დადგენილ მოთხოვნებთან "ინფორმაციის, საინფორმაციო ტექნოლოგიებისა და ინფორმაციის დაცვის შესახებ". „აკრძალულ ინფორმაციაზე წვდომის ფაქტების იდენტიფიცირებისა და დარღვევების შესახებ დამხმარე მასალების (მონაცემების) მოპოვების თვალსაზრისით აკრძალულ ინფორმაციაზე წვდომის შეზღუდვის მიზნით.

იმის გათვალისწინებით, რომ თუ არა ყველა, მაშინ ბევრმა პროვაიდერმა დააინსტალირა ეს მოწყობილობა, უნდა ყოფილიყო შუქურის ზონდების დიდი ქსელი, როგორიცაა RIPE ატლასი და კიდევ უფრო მეტი, მაგრამ დახურული წვდომით. თუმცა, შუქურა არის შუქურა ყველა მიმართულებით სიგნალების გასაგზავნად, მაგრამ რა მოხდება, თუ მათ დავიჭერთ და ვნახავთ, რა დავიჭირეთ და რამდენი?

სანამ ვითვლით, ვნახოთ, რატომ შეიძლება ეს შესაძლებელი.

ცოტა თეორია

აგენტები ამოწმებენ რესურსის ხელმისაწვდომობას, მათ შორის, 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 აკრძალული სიიდან, ამიტომ ის დაბლოკილია. თავიდან ვიფიქრე, რომ ჩემი ანგარიში დაბლოკილია, ეს ასე არ იყო. მერე ვიფიქრე, რომ ისინი უბრალოდ მაფრთხილებდნენ რაღაცის შესახებ, რაც უკვე ვიცოდი. მაგრამ აღმოჩნდა, რომ ჰოსტერმა ჩართო თავისი ფილტრი ჩემი დომენის წინ და შედეგად ორმაგი ფილტრაციის ქვეშ მოვედი: პროვაიდერებიდან და ჰოსტერიდან. ფილტრმა გაიარა მხოლოდ მოთხოვნების ბოლოები: 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-ის ტოლი მედიანას. მაგრამ მე ვერ გამოვრიცხავ მათ მკაფიო კრიტერიუმზე დაყრდნობით. პირიქით, შემთხვევითმა შემოწმებამ აჩვენა, რომ ისინი დაკავშირებულია აკრძალული რესურსის მოთხოვნასთან.

მისამართები არის მისამართები, მაგრამ ინტერნეტში ავტონომიური სისტემები - AS, რაც უფრო მნიშვნელოვანი აღმოჩნდა 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 ზონაში არის მსგავსი რაოდენობის AS-ები რეგისტრირებული რუსეთში - 6230, რომელთაგან ყველა არ არის პროვაიდერი. UserSide-მ უფრო მკაცრი გამოთვლა გააკეთა და მიიღო 3940 კომპანია 2017 წელს და ეს უფრო ზემოდან მიღებული შეფასებაა. ნებისმიერ შემთხვევაში, ჩვენ გვაქვს განათებული AS-ების რაოდენობა ორნახევარჯერ ნაკლები. მაგრამ აქ უნდა გვესმოდეს, რომ AS არ არის მკაცრად ტოლი პროვაიდერთან. ზოგიერთ პროვაიდერს არ აქვს საკუთარი AS, ზოგიერთს აქვს ერთზე მეტი. თუ ვივარაუდებთ, რომ ყველას ჯერ კიდევ ჰყავს აგენტები, მაშინ ვიღაც უფრო ძლიერად ფილტრავს, ვიდრე სხვები, ისე, რომ მათი მოთხოვნები არ განსხვავდება ნაგვისგან, თუ ისინი საერთოდ მიაღწევენ მათ. მაგრამ უხეში შეფასებისთვის ეს საკმაოდ ასატანია, თუნდაც რაღაც დაიკარგა ჩემი მეთვალყურეობის გამო.

DPI-ს შესახებ

მიუხედავად იმისა, რომ ჩემმა ჰოსტინგის პროვაიდერმა ჩართო მისი ფილტრი მეორე დღიდან, პირველივე დღიდან მიღებული ინფორმაციის საფუძველზე შეგვიძლია დავასკვნათ, რომ დაბლოკვა წარმატებით მუშაობს. მხოლოდ 4 წყარომ შეძლო გავლა და მთლიანად დაასრულა HTTP და TCP სესიები (როგორც ზემოთ მოცემულ მაგალითში). კიდევ 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-ის შესახებ

კარგი ამბავი ის არის, რომ ის არსებობს. თამამად შემიძლია ვთქვა, რომ პერიოდული მოთხოვნები აკრძალულ რესურსზე ხდება 5 სხვადასხვა IPv6 მისამართიდან, რაც სწორედ აგენტების ქცევას ველოდი. უფრო მეტიც, ერთ-ერთი IPv6 მისამართი არ ექვემდებარება ფილტრაციას და მე ვხედავ სრულ სესიას. კიდევ ორიდან ვნახე მხოლოდ ერთი დაუმთავრებელი სესია, რომელთაგან ერთი შეწყდა RST ფილტრიდან მეორე დროში. Მთლიანი რაოდენობა 7.

რადგან მისამართი ცოტაა, ყველა დეტალურად შევისწავლე და აღმოჩნდა, რომ იქ მხოლოდ 3 პროვაიდერია, შეიძლება ოვაციების დადგმა! სხვა მისამართი არის ღრუბლოვანი ჰოსტინგი რუსეთში (არ ფილტრავს), მეორე არის კვლევითი ცენტრი გერმანიაში (ფილტრი არის, სად?). მაგრამ რატომ ამოწმებენ აკრძალული რესურსების ხელმისაწვდომობას გრაფიკზე, კარგი კითხვაა. დანარჩენმა ორმა გააკეთა ერთი მოთხოვნა და მდებარეობს რუსეთის ფარგლებს გარეთ და ერთი მათგანი გაფილტრულია (ტრანზიტში, ბოლოს და ბოლოს?).

ბლოკირება და აგენტები დიდი შემაფერხებელია IPv6-ისთვის, რომლის განხორციელება არც თუ ისე სწრაფად მიდის. სამწუხაროა. მათ, ვინც ეს პრობლემა გადაჭრა, შეიძლება სრულად იამაყოს საკუთარი თავით.

დასასრულს

მე არ ვცდილობდი 100%-იანი სიზუსტისთვის, მაპატიეთ ამის გამო, იმედია ვინმეს მოუნდება ამ ნაწარმოების უფრო დიდი სიზუსტით გამეორება. ჩემთვის მნიშვნელოვანი იყო იმის გაგება, იმუშავებდა თუ არა ეს მიდგომა პრინციპში. პასუხი არის დიახ. მიღებული მაჩვენებლები, როგორც პირველი მიახლოება, ვფიქრობ, საკმაოდ სანდოა.

კიდევ რისი გაკეთება შეიძლებოდა და რისი გაკეთებაც ძალიან მეზარებოდა, იყო DNS მოთხოვნების დათვლა. ისინი არ არის გაფილტრული, მაგრამ ასევე არ იძლევა დიდ სიზუსტეს, რადგან ისინი მუშაობენ მხოლოდ დომენისთვის და არა მთელი URL-ისთვის. სიხშირე უნდა იყოს ხილული. თუ თქვენ დააკავშირებთ მას იმას, რაც პირდაპირ კითხვებში ჩანს, ეს საშუალებას მოგცემთ გამოყოთ არასაჭირო და მიიღოთ მეტი ინფორმაცია. შესაძლებელია პროვაიდერების მიერ გამოყენებული DNS-ის შემქმნელების დადგენა და მრავალი სხვა.

აბსოლუტურად არ ველოდი, რომ ჰოსტერი ასევე მოიცავდა საკუთარ ფილტრს ჩემი VPS-სთვის. შესაძლოა ეს ჩვეულებრივი პრაქტიკაა. საბოლოო ჯამში, RKN უგზავნის მოთხოვნას რესურსის წაშლის შესახებ ჰოსტერში. მაგრამ ეს არ გამიკვირდა და გარკვეულწილად ჩემს სასარგებლოდაც კი მუშაობდა. ფილტრი მუშაობდა ძალიან ეფექტურად, წყვეტდა ყველა სწორი HTTP მოთხოვნას აკრძალულ URL-ზე, მაგრამ არასწორმა, რომლებიც ადრე გადიოდა პროვაიდერების ფილტრში, მიაღწია მათ, თუმცა მხოლოდ დაბოლოებების სახით: FIN-ACK и RST - მინუს მინუსზე და კინაღამ პლიუსი აღმოჩნდა. სხვათა შორის, IPv6 არ იყო გაფილტრული ჰოსტერის მიერ. რა თქმა უნდა, ამან იმოქმედა შეგროვებული მასალის ხარისხზე, მაგრამ მაინც შესაძლებელი გახადა სიხშირის დანახვა. აღმოჩნდა, რომ ეს მნიშვნელოვანი პუნქტია რესურსების განთავსებისთვის საიტის არჩევისას; არ უნდა დაგვავიწყდეს, რომ დაინტერესდეთ სამუშაოს ორგანიზების საკითხით აკრძალული საიტების ჩამონათვალთან და RKN-ს მოთხოვნით.

თავიდან ას „ინსპექტორს“ შევადარე RIPE ატლასი. ეს შედარება საკმაოდ გამართლებულია და აგენტების დიდი ქსელი შეიძლება იყოს მომგებიანი. მაგალითად, რესურსების ხელმისაწვდომობის ხარისხის განსაზღვრა სხვადასხვა პროვაიდერებისგან ქვეყნის სხვადასხვა ნაწილში. თქვენ შეგიძლიათ გამოთვალოთ შეფერხებები, შეგიძლიათ შექმნათ გრაფიკები, შეგიძლიათ გაანალიზოთ ეს ყველაფერი და ნახოთ ცვლილებები, რომლებიც ხდება ადგილობრივ და გლობალურ დონეზე. ეს არ არის ყველაზე პირდაპირი გზა, მაგრამ ასტრონომები იყენებენ "სტანდარტულ სანთლებს", რატომ არ იყენებენ აგენტებს? მათი სტანდარტული ქცევის ცოდნით (იპოვეთ), შეგიძლიათ განსაზღვროთ ცვლილებები, რაც მათ გარშემო ხდება და როგორ აისახება ეს მოწოდებული სერვისების ხარისხზე. ამავდროულად, თქვენ არ გჭირდებათ დამოუკიდებლად განათავსოთ ზონდები ქსელში; Roskomnadzor-მა უკვე დააინსტალირა ისინი.

კიდევ ერთი წერტილი, რომელზეც მინდა შევეხო არის ის, რომ ყველა ინსტრუმენტი შეიძლება იყოს იარაღი. AS "ინსპექტორი" არის დახურული ქსელი, მაგრამ აგენტები გადასცემენ ყველას აკრძალული სიიდან ყველა რესურსის მოთხოვნის გაგზავნით. ასეთი რესურსის ქონა არანაირ პრობლემას არ წარმოადგენს. მთლიანობაში, პროვაიდერები აგენტების მეშვეობით, უნებურად, ბევრ მეტს ამბობენ თავიანთი ქსელის შესახებ, ვიდრე ალბათ ღირს: DPI და DNS ტიპები, აგენტის მდებარეობა (ცენტრალური კვანძი და სერვისის ქსელი?), შეფერხებებისა და დანაკარგების ქსელის მარკერები - და ეს არის მხოლოდ ყველაზე აშკარა. ისევე, როგორც ვინმეს შეუძლია აკონტროლოს აგენტების ქმედებები მათი რესურსების ხელმისაწვდომობის გასაუმჯობესებლად, ვიღაცას შეუძლია ამის გაკეთება სხვა მიზნებისთვის და ამისთვის არანაირი დაბრკოლება არ არსებობს. შედეგი არის ორპირიანი და ძალიან მრავალმხრივი ინსტრუმენტი, ამის დანახვა ყველას შეუძლია.

წყარო: www.habr.com