"ఇన్‌స్పెక్టర్" ఏజెంట్లను లెక్కిద్దాం

రష్యాలో నిషేధించబడిన సమాచారం యొక్క జాబితాలో నిరోధించే నియంత్రణ ఆటోమేటెడ్ సిస్టమ్ "ఇన్స్పెక్టర్" ద్వారా పర్యవేక్షించబడుతుందనేది రహస్యం కాదు. ఇది ఎలా పని చేస్తుందో ఇక్కడ బాగా వ్రాయబడింది Habr పై వ్యాసం, అదే స్థలం నుండి చిత్రం:

ప్రొవైడర్ వద్ద నేరుగా ఇన్‌స్టాల్ చేయబడింది మాడ్యూల్ "ఏజెంట్ ఇన్స్పెక్టర్":

"ఏజెంట్ ఇన్‌స్పెక్టర్" మాడ్యూల్ అనేది ఆటోమేటెడ్ సిస్టమ్ "ఇన్‌స్పెక్టర్" (AS "ఇన్‌స్పెక్టర్") యొక్క నిర్మాణ మూలకం. జూలై 15.1, 15.4 నెం. 27-FZ “సమాచారం, సమాచార సాంకేతికతలు మరియు సమాచార రక్షణపై ఫెడరల్ చట్టంలోని ఆర్టికల్స్ 2006-149 ద్వారా ఏర్పాటు చేయబడిన నిబంధనల చట్రంలో యాక్సెస్ పరిమితి అవసరాలతో టెలికాం ఆపరేటర్ల సమ్మతిని పర్యవేక్షించడానికి ఈ వ్యవస్థ రూపొందించబడింది. ”

జూలై 15.1, 15.4 నెం. 27-FZ "సమాచారం, ఇన్ఫర్మేషన్ టెక్నాలజీస్ మరియు ఇన్ఫర్మేషన్ ప్రొటెక్షన్‌పై ఫెడరల్ లా యొక్క ఆర్టికల్స్ 2006-149 ద్వారా ఏర్పాటు చేయబడిన అవసరాలకు టెలికాం ఆపరేటర్ల సమ్మతిని పర్యవేక్షించడం AS "రివైజర్"ని సృష్టించడం యొక్క ముఖ్య ఉద్దేశ్యం. " నిషేధించబడిన సమాచారానికి ప్రాప్యత యొక్క వాస్తవాలను గుర్తించడం మరియు నిషేధించబడిన సమాచారానికి ప్రాప్యతను పరిమితం చేయడానికి ఉల్లంఘనల గురించి సహాయక సామగ్రిని (డేటా) పొందడం పరంగా.

అన్నీ కాకపోయినా, చాలా మంది ప్రొవైడర్లు ఈ పరికరాన్ని ఇన్‌స్టాల్ చేశారనే వాస్తవాన్ని పరిగణనలోకి తీసుకుంటే, బెకన్ ప్రోబ్స్ యొక్క పెద్ద నెట్‌వర్క్ ఉండాలి 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 బ్లాకింగ్ రకంతో తగిన ఉచిత డొమైన్‌ను ఎంచుకోవాలి, ఎజెంట్‌ల నుండి మినహా అదనపు ట్రాఫిక్‌ను తగ్గించడానికి చాలా కాలం పాటు వదిలివేయబడుతుంది. ఈ పని అస్సలు కష్టం కాదని తేలింది; నిషేధిత సమాచారం యొక్క రిజిస్టర్‌లో మరియు ప్రతి రుచికి చాలా ఉచిత డొమైన్‌లు ఉన్నాయి. అందువల్ల, డొమైన్ కొనుగోలు చేయబడింది మరియు నడుస్తున్న 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కి సమానమైన మధ్యస్థాన్ని పొందుతాము. కానీ స్పష్టమైన ప్రమాణం ఆధారంగా నేను వాటిని మినహాయించలేను. దీనికి విరుద్ధంగా, ఒక యాదృచ్ఛిక తనిఖీలో అవి నిషేధించబడిన వనరు కోసం అభ్యర్థనలకు సంబంధించినవి అని చూపించింది.

