Podstaknuo me na ovaj post .
citiram ovde:
danas u 18:53
Danas sam bio zadovoljan provajderom. Uporedo sa ažuriranjem sistema za blokiranje sajtova zabranjen mu je mailer mail.ru Zovem tehničku podršku od jutra, ali ne mogu ništa. Provajder je mali, i očigledno ga blokiraju provajderi višeg ranga. Primetio sam i usporavanje otvaranja svih sajtova, mozda su instalirali nekakav krivo DLP? Ranije nije bilo problema sa pristupom. Uništenje Runeta se dešava pred mojim očima...
Činjenica je da izgleda da smo mi isti provajder :)
Zaista, Skoro sam pogodio uzrok problema sa mail.ru (iako smo dugo odbijali da verujemo u tako nešto).
Ono što slijedi bit će podijeljeno u dva dijela:
- razloge za naše trenutne probleme sa mail.ru i uzbudljivu potragu da ih pronađemo
- postojanje ISP-a u današnjoj stvarnosti, stabilnost suverenog Runeta.
Problemi sa pristupačnošću sa mail.ru
Oh, to je prilično duga priča.
Činjenica je da smo u cilju implementacije zahtjeva države (detaljnije u drugom dijelu) nabavili, konfigurirali i instalirali određenu opremu – kako za filtriranje zabranjenih resursa tako i za implementaciju pretplatnika.
Prije nekog vremena konačno smo obnovili jezgro mreže na način da je sav pretplatnički promet prolazio kroz ovu opremu striktno u pravom smjeru.
Prije nekoliko dana smo uključili zabranjeno filtriranje na njemu (dok stari sistem ne radi) - činilo se da je sve dobro prošlo.
Zatim su postepeno počeli da omogućavaju NAT na ovoj opremi za različite delove pretplatnika. Sudeći po izgledu, takođe se činilo da je sve dobro prošlo.
Ali danas, nakon što smo omogućili NAT na opremi za sljedeći dio pretplatnika, od samog jutra bili smo suočeni s pristojnim brojem pritužbi na nedostupnost ili djelomičnu dostupnost i drugi resursi Mail Ru grupe.
Počeli su provjeravati: nešto negdje ponekad, povremeno šalje kao odgovor na zahtjeve isključivo na mail.ru mreže. Štaviše, šalje pogrešno generisan (bez ACK), očigledno veštački TCP RST. Ovako je to izgledalo:
Naravno, prve misli bile su o novoj opremi: užasan DPI, nema povjerenja u njega, nikad se ne zna šta može - na kraju krajeva, TCP RST je prilično uobičajena stvar među alatima za blokiranje.
Pretpostavke Izneli smo i ideju da neko „nadređeni“ filtrira, ali smo je odmah odbacili.
Prvo, imamo dovoljno zdrave uplinkove da ne moramo ovako da patimo :)
Drugo, povezani smo sa nekoliko u Moskvi, a saobraćaj na mail.ru ide preko njih - a oni nemaju ni obaveze ni bilo kakav drugi motiv da filtriraju saobraćaj.
Sljedećih pola dana proveli smo u onom što se obično zove šamanizam - zajedno sa prodavcem opreme, na čemu im zahvaljujemo, nisu odustajali :)
- filtriranje je potpuno onemogućeno
- NAT je onemogućen upotrebom nove šeme
- test PC je stavljen u odvojeni izolovani bazen
- IP adresa je promijenjena
U popodnevnim satima je dodijeljena virtuelna mašina koja se povezivala na mrežu po šemi redovnog korisnika, a predstavnicima dobavljača je omogućen pristup njoj i opremi. Šamanizam se nastavio :)
Na kraju je predstavnik dobavljača samouvjereno izjavio da hardver nema apsolutno nikakve veze s tim: prvi dolaze odnekud više.
primjedbaU ovom trenutku neko može reći: ali bilo je mnogo lakše uzeti deponiju ne sa testnog računara, već sa autoputa iznad DPI?
Ne, nažalost, uzimanje dump-a (pa čak i samo preslikavanje) 40+gbps nije nimalo trivijalno.
Nakon ovoga, uveče, nije preostalo ništa drugo nego da se vratim na pretpostavku o čudnoj filtraciji negdje iznad.
Pogledao sam kroz koji IX saobraćaj ka MRG mrežama sada prolazi i jednostavno sam otkazao bgp sesije za njega. I - eto! - sve se odmah vratilo u normalu 🙁
S jedne strane, šteta što je cijeli dan potrošen na traženje problema, iako je riješen za pet minuta.
S druge strane:
— u mom sećanju ovo je stvar bez presedana. Kao što sam već napisao - IX stvarno nema smisla filtrirati tranzitni saobraćaj. Obično imaju stotine gigabita/terabita u sekundi. Jednostavno nisam mogao ozbiljno da zamislim ovako nešto do nedavno.
— nevjerovatno srećan stjecaj okolnosti: novi složeni hardver kojem se ne vjeruje i od kojeg nije jasno šta se može očekivati — skrojen posebno za blokiranje resursa, uključujući TCP RST-ove
NOC ove internet razmjene trenutno traži problem. Po njima (a ja im vjerujem) nemaju nikakav posebno razvijen sistem filtracije. Ali, hvala nebesima, dalja potraga više nije naš problem :)
Ovo je bio mali pokušaj da se opravdam, molim vas da razumete i oprostite :)
PS: Namjerno ne imenujem proizvođača DPI/NAT ili IX (u stvari, nemam čak ni nekih posebnih zamjerki na njih, glavno je razumjeti o čemu se radi)
Današnja (kao i jučerašnja i prekjučerašnja) stvarnost sa stanovišta internet provajdera
Proveo sam posljednje sedmice značajno obnavljajući jezgro mreže, izvodeći gomilu manipulacija “za profit”, uz rizik da značajno utječem na promet korisnika uživo. S obzirom na ciljeve, rezultate i posljedice svega ovoga, moralno je sve to prilično teško. Posebno - još jednom slušajući lijepe govore o zaštiti stabilnosti Runeta, suvereniteta itd. i tako dalje.
U ovom odeljku pokušaću da opišem „evoluciju“ mrežnog jezgra tipičnog ISP-a u proteklih deset godina.
Prije deset godina.
U tim blagoslovenim vremenima, srž mreže provajdera mogla bi biti jednostavna i pouzdana poput saobraćajne gužve:
Na ovoj vrlo, vrlo pojednostavljenoj slici, nema trankova, prstenova, ip/mpls rutiranja.
Njegova suština je da je korisnički saobraćaj na kraju došao do prebacivanja nivoa kernela - odakle je otišao , odakle se, u pravilu, vraćaju na prebacivanje jezgre, a zatim "napolje" - kroz jedan ili više graničnih kapija na Internet.
Takvu šemu je vrlo, vrlo lako rezervirati i na L3 (dinamičko rutiranje) i na L2 (MPLS).
Možete instalirati N+1 bilo čega: pristupni serveri, prekidači, granice - i na ovaj ili onaj način ih rezervirati za automatsko prebacivanje.
Nakon nekoliko godina Svima u Rusiji postalo je jasno da je nemoguće više ovako živjeti: hitno je zaštititi djecu od pogubnog utjecaja interneta.
Postojala je hitna potreba za pronalaženjem načina za filtriranje korisničkog prometa.
Ovdje postoje različiti pristupi.
U ne baš dobrom slučaju, nešto se stavlja „u jaz“: između korisničkog prometa i interneta. Analizira se promet koji prolazi kroz ovo „nešto“ i, na primjer, lažni paket sa preusmjeravanjem se šalje prema pretplatniku.
U malo boljem slučaju - ako obim prometa dozvoljava - možete napraviti mali trik sa svojim ušima: poslati na filtriranje samo promet koji potiče od korisnika samo na one adrese koje je potrebno filtrirati (da biste to učinili, možete ili uzeti IP adrese tamo navedene iz registra, ili dodatno riješiti postojeće domene u registru).
Svojevremeno sam za te svrhe napisao jednostavnu - mada se ni ne usuđujem da ga tako nazovem. Vrlo je jednostavan i ne baš produktivan – međutim, omogućio je nama i desetinama (ako ne i stotinama) drugih provajdera da ne potrošimo odmah milione na industrijske DPI sisteme, već je dalo nekoliko dodatnih godina vremena.
Inače, o tadašnjem i sadašnjem DPIInače, mnogi koji su kupili DPI sisteme dostupne na tržištu u to vrijeme već su ih bacili. Pa, nisu dizajnirani za ovo: stotine hiljada adresa, desetine hiljada URL-ova.
A u isto vrijeme, domaći proizvođači su se vrlo snažno popeli na ovo tržište. Ne govorim o hardverskoj komponenti - ovdje je sve jasno, ali softver - ono glavno što DPI ima - je možda danas, ako ne najnapredniji na svijetu, onda svakako a) razvija se skokovima i granicama, i b) po cijeni proizvoda u kutiji - jednostavno neuporedivu sa stranim konkurentima.
Voleo bih da budem ponosan, ali malo tuzan =)
Sada je sve izgledalo ovako:
Za par godina svi su već imali revizore; U registru je bilo sve više resursa. Za neku stariju opremu (na primjer, Cisco 7600), shema "bočnog filtriranja" jednostavno je postala neprimjenjiva: broj ruta na 76 platformi ograničen je na otprilike devetsto hiljada, dok se broj samo IPv4 ruta danas približava 800 hiljada. A ako je i ipv6... I takođe... koliko ima? 900000 pojedinačnih adresa u zabrani RKN? =)
Neko je prešao na šemu sa preslikavanjem cjelokupnog backbone prometa na server za filtriranje, koji bi trebao analizirati cijeli tok i, ako se pronađe nešto loše, poslati RST u oba smjera (pošiljalac i primalac).
Međutim, što je veći promet, to je ova šema manje primjenjiva. Ako dođe do najmanjeg kašnjenja u obradi, preslikani promet će jednostavno proleteti neprimjetno, a provajder će dobiti novčanu prijavu.
Sve više i više provajdera je prinuđeno da instalira DPI sisteme različitog stepena pouzdanosti na autoputevima.
Prije godinu ili dvije prema glasinama, skoro ceo FSB je počeo da zahteva stvarnu ugradnju opreme (ranije je većina provajdera upravljala uz odobrenje vlasti SORM plan - plan operativnih mjera u slučaju potrebe da se nešto nađe negdje)
Osim novca (ne baš prevelikog, ali ipak milionskog), SORM je zahtijevao još mnogo manipulacija mrežom.
- SORM mora vidjeti “sive” korisničke adrese prije nat prijevoda
- SORM ima ograničen broj mrežnih interfejsa
Stoga smo, posebno, morali u velikoj mjeri rekonstruirati dio kernela - jednostavno da bismo prikupili korisnički promet do pristupnih servera negdje na jednom mjestu. Da bi se preslikao u SORM sa nekoliko linkova.
To jest, vrlo pojednostavljeno, bilo je (lijevo) nasuprot postalo (desno):
Sada Većina provajdera takođe zahteva implementaciju SORM-3 - što uključuje, između ostalog, evidentiranje nat emitovanja.
U ove svrhe, morali smo dodati i zasebnu opremu za NAT na dijagram iznad (upravo ono o čemu se govori u prvom dijelu). Štaviše, dodajte određenim redoslijedom: pošto SORM mora “vidjeti” promet prije prevođenja adresa, promet mora ići striktno na sljedeći način: korisnici -> prebacivanje, kernel -> pristupni serveri -> SORM -> NAT -> prebacivanje, kernel - > Internet. Da bismo to uradili, morali smo bukvalno da „okrenemo“ saobraćajne tokove u drugom pravcu radi zarade, što je takođe bilo prilično teško.
Ukratko: u proteklih deset godina, dizajn jezgra prosječnog provajdera postao je višestruko složen, a dodatne tačke kvara (kako u obliku opreme tako i u obliku pojedinačnih uklopnih linija) su se značajno povećale. Zapravo, sam zahtjev da se “vidi sve” podrazumijeva svođenje ovog “svega” na jednu tačku.
Mislim da se ovo može prilično transparentno ekstrapolirati na trenutne inicijative da se Runet suverenizuje, zaštiti, stabilizira i poboljša :)
A Yarovaya je još uvijek ispred.
izvor: www.habr.com