Ymateb manwl i'r sylw, yn ogystal ag ychydig am fywyd darparwyr yn Ffederasiwn Rwsia

Wedi fy annog i'r post hwn dyma'r sylw.

Rwy'n ei ddyfynnu yma:

kaleman heddiw am 18:53

Roeddwn yn falch gyda'r darparwr heddiw. Ynghyd â diweddariad y system blocio safle, gwaharddwyd ei mailer mail.ru Rwyf wedi bod yn galw cymorth technegol ers y bore, ond ni allant wneud unrhyw beth. Mae'r darparwr yn fach, ac mae'n ymddangos bod darparwyr o safle uwch yn ei rwystro. Sylwais hefyd ar arafu yn agoriad pob safle, efallai eu bod wedi gosod rhyw fath o DLP cam? Yn flaenorol nid oedd unrhyw broblemau gyda mynediad. Mae dinistr RuNet yn digwydd reit o flaen fy llygaid ...

Y gwir yw ei bod yn ymddangos mai ni yw'r un darparwr :)

Ac yn wir, kaleman Bu bron i mi ddyfalu achos y problemau gyda mail.ru (er inni wrthod credu yn y fath beth am amser hir).

Bydd yr hyn a ganlyn yn cael ei rannu'n ddwy ran:

  1. y rhesymau dros ein problemau presennol gyda mail.ru a'r ymdrech gyffrous i ddod o hyd iddynt
  2. bodolaeth ISP yn realiti heddiw, sefydlogrwydd y RuNet sofran.

Problemau hygyrchedd gyda mail.ru

O, mae'n stori eithaf hir.

Y ffaith yw, er mwyn gweithredu gofynion y wladwriaeth (mwy o fanylion yn yr ail ran), fe wnaethom brynu, ffurfweddu a gosod rhywfaint o offer - ar gyfer hidlo adnoddau gwaharddedig ac ar gyfer gweithredu cyfieithiadau NAT tanysgrifwyr.

Beth amser yn ôl, fe wnaethom ailadeiladu craidd y rhwydwaith o'r diwedd yn y fath fodd fel bod yr holl draffig tanysgrifwyr yn mynd trwy'r offer hwn i'r cyfeiriad cywir.

Ychydig ddyddiau yn ôl fe wnaethom droi ar hidlo gwaharddedig arno (wrth adael yr hen system yn gweithio) - roedd popeth i'w weld yn mynd yn dda.

Nesaf, dechreuon nhw alluogi NAT yn raddol ar yr offer hwn ar gyfer gwahanol rannau o danysgrifwyr. O'i olwg, roedd popeth hefyd i'w weld yn mynd yn dda.

Ond heddiw, ar ôl galluogi NAT ar yr offer ar gyfer y rhan nesaf o danysgrifwyr, o'r bore cyntaf roeddem yn wynebu nifer dda o gwynion am ddiffyg argaeledd neu argaeledd rhannol. mail.ru ac adnoddau eraill Mail Ru Group.

Dechreuon nhw wirio: rhywbeth yn rhywle weithiau, yn achlysurol yn anfon TCP RST mewn ymateb i geisiadau i rwydweithiau mail.ru yn unig. Ar ben hynny, mae'n anfon TCP RST a gynhyrchir yn anghywir (heb ACK), yn amlwg yn artiffisial. Dyma sut olwg oedd arno:

Ymateb manwl i'r sylw, yn ogystal ag ychydig am fywyd darparwyr yn Ffederasiwn Rwsia

Ymateb manwl i'r sylw, yn ogystal ag ychydig am fywyd darparwyr yn Ffederasiwn Rwsia

Ymateb manwl i'r sylw, yn ogystal ag ychydig am fywyd darparwyr yn Ffederasiwn Rwsia

Yn naturiol, roedd y meddyliau cyntaf yn ymwneud â'r offer newydd: DPI ofnadwy, dim ymddiriedaeth ynddo, nid ydych byth yn gwybod beth y gall ei wneud - wedi'r cyfan, mae TCP RST yn beth eithaf cyffredin ymhlith offer blocio.

Rhagdybiaeth kaleman Fe wnaethon ni hefyd gyflwyno'r syniad bod rhywun “uwchradd” yn hidlo, ond fe wnaethon ni ei daflu ar unwaith.

Yn gyntaf, mae gennym ni uplinks digon call fel nad oes rhaid i ni ddioddef fel hyn :)

