Kohandatud vastus kommentaarile ning natuke venelaste elust.

See innustas mind seda postitust kirjutama. just see kommentaar..

Tõin selle siia:

kaleman täna kell 18:53.

Täna üllatas mind teenusepakkuja. Koos süsteemi blokeerimise uuendamisega sattus nende alla mail.ru. Hommikul helistasin klienditoe poole, nad ei suutnud midagi teha. Teenusepakkuja on väike ja ilmselt blokeerivad nad kõrgemad teenusepakkujad. Märkasin ka, et kõikide veebisaitide avamine on aeglustunud, kas on mingit vale DLP-d lisatud? Varem ei olnud ju mingeid ligipääsuprobleeme. RuNeti hävitamine toimub just minu silme all...

Asi on selles, et me oleme ilmselt see teenusepakkuja 🙁

Ja tõepoolest, kaleman peaaegu arvasin mail.ru probleemide põhjust (kuigi me keeldusime pikka aega sellesse uskuma).

Eesootav jaguneb kaheks osaks:

1. meie tänaste probleemide põhjused mail.ru juures ja põnev missioon nende leidmiseks.
2. ISP-de olemasolu tänastes reaalsustes, suveräänse RuNeti stabiilsus.

Probleemid mail.ru ligipääsetavusega

Oh, see on üsna pikk lugu.

Küsimus on selles, et riigi nõuete täitmiseks (täiendavalt teises osas) soetasime, seadistasime ja paigaldasime teatud seadmeid — nii keelatud ressursside filtreerimiseks kui ka NAT-ülekannete tegemiseks. NAT-ülekanded tellijatele.

Mõni aeg tagasi ümber ehitatud meie võrguydin nii, et tellijate kogu liiklus kulges läbi selle seadme rangelt soovitud suunal.

Mõni päev tagasi lülitasime sellele seadmele keelatud ressursside filtreerimise (samaaegselt vanas süsteemis) — esialgu tundus kõik minevat hästi.

Edasi hakati järk-järgult lülitama erinevates osades tellijatele NAT-i sellele seadmele. Esialgu näis samuti kõik sujuvat.

Aga täna, lülitades seadmele NAT-i järgmisele osale tellijatest — hommikust alates saime teateid rohkete ligipääsmis- või osalise ligipääsmise kaebustega. mail.ru ja teiste Mail Ru Groupi ressursside kohta.

Hakkasime kontrollima: midagi kuskil mõnikord, harva saadab TCP RST vastuseks mail.ru võrkudele esitatud päringutele. Veelgi enam — saadetakse vale hallatud (ilma ACK-ta), selgelt kunstlik TCP RST. Näiteks nägi see välja umbes nii:

Muidugi, esimesed mõtted olid uue varustuse üle: hirmutav DPI, usaldust temasse ei olnud, kes teab, mida ta võib veel teha — sest TCP RST on blokeerimistarkvaras üsna levinud asi.

Eeldamine kaleman selle üle, et keegi ülemine filtri, tõstatus samuti — kuid see lükati kohe kõrvale.

Esiteks, meie ülesse loomingud on piisavalt normaalsed, et sellise asja all ei kannataks 🙂

Teiseks, me oleme ühendatud mitme IX Moskvasse ning liiklus mail.ru-ni läheb tõepoolest nende kaudu — ja neil pole mingit kohustust ega mingit muud motiivi, et liiklust filtreerida.

Järgmine päevapoolne osa kulus sellele, mida tavaliselt nimetatakse šamaanitööks — koos seadme tarnijaga, kelle eest oleme tänulikud, ei jätnud nad meid maha 🙂

• filtreerimine lülitati täielikult välja
• NAT lülitati välja uue skeemi järgi
• testarvuti viidi eraldi isoleeritud õhku
• IP-aadress muutus

Teise päeva poole eraldati virtuaalmasin, mis pääseb internetti tavakasutaja skeemi järgi, ning sellele ja seadmele anti juurdepääs tarnija esindajatele. Šamaanitöö jätkus 🙂

Lõppude lõpuks kinnitas edasimüüja, et riistvara ei ole selles süüdi: rst'id tulevad kusagilt kõrgemalt.

MärkusSiin võib keegi öelda: aga oleks ju palju lihtsam teha dump mitte testarvutist, vaid kõrgemalt DPI-lt?

Kahjuks pole 40+ gbps dump'i (ja isegi lihtsalt mirror'ima) tegemine sugugi triviaalne.

Pärast seda, juba õhtul, ei jäänud midagi muud üle, kui naasta ebatavalise filtreerimise oletuse juurde kusagil kõrgemal.

