Ajendas mind selle postituse juurde .
Tsiteerin seda siin:
täna kell 18:53
Jäin täna teenusepakkujaga rahule. Koos saidi blokeerimissüsteemi uuendamisega keelati ära ka tema mailer mail.ru.Olen hommikust saati helistanud tehnilisele toele, aga nad ei oska midagi teha. Pakkuja on väike ja ilmselt kõrgema positsiooniga pakkujad blokeerivad selle. Märkasin ka kõigi saitide avanemise aeglustumist, äkki paigaldasid mingi kõvera DLP? Varem ei olnud juurdepääsuga probleeme. RuNeti hävitamine toimub otse minu silme all...
Fakt on see, et tundub, et oleme sama pakkuja :)
Ja tõepoolest, Ma peaaegu aimasin mail.ru probleemide põhjust (kuigi me keeldusime pikka aega sellist asja uskumast).
Järgnev jagatakse kaheks osaks:
- meie praeguste mail.ru probleemide põhjused ja nende leidmise põnev otsimine
- Interneti-teenuse pakkuja olemasolu tänapäeva reaalsuses, suveräänse RuNeti stabiilsus.
Juurdepääsetavusprobleemid saidil mail.ru
Oh, see on päris pikk lugu.
Fakt on see, et riigi nõuete rakendamiseks (täpsemalt teises osas) ostsime, konfigureerisime ja paigaldasime osa seadmeid - nii keelatud ressursside filtreerimiseks kui ka juurutamiseks. tellijad.
Mõni aeg tagasi ehitasime lõpuks võrgutuumiku ümber selliselt, et kogu abonendiliiklus käis sellest seadmest läbi rangelt õiges suunas.
Paar päeva tagasi lülitasime sellel sisse keelatud filtreerimise (jättes samas vana süsteemi tööle) - kõik tundus olevat hästi.
Järgmisena hakkasid nad järk-järgult lubama sellel seadmel NAT-i abonentide erinevate osade jaoks. Ka pealtnäha tundus kõik hästi minevat.
Kuid täna, lubades NAT-i seadmetes järgmise osa abonentide jaoks, seisis meid juba hommikust saati korralik arv kaebusi kättesaamatuse või osalise kättesaadavuse kohta. ja muud Mail Ru Groupi ressursid.
Nad hakkasid kontrollima: kuskil midagi mõnikord, aeg-ajalt saadab vastuseks ainult mail.ru võrkudele suunatud päringutele. Veelgi enam, see saadab valesti loodud (ilma ACK-ita), ilmselt kunstliku TCP RST. See nägi välja selline:
Esimesed mõtted olid loomulikult uue varustuse kohta: kohutav DPI, selle vastu ei usaldata, kunagi ei tea, mida see suudab - on ju TCP RST blokeerimisvahendite hulgas üsna tavaline asi.
Eeldus Esitasime ka idee, et keegi "ülem" filtreerib, kuid loobusime sellest kohe.
Esiteks on meil piisavalt mõistlikud üleslingid, et me ei peaks niimoodi kannatama :)
Teiseks oleme seotud mitmega Moskvas ja mail.ru liiklus käib nende kaudu – ja neil pole ei kohustusi ega muud motiivi liiklust filtreerida.
Järgmine pool päevast kulus sellele, mida tavaliselt nimetatakse šamanismiks - koos varustuse müüjaga, mille eest täname, nad ei andnud alla :)
- filtreerimine oli täielikult keelatud
- NAT keelati uue skeemi abil
- testarvuti paigutati eraldi isoleeritud basseini
- IP-aadress muudetud
Pärastlõunal eraldati tavakasutaja skeemi järgi võrku ühendatud virtuaalmasin, millele ja seadmetele anti ligipääs müüja esindajatele. Šamanism jätkus :)
Lõpuks väitis müüja esindaja enesekindlalt, et riistvaral pole sellega absoluutselt mingit pistmist: esimesed tulevad kuskilt kõrgemalt.
MärkusSiinkohal võib keegi öelda: aga palju lihtsam oli prügikasti võtta mitte testarvutist, vaid DPI kohal asuvalt maanteelt?
Ei, kahjuks ei ole 40+gbps tühjendamine (ja isegi lihtsalt peegeldamine) sugugi triviaalne.
Pärast seda, õhtul, ei jäänud muud üle, kui pöörduda tagasi kummalise filtreerimise oletuse juurde kuskil ülal.
Vaatasin, millisest IX-st MRG võrkude liiklus nüüd läbi käib, ja lihtsalt tühistasin selle bgp-seansid. Ja – ennäe! - kõik normaliseerus koheselt 🙁
Ühest küljest on kahju, et terve päev kulus probleemi otsimisele, kuigi see lahenes viie minutiga.
Teiselt poolt:
— minu mäletamist mööda on see enneolematu asi. Nagu ma juba eespool kirjutasin - IX tegelikult transiitliiklust pole mõtet filtreerida. Tavaliselt on neil sadu gigabitte/terabitti sekundis. Ma lihtsalt ei osanud kuni viimase ajani midagi sellist tõsiselt ette kujutada.
— uskumatult õnnelik asjaolude kokkulangevus: uus keeruline riistvara, mida eriti ei usaldata ja millelt pole selge, mida võib oodata — mis on spetsiaalselt kohandatud ressursside, sealhulgas TCP RST-de blokeerimiseks
Selle Interneti-börsi NOC otsib praegu probleemi. Nende sõnul (ja ma usun neid) neil pole spetsiaalselt kasutusele võetud filtreerimissüsteemi. Aga, taevas tänatud, edasine otsimine pole enam meie probleem :)
See oli väike katse end õigustada, palun saage aru ja andke andeks :)
PS: Ma ei nimeta meelega DPI/NAT ega IX tootjat (tegelikult pole mul nende kohta isegi mingeid erilisi kaebusi, peaasi, et aru saaks, mis see oli)
Tänane (nagu ka eilne ja üleeilne) reaalsus internetipakkuja vaatevinklist
Olen viimased nädalad veetnud võrgu tuumikut märkimisväärselt ümber ehitades, tehes hunniku manipulatsioone "kasumi nimel", riskides sellega oluliselt mõjutada reaalajas kasutajaliiklust. Arvestades selle kõige eesmärke, tulemusi ja tagajärgi, on see kõik moraalselt üsna raske. Eriti - kuulates taaskord ilusaid kõnesid Runeti stabiilsuse, suveräänsuse jms kaitsmise kohta. ja nii edasi.
Selles jaotises püüan kirjeldada tüüpilise Interneti-teenuse pakkuja võrgutuuma "arengut" viimase kümne aasta jooksul.
Kümme aastat tagasi.
Nendel õnnistatud aegadel võib pakkujavõrgu tuum olla sama lihtne ja usaldusväärne kui liiklusummik:
Sellel väga-väga lihtsustatud pildil puuduvad magistraalid, rõngad, ip/mpls marsruutimine.
Selle olemus seisneb selles, et kasutajaliiklus jõudis lõpuks kerneli taseme vahetamiseni – sealt, kuhu see läks , kust reeglina tagasi põhilülitusse ja seejärel "välja" - ühe või mitme piirilüüsi kaudu Internetti.
Sellist skeemi on väga-väga lihtne broneerida nii L3-l (dünaamiline marsruutimine) kui ka L2-l (MPLS).
Saate installida N+1 kõike: juurdepääsu serveritele, lülititele, ääristele – ja ühel või teisel viisil reserveerida need automaatseks tõrkevahetuseks.
Mõne aasta pärast Kõigile Venemaal sai selgeks, et nii edasi elada on võimatu: lapsi oli vaja kiiresti kaitsta Interneti kahjuliku mõju eest.
Kiiresti oli vaja leida viise kasutajate liikluse filtreerimiseks.
Siin on erinevaid lähenemisi.
Mitte eriti heal juhul pannakse midagi "lüngasse": kasutajaliikluse ja Interneti vahele. Analüüsitakse seda “midagi” läbivat liiklust ja näiteks saadetakse abonendi poole ümbersuunamisega võltspakett.
Veidi paremal juhul - kui liikluse mahud lubavad - saate oma kõrvaga teha väikese triki: saata filtreerimiseks ainult kasutajatelt pärinev liiklus ainult nendele aadressidele, mis vajavad filtreerimist (selleks võite võtta kas IP-aadressid seal registrist määratud või täiendavalt lahendada olemasolevad domeenid registris).
Korraga kirjutasin nendel eesmärkidel lihtsa - kuigi ma ei julge teda isegi nii kutsuda. See on väga lihtne ja mitte eriti produktiivne – see võimaldas meil ja kümnetel (kui mitte sadadel) teistel pakkujatel tööstuslike DPI-süsteemide pealt kohe miljoneid välja maksta, vaid andis veel mitu aastat aega.
Muide, toonase ja praeguse DPI kohtaMuide, paljud, kes ostsid sel ajal turul olevad DPI-süsteemid, olid need juba minema visanud. Noh, need pole selleks loodud: sajad tuhanded aadressid, kümned tuhanded URL-id.
Ja samas on kodumaised tootjad väga tugevalt sellele turule tõusnud. Ma ei räägi riistvarakomponendist – siin on kõik selge, aga tarkvara – põhiline, mis DPI-l on – on ehk täna, kui mitte kõige arenenum maailmas, siis kindlasti a) areneb hüppeliselt, ja b) karbis oleva toote hinnaga – lihtsalt võrreldamatu välismaiste konkurentidega.
Tahaks uhke olla, aga natuke kurb =)
Nüüd nägi kõik välja selline:
Paari aasta pärast veel kõigil olid juba audiitorid; Üha rohkem ressursse oli registris. Mõnede vanemate seadmete (näiteks Cisco 7600) puhul muutus külgfiltreerimise skeem lihtsalt kohaldamatuks: 76 platvormi marsruutide arv on piiratud umbes üheksasaja tuhandega, samal ajal kui ainuüksi IPv4 marsruutide arv läheneb täna 800-le. tuhat. Ja kui see on ka ipv6... Ja ka... kui palju seal on? 900000 XNUMX individuaalset aadressi RKN keelus? =)
Keegi läks üle skeemile, mis peegeldab kogu magistraalliikluse filtreerimisserverisse, mis peaks analüüsima kogu voogu ja kui midagi halba avastatakse, saatma RST mõlemas suunas (saatja ja saaja).
Mida suurem on liiklus, seda vähem see skeem on rakendatav. Kui töötlemisel esineb vähimatki viivitust, lendab peegeldatud liiklus lihtsalt märkamatult mööda ja teenusepakkuja saab trahvi raporti.
Üha enam pakkujaid on sunnitud paigaldama maanteedele erineva töökindlusega DPI-süsteeme.
Aasta või kaks tagasi kuulujuttude järgi hakkasid peaaegu kõik FSB nõudma seadmete tegelikku paigaldamist (Varem haldas enamik teenusepakkujaid ametiasutuste nõusolekul SORM plaan - operatiivmeetmete plaan, kui on vaja midagi kuskilt leida)
Lisaks rahale (mitte just üüratu, aga siiski miljoneid) nõudis SORM veel palju võrguga manipuleerimist.
- SORM peab enne nat-tõlget nägema "halli" kasutajaaadresse
- SORM-il on piiratud arv võrguliideseid
Seetõttu pidime eelkõige osa kernelist kõvasti ümber ehitama – lihtsalt selleks, et koguda kasutajaliiklus ligipääsuserveritele kuhugi ühte kohta. Selle peegeldamiseks SORM-is mitme lingiga.
See tähendab, et väga lihtsustatult oli (vasakul) vs sai (paremal):
Nüüd Enamik pakkujaid nõuab ka SORM-3 juurutamist – see hõlmab muu hulgas nat-saadete logimist.
Nendel eesmärkidel pidime ülaltoodud diagrammile lisama ka eraldi seadmed NAT-i jaoks (täpselt sellest, millest esimeses osas juttu). Lisaks lisage kindlas järjekorras: kuna SORM peab enne aadresside tõlkimist liiklust "nägema", peab liiklus toimuma rangelt järgmiselt: kasutajad -> vahetamine, kernel -> juurdepääsuserverid -> SORM -> NAT -> vahetamine, kernel - > Internet. Selleks pidime liiklusvoogusid kasumi nimel sõna otseses mõttes teistpidi “keerama”, mis oli samuti päris keeruline.
Kokkuvõttes: viimase kümne aasta jooksul on keskmise pakkuja põhikonstruktsioon muutunud kordades keerukamaks ning täiendavad tõrkepunktid (nii seadmete kui üksikute lülitusliinide näol) on oluliselt suurenenud. Tegelikult tähendab „kõike nägemise” nõue selle „kõige” vähendamist ühe punktini.
Ma arvan, et seda saab üsna läbipaistvalt ekstrapoleerida praegustele algatustele Runeti suveräänseks muutmiseks, kaitsmiseks, stabiliseerimiseks ja täiustamiseks :)
Ja Yarovaya on veel ees.
Allikas: www.habr.com