Ez indított el engem erre a bejegyzésre .
Ide másolom:
ma 18:53-kor
Ma örömet okozott nekem a szolgáltató. Az új weboldalak blokkolási rendszerének frissítésével együtt a mail.ru levelező is blokkolás alá került. Reggel telefonálok a technikai támogatásnak, nem tudnak semmit tenni. A szolgáltató kicsi, és valószínűleg a magasabb szintű szolgáltatók blokkolják őket. Még észleltem, hogy minden weboldal betöltése lassult, lehet, hogy valami hibás DLP-t telepítettek? Korábban nem voltak problémák a hozzáféréssel. A runet elpusztítása a szemem előtt zajlik...
A helyzet az, hogy úgy tűnik, mi vagyunk az a szolgáltató 🙁
És valóban, majdnem eltaláltuk a mail.ru problémáinak okát (bár sokáig nem akartuk elhinni).
A továbbiakban két részre oszlik:
- a mail.ru-val kapcsolatos problémáink okai és izgalmas küldetés a megoldásukra
- az ISP-k létezése a mai realitásokban, a szuverén runet stabilitása.
Problémák a mail.ru elérhetőségével
Oh, ez egy elég hosszú történet.
A lényeg az, hogy az állami követelmények teljesítése érdekében (részletesebben a második részben) vásároltunk, beállítottunk és telepítettünk néhány berendezést — mind a tiltott források szűrésére, mind a előfizetői számára.
Néhány idővel ezelőtt végre átstrukturáltuk a hálózat magját úgy, hogy az összes előfizetői forgalom ezen a berendezésen keresztül haladjon a megfelelő irányba.
Néhány nappal ezelőtt aktiváltuk ezen a berendezésen a tiltott tartalom szűrését (egyszerre működtetve a régi rendszert is) — első pillantásra minden rendben ment.
Ezután fokozatosan aktiváltuk a NAT-ot az előfizetők különböző részein ezzel a berendezéssel. Első pillantásra — szintén minden jól működött.
De ma, amikor bekapcsoltuk a NAT-ot az előfizetők következő részén — reggel óta jelentős számú panasz érkezett a hozzáférhetőség hiányáról vagy részleges hozzáféréséről és más Mail Ru Group erőforrásokról.
Kezdtük ellenőrizni: valami valahol néha, ritkán TCP RST-t a mail.ru hálózatokhoz érkező kérésekre adott válaszként. Ráadásul helytelenül generált (ACK nélkül) egyértelműen mesterséges TCP RST-t küld. Körülbelül így nézett ki:
Természetesen, az első gondolatok az új hardverre irányultak: félelmetes DPI, semmilyen bizalom, ki tudja, mit cselekedhet — hiszen a TCP RST meglehetősen elterjedt dolog a blokkolási eszközök között.
Feltételezés arról, hogy valaki "felsőbb" szinten szűr, szintén felmerült — de azt azonnal elvetettük.
Először is, elegendően megfelelő uplinkjeink vannak ahhoz, hogy ilyesmivel ne szenvedjünk 🙂
Másodszor, több van Moszkvában, és a forgalom a mail.ru felé igazából rajtuk keresztül megy — és nekik sincsenek kötelezettségeik, semmilyen más motivációjuk a forgalom szűrésére.
A nap következő felében arra fordítottuk az időt, amit általában varázslásnak hívnak — az eszköz gyártójával együtt dolgoztunk, ezért hálásak vagyunk, hogy nem hagytak minket cserben 🙂
- teljesen le lett állítva a szűrés
- az új terv szerint le lett állítva a NAT
- a teszt PC-t egy külön elszigetelt medencébe vittük
- megváltozott az IP-címzés
A nap második felében egy virtuális gépet szenteltek, amely a normál felhasználó üzemmódja szerint csatlakozik a hálózathoz, és hozzá, valamint az eszközhöz a gyártó képviselői is hozzáférést kaptak. A varázslás folytatódott 🙂
Végül a gyártó képviselője magabiztosan kijelentette, hogy a hardver biztosan nem tehető felelőssé: az rst-k valahonnan fentről érkeznek.
MegjegyzésItt valaki azt mondhatja: de sokkal egyszerűbb lett volna a dumpot nem a teszt PC-ről, hanem a DPI feletti gerincről venni?
Sajnos nem, a 40+ gbps dump (és még csak simán tükörforgalmazás) nem trivialis feladat.
Ezután, már este — nem maradt más hátra, mint visszatérni a gyanúra egy furcsa szűrésről valahol fent.
Megnéztem, hogy melyik IX-en keresztül megy a forgalom az MRG hálózataihoz, és egyszerűen leállítottam a BGP-sessionokat. És — ó csoda! — minden azonnal normalizálódott 🙁
Egyrészt nagyon sajnálom, hogy a probléma keresésére egész napot kellett pazarolni, pedig öt perc alatt megoldható volt.
Másrészt:
— az emlékeim szerint ez precedens nélküli dolog. Ahogy már írtam korábban — az IX-nek valóban nincs semmiféle értelme szűrni a tranzitforgalmat. Általában több száz gigabit/terabit forgalmuk van másodpercenként. Egyszerűen nem tudtam az utolsó pillanatig komolyan venni egy ilyen feltételezést.
— egy hihetetlenül szerencsés véletlen: új, bonyolult hardver, amelyben nincs különösebb bizalom, és amelytől nem tudni, mit lehet várni — kifejezetten a források blokkolására tervezve, beleértve a TCP RST-okat is.
Jelenleg ennek az internetcsomópontnak a NOC-ja problémát keres. Állításuk szerint (és én hiszek nekik) nem rendelkeznek speciálisan kialakított szűrősystemekkel. De hála az égnek, a további küldetés már nem a mi problémánk 🙂
Ez egy kis kísérlet volt az igazolásra, kérjük, értsenek meg és bocsássanak meg 🙂
P.S.: szándékosan nem nevezem meg a DPI/NAT gyártóját és az IX-et (tulajdonképpen nincs különösebb panaszom rájuk, a lényeg — megérteni, mi volt ez)
A mai (valamint a tegnapi és a tegnap előtti) valóság internetszolgáltató szempontjából
Az utolsó heteket azzal töltöttem, hogy jelentősen átalakítottam a hálózatot, rengeteg műveletet végeztem "élőben", kockázatot vállalva a valódi felhasználói forgalom jelentős érintésére. Figyelembe véve a célokat, eredményeket és a következményeket — ezt morálisan eléggé nehéz elviselni. Különösen, amikor újra és újra hallom a nagyszerű beszédeket a Runet stabilitásának védelméről, a szuverenitásról stb. stb.
Ebben a részben megpróbálom elmondani a tipikus internetes szolgáltató hálózati magjának "evolúcióját" az elmúlt tíz évben.
Tíz évvel ezelőtt.
Azokban az áldott időkben a szolgáltatói hálózat magja olyan egyszerű és megbízható volt, mint egy dugó:
Ezen a nagyon-nagyon leegyszerűsített képen hiányoznak a gerincvonalak, gyűrűk, IP/MPLS forgalmazás.
A lényeg az, hogy a felhasználói forgalom végül a mag szintű kapcsolásába érkezett — ahonnan továbbment a , ahonnan általában — vissza a mag kapcsolásába, és onnan "kifelé" — egy vagy több határolási átjárón keresztül az internetre.
Ez a séma rendkívül könnyen biztonságosra állítható mind L3 (dinamikus útválasztás) mind L2 (MPLS) szinten.
Bármiből N+1-et lehet telepíteni: hozzáférési szerverekből, kapcsolókból, határolókból — és így vagy úgy fenntartani őket automatikus hibás működés esetén.
Néhány év múlva mindenki Oroszországban rájött, hogy így tovább nem lehet élni: sürgősen meg kell védeni a gyermekeket a hálózat romlott hatásaitól.
Sürgősen szükség volt felhasználói forgalom szűrési módszerek kidolgozására.
Itt különböző megközelítések léteznek.
Nem túl szerencsés esetben — valami "keresztezésként" kerül telepítésre: a felhasználói forgalom és az internet között. A keresztülhaladó forgalom elemzés alá kerül, és például egy hamis csomag kerül elküldésre a felhasználónak átirányítással.
Könnyebb esetben — ha a forgalom mennyisége lehetővé teszi — egy kis trükköt alkalmazhatunk: a felhasználóktól származó forgalmat csak azokhoz a címekhez irányítsuk szűrésre, amelyeket szükséges kiszűrni (ehhez vehetjük a nyilvántartásban megadott IP-címeket, vagy további névfeloldást végezhetünk a nyilvántartásban található domainekre).
Valaha ehhez a célhoz írtam egy egyszerű — bár a nyelv még így sem akarja ezt mondani. Nagyon egyszerű és nem túl teljesítményorientált — azonban nekünk és több tucat (ha nem több mint száz) másik szolgáltatónak lehetővé tette, hogy ne kelljen azonnal milliókat költeni ipari DPI-rendszerekre, hanem további éveket nyertünk vele.
Mellesleg, a akkori és mai DPI-królMeg kell jegyezni, hogy sokan, akik a piacon akkor elérhető DPI-rendszereket vásároltak — már kidobták azokat. Nem erre lettek tervezve: számos címmel, tízezer URL-lal.
Ugyanakkor e piacon erőteljesen megerősödtek a hazai gyártók. Nem arról beszélek, hogy mi a helyzet a hardverrel — ez mindenkinek világos, de a szoftver — a DPI fő eleme — talán ma a világ legfejlettebbje, vagy legalábbis a) óriási léptekkel fejlődik, és b) dobozos áron — egyszerűen össze sem hasonlítható a külföldi versenytársakkal.
Szeretném büszkén említeni, de kicsit szomorú =)
Most így nézett ki:
Pár év múlva már mindenkinek revizorai voltak; a nyilvántartásban levő erőforrások folyamatosan gyűltek. Néhány régi berendezés (például Cisco 7600) esetében a „mellékes szűrés” elképzelése egyszerűen használhatatlanná vált: a 76-os platformokon a kapcsolatok száma körülbelül kilencszázezerre korlátozódik, míg a csupán IPv4 útvonalak száma ma már közel 800 ezerhez közelít. És ha még az ipv6… és mennyi van ott? 900000 külön címet eltávolítottak a RKN tilalmából? =)
Valaki átállt arra, hogy a fő forgalmat a szűrő szerverre tükrözze, amelynek analizálnia kellett az egész áramlást, és ha valami rossz dologra bukkant, akkor mindkét irányba (a küldőnek és a fogadónak) RST-t kellett küldeni.
De minél nagyobb a forgalom, annál kevésbé alkalmazható ez a séma. A legkisebb feldolgozási késedelem esetén a tükrözött forgalom egyszerűen észrevétlenül átsiklik, és a szolgáltató büntetést kap.
Egyre több szolgáltató kénytelen különböző megbízhatósági fokozatú DPI-rendszereket telepíteni a fővonalakon.
Körülbelül egy-két évvel ezelőtt a pletykák szerint szinte mindenhol megkövetelte a FSB a valós berendezések telepítését (korábban a legtöbb szolgáltató megelégedett azzal, hogy jóváhagyásokat kérjen a hatóságoktól SORM tervével — a sürgősségi intézkedések terve, ha szükséges valamit valahol megtalálni)
A pénz mellett (nem mintha valóban elérhetetlen lenne, de mégis — milliók), a SORM sok esetben újabb manővereket követelt a hálózaton.
- A SORM-nak látnia kell a felhasználók „szürke” címeit, a nat-transzláció előtt.
- A SORM-nak korlátozott számú hálózati interfésze van.
Ezért nekünk, többek között, jelentősen át kellett alakítanunk a kernel egy részét — egyszerűen azért, hogy összegyűjtsük a felhasználók forgalmát a hozzáférési szerverekhez. Ennek érdekében több vonalon is tükrözni kellett a SORM-ba.
Tehát, nagyon leegyszerűsítve, volt (bal oldalon) vs lett (jobboldalon):
Jelenleg a legtöbb szolgáltatónál a SORM-3 bevezetését is követelik — amely magában foglalja többek között a nat-transzlációk naplózását.
Ezeknek a céloknak megfelelően a fenti séma miatt további berendezéseket kellett hozzáadnunk a NAT-hoz (éppen arról van szó, amiről az első részben szó esett). Ráadásul meghatározott sorrendben kell hozzáadni: mivel a SORM-nak „látnia” kell a forgalmat a címek transzlációja előtt — a forgalom szigorúan a következőképpen kell, hogy haladjon: felhasználók -> kapcsolás, kernel -> hozzáférési szerverek -> SORM -> NAT -> kapcsolás, kernel -> internet. Ennek érdekében szó szerint „meg kellett fordítanunk” a forgalmi folyamokat, ami szintén elég nehéz volt.
Összesen: egy évtized alatt a közepes szolgáltató magjának rendszere többszörös bonyolultságon ment keresztül, és a további lehetséges hibapontok (mind az eszközök, mind a kapcsolási vonalak tekintetében) jelentősen megnövekedtek. Magában az követelményben, hogy „mindent látni” kell, ezeket a „mindent” egy pontra kell redukálni.
Úgy érzem, ezt teljesen átláthatóan extrapolálni lehet a jelenlegi kezdeményezésekre a runet szuverenizálásáról, védelméről, stabilizálásáról és javításáról 🙂
A jövőben még jön a Yarovaya.
Forrás: habr.com
