ไม่มีความลับใดที่การควบคุมการบล็อกในรายการข้อมูลที่ต้องห้ามในรัสเซียได้รับการตรวจสอบโดยระบบอัตโนมัติ "ผู้ตรวจสอบ" วิธีการทำงานก็เขียนได้ดีที่นี่ ,ภาพจากที่เดียวกัน:
ติดตั้งกับผู้ให้บริการโดยตรง :
โมดูล "Agent Inspector" เป็นองค์ประกอบโครงสร้างของระบบอัตโนมัติ "Inspector" (AS "Inspector") ระบบนี้ได้รับการออกแบบมาเพื่อตรวจสอบการปฏิบัติตามโดยผู้ให้บริการโทรคมนาคมที่มีข้อกำหนดการ จำกัด การเข้าถึงภายในกรอบของบทบัญญัติที่กำหนดโดยมาตรา 15.1-15.4 ของกฎหมายของรัฐบาลกลางวันที่ 27 กรกฎาคม 2006 ฉบับที่ 149-FZ“ เกี่ยวกับข้อมูลเทคโนโลยีสารสนเทศและการปกป้องข้อมูล ”
วัตถุประสงค์หลักของการสร้าง AS "Revizor" คือเพื่อให้แน่ใจว่าการตรวจสอบการปฏิบัติตามข้อกำหนดของผู้ให้บริการโทรคมนาคมตามข้อกำหนดที่กำหนดโดยมาตรา 15.1-15.4 ของกฎหมายของรัฐบาลกลางวันที่ 27 กรกฎาคม 2006 ฉบับที่ 149-FZ "เกี่ยวกับข้อมูลเทคโนโลยีสารสนเทศและการคุ้มครองข้อมูล " ในด้านการระบุข้อเท็จจริงในการเข้าถึงข้อมูลต้องห้ามและการได้รับเอกสารสนับสนุน (ข้อมูล) เกี่ยวกับการละเมิดเพื่อจำกัดการเข้าถึงข้อมูลต้องห้าม
เมื่อคำนึงถึงความจริงที่ว่าหากไม่ใช่ทั้งหมด ผู้ให้บริการหลายรายได้ติดตั้งอุปกรณ์นี้ ก็ควรมีเครือข่ายโพรบบีคอนขนาดใหญ่เช่น และอีกมากมายแต่มีการเข้าถึงแบบปิด อย่างไรก็ตาม บีคอนก็คือบีคอนที่ส่งสัญญาณไปทุกทิศทุกทาง แต่ถ้าเราจับได้ แล้วดูว่าจับอะไรได้กี่ตัวล่ะ?
ก่อนที่เราจะนับ เรามาดูกันว่าเหตุใดจึงเป็นไปได้
ทฤษฎีเล็กน้อย
เจ้าหน้าที่ตรวจสอบความพร้อมใช้งานของทรัพยากร รวมถึงผ่านคำขอ 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 บางส่วนไม่จำเป็นอย่างไม่ต้องสงสัย แต่ก็ยากที่จะแยกออกได้อย่างน่าเชื่อถือเนื่องจากทรัพยากรอยู่ภายใต้การบล็อกและตั้งแต่วันที่สองภายใต้การบล็อกสองครั้งและเซสชันส่วนใหญ่เป็นเพียงการแลกเปลี่ยนแพ็กเก็ตบริการต่างๆ ยอมรับว่านี่เป็นเพียงส่วนเล็กๆ
ตัวเลขเหล่านี้สามารถเปรียบเทียบได้กับจำนวนผู้ให้บริการในรัสเซียแล้ว ใบอนุญาตสำหรับ "บริการการสื่อสารสำหรับการส่งข้อมูล ไม่รวมเสียง" - 6387 แต่นี่เป็นค่าประมาณที่สูงมากจากด้านบน ใบอนุญาตเหล่านี้บางส่วนอาจไม่มีผลกับผู้ให้บริการอินเทอร์เน็ตที่ต้องการติดตั้งตัวแทนโดยเฉพาะ ในโซน RIPE NCC มี ASes จำนวนใกล้เคียงกันที่จดทะเบียนในรัสเซีย - 6230 ซึ่งไม่ใช่ผู้ให้บริการทั้งหมด และได้รับบริษัท 3940 แห่งในปี 2017 และนี่เป็นการประมาณการจากด้านบน ไม่ว่าในกรณีใด เรามี AS ที่ส่องสว่างน้อยกว่าสองเท่าครึ่ง แต่ที่นี่ควรเข้าใจว่า AS ไม่เท่ากับผู้ให้บริการอย่างเคร่งครัด ผู้ให้บริการบางรายไม่มี AS ของตนเอง บางรายมีมากกว่าหนึ่งราย หากเราถือว่าทุกคนยังมีตัวแทนอยู่ ก็จะมีบางคนกรองอย่างเข้มงวดมากกว่าคนอื่นๆ เพื่อให้คำขอของพวกเขาแยกไม่ออกจากขยะหากพวกเขาไปถึงพวกเขาเลย แต่สำหรับการประเมินคร่าวๆ ก็ถือว่าค่อนข้างทนได้ แม้ว่าบางสิ่งจะสูญหายไปเนื่องจากการกำกับดูแลของฉันก็ตาม
เกี่ยวกับ ดีพีไอ
แม้ว่าผู้ให้บริการโฮสติ้งของฉันจะเปิดตัวกรองตั้งแต่วันที่สองก็ตาม แต่จากข้อมูลในวันแรก เราสามารถสรุปได้ว่าการบล็อกทำงานได้สำเร็จ มีเพียง 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
ข่าวดีก็คือว่ามันมีอยู่จริง ฉันสามารถพูดได้อย่างน่าเชื่อถือว่าคำขอเป็นระยะไปยังทรัพยากรต้องห้ามนั้นเกิดขึ้นจากที่อยู่ IPv5 ที่แตกต่างกัน 6 รายการ ซึ่งเป็นพฤติกรรมของตัวแทนที่ฉันคาดหวังไว้อย่างแน่นอน นอกจากนี้ หนึ่งในที่อยู่ IPv6 ไม่ตกอยู่ภายใต้การกรอง และฉันเห็นเซสชันทั้งหมด จากอีกสองเซสชัน ฉันเห็นเซสชันที่ยังทำไม่เสร็จเพียงเซสชันเดียว ซึ่งเซสชันหนึ่งถูกขัดจังหวะด้วย RST จากตัวกรองเป็นครั้งที่สอง จำนวนเงินทั้งหมด 7.
เนื่องจากมีที่อยู่ไม่มากนัก ฉันจึงศึกษาทั้งหมดโดยละเอียดและปรากฏว่ามีผู้ให้บริการเพียง 3 รายที่นั่น พวกเขาสามารถได้รับการปรบมือต้อนรับ! อีกที่อยู่หนึ่งคือคลาวด์โฮสติ้งในรัสเซีย (ไม่กรอง) อีกแห่งคือศูนย์วิจัยในเยอรมนี (มีตัวกรองอยู่ที่ไหน?) แต่เหตุใดพวกเขาจึงตรวจสอบความพร้อมของทรัพยากรต้องห้ามตามกำหนดเวลาจึงเป็นคำถามที่ดี อีกสองคนที่เหลือส่งคำขอหนึ่งครั้งและตั้งอยู่นอกรัสเซีย และหนึ่งในนั้นถูกกรอง (ระหว่างทางใช่ไหม)
การบล็อกและเอเจนต์เป็นอุปสรรคสำคัญต่อ IPv6 ซึ่งการใช้งานไม่ได้ดำเนินไปอย่างรวดเร็วนัก มันเป็นเรื่องน่าเศร้า ผู้ที่แก้ไขปัญหานี้สามารถภาคภูมิใจในตนเองได้อย่างเต็มที่
ในข้อสรุป
ฉันไม่ได้มุ่งมั่นเพื่อความถูกต้อง 100% โปรดยกโทษให้ฉันด้วย ฉันหวังว่าจะมีคนต้องการทำซ้ำงานนี้ให้มีความแม่นยำมากขึ้น เป็นสิ่งสำคัญสำหรับฉันที่จะเข้าใจว่าแนวทางนี้จะได้ผลในหลักการหรือไม่ คำตอบคือใช่ ฉันคิดว่าตัวเลขที่ได้รับเป็นการประมาณครั้งแรกค่อนข้างเชื่อถือได้
มีอะไรอีกที่สามารถทำได้และสิ่งที่ฉันขี้เกียจเกินกว่าจะทำคือการนับคำขอ DNS ไม่มีการกรอง แต่ก็ไม่ได้ให้ความแม่นยำมากนัก เนื่องจากใช้ได้เฉพาะกับโดเมนเท่านั้น ไม่ใช่กับ URL ทั้งหมด ควรมองเห็นความถี่ได้ หากคุณรวมเข้ากับสิ่งที่มองเห็นได้โดยตรงในแบบสอบถาม จะช่วยให้คุณสามารถแยกสิ่งที่ไม่จำเป็นออกและรับข้อมูลเพิ่มเติมได้ เป็นไปได้ที่จะระบุผู้พัฒนา DNS ที่ผู้ให้บริการใช้และอีกมากมาย
ฉันไม่ได้คาดหวังเลยจริงๆ ว่าผู้ให้บริการโฮสต์จะมีตัวกรองของตัวเองสำหรับ VPS ของฉันด้วย บางทีนี่อาจเป็นวิธีปฏิบัติทั่วไป ในท้ายที่สุด RKN จะส่งคำขอให้ลบทรัพยากรไปยังโฮสต์ แต่สิ่งนี้ไม่ได้ทำให้ฉันประหลาดใจและในบางวิธีก็ใช้ได้ผลดีกับฉันด้วย ตัวกรองทำงานได้อย่างมีประสิทธิภาพมาก โดยตัดคำขอ HTTP ที่ถูกต้องทั้งหมดไปยัง URL ที่ต้องห้าม แต่คำขอไม่ถูกต้องที่ส่งผ่านตัวกรองของผู้ให้บริการก่อนหน้านี้เข้าถึงได้ แม้ว่าจะอยู่ในรูปแบบของการลงท้ายเท่านั้น: FIN-ACK и RST - ลบต่อลบ และเกือบจะกลายเป็นบวก อย่างไรก็ตาม IPv6 ไม่ได้ถูกกรองโดยโฮสต์ แน่นอนว่าสิ่งนี้ส่งผลต่อคุณภาพของวัสดุที่รวบรวม แต่ก็ยังทำให้สามารถมองเห็นความถี่ได้ ปรากฎว่านี่เป็นจุดสำคัญในการเลือกสถานที่สำหรับวางทรัพยากรอย่าลืมที่จะสนใจในเรื่องของการจัดงานพร้อมรายชื่อไซต์ต้องห้ามและคำขอจาก RKN
ในตอนแรกผมเปรียบเทียบ AS "Inspector" กับ . การเปรียบเทียบนี้ค่อนข้างสมเหตุสมผลและเครือข่ายตัวแทนขนาดใหญ่ก็สามารถเป็นประโยชน์ได้ ตัวอย่างเช่น การพิจารณาคุณภาพของทรัพยากรที่มีอยู่จากผู้ให้บริการที่แตกต่างกันในส่วนต่างๆ ของประเทศ คุณสามารถคำนวณความล่าช้า คุณสามารถสร้างกราฟ คุณสามารถวิเคราะห์ได้ทั้งหมด และดูการเปลี่ยนแปลงที่เกิดขึ้นทั้งในระดับท้องถิ่นและระดับโลก นี่ไม่ใช่วิธีที่ตรงที่สุด แต่นักดาราศาสตร์ใช้ "เทียนมาตรฐาน" ทำไมไม่ใช้ตัวแทนล่ะ เมื่อทราบ (เมื่อพบ) พฤติกรรมมาตรฐานแล้ว คุณสามารถกำหนดการเปลี่ยนแปลงที่เกิดขึ้นรอบตัวพวกเขาได้ และสิ่งนี้ส่งผลต่อคุณภาพของบริการที่มีให้อย่างไร และในเวลาเดียวกันคุณไม่จำเป็นต้องวางโพรบบนเครือข่ายอย่างอิสระ Roskomnadzor ได้ติดตั้งไว้แล้ว
อีกประเด็นที่ผมอยากพูดถึงคือเครื่องมือทุกอย่างสามารถเป็นอาวุธได้ AS "Inspector" เป็นเครือข่ายปิด แต่ตัวแทนมอบทุกคนโดยส่งคำขอทรัพยากรทั้งหมดจากรายการต้องห้าม การมีทรัพยากรดังกล่าวไม่ได้ทำให้เกิดปัญหาแต่อย่างใด โดยรวมแล้ว ผู้ให้บริการผ่านตัวแทนบอกเล่าเรื่องราวต่างๆ มากมายเกี่ยวกับเครือข่ายของตนโดยไม่รู้ตัวมากกว่าที่ควรจะเป็น: ประเภท DPI และ DNS, ตำแหน่งของตัวแทน (โหนดกลางและเครือข่ายบริการ?), เครื่องหมายเครือข่ายของความล่าช้าและการสูญเสีย - และนี่คือ ที่ชัดเจนที่สุดเท่านั้น เช่นเดียวกับที่ใครบางคนสามารถตรวจสอบการกระทำของตัวแทนเพื่อปรับปรุงความพร้อมใช้งานของทรัพยากรของพวกเขา บางคนก็สามารถทำเช่นนี้เพื่อวัตถุประสงค์อื่นได้ และไม่มีอุปสรรคในเรื่องนี้ ผลลัพธ์ที่ได้คือเครื่องดนตรีสองคมและมีหลายแง่มุม ใครๆ ก็สามารถเห็นสิ่งนี้ได้
ที่มา: will.com