Üksikasjalik vastus kommentaarile, samuti natuke elust teenusepakkujate seas Venemaal

Inspireeris mind see postitus see kommentaar.

Tõin selle siia:

kaleman täna kell 18:53

Minu teenusepakkuja rõõmustas mind täna. Koos said blokki kõikide saitide blokeerimise süsteemi värskendustega ka mail.ru postiteenuse pakkuja. Hommikust saadik helistan tehnilisse toetusse, nad ei saa midagi teha. Teenusepakkuja on väike ja ilmselt blokeerivad nad kõrgemad teenusepakkujad. Lisaks märkasin, et kõikide saitide avamine on aeglustunud, võib-olla on nad pannud mingisuguse vale DLP-süsteemi? Varem ei olnud ju ligipääsuga mingeid probleeme. Ruuneta hävitamine käib minu silme all...

Asi on selles, et näib, et meie olemegi see teenusepakkuja 🙁

Ja tõepoolest, kaleman peaaegu arvasin probleemide põhjuse mail.ru osas (kuigi me kaua ei uskunud sellesse).

Edasi läheb see kaheks osaks:

1. meie tänaste probleemide põhjused mail.ru ja põnev otsingupüüd nende leidmiseks
2. ISP olemasolu tänapäeva reaalsetes tingimustes, suveräänse ruuneta stabiilsus.

Probleemid ligipääsetavusega mail.ru

Oh, see on üsna pikk lugu.

Asi on selles, et riigi nõuete täitmiseks (täpsemalt teises osas) oleme me ostnud, seadistanud ja paigaldanud teatud seadmed — nii lubatud ressursside filtreerimiseks kui ka NAT-muundamiste abonentide jaoks.

Mõni aeg tagasi tegime lõpuks meie võrgu tuuma ümber nii, et kogu abonentide liiklus läheb nende seadmete kaudu rangelt soovitud suunas.

Mõni päev tagasi aktiveerisime seal keelatud ressursside filtreerimise (samal ajal jättes vanade süsteemide tööle) — väliselt näis kõik hästi minevat.

Edasi — hakkasime järk-järgult aktiveerima eri abonentide osade NAT-i nende seadmete peal. Väliselt — samuti tundus, et kõik, näiliselt, läks hästi.

Aga täna, aktiveerides NAT-i järgmise abonentide osa jaoks — hommikul, satume üha enam kaebustele ligipääsu puudumise või osalise ligipääsu kohta mail.ru ja teiste Mail Ru grupi ressursside kohta.

Hakkasime kontrollima: midagi kuskil mõnikord, harva saadetakse TCP RST vastuseks päringutele, mis on suunatud ainult mail.ru võrkudele. Mis veelgi enam — saadetakse vale genereeritud (tanemata ACK), selgelt kunstlik TCP RST. Umbes nii see välja nägi:

Ilmselgelt olid esimesed mõtted uue seadme kohta: kohutav DPI, usaldus sellele puudub, ega tea, mida ta teha võib — ju on TCP RST päris levinud asi blokeerimisseadmete seas.

Oletus kaleman selle kohta, et keegi "ülemine" filtrit seab, tõstsime samuti esile — kuid loobusime sellest kiiresti.

Esiteks, meil on piisavalt normaalsed ülesvoolud, et selliseid asju mitte kogeda 🙂

Teiseks, oleme ühendatud mitmete IX Moskvasse ning liiklus mail.ru-sse läheb tõepoolest nende kaudu — neil ei ole ei kohustusi ega mingisugust muud motivatsiooni liikluse filtreerimiseks.

Järgmine pool päeva kulus sellele, mida tavaliselt nimetatakse šamaanitööks — koos seadme tootjaga, kellele suure tänu eest, ei jätnud meid 🙂

• filtreerimine lülitati täielikult välja
• NAT lülitati välja uue skeemi järgi
• testimispink viidi eraldi isoleeritud gruppi
• IP-aadressimine muudeti

Teise pool päeva jooksul eraldati virtuaalmasin, mis pääses võrku nagu tavaline kasutaja, ja sellele ning seadmele anti juurdepääs tootja esindajatele. Šamaanitöö jätkus 🙂

Lõpuks teatas tootja esindaja kindlalt, et seade ei ole süüdi: rst-id tulevad kuskilt kõrgemalt.

MärkusKusagil võivad inimesed väita: aga oleks olnud palju lihtsam võtta dump mitte testimis-PC-lt, vaid DPI ülemiselt maanteelt?