Vaatasin, milline IX praegu sõidab MRG võrkudesse ja lihtsalt sulgesin BGP-seansid. Ja — imet! — kõik normaliseerus koheselt 🙁

Ühelt poolt on väga kahju, et probleemi leidmiseks kulus terve päev, kuigi see lahendati viie minutiga.

Teiselt poolt:

— minu mäletamist mööda on see pretsedenditut asjaolu. Nagu ma juba varem mainisin — IX-ide tõesti ei ole mingit mõtet filtreerida transiitliiklust. Neil on seda tavaliselt sadu gigabite / terabite sekundis. Ma lihtsalt viimase hetkeni ei osanud midagi sellist tõsiselt kaaluda.

— uskumatult soodne kokkujooks: uus keeruline riistvara, millele ei ole suurt usaldust ja mille kohta ei ole selge, mida oodata — just sobiv ressursside blokeerimiseks, sealhulgas TCP RST-dega

Praegu otsib selle interneti vahetuse NOC probleemi. Nende sõnul (ja ma usun neile) ei ole neil mingit spetsiaalselt rakendatud filtreerimissüsteemi. Aga tänu taevasse, edasine missioon — ei ole enam meie probleem 🙂

See oli väike katse õigustada end, palume mõista ja andestada 🙂

P.S.: ma ei nimeta tahtlikult ei DPI/NAT tootjat ega IX-d (mul ei ole tegelikult ka nende vastu erilisi kaebusi, peamine — mõista, mis toimus)

Tänane (nagu ka eilne ja üle-eilne) reaalsus interneti pakkuja vaatepunktist

Viimased nädalad olen veetnud, põhjalikult ümber struktuureides võrgu tuuma, tehes hulga manipuleerimisi 'live' keskkonnas, riskides oluliselt puudutada aktiivset kasutajatrafikut. Arvestades eesmärke, tulemusi ja kõiki neid tagajärgi — on see vaimselt päris keeruline. Eriti jälle, kuulates suurepäraseid kõnesid rünnaku stabiilsuse kaitsmisest, suveräänsusest jne.

Selles jaotises püüan ma rääkida tüüpilise Interneti-teenuse pakkuja võrgu tuuma "evolutsioonist" viimase kümne aasta jooksul.

Kümme aastat tagasi.

Neil õnnelikel aegadel võis teenuse pakkuja võrgu tuum olla sama lihtne ja usaldusväärne kui kork:

Sellel väga, väga lihtsustatud joonisel puuduvad maanteed, ringid, IP/MPLS marsruutimine.

Selle olemus oli selles, et kasutajate liiklus jõudis lõpuks tuuma lülitamiseni — kust see suundus BNG, kust see tavaliselt — tagasi tuuma lülitamiseks ja edasi "väljaminekuks" — läbi ühe või mitme piiri värava Internetti.

Sarnast skeemi on väga, väga lihtne reserveerida nii L3 (dünaamiline marsruutimine) kui ka L2 (MPLS) tasemel.

Saate paigaldada N+1 mida iganes: juurdepääsu servereid, lüliteid, piiri — ja neid reserveerida automaatseks veaparandamiseks.

Mõne aasta pärast oli kõigile Venemaal selge, et nii ei saa enam elada: on vaja kiiresti kaitsta lapsi interneti saasta mõju eest.

Tekkis vajadus kiiresti leida viise kasutajate liikluse filtreerimiseks.

Siin on erinevaid lähenemisviise.

Halvemal — midagi paigutatakse 'risti': kasutajaliikluse ja interneti vahele. Selle 'midagi' kaudu kulgev liiklus analüüsitakse ja näiteks suunatakse abonendile vale pakett koos redirectiga.

Natuke paremal juhul — kui liiklusmaht võimaldab — saab teha väikese triki: suunata filtreerimisele ainult kasutajatelt väljuv liiklus ainult neile aadressidele, mida on vaja filtreerida (selleks saab kasutada kas registris näidatud IP-aadresse või täiendavalt resolverida registris olevaid domeene).

Oma ajal kirjutasin nende eesmärkide saavutamiseks lihtsa mini-dpi — kuigi isegi keel ei pöördu selle nii nimetamise üle. See on väga lihtne ja mitte eriti jõudlane — kuid see võimaldas meil ja kümnetel (kui mitte sadadele) teistel teenusepakkujatel mitte välja panna kohe miljoneid tööstuslike DPI-süsteemide peale, vaid andis mõned lisanduvad aastad aega.