Yn ail, rydym yn gysylltiedig â sawl un IX ym Moscow, ac mae traffig i mail.ru yn mynd drwyddynt - ac nid oes ganddynt gyfrifoldebau nac unrhyw gymhelliad arall i hidlo traffig.

Treuliwyd hanner nesaf y diwrnod ar yr hyn a elwir fel arfer yn siamaniaeth - ynghyd â'r gwerthwr offer, yr ydym yn diolch iddynt am hynny, ni wnaethant roi'r gorau iddi :)

  • hidlo wedi'i analluogi'n llwyr
  • Cafodd NAT ei analluogi gan ddefnyddio'r cynllun newydd
  • gosodwyd y cyfrifiadur prawf mewn pwll ynysig ar wahân
  • Cyfeiriad IP wedi'i newid

Yn y prynhawn, dyrannwyd peiriant rhithwir a oedd yn cysylltu â'r rhwydwaith yn unol â chynllun defnyddiwr rheolaidd, a rhoddwyd mynediad iddo a'r offer i gynrychiolwyr y gwerthwr. Parhaodd y siamaniaeth :)

Yn y diwedd, dywedodd cynrychiolydd y gwerthwr yn hyderus nad oedd gan y caledwedd unrhyw beth i'w wneud ag ef: mae'r rhai cyntaf yn dod o rywle uwch.

NodynAr y pwynt hwn, efallai y bydd rhywun yn dweud: ond roedd yn llawer haws cymryd dymp nid o'r PC prawf, ond o'r briffordd uwchben y DPI?

Na, yn anffodus, nid yw cymryd dymp (a hyd yn oed dim ond adlewyrchu) 40+gbps yn ddibwys o gwbl.

Wedi hyn, yn yr hwyr, nid oedd dim ar ol i'w wneyd ond dychwelyd at y dybiaeth o hidlo rhyfedd yn rhywle uchod.

Edrychais trwy ba IX mae'r traffig i'r rhwydweithiau MRG bellach yn pasio drwodd a dim ond canslo'r sesiynau bgp iddo. Ac - wele ac wele! - daeth popeth yn ôl i normal ar unwaith 🙁

Ar y naill law, mae'n drueni bod y diwrnod cyfan wedi'i dreulio'n chwilio am y broblem, er iddi gael ei datrys mewn pum munud.

Ar y llaw arall:

— yn fy nghof mae hyn yn beth digynsail. Fel yr ysgrifenais eisoes uchod — IX a dweud y gwir nid oes diben hidlo traffig cludo. Fel arfer mae ganddyn nhw gannoedd o gigabits/terabits yr eiliad. Allwn i ddim dychmygu rhywbeth fel hyn o ddifrif tan yn ddiweddar.

— cyd-ddigwyddiad hynod ffodus o amgylchiadau: caledwedd cymhleth newydd nad oes llawer o ymddiriedaeth ynddo ac nad yw'n glir beth y gellir ei ddisgwyl ohono - wedi'i deilwra'n benodol ar gyfer blocio adnoddau, gan gynnwys TCP RSTs

Mae NOC y gyfnewidfa rhyngrwyd hon yn chwilio am broblem ar hyn o bryd. Yn ôl iddynt (a chredaf iddynt), nid oes ganddynt unrhyw system hidlo a ddefnyddir yn arbennig. Ond, diolch i'r nefoedd, nid y cwest pellach yw ein problem ni bellach :)

Ymgais bach oedd hwn i gyfiawnhau fy hun, deallwch a maddeuwch :)

PS: Nid wyf yn fwriadol yn enwi gwneuthurwr DPI / NAT neu IX (mewn gwirionedd, nid oes gennyf hyd yn oed unrhyw gwynion arbennig amdanynt, y prif beth yw deall beth ydoedd)

