Nid yw'n gyfrinach bod rheolaeth blocio ar y rhestr o wybodaeth waharddedig yn Rwsia yn cael ei fonitro gan y system awtomataidd "Arolygydd". Mae sut mae'n gweithio wedi'i ysgrifennu'n dda yma , llun o'r un lle:
Wedi'i osod yn uniongyrchol yn y darparwr :
Mae'r modiwl "Arolygydd Asiant" yn elfen strwythurol o'r system awtomataidd "Arolygydd" (UG "Arolygydd"). Mae'r system hon wedi'i chynllunio i fonitro cydymffurfiaeth gweithredwyr telathrebu â gofynion cyfyngu mynediad o fewn fframwaith y darpariaethau a sefydlwyd gan Erthyglau 15.1-15.4 o Gyfraith Ffederal Gorffennaf 27, 2006 Rhif 149-FZ “Ar Wybodaeth, Technolegau Gwybodaeth a Diogelu Gwybodaeth. ”
Prif bwrpas creu AS "Revizor" yw sicrhau monitro cydymffurfiad gweithredwyr telathrebu â'r gofynion a sefydlwyd gan Erthyglau 15.1-15.4 o Gyfraith Ffederal Gorffennaf 27, 2006 Rhif 149-FZ "Ar Wybodaeth, Technolegau Gwybodaeth a Diogelu Gwybodaeth “ o ran nodi ffeithiau mynediad at wybodaeth waharddedig a chael deunyddiau ategol (data) am droseddau i gyfyngu ar fynediad at wybodaeth waharddedig.
Gan gymryd i ystyriaeth y ffaith, os nad y cyfan, bod llawer o ddarparwyr wedi gosod y ddyfais hon, dylai fod rhwydwaith mawr o stilwyr beacon fel a mwy fyth, ond gyda mynediad caeedig. Fodd bynnag, mae beacon yn oleufa i anfon signalau i bob cyfeiriad, ond beth os ydym yn eu dal a gweld yr hyn y gwnaethom ei ddal a faint?
Cyn i ni gyfrif, gadewch i ni weld pam y gallai hyn fod yn bosibl hyd yn oed.
Darn o theori
Mae asiantau yn gwirio argaeledd adnodd, gan gynnwys trwy geisiadau HTTP(S), fel yr un hwn:
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"
Yn ogystal â'r llwyth tâl, mae'r cais hefyd yn cynnwys cyfnod sefydlu cysylltiad: cyfnewid SYN и SYN-ACK, a chamau cwblhau cysylltiad: FIN-ACK.
Mae'r gofrestr o wybodaeth waharddedig yn cynnwys sawl math o rwystro. Yn amlwg, os yw adnodd yn cael ei rwystro gan gyfeiriad IP neu enw parth, yna ni fyddwn yn gweld unrhyw geisiadau. Dyma'r mathau mwyaf dinistriol o rwystro, sy'n arwain at anhygyrchedd yr holl adnoddau ar un cyfeiriad IP neu'r holl wybodaeth ar barth. Mae yna hefyd fath "gan URL" o rwystro. Yn yr achos hwn, rhaid i'r system hidlo ddosrannu pennawd cais HTTP i benderfynu yn union beth i'w rwystro. Ac o'i flaen, fel y gwelir uchod, dylai fod cyfnod sefydlu cysylltiad y gallwch geisio ei olrhain, gan ei fod yn fwyaf tebygol y bydd yr hidlydd yn ei golli.
I wneud hyn, mae angen i chi ddewis parth rhad ac am ddim addas gyda'r math blocio “URL” a HTTP i hwyluso gwaith y system hidlo, yn ddelfrydol wedi'i gadael yn hir, i leihau mynediad traffig allanol ac eithrio gan Asiantau. Nid oedd y dasg hon yn anodd o gwbl; mae cryn dipyn o barthau rhydd yn y gofrestr o wybodaeth waharddedig ac at bob chwaeth. Felly, prynwyd y parth a'i gysylltu â chyfeiriadau IP ar VPS yn rhedeg tcpdump a dechreuodd y cyfrif.
Archwiliad o "Archwilwyr"
Roeddwn yn disgwyl gweld pyliau cyfnodol o geisiadau, a fyddai, yn fy marn i, yn dynodi camau rheoledig. Mae’n amhosib dweud na welais i o o gwbl, ond yn bendant doedd dim darlun clir:
Nid yw hyn yn syndod, hyd yn oed ar barth nad oes ei angen ar unrhyw un ac ar IP nas defnyddiwyd erioed, yn syml bydd tunnell o wybodaeth ddigymell, fel y Rhyngrwyd modern. Ond yn ffodus, dim ond ceisiadau am URL penodol oedd eu hangen arnaf, felly daethpwyd o hyd i'r holl sganwyr a chracwyr cyfrinair yn gyflym. Hefyd, roedd yn eithaf hawdd deall ble roedd y llifogydd yn seiliedig ar y màs o geisiadau tebyg. Nesaf, lluniais amlder cyfeiriadau IP a mynd trwy'r brig cyfan â llaw, gan wahanu'r rhai a'i collodd yn y camau blaenorol. Yn ogystal, torrais allan yr holl ffynonellau a anfonwyd mewn un pecyn, nid oedd llawer ohonynt bellach. A dyma beth ddigwyddodd:
Digression telynegol bach. Ychydig yn fwy na diwrnod yn ddiweddarach, anfonodd fy narparwr cynnal lythyr gyda chynnwys eithaf syml, yn dweud bod eich cyfleusterau'n cynnwys adnodd o restr waharddedig RKN, felly mae'n cael ei rwystro. Ar y dechrau roeddwn i'n meddwl bod fy nghyfrif wedi'i rwystro, nid oedd hyn yn wir. Yna meddyliais eu bod yn fy rhybuddio am rywbeth yr oeddwn eisoes yn gwybod amdano. Ond daeth i'r amlwg bod y gwesteiwr wedi troi ei hidlydd ymlaen o flaen fy mharth ac o ganlyniad deuthum o dan hidlo dwbl: gan y darparwyr ac o'r gwesteiwr. Dim ond diwedd y ceisiadau a basiodd yr hidlydd: FIN-ACK и RST torri i ffwrdd yr holl HTTP ar URL gwaharddedig. Fel y gwelwch o'r graff uchod, ar ôl y diwrnod cyntaf dechreuais dderbyn llai o ddata, ond fe'i derbyniais o hyd, a oedd yn ddigon eithaf ar gyfer y dasg o gyfrif ffynonellau ceisiadau.
Cyrraedd y pwynt. Yn fy marn i, mae dau byrstio i'w gweld yn glir bob dydd, y cyntaf yn llai, ar ôl amser Moscow hanner nos, yr ail yn nes at 6 am gyda chynffon tan hanner dydd. Nid yw'r brig yn digwydd ar yr un pryd yn union. Ar y dechrau, roeddwn i eisiau dewis cyfeiriadau IP a ddisgynnodd yn y cyfnodau hyn yn unig a phob un ym mhob cyfnod, yn seiliedig ar y rhagdybiaeth bod gwiriadau gan Asiantau yn cael eu perfformio o bryd i'w gilydd. Ond o adolygu'n ofalus, darganfyddais yn gyflym fod cyfnodau'n disgyn i gyfnodau eraill, gydag amleddau eraill, hyd at un cais bob awr. Yna meddyliais am barthau amser ac efallai bod ganddo rywbeth i'w wneud â nhw, yna meddyliais yn gyffredinol efallai na fyddai'r system yn cael ei chydamseru'n fyd-eang. Yn ogystal, mae'n debyg y bydd NAT yn chwarae rhan a gall yr un Asiant wneud ceisiadau gan IPs cyhoeddus gwahanol.
Gan nad oedd fy nod cychwynnol yn union, fe wnes i gyfri'r holl gyfeiriadau y des i ar eu traws mewn wythnos a chael - 2791. Mae nifer y sesiynau TCP a sefydlwyd o un cyfeiriad ar gyfartaledd yn 4, gyda chanolrif o 2. Sesiynau uchaf fesul cyfeiriad: 464, 231, 149, 83, 77. Yr uchafswm o 95% o'r sampl yw 8 sesiwn fesul cyfeiriad. Nid yw'r canolrif yn uchel iawn, gadewch imi eich atgoffa bod y graff yn dangos cyfnod dyddiol clir, felly gallai rhywun ddisgwyl rhywbeth tua 4 i 8 mewn 7 diwrnod. Os byddwn yn taflu allan yr holl sesiynau sy'n digwydd unwaith, byddwn yn cael canolrif cyfartal i 5. Ond ni allwn eu heithrio yn seiliedig ar faen prawf clir. I'r gwrthwyneb, dangosodd gwiriad ar hap eu bod yn gysylltiedig â cheisiadau am adnodd gwaharddedig.
Cyfeiriadau yw cyfeiriadau, ond ar y Rhyngrwyd, systemau ymreolaethol - AS, a drodd allan i fod yn bwysicach 1510, ar gyfartaledd 2 gyfeiriad fesul UG gyda chanolrif o 1. Cyfeiriad uchaf fesul UG: 288, 77, 66, 39, 27. Uchafswm y sampl o 95% yw 4 cyfeiriad fesul UG. Yma disgwylir y canolrif - un Asiant i bob darparwr. Rydym hefyd yn disgwyl y brig - mae chwaraewyr mawr ynddo. Mewn rhwydwaith mawr, mae'n debyg y dylai Asiantau gael eu lleoli ym mhob rhanbarth o bresenoldeb y gweithredwr, a pheidiwch ag anghofio am NAT. Os byddwn yn ei gymryd yn ôl gwlad, yr uchafsymiau fydd: 1409 - RU, 42 - AU, 23 - CZ, 36 o ranbarthau eraill, nid RIPE NCC. Mae ceisiadau o'r tu allan i Rwsia yn denu sylw. Mae'n debyg y gellir esbonio hyn gan wallau geolocation neu wallau cofrestrydd wrth lenwi data. Neu'r ffaith efallai na fydd gan gwmni Rwsia wreiddiau Rwsia, neu fod â swyddfa cynrychiolydd tramor oherwydd ei fod yn haws, sy'n naturiol wrth ddelio â sefydliad tramor RIPE NCC. Heb os, mae rhywfaint o ran yn ddiangen, ond mae'n anodd ei wahanu'n ddibynadwy, gan fod yr adnodd dan flocio, ac o'r ail ddiwrnod o dan flocio dwbl, ac mae'r rhan fwyaf o sesiynau yn gyfnewidiad o sawl pecyn gwasanaeth yn unig. Gadewch i ni gytuno mai rhan fach yw hon.
Gellir cymharu'r niferoedd hyn eisoes â nifer y darparwyr yn Rwsia. trwyddedau ar gyfer “Gwasanaethau cyfathrebu ar gyfer trosglwyddo data, heb gynnwys llais” - 6387, ond mae hwn yn amcangyfrif uchel iawn oddi uchod, nid yw pob un o'r trwyddedau hyn yn berthnasol yn benodol i ddarparwyr Rhyngrwyd sydd angen gosod Asiant. Yn y parth RIPE NCC mae nifer debyg o ASes wedi'u cofrestru yn Rwsia - 6230, ac nid yw pob un ohonynt yn ddarparwyr. a derbyniodd 3940 o gwmnïau yn 2017, ac mae hyn yn hytrach yn amcangyfrif oddi uchod. Beth bynnag, mae gennym ni ddwywaith a hanner yn llai o ASau wedi'u goleuo. Ond yma mae'n werth deall nad yw UG yn hollol gyfartal â'r darparwr. Nid oes gan rai darparwyr eu UG eu hunain, mae gan rai fwy nag un. Os tybiwn fod gan bawb Asiantau o hyd, yna mae rhywun yn hidlo'n gryfach nag eraill, fel bod eu ceisiadau yn anwahanadwy oddi wrth sothach, os byddant yn eu cyrraedd o gwbl. Ond ar gyfer asesiad bras mae'n eithaf goddefadwy, hyd yn oed os collwyd rhywbeth oherwydd fy amryfusedd.
Ynglŷn â DPI
Er gwaethaf y ffaith bod fy narparwr cynnal wedi troi ei hidlydd ymlaen gan ddechrau o'r ail ddiwrnod, yn seiliedig ar y wybodaeth o'r diwrnod cyntaf, gallwn ddod i'r casgliad bod y blocio yn gweithio'n llwyddiannus. Dim ond 4 ffynhonnell oedd yn gallu mynd drwodd ac wedi cwblhau sesiynau HTTP a TCP yn llwyr (fel yn yr enghraifft uchod). Gellir anfon 460 arall GET, ond terfynir y sesiwn ar unwaith gan RST. talu sylw i 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"
Gall amrywiadau o hyn fod yn wahanol: llai RST neu fwy o ail-drosglwyddiadau - hefyd yn dibynnu ar yr hyn y mae'r hidlydd yn ei anfon at y nod ffynhonnell. Beth bynnag, dyma'r templed mwyaf dibynadwy, ac mae'n amlwg mai adnodd gwaharddedig y gofynnwyd amdano. Hefyd mae yna bob amser ateb sy'n ymddangos yn y sesiwn gyda TTL yn fwy nag mewn pecynnau blaenorol a dilynol.
Ni allwch hyd yn oed ei weld gan y gweddill 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"
Neu felly:
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"
...
Mae'r gwahaniaeth yn bendant yn weladwy TTL os daw rhywbeth o'r hidlydd. Ond yn aml efallai na fydd dim yn cyrraedd o gwbl:
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"
...
Neu felly:
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"
...
Ac mae hyn i gyd yn cael ei ailadrodd a'i ailadrodd a'i ailadrodd, fel y gwelir ar y graff, fwy nag unwaith, bob dydd.
Ynglŷn â IPv6
Y newyddion da yw ei fod yn bodoli. Gallaf ddweud yn ddibynadwy bod ceisiadau cyfnodol i adnodd gwaharddedig yn digwydd o 5 cyfeiriad IPv6 gwahanol, sef union ymddygiad yr Asiantau yr oeddwn yn ei ddisgwyl. Ar ben hynny, nid yw un o'r cyfeiriadau IPv6 yn dod o dan hidlo a gwelaf sesiwn lawn. O ddau arall gwelais un sesiwn anorffenedig yn unig, ac amharwyd ar un ohonynt RST o'r hidlydd, yn ail mewn amser. Cyfanswm 7.
Gan nad oes llawer o gyfeiriadau, astudiais bob un ohonynt yn fanwl a daeth i'r amlwg mai dim ond 3 darparwr sydd yno, gellir rhoi cymeradwyaeth iddynt! Cyfeiriad arall yw hosting cloud yn Rwsia (nid yw'n hidlo), mae un arall yn ganolfan ymchwil yn yr Almaen (mae hidlydd, ble?). Ond pam maen nhw'n gwirio argaeledd adnoddau gwaharddedig ar amserlen yn gwestiwn da. Gwnaeth y ddau arall un cais ac maent wedi'u lleoli y tu allan i Rwsia, ac mae un ohonynt wedi'i hidlo (wrth ei gludo, wedi'r cyfan?).
Mae Blocio ac Asiantau yn rhwystr mawr i IPv6, nad yw ei weithrediad yn symud yn gyflym iawn. Mae'n drist. Gall y rhai a ddatrysodd y broblem hon fod yn gwbl falch ohonynt eu hunain.
I gloi
Wnes i ddim ymdrechu am gywirdeb 100%, maddeuwch i mi am hyn, gobeithio bod rhywun eisiau ailadrodd y gwaith hwn yn fwy cywir. Roedd yn bwysig imi ddeall a fyddai’r dull hwn yn gweithio mewn egwyddor. Yr ateb yw ydy. Mae'r ffigurau a gafwyd, fel brasamcan cyntaf, rwy'n meddwl, yn eithaf dibynadwy.
Beth arall y gellid bod wedi'i wneud a'r hyn yr oeddwn yn rhy ddiog i'w wneud oedd cyfrif ceisiadau DNS. Nid ydynt yn cael eu hidlo, ond nid ydynt ychwaith yn darparu llawer o gywirdeb gan eu bod yn gweithio i'r parth yn unig, ac nid ar gyfer yr URL cyfan. Dylai'r amlder fod yn weladwy. Os ydych chi'n ei gyfuno â'r hyn sydd i'w weld yn uniongyrchol yn yr ymholiadau, bydd hyn yn caniatáu ichi wahanu'r diangen a chael mwy o wybodaeth. Mae hyd yn oed yn bosibl pennu datblygwyr y DNS a ddefnyddir gan ddarparwyr a llawer mwy.
Nid oeddwn yn disgwyl y byddai'r gwesteiwr hefyd yn cynnwys ei hidlydd ei hun ar gyfer fy VPS. Efallai bod hyn yn arfer cyffredin. Yn y diwedd, mae RKN yn anfon cais i ddileu'r adnodd i'r gwesteiwr. Ond nid oedd hyn yn syndod i mi ac mewn rhai ffyrdd hyd yn oed yn gweithio er fy mantais. Gweithiodd yr hidlydd yn effeithiol iawn, gan dorri i ffwrdd yr holl geisiadau HTTP cywir i URL gwaharddedig, ond nid oedd y rhai cywir a oedd wedi pasio trwy hidlydd y darparwyr yn flaenorol yn eu cyrraedd, er mai dim ond ar ffurf terfyniadau: FIN-ACK и RST - minws ar gyfer minws ac mae bron yn troi allan i fod yn fantais. Gyda llaw, ni chafodd IPv6 ei hidlo gan y gwesteiwr. Wrth gwrs, roedd hyn yn effeithio ar ansawdd y deunydd a gasglwyd, ond roedd yn dal yn bosibl gweld yr amlder. Mae'n troi allan bod hwn yn bwynt pwysig wrth ddewis safle ar gyfer gosod adnoddau; peidiwch ag anghofio i gymryd diddordeb yn y mater o drefnu gwaith gyda'r rhestr o safleoedd gwaharddedig a cheisiadau gan y RKN.
Ar y dechrau, cymharais yr "Arolygydd" UG â . Mae'r gymhariaeth hon yn eithaf cyfiawn a gall rhwydwaith mawr o Asiantau fod yn fuddiol. Er enghraifft, pennu ansawdd yr adnoddau sydd ar gael gan ddarparwyr gwahanol mewn gwahanol rannau o'r wlad. Gallwch gyfrifo oedi, gallwch adeiladu graffiau, gallwch ddadansoddi'r cyfan a gweld y newidiadau yn digwydd yn lleol ac yn fyd-eang. Nid dyma’r ffordd fwyaf uniongyrchol, ond mae seryddwyr yn defnyddio “canhwyllau safonol”, beth am ddefnyddio Asiantau? Gan wybod (ar ôl darganfod) eu hymddygiad safonol, gallwch chi benderfynu ar y newidiadau sy'n digwydd o'u cwmpas a sut mae hyn yn effeithio ar ansawdd y gwasanaethau a ddarperir. Ac ar yr un pryd, nid oes angen i chi osod stilwyr yn annibynnol ar y rhwydwaith; mae Roskomnadzor eisoes wedi eu gosod.
Pwynt arall yr wyf am ei gyffwrdd yw y gall pob teclyn fod yn arf. Mae AS "Arolygydd" yn rhwydwaith caeedig, ond mae'r Asiantau yn trosglwyddo pawb trwy anfon ceisiadau am yr holl adnoddau o'r rhestr waharddedig. Nid yw cael adnodd o'r fath yn peri unrhyw broblemau o gwbl. Yn gyfan gwbl, mae darparwyr trwy Asiantau, yn ddiarwybod, yn dweud llawer mwy am eu rhwydwaith nag sy'n werth chweil yn ôl pob tebyg: mathau DPI a DNS, lleoliad yr Asiant (nôd canolog a rhwydwaith gwasanaeth?), marcwyr rhwydwaith o oedi a cholledion - ac mae hyn yn dim ond y mwyaf amlwg. Yn union fel y gall rhywun fonitro gweithredoedd Asiantau i wella argaeledd eu hadnoddau, gall rhywun wneud hyn at ddibenion eraill ac nid oes unrhyw rwystrau i hyn. Y canlyniad yw offeryn dwbl-ymyl ac amlochrog iawn, gall unrhyw un weld hwn.
Ffynhonnell: hab.com