Ei, kahjuks ei ole 40+ gbps dumpi (ja isegi lihtsalt mirrorida) saada sugugi triviaalne.

Pärast seda, juba õhtul — ei jäänud muud üle, kui naasta oletuse juurde kummalisest filtreerimisest kuskil kõrgemal.

Vaatasin, millise IX kaudu liigub liiklus MRGi võrku ja lihtsalt katkestasin sellele bgp-seansid. Ja — oh ime! — kõik normaliseerus kohe 🙁

Ühest küljest — väga kahju, et probleemile lahenduse leidmiseks kulus terve päev, kuigi see lahendati viie minutiga.

Teisest küljest:

— minu mäletamise järgi on see pretsedentide puudumine. Nagu ma eespool olen kirjutanud — IX-del tõeliselt ei ole mingit mõtet filtreerida transiidiliiklust. Neil on tavaliselt sadu gigabitte / terabitte sekundis. Ma lihtsalt ei suutnud viimaseni tõsiselt sellist oletust välja mõelda.

— uskumatult soodne kokkusattumus: uus keeruline riistvara, millele ei ole erilist usaldust ja millest on raske aru saada, mida oodata — just ressursside blokeerimiseks, sealhulgas TCP RST-dega, välja töötatud

Praegu otsib selle interneti vahetuse NOC probleemi. Nende väitel (ja ma usun neile) ei ole neil mingit spetsiaalselt arendatud filtratsioonisüsteemi. Kuid, tänu taevasele, on järgmine teekond — juba mitte meie probleem 🙂

See oli väike katse ennast õigustada, palun mõista ja andesta 🙂

P.S.: ma ei nimeta tahtlikult ei DPI/NAT tootjat ega IX'i (mul endal pole neist isegi erilisi pretensioone, peamine on mõista, mida see oli)

Tänane (nagu ka eilne ja üleeile) reaalsus internetiteenuse pakkuja vaatevinklist

Viimased nädalad olen veetnud, oluliselt ümber ehitades võrgu tuuma, tehes hulga manipuleerimisi „otse”, riskides oluliselt mõjutada elavat kasutajate liiklust. Arvestades selle kõigega seotud eesmärke, tulemusi ja tagajärgi — on see vaimselt üsna raske. Eriti jälle kuulates kauneid kõnesid rünete stabiilsuse, suveräänsuse kaitsmise ja nii edasi.

Selles osas püüan rääkida tüüpilise internetiteenuse pakkuja võrgu tuuma „evolutsioonist” viimase kümne aasta jooksul.

Kümme aastat tagasi.

Nendel õnnistatud aegadel võiks võrgu tuum olla nii lihtne ja usaldusväärne nagu ummistuskork:

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

Selle olemus oli see, et kasutajate liiklus jõudis lõpuks tuuma lülitamise tasemele — kust suundus edasi BNG, kust enamasti — tagasi tuuma lülitamisele ja edasi "välja" — läbi ühe või mitme piiripunkti internetti.

Sarnast skeemi on väga-väga lihtne varundada nii L3 (dünaamilise marsruutimise) kui ka L2 (MPLS) tasemel.

Saab paigaldada N+1 mida iganes: juurdepääsu servereid, lüliteid, piirajaid — ja neid varundada automaatseks fail-overiks.

Mõne aasta pärast oli kõigile Venemaal selge, et nii ei saa enam elada: lapsi tuleb kiiresti kaitsta võrgu kahjulikest mõjudest.

Tuli kiiresti leida viise kasutajate liikluse filtreerimiseks.

Siin on erinevaid lähenemisviise.

Halvimal juhul paigaldatakse midagi "risti": kasutajate liikluse ja interneti vahele. Sellega läbiv liiklus analüüsitakse ja saadetakse näiteks abonendile vale pakett ümber suunamisega.

Veidi paremas olukorras - kui liiklusmahud lubavad - on võimalik teha väike trikk: filtreerida ainult neid adresse, kuhu kasutajatelt saadud liiklus on vajalik filtreerida (selleks võib kas kasutada registris märgitud IP-aadresse või täiendavalt lahendada registris olevaid domeene).

Oma ajal kirjutasin ma selleks lihtsa mini-dpi kuigi isegi keele ei pöördu selle nimetamisse. See on väga lihtne ja mitte eriti jõudlane - kuid meile ja kümnetele (kui mitte sadadele) teistele teenusepakkujatele lubas see mitte kohe miljonitest kulutada tööstuslikele DPI-süsteemidele, vaid andis paar lisaaastat aega.