Realiti heddiw (yn ogystal â ddoe a'r diwrnod cyn ddoe) o safbwynt darparwr Rhyngrwyd

Rwyf wedi treulio'r wythnosau diwethaf yn ailadeiladu craidd y rhwydwaith yn sylweddol, gan berfformio criw o driniaethau “er elw”, gyda'r risg o effeithio'n sylweddol ar draffig defnyddwyr byw. O ystyried nodau, canlyniadau a chanlyniadau hyn i gyd, yn foesol mae'r cyfan yn eithaf anodd. Yn enwedig - unwaith eto gwrando ar areithiau hardd am amddiffyn sefydlogrwydd y Runet, sofraniaeth, ac ati. ac yn y blaen.

Yn yr adran hon, byddaf yn ceisio disgrifio “esblygiad” craidd rhwydwaith ISP nodweddiadol dros y deng mlynedd diwethaf.

Ddeng mlynedd yn ôl.

Yn yr amseroedd bendigedig hynny, gallai craidd rhwydwaith darparwyr fod mor syml a dibynadwy â thagfa draffig:

Ymateb manwl i'r sylw, yn ogystal ag ychydig am fywyd darparwyr yn Ffederasiwn Rwsia

Yn y llun syml iawn hwn, nid oes unrhyw foncyffion, modrwyau, llwybro ip/mpls.

Ei hanfod yw bod traffig defnyddwyr yn y pen draw wedi dod i'r newid lefel cnewyllyn - o ble yr aeth BNG, o ble, fel rheol, yn ôl i'r newid craidd, ac yna "allan" - trwy un neu fwy o byrth ffin i'r Rhyngrwyd.

Mae cynllun o'r fath yn hawdd iawn, iawn i'w gadw ar L3 (llwybro deinamig) ac ar L2 (MPLS).

Gallwch osod N+1 o unrhyw beth: cyrchu gweinyddwyr, switshis, borderi - ac un ffordd neu'r llall eu cadw ar gyfer methiant awtomatig.

Ar ôl ychydig flynyddoedd Daeth yn amlwg i bawb yn Rwsia ei bod yn amhosibl byw fel hyn mwyach: roedd yn fater brys i amddiffyn plant rhag dylanwad niweidiol y Rhyngrwyd.

Roedd angen dod o hyd i ffyrdd o hidlo traffig defnyddwyr ar fyrder.

Mae yna wahanol ddulliau gweithredu yma.

Mewn achos nad yw'n dda iawn, mae rhywbeth yn cael ei roi “yn y bwlch”: rhwng traffig defnyddwyr a'r Rhyngrwyd. Mae'r traffig sy'n mynd trwy'r "rhywbeth" hwn yn cael ei ddadansoddi ac, er enghraifft, mae pecyn ffug gydag ailgyfeiriad yn cael ei anfon at y tanysgrifiwr.

Mewn achos ychydig yn well - os yw niferoedd traffig yn caniatáu - gallwch chi wneud tric bach gyda'ch clustiau: anfonwch am hidlo traffig sy'n tarddu gan ddefnyddwyr yn unig, dim ond i'r cyfeiriadau hynny y mae angen eu hidlo (i wneud hyn, gallwch naill ai gymryd yr IP cyfeiriadau a nodir yno o'r gofrestrfa, neu ddatrys parthau rhai presennol yn y gofrestrfa hefyd).

Ar un adeg, at y dibenion hyn, ysgrifennais syml dpi bach - er na feiddiaf ei alw'n hynny hyd yn oed. Mae'n syml iawn ac nid yw'n gynhyrchiol iawn - fodd bynnag, roedd yn caniatáu i ni a dwsinau (os nad cannoedd) o ddarparwyr eraill beidio â thalu miliynau ar systemau DPI diwydiannol ar unwaith, ond rhoddodd sawl blwyddyn ychwanegol o amser.

Gyda llaw, am y DPI bryd hynny a'r presennolGyda llaw, roedd llawer a brynodd y systemau DPI a oedd ar gael ar y farchnad bryd hynny eisoes wedi eu taflu. Wel, nid ydynt wedi'u cynllunio ar gyfer hyn: cannoedd o filoedd o gyfeiriadau, degau o filoedd o URLs.

Ac ar yr un pryd, mae cynhyrchwyr domestig wedi codi'n gryf iawn i'r farchnad hon. Dydw i ddim yn sôn am y gydran caledwedd - mae popeth yn glir i bawb yma, ond meddalwedd - y prif beth sydd gan DPI - efallai heddiw, os nad y mwyaf datblygedig yn y byd, yna yn sicr a) datblygu llamu a therfynau, ac b) am bris cynnyrch mewn bocs - dim ond yn anghymharol â chystadleuwyr tramor.

Hoffwn i fod yn falch, ond ychydig yn drist =)

Nawr roedd popeth yn edrych fel hyn:

Ymateb manwl i'r sylw, yn ogystal ag ychydig am fywyd darparwyr yn Ffederasiwn Rwsia