Muide, tollaste ja praeguste DPI kohtaTuleb märkida, et paljude jaoks, kes ostsid toona turul olemasolevad DPI-süsteemid, on need juba ammu kõrvale heidetud. Need ei ole sarnaste ülesannete täitmiseks sobivad: sadu tuhandeid aadresse, kümneid tuhandeid URL-e.

Samas on kodumaised tootjad selle turu kaalutlustega oluliselt tõusnud. Ma ei räägi riistvarast — see on kõigile selge, kuid tarkvara — see, mis on DPI-s kõige tähtsam — võib-olla tänaseks ei ole see maailmas kõige arenenum, kuid a) areneb märgatavalt kiires tempos ja b) on pakendihinna poolest — lihtsalt võrreldamatu välismaiste konkurentidega.

Tahaksin uhkust tunda, kuid see teeb natuke kurvaks =)

Nüüd nägi kõik välja nii:

Veel paar aastat hiljem olid kõikidel juba revideerijad; ressursid registris kasvasid järjest enam. Teatud vana varustuse jaoks (näiteks cisco 7600) muutus 'külgfiltide' skeem lihtsalt rakendamatuks: marsruutide arv 76-l platvormil on piiratud umbes üheksa saja tuhande lähedale, samas kui IPv4 marsruutide arv on täna juba lähenemas 800 tuhandele. Ja kui lisada ipv6... Ja veel... kui palju seal on? 900000 eraldi aadressi rkn-is blokeeritud? =)

Keegi on liikunud kogu peamise liikluse peegeldamise skeemi suunas filtriserverisse, mis peab analüüsima kogu voogu ja kui midagi kahtlast avastatakse, saatma mõlemale poole (saatajale ja vastuvõtjale) RST.

Kuid mida rohkem on liiklust, seda vähem on selline skeem rakendatav. Iga väikese viivituse korral töötlemisel – peegeldatud liiklus lihtsalt möödub märkamatult, ja teenusepakkuja saab trahvi protokolli.

Üha rohkem teenusepakkujaid on sunnitud paigaldama DPI-süsteeme erineva usaldusväärsuse tasemega maanteede lõikudele.

Aasta või kaks tagasi kuuldavasti on praktiliselt kõikelt FSB hakanud nõudma seadmete tõelist paigaldamist SORM (varem said enamus teenusepakkujatest hakkama kooskõlastamisega ametiasutustega SORM-kava – operatiivtegevuste kava, et vajadusel midagi kuskil leida)

Peale raha (mitte nii, et ülevalt iga hind on suurt, kuid ikkagi – miljoneid), nõudis SORM paljusid edasiseid manipulatsioone võrgus.

• SORM peab nägema kasutajate «hallid» aadresse enne nat-ülekanne
• SORM-il on piiratud arv võrgu liideseid

Seetõttu pidime me konkreetselt põhikoodi korralikult ümber tegema — lihtsalt selleks, et suunata kasutajate liiklus juurdepääsusüsteemide serveritesse kuskil ühes kohas. Selleks, et peegeldada seda mitme lingiga SORM-iga.

Ehk siis, väga lihtsustatult, oli (vasakul) vs on (paremal):

Praegu enamikelt teenusepakkujatelt nõutakse ka SORM-3 rakendamist — mis hõlmab muu hulgas ka NAT-ülekannete logimist.

Nende eesmärkide saavutamiseks pidime eelnevalt esitatud skeemile lisama ka eraldi varustuse NAT-i jaoks (just see, millest jutt oli esimese osa ajal). Lisaks pidime seda lisama kindlas järjekorras: kuna SORM peab liiklust „nägema“ enne aadresside edastamist — liiklus peab minema rangelt järgmiselt: kasutajad -> ühendsüsteem, põhikood -> juurdepääsusüsteemide serverid -> SORM -> NAT -> ühendsüsteem, põhikood -> internet. Selle saavutamiseks pidime liiklusvooge sõna otseses mõttes „tagurpidi“ pöörama, mis oli samuti üsna keeruline.

Kokkuvõtteks, aastatega on keskmise teenusepakkuja tuumastruktuur oluliselt keerulisemaks muutunud, lisades mitmeid rikkepunkte (nii riistvaras kui ka ühendusliinides). Tegelikult tähendavad nõudmised 'näha kõike' selle 'kõik' kokku toomist ühte punkti.

Arvan, et seda saab täiesti selgelt projitseerida praegustele algatustele rikka interneti suveräänsuse, kaitse, stabiliseerimise ja täiustamise osas 🙂

Ees ootab veel Yarovaya.

Allikas: habr.com