Muide, siis ja praeguste DPI-de kohtaPean ütlema, et paljudele, kes ostsid tol ajal turul olevad DPI-süsteemid - on nad juba ära visatud. Need ei ole selleks sobivad: sadade tuhandete aadressidega, kümnete tuhandete URL-idega.

Samuti on kodumaised tootjad sellele turule väga tugevalt tõusnud. Ma ei räägi riistvarast - see on kõigile selge, kuid tarkvara - peamine, mis DPI-s on - on võimalik, et tänapäeval, kui mitte kõige edasijõudnum maailmas, siis kindlasti a) areneb see tohutult kiiresti ja b) pakettide hinnaga - ei saa võrrelda välismaiste konkurentidega.

Tahaksin uhkustada, aga natuke kurb =)

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

Veel paar aastat hiljem olid kõigil juba revisjonid; registris olevate ressursside hulk kasvas üha rohkem. Teatud vana varustuse (näiteks Cisco 7600) jaoks muutus „külgfiltimise” skeem lihtsalt kasutuskõlbmatuks: marsruutide arv 76 platvormil on piiratud umbes üheksasaja tuhandega, samas kui ainult IPv4 marsruutide arv läheneb täna juba 800 tuhandele. Ja kui lisada ipv6… Ja veel… kui palju seal on? 900000 eraldi aadressi RKN-is? =)

Mõned läksid skeemile, kus peamine liiklus peegeldati filtriserverile, mis peab analüüsima kogu voogu ja leides midagi kahtlast, saatma mõlemasse suunda (lühi- ja vastuvõtjale) RST.

Kuid mida rohkem liiklust, seda vähem sobib selline skeem. Kõige väiksemagi viivituse korral töötlemisel - peegeldatud liiklus lihtsalt märkamatult külg põgeneb, ja teenusepakkujale saadetakse trahvi teavitamine.

Üha rohkem teenusepakkujaid peab paigaldama erineva usaldusväärsusega DPI-süsteeme kärude vahele.

Aasta või kaks tagasi kuulduste kohaselt nõudis peaaegu kõik FSB-lt seadmete tõelist paigaldamist SORM (varem leidis enamik teenusepakkujaid kompromissi ametiasutustega SORMi plaan — operatiivsete tegevuste plaan, et vajadusel midagi kuskil leida)

Lisaks rahale (mida ei saa öelda, et see oleks täiesti ülemõistuse, aga siiski — miljonid), nõudis SORM paljusid täiendavaid manipulatsioone võrgus.

• SORM peab nägema kasutajate 'hallide' aadresse enne NAT-i tõlkimist
• SORM-il on piiratud arv võrguliideseid

Seetõttu oli meil, sealhulgas, tõesti palju kaalu üles ehitada tuumastruktuuri — lihtsalt selleks, et koguda kuskil ühes kohas kasutajate liiklust juurdepääsiserveritesse. Et paljude linkide kaudu selle SORM-ile peegeldada.

Teisisõnu, väga lihtsustatult, oli (vasakul) vs sai (paremal):

Praegu enamikelt teenusepakkujatelt nõutakse ka SORM-3 rakendamist — mis sisaldab endas ka NAT-i tõlgete logimist.

Nende eesmärkide saavutamiseks pidime ülalkirjeldatud skeemile lisama veel eraldi seadmed NAT-i jaoks (just seda, millest räägiti esimese osa puhul). Ja selle paigutamine kindlas järjekorras: kuna SORM peab 'nägema' liiklust enne aadresside tõlkimist — liiklus peab kulgema rangelt järgmiselt: kasutajad -> kommuteerimine, tuum -> juurdepääsiserverid -> SORM -> NAT -> kommuteerimine, tuum -> internet. Selleks pidime, tõeliselt, liiklusvooge teises suunas elus tõukama, mis oli samuti üsna keeruline.

Kokkuvõtteks: viimase kümne aasta jooksul on keskmise teenusepakkuja tuumaskeem keerukamaks muutunud ning täiendavate rikete punkte (nii seadmete kui ka ainuõiguste kommuteerimisliinide näol) on märkimisväärselt juurde tulnud. Tegelikult tähendab nõue 'näha kõike' selle 'kõikse' kokku toomist ühte punkti.

Arvan, et seda võib täiesti selgelt ekstrapoleerida praegustele algatustele rünneteemade suveräänsuse, kaitse, stabiliseerimise ja parandamise osas 🙂

Ja ees seisab veel Yarovaya.

Allikas: habr.com