Mewn cwpl o flynyddoedd eto roedd gan bawb archwilwyr eisoes; Roedd mwy a mwy o adnoddau yn y gofrestrfa. Ar gyfer rhai offer hŷn (er enghraifft, Cisco 7600), daeth y cynllun “hidlo ochr” yn amherthnasol: mae nifer y llwybrau ar 76 platfform wedi'i gyfyngu i rywbeth fel naw can mil, tra bod nifer y llwybrau IPv4 yn unig heddiw yn agosáu at 800 mil. Ac os yw hefyd yn ipv6... A hefyd... faint sydd yna? 900000 o gyfeiriadau unigol yn y gwaharddiad RKN? =)

Newidiodd rhywun i gynllun sy'n adlewyrchu'r holl draffig asgwrn cefn i weinydd hidlo, a ddylai ddadansoddi'r llif cyfan ac, os canfyddir rhywbeth drwg, anfon RST i'r ddau gyfeiriad (anfonwr a derbynnydd).

Fodd bynnag, po fwyaf o draffig, y lleiaf perthnasol yw'r cynllun hwn. Os bydd yr oedi lleiaf wrth brosesu, bydd y traffig a adlewyrchir yn hedfan heibio heb i neb sylwi, a bydd y darparwr yn derbyn adroddiad dirwy.

Mae mwy a mwy o ddarparwyr yn cael eu gorfodi i osod systemau DPI o wahanol raddau o ddibynadwyedd ar draws priffyrdd.

Flwyddyn neu ddwy yn ôl yn ôl sibrydion, dechreuodd bron pob un o'r Ffederasiwn Busnesau Bach fynnu gosod offer mewn gwirionedd SORM (yn flaenorol, roedd y rhan fwyaf o ddarparwyr yn rheoli gyda chymeradwyaeth yr awdurdodau cynllun SORM - cynllun o fesurau gweithredol rhag ofn y bydd angen dod o hyd i rywbeth yn rhywle)

Yn ogystal ag arian (nid yn union afresymol, ond yn dal i filiynau), roedd SORM angen llawer mwy o driniaethau gyda'r rhwydwaith.

  • Mae angen i SORM weld cyfeiriadau defnyddwyr “llwyd” cyn cyfieithu nat
  • Mae gan SORM nifer gyfyngedig o ryngwynebau rhwydwaith

Felly, yn arbennig, bu'n rhaid i ni ailadeiladu darn o'r cnewyllyn yn fawr - yn syml er mwyn casglu traffig defnyddwyr i'r gweinyddwyr mynediad rhywle mewn un lle. Er mwyn ei adlewyrchu yn SORM gyda sawl dolen.

Hynny yw, wedi'i symleiddio'n fawr, roedd (chwith) yn erbyn dod yn (dde):

Ymateb manwl i'r sylw, yn ogystal ag ychydig am fywyd darparwyr yn Ffederasiwn Rwsia

Nawr Mae'r rhan fwyaf o ddarparwyr hefyd yn gofyn am weithredu SORM-3 - sy'n cynnwys, ymhlith pethau eraill, logio darllediadau nat.

At y dibenion hyn, roedd yn rhaid i ni hefyd ychwanegu offer ar wahân ar gyfer NAT at y diagram uchod (yn union yr hyn a drafodir yn y rhan gyntaf). Ar ben hynny, ychwanegwch mewn trefn benodol: gan fod yn rhaid i SORM “weld” y traffig cyn cyfieithu cyfeiriadau, rhaid i'r traffig fynd yn llym fel a ganlyn: defnyddwyr -> newid, cnewyllyn -> gweinyddwyr mynediad -> SORM -> NAT -> newid, cnewyllyn - > Rhyngrwyd. I wneud hyn, roedd yn rhaid i ni yn llythrennol “droi” llif traffig i'r cyfeiriad arall er mwyn gwneud elw, a oedd hefyd yn eithaf anodd.

I grynhoi: dros y deng mlynedd diwethaf, mae dyluniad craidd darparwr cyfartalog wedi dod yn llawer mwy cymhleth, ac mae pwyntiau methiant ychwanegol (ar ffurf offer ac ar ffurf llinellau switsh sengl) wedi cynyddu'n sylweddol. A dweud y gwir, mae’r union ofyniad i “weld popeth” yn awgrymu lleihau’r “popeth” hwn i un pwynt.

Rwy'n meddwl y gellir allosod hyn yn eithaf tryloyw i fentrau cyfredol i sofraneiddio'r Runet, ei amddiffyn, ei sefydlogi a'i wella :)

Ac mae Yarovaya ar y blaen o hyd.

Ffynhonnell: hab.com

Ychwanegu sylw