Erre a bejegyzésre ösztönzött .
Itt idézem:
ma 18:53-kor
Ma elégedett voltam a szolgáltatóval. Az oldalblokkoló rendszer frissítésével együtt letiltották a mail.ru levelezőjét, reggel óta hívom a technikai támogatást, de nem tudnak mit tenni. A szolgáltató kicsi, és láthatóan magasabb rangú szolgáltatók blokkolják. Észrevettem az összes oldal megnyitásának lassulását is, esetleg valami ferde DLP-t telepítettek? Korábban nem volt probléma a hozzáféréssel. A RuNet pusztulása a szemem előtt zajlik...
Az tény, hogy úgy tűnik, ugyanaz a szolgáltató vagyunk :)
Valóban, Szinte sejtettem a mail.ru problémáinak okát (bár sokáig nem hittünk az ilyesmiben).
Az alábbiak két részre oszlanak:
- a mail.ru-val kapcsolatos jelenlegi problémáink okai és a megtalálásukra irányuló izgalmas küldetés
- az ISP létezése a mai valóságban, a szuverén RuNet stabilitása.
Hozzáférhetőségi problémák a mail.ru-val
Ó, ez elég hosszú történet.
A helyzet az, hogy az állami követelmények teljesítése érdekében (további részletek a második részben) vásároltunk, konfiguráltunk és telepítettünk néhány berendezést - mind a tiltott források szűrésére, mind a megvalósításra. előfizetők.
Valamivel ezelőtt végre úgy építettük át a hálózati magot, hogy az összes előfizetői forgalom szigorúan a megfelelő irányba haladt ezen a berendezésen.
Néhány napja bekapcsoltuk rajta a tiltott szűrést (miközben a régi rendszert működni hagytuk) - úgy tűnt, minden rendben ment.
Ezután fokozatosan elkezdték engedélyezni a NAT-ot ezen a berendezésen az előfizetők különböző részei számára. Ránézésre is úgy tűnt, minden jól megy.
De ma, miután az előfizetők következő része számára engedélyeztük a NAT-ot a berendezésen, már reggeltől fogva elég sok panasszal szembesültünk az elérhetetlenség vagy a részleges elérhetőség miatt. és a Mail Ru Group egyéb erőforrásai.
Elkezdték ellenőrizni: valami valahol néha, néha küld kizárólag a mail.ru hálózatokhoz intézett kérésekre válaszolva. Ráadásul hibásan generált (ACK nélkül), nyilvánvalóan mesterséges TCP RST-t küld. Így nézett ki:
Természetesen az első gondolatok az új berendezésről szóltak: szörnyű DPI, nincs bizalom benne, soha nem tudhatod, mire képes - elvégre a TCP RST meglehetősen gyakori dolog a blokkoló eszközök között.
Feltevés Felvettük azt is, hogy valaki „felsőbbrendű” szűr, de azonnal elvetettük.
Először is kellően józan felfelé linkjeink vannak, hogy ne kelljen így szenvednünk :)
Másodszor, többel is kapcsolatban vagyunk Moszkvában, és rajtuk keresztül megy a mail.ru forgalom – és nincs sem felelősségük, sem egyéb indítékuk a forgalom szűrésére.
A nap következő fele a szokásosan sámánizmussal telt - a felszerelés eladójával együtt, amit köszönünk, nem adták fel :)
- a szűrés teljesen le van tiltva
- A NAT letiltásra került az új séma használatával
- a teszt PC-t külön elkülönített medencébe helyeztük
- IP cím megváltozott
Délután kiosztottak egy virtuális gépet, amely egy normál felhasználó séma szerint csatlakozott a hálózathoz, és a gyártó képviselői hozzáfértek hozzá és a berendezéshez. A sámánizmus folytatódott :)
A gyártó képviselője végül magabiztosan kijelentette, hogy a hardvernek semmi köze hozzá: az rsztek valahonnan magasabbról jönnek.
MegjegyzésEzen a ponton valaki azt mondhatja: de sokkal könnyebb volt nem a teszt PC-ről, hanem a DPI feletti autópályáról lerakni?
Nem, sajnos a 40+gbps kiíratása (és akár csak tükrözése) egyáltalán nem triviális.
Ezek után este nem volt más hátra, mint visszatérni a furcsa szűrés feltételezéséhez valahol fent.
Megnéztem, hogy most melyik IX-en halad át az MRG hálózatok forgalma, és egyszerűen töröltem a bgp munkameneteit. És - lám! - minden azonnal visszatért a normális kerékvágásba 🙁
Egyrészt kár, hogy az egész nap a probléma keresésével telt, bár öt perc alatt megoldódott.
Másrészt:
— emlékezetem szerint ez példátlan dolog. Ahogy fentebb már írtam - IX tényleg nincs értelme a tranzitforgalmat szűrni. Általában több száz gigabit/terabit másodpercenként. Egészen a közelmúltig nem tudtam komolyan elképzelni ilyesmit.
— a körülmények hihetetlenül szerencsés egybeesése: egy új összetett hardver, amelyben nem különösebben bíznak, és amelytől nem világos, hogy mi várható – kifejezetten az erőforrások blokkolására szabva, beleértve a TCP RST-ket is.
Ennek az internetes tőzsdének a NOC-ja jelenleg problémát keres. Szerintük (és én elhiszem nekik) nincs semmiféle speciálisan kiépített szűrőrendszerük. De hála az égnek, a további keresés már nem a mi problémánk :)
Ez egy kis próbálkozás volt, hogy igazoljam magam, kérlek értsd meg és bocsáss meg :)
PS: Szándékosan nem nevezem meg a DPI/NAT vagy az IX gyártóját (sőt, nincs is rájuk különösebb panaszom, a lényeg, hogy megértsem, mi volt az)
A mai (valamint a tegnapi és a tegnapelőtti) valóság egy internetszolgáltató szemszögéből
Az elmúlt heteket azzal töltöttem, hogy jelentősen átépítettem a hálózat magját, egy csomó manipulációt végeztem „nyereség érdekében”, azzal a kockázattal, hogy jelentősen befolyásolom az élő felhasználói forgalmat. Mindezek céljait, eredményeit és következményeit figyelembe véve, morálisan mindez meglehetősen nehéz. Különösen - ismét hallgatva gyönyörű beszédeket a Runet stabilitásának védelméről, szuverenitásáról stb. stb.
Ebben a részben megpróbálom leírni egy tipikus internetszolgáltató hálózati magjának „fejlődését” az elmúlt tíz év során.
Tíz éve.
Azokban az áldott időkben a szolgáltatói hálózat magja olyan egyszerű és megbízható lehetett, mint egy forgalmi dugó:
Ezen a nagyon-nagyon leegyszerűsített képen nincs trunk, ring, ip/mpls routing.
Lényege, hogy a felhasználói forgalom végül a kernelszintű váltásig érkezett – onnan, ahová , ahonnan általában vissza a központi kapcsoláshoz, majd „ki” - egy vagy több határátjárón keresztül az internetre.
Egy ilyen sémát nagyon-nagyon könnyű lefoglalni mind L3-on (dinamikus útválasztás), mind L2-n (MPLS).
N+1 bármit telepíthet: elérheti a szervereket, kapcsolókat, határokat – és így vagy úgy lefoglalhatja őket az automatikus feladatátvételhez.
Néhány év után Oroszországban mindenki számára világossá vált, hogy nem lehet így tovább élni: sürgősen meg kell védeni a gyerekeket az internet káros befolyásától.
Sürgősen meg kellett találni a felhasználói forgalom szűrésének módját.
Itt különböző megközelítések léteznek.
Nem túl jó esetben valami „résbe” kerül: a felhasználói forgalom és az internet közé. A „valami”-n áthaladó forgalmat elemzik, és például egy átirányítással ellátott hamis csomagot küldenek az előfizető felé.
Kicsit jobb esetben - ha a forgalom megengedi - megtehetsz egy kis trükköt a füleddel: csak a felhasználóktól származó forgalmat küldd szűrésre csak azokra a címekre, amelyeket szűrni kell (ehhez vagy az IP-címeket veheted át megadni a rendszerleíró adatbázisból, vagy feloldani a meglévő domaineket is a nyilvántartásban).
Egy időben, ezekre a célokra, írtam egy egyszerű - bár nem is merem így hívni. Nagyon egyszerű és nem túl produktív – azonban lehetővé tette számunkra és több tucat (ha nem több száz) más szolgáltató számára, hogy ne azonnal milliókat fizessünk ki az ipari DPI-rendszerekből, hanem több évnyi időt adott.
Egyébként az akkori és jelenlegi DPI-rőlEgyébként sokan, akik megvásárolták az akkoriban a piacon kapható DPI rendszereket, már kidobták azokat. Nos, nem erre vannak kitalálva: több százezer cím, több tízezer URL.
És ugyanakkor a hazai termelők nagyon erősen felemelkedtek erre a piacra. Nem a hardver komponensről beszélek - itt mindenki számára világos, de a szoftver - ami a DPI-nek a fő dolga - ma talán, ha nem is a legfejlettebb a világon, de minden bizonnyal a) ugrásszerűen fejlődik, és b) dobozos termék árán – egyszerűen összehasonlíthatatlan a külföldi versenytársakkal.
Szeretnék büszke lenni, de egy kicsit szomorú =)
Most minden így nézett ki:
Még pár év múlva mindenkinek volt már könyvvizsgálója; Egyre több forrás volt a nyilvántartásban. Egyes régebbi berendezéseknél (például Cisco 7600) az „oldalszűrős” séma egyszerűen használhatatlanná vált: 76 platformon az útvonalak száma körülbelül kilencszázezerre korlátozódik, míg az IPv4 útvonalak száma ma már megközelíti a 800-at. ezer. És ha ez is ipv6... És még... mennyi van? 900000 XNUMX egyéni cím az RKN-tilalomban? =)
Valaki olyan sémára váltott, amely a teljes gerincforgalmat tükrözi egy szűrőkiszolgálóra, amely elemzi a teljes folyamot, és ha valami rosszat talál, elküldi az RST-t mindkét irányba (küldő és címzett).
Azonban minél nagyobb a forgalom, annál kevésbé alkalmazható ez a rendszer. Ha a feldolgozásban a legkisebb késés is előfordul, a tükrözött forgalom egyszerűen észrevétlenül elszáll, és a szolgáltató finom jelentést kap.
Egyre több szolgáltató kénytelen különböző megbízhatóságú DPI-rendszereket telepíteni az autópályákon.
Egy-két éve pletykák szerint szinte az összes FSB követelni kezdte a berendezések tényleges telepítését (korábban a legtöbb szolgáltató a hatóságok jóváhagyásával kezelte SORM terv - operatív intézkedések terve arra az esetre, ha valahol valamit találni kell)
A (nem éppen túlzó, de mégis milliós) pénz mellett a SORM még sok manipulációt igényelt a hálózattal.
- A SORM-nak látnia kell a „szürke” felhasználói címeket a nat fordítás előtt
- A SORM korlátozott számú hálózati interfésszel rendelkezik
Ezért különösen nagymértékben át kellett építenünk a kernel egy darabját – egyszerűen azért, hogy valahol egy helyen összegyűjtsük a felhasználói forgalmat a hozzáférési szerverekre. Annak érdekében, hogy több hivatkozással tükrözze a SORM-ban.
Vagyis nagyon leegyszerűsítve ez volt (balra) vs lett (jobbra):
Most A legtöbb szolgáltató megköveteli a SORM-3 megvalósítását is, amely többek között a nat adások naplózását is magában foglalja.
Ebből a célból a fenti diagramhoz külön felszerelést is kellett hozzáadnunk a NAT számára (pontosan az első részben tárgyalt). Sőt, bizonyos sorrendben adja hozzá: mivel a SORM-nak „látnia” kell a forgalmat a címek lefordítása előtt, a forgalomnak szigorúan a következőképpen kell mennie: felhasználók -> váltás, kernel -> hozzáférési szerverek -> SORM -> NAT -> váltás, kernel - > Internet. Ehhez a forgalmi áramlásokat szó szerint a másik irányba kellett „fordítani” a profit érdekében, ami szintén elég nehéz volt.
Összegezve: az elmúlt tíz év során egy átlagos szolgáltató alapfelépítése sokszorosára bonyolódott, és a további meghibásodási pontok (mind a berendezések, mind az egyes kapcsolóvonalak formájában) jelentősen megnőttek. Valójában maga a „mindent lássanak” követelmény azt jelenti, hogy ezt a „mindent” egy pontra kell csökkenteni.
Azt hiszem, ez elég átláthatóan extrapolálható a jelenlegi kezdeményezésekre a Runet szuverenizálására, védelmére, stabilizálására és fejlesztésére :)
És Yarovaya még mindig előrébb van.
Forrás: will.com