చిరునామాలు చిరునామాలు, కానీ ఇంటర్నెట్‌లో, స్వయంప్రతిపత్త వ్యవస్థలు - AS, ఇది మరింత ముఖ్యమైనదిగా మారింది 1510, సగటున 2 చిరునామాలు ప్రతి AS మధ్యస్థం 1. అగ్ర చిరునామాలు: 288, 77, 66, 39, 27. నమూనాలో గరిష్టంగా 95% ప్రతి ASకి 4 చిరునామాలు. ఇక్కడ మధ్యస్థం అంచనా వేయబడుతుంది - ప్రతి ప్రొవైడర్‌కు ఒక ఏజెంట్. మేము కూడా అగ్రస్థానాన్ని ఆశిస్తున్నాము - అందులో పెద్ద ఆటగాళ్లు ఉన్నారు. పెద్ద నెట్‌వర్క్‌లో, ఏజెంట్లు బహుశా ఆపరేటర్ ఉనికిలో ఉన్న ప్రతి ప్రాంతంలో ఉండాలి మరియు NAT గురించి మర్చిపోవద్దు. మేము దానిని దేశం వారీగా తీసుకుంటే, గరిష్టాలు: 1409 - RU, 42 - UA, 23 - CZ, 36 ఇతర ప్రాంతాల నుండి, RIPE NCC కాదు. రష్యా వెలుపల నుండి వచ్చిన అభ్యర్థనలు దృష్టిని ఆకర్షిస్తాయి. డేటాను పూరించేటప్పుడు జియోలొకేషన్ లోపాలు లేదా రిజిస్ట్రార్ ఎర్రర్‌ల ద్వారా ఇది బహుశా వివరించబడవచ్చు. లేదా ఒక రష్యన్ కంపెనీ రష్యన్ మూలాలను కలిగి ఉండకపోవచ్చు లేదా విదేశీ ప్రతినిధి కార్యాలయాన్ని కలిగి ఉండకపోవచ్చు, ఎందుకంటే ఇది సులభంగా ఉంటుంది, ఇది విదేశీ సంస్థ RIPE NCCతో వ్యవహరించేటప్పుడు సహజమైనది. కొంత భాగం నిస్సందేహంగా నిరుపయోగంగా ఉంది, కానీ దానిని వేరు చేయడం విశ్వసనీయంగా కష్టం, ఎందుకంటే వనరు నిరోధించబడుతోంది మరియు రెండవ రోజు నుండి డబుల్ బ్లాకింగ్‌లో ఉంది మరియు చాలా సెషన్‌లు అనేక సేవా ప్యాకెట్‌ల మార్పిడి మాత్రమే. ఇది చిన్న భాగమని ఒప్పుకుందాం.

ఈ సంఖ్యలను ఇప్పటికే రష్యాలోని ప్రొవైడర్ల సంఖ్యతో పోల్చవచ్చు. RKN ప్రకారం “వాయిస్ మినహా డేటా ట్రాన్స్‌మిషన్ కోసం కమ్యూనికేషన్ సేవలు” కోసం లైసెన్స్‌లు - 6387, కానీ ఇది పై నుండి చాలా ఎక్కువ అంచనా, ఈ లైసెన్సులన్నీ ఏజెంట్‌ను ఇన్‌స్టాల్ చేయాల్సిన ఇంటర్నెట్ ప్రొవైడర్లకు ప్రత్యేకంగా వర్తించవు. RIPE NCC జోన్‌లో రష్యాలో నమోదు చేయబడిన AS ల సంఖ్య ఇదే - 6230, వీటిలో అన్నీ ప్రొవైడర్లు కాదు. యూజర్‌సైడ్ మరింత కఠినమైన గణనను చేసింది మరియు 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 రిసోర్స్‌ని తొలగించమని రిక్వెస్ట్‌ని హోస్టర్‌కి పంపుతుంది. కానీ ఇది నాకు ఆశ్చర్యం కలిగించలేదు మరియు కొన్ని మార్గాల్లో నా ప్రయోజనానికి కూడా పనిచేసింది. ఫిల్టర్ చాలా ప్రభావవంతంగా పనిచేసింది, నిషేధించబడిన URLకి సంబంధించిన అన్ని సరైన HTTP అభ్యర్థనలను కత్తిరించింది, కానీ అంతకుముందు ప్రొవైడర్ల ఫిల్టర్ ద్వారా వెళ్ళిన సరైనవి వాటిని చేరుకోలేదు, అయినప్పటికీ ముగింపుల రూపంలో మాత్రమే: FIN-ACK и RST - మైనస్‌కి మైనస్ మరియు ఇది దాదాపు ప్లస్‌గా మారింది. మార్గం ద్వారా, IPv6 హోస్టర్ ద్వారా ఫిల్టర్ చేయబడలేదు. వాస్తవానికి, ఇది సేకరించిన పదార్థం యొక్క నాణ్యతను ప్రభావితం చేసింది, అయితే ఇది ఇప్పటికీ ఫ్రీక్వెన్సీని చూడటం సాధ్యం చేసింది. వనరులను ఉంచడానికి సైట్‌ను ఎన్నుకునేటప్పుడు ఇది ఒక ముఖ్యమైన విషయం అని తేలింది; నిషేధించబడిన సైట్‌ల జాబితా మరియు RKN నుండి అభ్యర్థనలతో పనిని నిర్వహించే సమస్యపై ఆసక్తి చూపడం మర్చిపోవద్దు.

