Sain minut tähän viestiin .
Lainaan sitä tässä:
tänään klo 18:53
Olin tänään tyytyväinen palveluntarjoajaan. Sivuston estojärjestelmän päivityksen myötä hänen sähköpostinsa mail.ru kiellettiin. Olen soittanut tekniseen tukeen aamusta lähtien, mutta he eivät voi tehdä mitään. Palveluntarjoaja on pieni, ja ilmeisesti korkea-arvoiset palveluntarjoajat estävät sen. Huomasin myös hidastumisen kaikkien sivustojen avaamisessa, ehkä he asensivat jonkinlaisen vinon DLP: n? Aiemmin pääsyssä ei ollut ongelmia. RuNetin tuhoutuminen tapahtuu silmieni edessä...
Tosiasia on, että näyttää siltä, että olemme sama palveluntarjoaja :)
Ja todellakin Melkein arvasin syyn mail.ru:n ongelmiin (vaikka emme uskoneet sellaiseen pitkään aikaan).
Seuraavat asiat jaetaan kahteen osaan:
- syitä mail.ru:n nykyisiin ongelmiimme ja jännittävä pyrkimys löytää ne
- Internet-palveluntarjoajan olemassaolo nykypäivän todellisuudessa, suvereenin RuNetin vakaus.
Saavutettavuusongelmia mail.ru:ssa
Oho, se on aika pitkä tarina.
Tosiasia on, että valtion vaatimusten toteuttamiseksi (lisätietoja toisessa osassa) ostimme, konfiguroimme ja asensimme laitteita - sekä kiellettyjen resurssien suodattamiseen että toteuttamiseen. tilaajia.
Jokin aika sitten rakensimme vihdoin verkkoytimen uudelleen siten, että kaikki tilaajaliikenne kulki tämän laitteen läpi ehdottomasti oikeaan suuntaan.
Muutama päivä sitten laitoimme siihen kielletyn suodatuksen päälle (vanha järjestelmä jäi toimimaan) - kaikki näytti menevän hyvin.
Seuraavaksi he vähitellen alkoivat ottaa NAT:ia käyttöön näissä laitteissa tilaajien eri osille. Ulkonäön perusteella kaikki näytti myös menevän hyvin.
Mutta tänään, kun NAT oli otettu käyttöön laitteissa seuraavalle tilaajaosalle, kohtasimme heti aamusta lähtien kohtuullisen määrän valituksia käytettävyydestä tai osittaisesta saatavuudesta. ja muut Mail Ru -ryhmän resurssit.
He alkoivat tarkistaa: jotain jossain joskus, silloin tällöin lähettää vastauksena pyyntöihin yksinomaan mail.ru-verkkoihin. Lisäksi se lähettää väärin generoidun (ilman ACK:ta), ilmeisen keinotekoisen TCP RST:n. Se näytti jotakuinkin tältä:
Luonnollisesti ensimmäiset ajatukset koskivat uusia laitteita: kauhea DPI, ei luottamusta siihen, ei koskaan tiedä mitä se voi tehdä - loppujen lopuksi TCP RST on melko yleinen asia estotyökalujen joukossa.
olettamus Esitimme myös ajatuksen, että joku "ylempi" suodattaa, mutta hylkäsimme sen välittömästi.
Ensinnäkin meillä on tarpeeksi järkevät uplinkit, jotta meidän ei tarvitse kärsiä näin :)
Toiseksi olemme yhteydessä useisiin Moskovassa, ja mail.ru:n liikenne kulkee heidän kauttaan - eikä heillä ole velvollisuuksia eikä muitakaan motiiveja suodattaa liikennettä.
Seuraava puolet päivästä meni tavallisesti shamanismiksi kutsuttuun pariin - yhdessä laitemyyjän kanssa, mistä kiitämme, he eivät antaneet periksi :)
- suodatus poistettiin kokonaan käytöstä
- NAT poistettiin käytöstä uudella mallilla
- testi-PC asetettiin erilliseen eristettyyn pooliin
- IP-osoite muutettu
Iltapäivällä varattiin virtuaalikone, joka liittyi verkkoon tavallisen käyttäjän kaavan mukaan, ja toimittajan edustajille annettiin pääsy siihen ja laitteisiin. Shamanismi jatkui :)
Lopulta myyjän edustaja totesi luottavaisesti, että laitteistolla ei ollut mitään tekemistä sen kanssa: ensimmäiset tulevat jostain korkeammalta.
HuomataTässä vaiheessa joku voi sanoa: mutta oli paljon helpompaa ottaa kaatopaikka ei testitietokoneelta, vaan moottoritieltä DPI:n yläpuolella?
Ei, valitettavasti 40+gbps dump (ja jopa pelkkä peilaus) ei ole ollenkaan triviaalia.
Tämän jälkeen illalla ei ollut enää muuta tekemistä kuin palata oletukseen oudosta suodatuksesta jossain ylhäällä.
Katsoin minkä IX:n kautta liikenne MRG-verkkoihin nyt kulkee ja peruin yksinkertaisesti sen bgp-istunnot. Ja - katso ja katso! - kaikki palautui heti normaaliksi 🙁
Toisaalta on sääli, että koko päivä meni ongelman etsimiseen, vaikka se ratkesi viidessä minuutissa.
Toisaalta:
– Tämä on muistissani ennennäkemätön asia. Kuten jo edellä kirjoitin - IX todella ei ole mitään järkeä suodattaa liikennettä. Niissä on yleensä satoja gigabittejä/terabittejä sekunnissa. En vain osannut vakavasti kuvitella jotain tällaista vasta äskettäin.
— uskomattoman onnekas olosuhteiden yhteensattuma: uusi monimutkainen laitteisto, johon ei erityisen luoteta ja jolta ei ole selvää, mitä voidaan odottaa — räätälöity erityisesti resurssien, mukaan lukien TCP RST:n, estoon
Tämän Internet-vaihdon NOC etsii parhaillaan ongelmaa. Heidän mukaansa (ja minä uskon niihin) heillä ei ole mitään erityistä suodatusjärjestelmää. Mutta luojan kiitos, jatkohaku ei ole enää meidän ongelmamme :)
Tämä oli pieni yritys oikeuttaa itseni, ymmärtäkää ja anteeksi :)
PS: En tarkoituksella nimeä DPI/NAT:n tai IX:n valmistajaa (itse asiassa minulla ei ole edes mitään erityisiä valituksia niistä, tärkeintä on ymmärtää mikä se oli)
Tämän päivän (samoin kuin eilisen ja toissapäivän) todellisuus Internet-palveluntarjoajan näkökulmasta
Olen viettänyt viime viikkoina rakentaen merkittävästi uudelleen verkon ydintä ja suorittanut joukon manipulaatioita "voittoa tavoittelemassa", mikä on vaarassa vaikuttaa merkittävästi live-käyttäjäliikenteeseen. Kaiken tämän tavoitteet, tulokset ja seuraukset huomioon ottaen se on moraalisesti melko vaikeaa. Erityisesti - kuunnellen jälleen kauniita puheita Runetin vakauden, suvereniteetin jne. suojaamisesta. ja niin edelleen.
Tässä osiossa yritän kuvata tyypillisen Internet-palveluntarjoajan verkkoytimen "kehitystä" viimeisen kymmenen vuoden aikana.
Kymmenen vuotta sitten.
Näinä siunatuina aikoina palveluntarjoajan verkon ydin voisi olla yhtä yksinkertainen ja luotettava kuin liikenneruuhka:
Tässä hyvin, hyvin yksinkertaistetussa kuvassa ei ole runkoja, renkaita, ip/mpls-reititystä.
Sen olemus on, että käyttäjäliikenne tuli lopulta ytimen tason vaihtamiseen - mistä se meni , josta pääsääntöisesti takaisin ydinvaihtoon ja sitten "ulos" - yhden tai useamman rajayhdyskäytävän kautta Internetiin.
Tällainen malli on erittäin, erittäin helppo varata sekä L3:lle (dynaaminen reititys) että L2:lle (MPLS).
Voit asentaa N+1 mitä tahansa: käyttää palvelimia, kytkimiä, reunoja ja varata ne tavalla tai toisella automaattista vikasietoa varten.
Muutaman vuoden jälkeen Kaikille Venäjällä kävi selväksi, että näin ei voi enää elää: oli kiireellistä suojella lapsia Internetin haitallisilta vaikutuksilta.
Oli kiireesti löydettävä tapoja suodattaa käyttäjäliikennettä.
Tässä on erilaisia lähestymistapoja.
Ei kovin hyvässä tapauksessa jotain laitetaan "aukkoon": käyttäjäliikenteen ja Internetin väliin. Tämän ”jonkin” läpi kulkeva liikenne analysoidaan ja tilaajalle lähetetään esimerkiksi väärennetty uudelleenohjattu paketti.
Hieman paremmassa tapauksessa - jos liikennemäärät sallivat - voit tehdä pienen tempun korvillasi: lähettää suodatukseen vain käyttäjiltä tuleva liikenne vain niihin osoitteisiin, jotka on suodatettava (tätä varten voit ottaa joko IP-osoitteet määritettynä siellä rekisteristä tai ratkaise lisäksi olemassa olevia verkkotunnuksia rekisterissä).
Kerran näitä tarkoituksia varten kirjoitin yksinkertaisen - vaikka en edes uskalla kutsua häntä sillä. Se on hyvin yksinkertainen ja ei kovin tuottava – sen ansiosta me ja kymmenet (elleivät sadat) muut palveluntarjoajat eivät kuitenkaan heti maksaneet miljoonia teollisille DPI-järjestelmille, vaan antoivat useita vuosia lisäaikaa.
Muuten, silloisesta ja nykyisestä DPI:stäMuuten, monet, jotka ostivat tuolloin markkinoilla olevat DPI-järjestelmät, olivat jo heittäneet ne pois. No, niitä ei ole suunniteltu tähän: satoja tuhansia osoitteita, kymmeniä tuhansia URL-osoitteita.
Ja samalla kotimaiset tuottajat ovat nousseet näille markkinoille erittäin voimakkaasti. En puhu laitteistokomponentista - kaikki on täällä kaikille selvää, mutta ohjelmisto - tärkein asia, joka DPI:llä on - on ehkä tänään, jos ei maailman edistynein, niin varmasti a) kehittyy harppauksin, ja b) pakatun tuotteen hinnalla - yksinkertaisesti vertaansa vailla ulkomaisten kilpailijoiden kanssa.
Haluaisin olla ylpeä, mutta hieman surullinen =)
Nyt kaikki näytti tältä:
Parin vuoden päästä vielä kaikilla oli jo tilintarkastajat; Rekisteriin tuli yhä enemmän resursseja. Joillekin vanhemmille laitteille (esimerkiksi Cisco 7600) "sivusuodatus" yksinkertaisesti muuttui käyttökelvottomaksi: reittien määrä 76 alustalla on rajoitettu noin yhdeksänsataantuhanteen, kun taas IPv4-reittien määrä on nykyään lähes 800. tuhat. Ja jos se on myös ipv6... Ja myös... kuinka paljon siellä on? 900000 XNUMX yksittäistä osoitetta RKN-kiellossa? =)
Joku siirtyi järjestelmään, jossa kaikki runkoliikenne peilataan suodatuspalvelimelle, jonka pitäisi analysoida koko kulku ja jos jotain vikaa löytyy, lähettää RST molempiin suuntiin (lähettäjä ja vastaanottaja).
Mitä enemmän liikennettä, sitä vähemmän sovellettavissa tämä järjestelmä on. Jos käsittelyssä on pienintäkään viivettä, peilattu liikenne yksinkertaisesti lentää huomaamatta ja palveluntarjoaja saa hienon raportin.
Yhä useammat palveluntarjoajat joutuvat asentamaan eri luotettavuusasteisia DPI-järjestelmiä moottoriteille.
Vuosi tai kaksi sitten huhujen mukaan melkein kaikki FSB alkoi vaatia laitteiden varsinaista asennusta (aiemmin useimmat palveluntarjoajat hoitivat viranomaisten hyväksynnän SORM-suunnitelma - suunnitelma operatiivisista toimenpiteistä, jos jotain on löydettävä jostain)
Rahan (ei aivan kohtuuttoman, mutta silti miljoonien) lisäksi SORM vaati monia muita manipulaatioita verkon kanssa.
- SORM:n on nähtävä "harmaat" käyttäjäosoitteet ennen nat-käännöstä
- SORMilla on rajoitettu määrä verkkoliitäntöjä
Siksi jouduimme erityisesti rakentamaan uudelleen osan ytimestä - yksinkertaisesti kerätäksemme käyttäjäliikennettä pääsypalvelimille jonnekin yhteen paikkaan. Jotta se peilataan SORMissa useilla linkeillä.
Eli hyvin yksinkertaistettuna se oli (vasen) vs tuli (oikea):
Nyt Useimmat palveluntarjoajat vaativat myös SORM-3:n käyttöönottoa - joka sisältää muun muassa nat-lähetysten kirjaamisen.
Näitä tarkoituksia varten meidän piti myös lisätä erillinen NAT-laitteisto yllä olevaan kaavioon (täsmälleen mitä ensimmäisessä osassa käsitellään). Lisäksi lisää tietyssä järjestyksessä: koska SORM:n täytyy "nähdä" liikenne ennen osoitteiden kääntämistä, liikenteen tulee mennä tiukasti seuraavasti: käyttäjät -> vaihto, ydin -> pääsypalvelimet -> SORM -> NAT -> vaihto, ydin -> > Internetiä. Tätä varten meidän piti kirjaimellisesti "kääntää" liikennevirtoja toiseen suuntaan voiton saamiseksi, mikä oli myös melko vaikeaa.
Yhteenvetona: viimeisen kymmenen vuoden aikana keskimääräisen palveluntarjoajan ydinsuunnittelu on moninkertaistunut, ja lisävikakohdat (sekä laitteiden että yksittäisten kytkentälinjojen muodossa) ovat lisääntyneet merkittävästi. Itse asiassa vaatimus "nähdä kaikki" tarkoittaa tämän "kaiken" vähentämistä yhteen pisteeseen.
Luulen, että tämä voidaan varsin avoimesti ekstrapoloida nykyisiin aloitteisiin Runetin hallitsemiseksi, suojelemiseksi, vakauttamiseksi ja parantamiseksi :)
Ja Yarovaya on edelleen edessä.
Lähde: will.com