Inšpirovalo ma to k tomuto príspevku .
Uvádzam ho tu:
dnes o 18:53
Dnes ma potešil poskytovateľ. Spolu s aktualizáciou systému blokovania stránok sa dostal pod zákaz poštový server mail.ru. Od rána kontaktujem technickú podporu, nemôžu s tým nič urobiť. Poskytovateľ je malý a zdá sa, že blokujú nadriadení poskytovatelia. Ešte som si všimol spomalenie načítania všetkých stránok, možno nasadili nejaký chybný DLP? Predtým neboli žiadne problémy s prístupom. Ničenie runetu pokračuje priamo pred mojimi očami…
Ide o to, že sa zdá, že sme práve my ten poskytovateľ 🙁
A naozaj, takmer sme sa trafili do príčiny problémov s mail.ru (aj keď sme dlho odmietali veriť v niečo také).
Ďalšie bude rozdelené na dve časti:
- príčiny našich dnešných problémov s mail.ru a fascinujúci quest po ich hľadaní
- existencia ISP v dnešných reáliách, stabilita suverénneho runetu.
Problémy s dostupnosťou mail.ru
Och, to je dosť dlhý príbeh.
Ide o to, že na realizáciu požiadaviek štátu (podrobnejšie v druhej časti) sme zakúpili, nastavili a nainštalovali niektoré zariadenia — ako na filtrovanie zakázaných zdrojov, tak aj na vykonávanie abonentov.
Pred nejakým časom sme konečne prebudovali jadro siete tak, aby celý traffic abonentov prechádzal cez toto zariadenie prísne v požadovanom smere.
Pred niekoľkými dňami sme na ňom zapli filtrovanie zakázaného obsahu (súčasne sme nechali fungovať aj starý systém) — na pohľad všetko prebehlo dobre.
Ďalej — postupne sme začali zapínať pre rôzne časti abonentov NAT na tomto zariadení. Na pohľad — tiež všetko, zdalo sa, že išlo dobre.
Ale dnes, keď sme na zariadení zapli NAT pre ďalšiu časť abonentov — od rána sme sa stretli so značným množstvom sťažností na nedostupnosť alebo čiastočnú dostupnosť a iných zdrojov Mail Ru Group.
Začali sme kontrolovať: niečo niekde občas, zriedkavo posiela v odpovedi na požiadavky výlučne k sieťam mail.ru. Navyše — posiela nesprávne generované (bez ACK), jasne umelé TCP RST. Takto to asi vyzeralo:
Samozrejme, prvé myšlienky sa týkali nového vybavenia: hrozné DPI, nedôvera k nemu, veď nikdy neviete, čo môže spôsobiť — veď TCP RST je pomerne rozšírená záležitosť medzi blokovacími prostriedkami.
Predpoklad o tom, že niekto „vyšší“ filtruje, sme tiež navrhli — ale hneď sme to zamietli.
Po prvé, máme dosť rozumné uplinky, aby sme sa s týmto problémom nestretli 🙂
Po druhé, sme pripojení na niekoľko v Moskve, a prevádzka do mail.ru ide práve cez ne — a oni nemajú žiadne povinnosti ani iné motivy filtrovať prevádzku.
Nasledujúca polovica dňa bola strávená tým, čo obyčajne nazývajú šamanizmom — spolu s dodávateľom vybavenia, za čo im ďakujeme, sa nevzdali 🙂
- kompletné odpojenie filtrovania
- NAT sa odpojil podľa nového schémy
- testovací PC bol umiestnený do samostatného izolovaného poolu
- menila sa IP adresa
V druhej polovici dňa bola vyčlenená virtuálka, ktorá sa pripojila do siete podľa schémy bežného používateľa, a táto virtuálka aj vybavenie dostali prístup k zástupcom dodávateľa. Šamanizmus pokračoval 🙂
Nakoniec zástupca dodávateľa s istotou vyhlásil, že zariadenie s tým nemá nič spoločné: rst prichádzajú odkiaľsi vyššie.
PoznámkaNa tomto mieste môže niekto vyhlásiť: ale predsa by bolo oveľa jednoduchšie získať dump nie z testovacieho PC, ale z magistrály nad DPI?
Nie, bohužiaľ, získať dump (a dokonca len jednoducho odmirrorovať) 40+gbps — rozhodne nie je triválne.
Po tom, už večer — neostávalo nič iné, len sa vrátiť k predpokladu o zvláštnom filtrovaní niekde vyššie.
Pozrel som sa, cez ktorý IX teraz prechádza prevádzka do sietí MRG a jednoducho som zrušil bgp-sessiony. A — ó zázrak! — všetko sa okamžite normalizovalo 🙁
Na jednej strane — veľmi ma mrzí, že na hľadanie problému bol strávený celý deň, hoci sa dal vyriešiť za päť minút.
Na druhej strane:
— čo sa mne pamätá, je to bezprecedentná záležitosť. Ako som už predtým písal — IX-om naozaj nemá zmysel filtrovať tranzitnú prevádzku. Zvyčajne majú stovky gigabitov / terabitov za sekundu. Jednoducho som až do poslednej chvíle nemohol seriózne niečo také predpokladať.
— neuveriteľná zhodou okolností: nové zložité zariadenie, ktorému sa nedá obzvlášť dôverovať a od ktorého nie je jasné, čo možno očakávať — presne navrhnuté na blokovanie zdrojov, vrátane TCP RST.
V súčasnosti NOC tohto internetového exchange hľadá problém. Podľa ich tvrdenia (a ja im verím) nemajú žiadny špeciálne nasadený filtračný systém. Ale, vďaka nebu, ďalší quest - už nie je naším problémom 🙂
Bola to malá snaha ospravedlniť sa, prosíme, pochopte a odpustite 🙂
P.S.: Úmyselne nespomínam žiadneho výrobcu DPI/NAT, ani IX (vlastne nemám voči nim žiadne osobitné výhrady, hlavne - pochopiť, čo to bolo)
Dnešná (a tiež včerajšia a predvčerajšia) realita z pohľadu internetového poskytovateľa
Posledné týždne som strávil významným prestavovaním jadra siete, pričom som robil množstvo manipulácií „naživo“, s rizikom silne zasiahnuť do živého používateľského trafiku. Zohľadňujúc ciele, výsledky a dôsledky všetkého tohto - morálne je to všetko celkom ťažké. Zvlášť - počúvajúc po x-tý krát idealistické reči o ochrane stability runetu, suverenite, atď.
V tejto časti sa pokúsim prerozprávať „evolúciu“ jadra siete typického internetového poskytovateľa za posledné desaťročie.
Pred desaťročím.
V tých požehnaných časoch mohlo byť jadro poskytovateľskej siete jednoduché a spoľahlivé, ako korková zátka:
Na tomto veľmi, veľmi zjednodušenom obrázku chýbajú magistrály, kruhy, ip/MPLS smerovanie.
Jeho podstata spočíva v tom, že používateľský traffic nakoniec prichádzal do jadrovej komutácie - odkiaľ sa posielal do , odkiaľ sa zvyčajne - späť do jadrovej komutácie, a ďalej „na výstup“ - cez jeden alebo viac border gateway do internetu.
Podobné schémy sú veľmi, veľmi ľahko zálohované ako na L3 (dynamické smerovanie), tak aj na L2 (MPLS).
Môžete nasadiť N+1 čohokoľvek: prístupových serverov, prepínačov, borderov - a tak alebo onak ich zálohovanie pre automatický failover.
O niekoľko rokov všetkým v Rusku sa stalo jasným, že takto sa žiť nedá: je potrebné naliehavo chrániť deti pred zhubným vplyvom siete.
Vznikla naliehavá potreba hľadať spôsoby, ako filtrovať používateľský traffic.
Existujú rôzne prístupy.
V nie veľmi dobrej situácii - niečo sa nasadzuje „naprieč“: medzi používateľským trafficom a internetom. Prechádzajúci cez toto „niečo“ traffic podlieha analýze a, napríklad, smeruje k odberateľovi falošný paket s preposlaním.
V trochu lepšom prípade — ak objemy prevádzky to umožňujú — je možné urobiť malý trik: posielať na filtrovanie iba od užívateľov prevádzku len na tie adresy, ktoré je potrebné filtrovať (na tento účel je možné buď vziať z registra uvedené tam IP adresy, alebo dodatočne resolvovať existujúce v registri domény).
V svojom čase som napísal jednoduchý — hoci ani jazyk sa neobracia ho takto nazývať. Je veľmi jednoduchý a nie veľmi výkonný — avšak pre nás, ako aj pre desiatky (ak nie stovky) ďalších poskytovateľov to umožnilo nezaplatit hneď milióny za priemyselné DPI systémy a dalo niekoľko ďalších rokov času.
Napriek tomu, o vtedajších a súčasných DPIMimochodom, mnohí, ktorí kúpili existujúce na trhu DPI systémy — už ich vyhodili. No nie sú prispôsobené pre takéto: stovky tisíc adries, desiatky tisíc URL.
A zároveň sa na tento trh veľmi zdvihli domáci výrobcovia. Nehovorím o hardvérovej súčasti — tu je všetko jasné, ale softvér — je to hlavné, čo je v DPI — možno, že ak nie najpokročilejší na svete, tak určite a) sa vyvíja obrovským tempom, a b) cenovo — jednoducho neporovnateľné so zahraničnými konkurentmi.
Chcel by som sa pýšiť, ale je to trochu smutné =)
Teraz to vyzeralo takto:
Ešte o pár rokov neskôr mal každý už inšpektorov; zdrojov v registri pribúdalo čoraz viac. Pre niektoré staré zariadenia (napríklad cisco 7600) sa schéma s "filtráciou z boku" stala jednoducho nepoužiteľnou: počet trás na 76 platformách je obmedzený na niečo okolo deväťsto tisíc, pričom len počet IPv4 trás dnes už dosahuje takmer 800 tisíc. A ak ešte aj ipv6… A ešte aj… koľko tam? 900000 jednotlivých adries v zákaze rkn? =)
Niektorí prechádzali na schému s mirrovaním celej magistrálnej prevádzky na filtrovanie servera, ktorý musí analyzovať celý tok a pri nájdení niečoho zlého posielať na obe strany (odošleteľovi a príjemcovi) RST.
Avšak čím viac prevádzky, tým menej je táto schéma aplikovateľná. Pri najmenšej oneskorení v spracovaní — zrkadlená prevádzka jednoducho nepozorovane preletí nikam, a poskytovateľ dostane protokol o pokute.
Stále viac a viac poskytovateľov sa núti inštalovať DPI systémy rôznej úrovne spoľahlivosti na hlavné tranzitné cesty.
Rok-dva dozadu podľa zvestí, prakticky od všetkých sa vyžaduje, aby skutočne inštalovali zariadenia (predtým väčšina poskytovateľov obchádzala schválením s orgánmi plánu SORF — plánom operatívnych opatrení v prípade potreby niečo niekde nájsť)
Okrem peňazí (nie tak, že by to boli priam nebeské sumy, ale predsa — milióny), SORF od mnohých vyžadoval aj ďalšie manipulácie so sieťou.
- SORF musí vidieť «šedé» adresy používateľov pred nat-transláciou
- SORF má obmedzený počet sieťových rozhraní.
Preto sme museli, medzi inými, významne zrekonštruovať časť jadra — len aby sme niekde na jednom mieste zhromaždili prevádzku používateľov k prístupovým serverom. Aby sme ich mohli pomocou niekoľkých liniek zrkadliť do SORF.
Inými slovami, veľmi zjednodušene, bolo (vľavo) vs stalo sa (vpravo):
Teraz od väčšiny poskytovateľov sa vyžaduje implementácia aj SORF-3 — ktorý zahŕňa aj logovanie nat-translácií.
Na tieto účely sme do schémy vyššie museli pridať aj samostatné zariadenie pre NAT (presne to, o čom sa hovorí v prvej časti). A to pridať v určitom poradí: keďže SORF musí «vidieť» prevádzku pred transláciou adries — prevádzka musí ísť prísne nasledujúcim spôsobom: používatelia -> prepínanie, jadro -> prístupové servery -> SORF -> NAT -> prepínanie, jadro -> internet. Na to sme museli, doslova, «otočiť» toky prevádzky na druhú stranu zaživa, čo bolo tiež dosť zložité.
Sumarizujúc: za desať rokov sa schéma jadra priemerného poskytovateľa zložila mnohonásobne, a počet dodatočných bodov zlyhania (či už vo forme zariadenia, alebo vo forme jednotných prepínacích liniek) — sa významne zvýšil. Samotná požiadavka «vidieť všetko» predpokladá zúženie tohto «všetkého» do jedného bodu.
Myslím, že to môžeme celkom priestranne extrapolovať na súčasné iniciatívy v oblasti suverenizácie ruského internetu, jeho ochrany, stabilizácie a zlepšovania 🙂
A ešte pred nami je Jarovaja.
Zdroj: habr.com