ప్రారంభంలో, నేను AS "ఇన్‌స్పెక్టర్"తో పోల్చాను RIPE అట్లాస్. ఈ పోలిక చాలా సమర్థించబడుతోంది మరియు ఏజెంట్ల పెద్ద నెట్‌వర్క్ ప్రయోజనకరంగా ఉంటుంది. ఉదాహరణకు, దేశంలోని వివిధ ప్రాంతాలలో వివిధ ప్రొవైడర్ల నుండి వనరుల లభ్యత నాణ్యతను నిర్ణయించడం. మీరు జాప్యాలను లెక్కించవచ్చు, మీరు గ్రాఫ్‌లను రూపొందించవచ్చు, మీరు అన్నింటినీ విశ్లేషించవచ్చు మరియు స్థానికంగా మరియు ప్రపంచవ్యాప్తంగా సంభవించే మార్పులను చూడవచ్చు. ఇది చాలా ప్రత్యక్ష మార్గం కాదు, కానీ ఖగోళ శాస్త్రవేత్తలు "ప్రామాణిక కొవ్వొత్తులను" ఉపయోగిస్తారు, ఎందుకు ఏజెంట్లను ఉపయోగించకూడదు? వారి ప్రామాణిక ప్రవర్తనను తెలుసుకోవడం (కనుగొనడం), మీరు వారి చుట్టూ సంభవించే మార్పులను మరియు అందించిన సేవల నాణ్యతను ఎలా ప్రభావితం చేస్తుందో నిర్ణయించవచ్చు. మరియు అదే సమయంలో, మీరు నెట్‌వర్క్‌లో స్వతంత్రంగా ప్రోబ్‌లను ఉంచాల్సిన అవసరం లేదు; Roskomnadzor ఇప్పటికే వాటిని ఇన్‌స్టాల్ చేసింది.

నేను టచ్ చేయాలనుకుంటున్న మరో విషయం ఏమిటంటే, ప్రతి సాధనం ఆయుధంగా ఉంటుంది. AS "ఇన్‌స్పెక్టర్" అనేది క్లోజ్డ్ నెట్‌వర్క్, కానీ ఏజెంట్లు నిషేధిత జాబితా నుండి అన్ని వనరుల కోసం అభ్యర్థనలను పంపడం ద్వారా ప్రతి ఒక్కరినీ అప్పగిస్తారు. అటువంటి వనరు కలిగి ఉండటం వలన ఎటువంటి సమస్యలు ఉండవు. మొత్తంగా, ఏజెంట్ల ద్వారా ప్రొవైడర్లు, తెలియకుండానే, వారి నెట్‌వర్క్ గురించి బహుశా విలువైన దానికంటే చాలా ఎక్కువ చెప్పండి: DPI మరియు DNS రకాలు, ఏజెంట్ యొక్క స్థానం (సెంట్రల్ నోడ్ మరియు సర్వీస్ నెట్‌వర్క్?), జాప్యాలు మరియు నష్టాల నెట్‌వర్క్ గుర్తులు - మరియు ఇది అత్యంత స్పష్టమైనది మాత్రమే. ఎవరైనా తమ వనరుల లభ్యతను మెరుగుపరచడానికి ఏజెంట్ల చర్యలను పర్యవేక్షించగలిగినట్లుగా, ఎవరైనా ఇతర ప్రయోజనాల కోసం దీన్ని చేయవచ్చు మరియు దీనికి ఎటువంటి అడ్డంకులు లేవు. ఫలితంగా డబుల్ ఎడ్జ్ మరియు చాలా బహుముఖ పరికరం, ఎవరైనా దీన్ని చూడగలరు.

మూలం: www.habr.com