Potaknuo me na ovaj post .
Citiram ga ovdje:
danas u 18:53
Danas sam bio zadovoljan ponuđačem. Zajedno s ažuriranjem sustava za blokiranje stranica zabranjen mu je mailer mail.ru Od jutra zovem tehničku podršku, ali ne mogu ništa. Provajder je mali, a navodno ga blokiraju provajderi višeg ranga. Primijetio sam i usporavanje otvaranja svih stranica, možda su instalirali kakav krivi DLP? Prije nije bilo problema s pristupom. Uništavanje Runeta se događa pred mojim očima...
Činjenica je da smo mi izgleda taj isti provajder :)
I doista, Gotovo sam pogodio uzrok problema s mail.ru (iako smo dugo odbijali vjerovati u tako nešto).
Ono što slijedi bit će podijeljeno u dva dijela:
- razloge naših trenutnih problema s mail.ru i uzbudljivu potragu da ih pronađemo
- postojanje ISP-a u današnjoj stvarnosti, stabilnost suverenog RuNeta.
Problemi s pristupačnošću s mail.ru
Oh, to je prilično duga priča.
Činjenica je da smo za provedbu zahtjeva države (više detalja u drugom dijelu) kupili, konfigurirali i instalirali određenu opremu - kako za filtriranje zabranjenih resursa, tako i za implementaciju pretplatnika.
Prije nekog vremena konačno smo obnovili jezgru mreže na način da sav pretplatnički promet prolazi kroz ovu opremu strogo u pravom smjeru.
Prije nekoliko dana uključili smo zabranjeno filtriranje na njemu (ostavljajući stari sustav da radi) - činilo se da je sve u redu.
Zatim su postupno počeli omogućavati NAT na ovoj opremi za različite dijelove pretplatnika. Naizgled se također č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: negdje nešto ponekad, povremeno šalje kao odgovor na zahtjeve isključivo za mreže mail.ru. Štoviše, šalje neispravno generiran (bez ACK-a), očito umjetni TCP RST. Izgledalo je otprilike ovako:
Naravno, prve misli bile su o novoj opremi: užasan DPI, nema povjerenja u njega, nikad ne znate što može učiniti - uostalom, TCP RST je prilično uobičajena stvar među alatima za blokiranje.
Pretpostavka Također smo iznijeli ideju da netko "nadređeni" filtrira, ali smo je odmah odbacili.
Prvo, imamo dovoljno zdrave uplinkove da se ne moramo ovako mučiti :)
Drugo, povezani smo s nekoliko njih u Moskvi, a promet na mail.ru ide preko njih - i nemaju niti odgovornosti niti bilo kojeg drugog motiva filtrirati promet.
Sljedeća polovica dana bila je potrošena na ono što se inače zove šamanizam - zajedno s prodavačem opreme, na čemu im zahvaljujemo, nisu odustali :)
- filtriranje je bilo potpuno onemogućeno
- NAT je onemogućen korištenjem nove sheme
- testno računalo stavljeno je u zasebno izolirano spremište
- IP adresa je promijenjena
U poslijepodnevnim satima dodijeljen je virtualni stroj koji se spajao na mrežu prema shemi običnog korisnika, a predstavnicima dobavljača omogućen je pristup njemu i opremi. Šamanizam se nastavio :)
Na kraju je predstavnik dobavljača samouvjereno izjavio da hardver nema apsolutno nikakve veze s tim: prvi dolaze s nekog višeg mjesta.
PrimijetitiU ovom trenutku netko može reći: ali je li bilo puno lakše uzeti deponij ne s testnog računala, već s autoceste iznad DPI-ja?
Ne, nažalost, uzimanje dumpa (pa čak i samo zrcaljenje) 40+gbps nije nimalo trivijalno.
Nakon toga, navečer, nije preostalo ništa drugo nego vratiti se na pretpostavku čudne filtracije negdje gore.
Pogledao sam kroz koji IX sada prolazi promet prema MRG mrežama i jednostavno sam otkazao bgp sesije prema njemu. I – gle čuda! - sve se odmah vratilo u normalu 🙁
S jedne strane šteta što je cijeli dan tražen problem, iako je riješen u pet minuta.
S druge strane:
— u mom sjećanju ovo je stvar bez presedana. Kao što sam već gore napisao - IX stvarno nema smisla filtrirati tranzitni promet. Obično imaju stotine gigabita/terabita u sekundi. Sve do nedavno nisam mogao ozbiljno zamisliti ovako nešto.
— nevjerojatno sretan splet okolnosti: novi složeni hardver kojemu se ne vjeruje osobito i od kojeg nije jasno što se može očekivati — skrojen posebno za blokiranje resursa, uključujući TCP RST-ove
NOC ove internetske razmjene trenutno traži problem. Prema njima (a ja im vjerujem), oni nemaju nikakav posebno postavljen sustav filtriranja. Ali, hvala nebesima, daljnja potraga više nije naš problem :)
Ovo je bio mali pokušaj da se opravdam, molim za razumijevanje i oprost :)
P.S.: Namjerno ne imenujem proizvođača DPI/NAT ili IX (zapravo, nemam čak ni posebnih pritužbi na njih, glavna stvar je razumjeti što je to bilo)
Današnja (kao i jučerašnja i prekjučerašnja) stvarnost iz ugla internet provajdera
Posljednje tjedne proveo sam značajno obnavljajući jezgru mreže, izvodeći hrpu manipulacija "za profit", s rizikom značajnog utjecaja na promet uživo korisnika. S obzirom na ciljeve, rezultate i posljedice svega toga, moralno je sve to dosta teško. Posebno - još jednom slušajući lijepe govore o zaštiti stabilnosti Runeta, suvereniteta itd. i tako dalje.
U ovom odjeljku pokušat ću opisati "evoluciju" mrežne jezgre tipičnog ISP-a u posljednjih deset godina.
Prije deset godina.
U tim blagoslovljenim vremenima jezgra mreže pružatelja usluga mogla je biti jednostavna i pouzdana poput prometne gužve:
Na ovoj vrlo, vrlo pojednostavljenoj slici nema trunkova, prstenova, ip/mpls usmjeravanja.
Njegova bit je da je korisnički promet na kraju došao do prebacivanja razine jezgre - odakle je otišao do , odakle se, u pravilu, vraća na ključnu komutaciju, a zatim "na izlaz" - kroz jedan ili više graničnih pristupnika na Internet.
Takvu shemu je vrlo, vrlo lako rezervirati i na L3 (dinamičko usmjeravanje) i na L2 (MPLS).
Možete instalirati N+1 od bilo čega: pristupnih poslužitelja, preklopnika, granica - i na ovaj ili onaj način rezervirati ih za automatski failover.
Nakon nekoliko godina Svima u Rusiji postalo je jasno da se ovako više ne može živjeti: hitno je potrebno zaštititi djecu od pogubnog utjecaja interneta.
Bilo je hitno potrebno pronaći načine za filtriranje korisničkog prometa.
Tu postoje različiti pristupi.
U ne baš dobrom slučaju, nešto se stavlja “u procjep”: između korisničkog prometa i interneta. Promet koji prolazi kroz to "nešto" se analizira i, na primjer, lažni paket s preusmjeravanjem šalje se prema pretplatniku.
U nešto boljem slučaju - ako to dopušta količina prometa - možete napraviti mali trik sa svojim ušima: poslati na filtriranje samo promet koji potječ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).
Svojedobno sam za te potrebe napisao jednostavan - iako se ne usuđujem da ga tako nazovem. Vrlo je jednostavan i ne baš produktivan - međutim, omogućio je nama i desecima (ako ne i stotinama) drugih pružatelja usluga da ne izdvojimo odmah milijune na industrijske DPI sustave, ali je dao nekoliko dodatnih godina vremena.
Usput, o tadašnjem i sadašnjem DPIUsput, mnogi koji su kupili DPI sustave koji su tada bili dostupni na tržištu već su ih bacili. Pa, nisu dizajnirani za ovo: stotine tisuća adresa, deseci tisuća URL-ova.
A u isto vrijeme domaći proizvođači su se vrlo snažno uzdigli na ovo tržište. Ne govorim o hardverskoj komponenti - ovdje je svima sve jasno, ali softver - ono glavno što DPI ima - možda je danas, ako ne i najnapredniji na svijetu, onda svakako a) razvija se velikim koracima, i b) po cijeni proizvoda u kutiji - jednostavno neusporedivo sa stranim konkurentima.
Htjela bih biti ponosna, ali pomalo tužna =)
Sada je sve izgledalo ovako:
Za još par godina svi su već imali revizore; U registru je bilo sve više izvora. Za neku stariju opremu (primjerice, Cisco 7600), shema “side-filtering” jednostavno je postala neprimjenjiva: broj ruta na 76 platformi ograničen je na otprilike devet stotina tisuća, dok se broj samo IPv4 ruta danas približava 800 tisuću. A ako je i ipv6 ... I također ... koliko ima? 900000 pojedinačnih adresa u zabrani RKN? =)
Netko je prešao na shemu sa zrcaljenjem cjelokupnog backbone prometa na server za filtriranje, koji bi trebao analizirati cijeli tok i, ako se nađe nešto loše, poslati RST u oba smjera (pošiljatelj i primatelj).
Međutim, što je veći promet, to je ova shema manje primjenjiva. Ako dođe do najmanjeg kašnjenja u obradi, zrcaljeni će promet jednostavno proletjeti nezapaženo, a pružatelj će dobiti fino izvješće.
Sve je više pružatelja usluga prisiljeno instalirati DPI sustave različitih stupnjeva pouzdanosti na autocestama.
Prije godinu-dvije prema glasinama, gotovo svi FSB počeli su zahtijevati stvarnu instalaciju opreme (prije je većina pružatelja upravljala uz odobrenje vlasti SORM plan — plan operativnih mjera u slučaju potrebe da se negdje nešto pronađe)
Osim novca (ne baš pretjeranog, ali ipak milijunskog), SORM-u je bilo potrebno još mnogo manipulacija s mrežom.
- SORM treba vidjeti "sive" korisničke adrese prije nat prijevoda
- SORM ima ograničen broj mrežnih sučelja
Stoga smo posebno morali uvelike obnoviti dio kernela - jednostavno kako bismo skupili korisnički promet prema pristupnim poslužiteljima negdje na jednom mjestu. Kako bi to preslikali u SORM s nekoliko poveznica.
Odnosno, vrlo pojednostavljeno, bilo je (lijevo) vs postalo (desno):
Sada Većina pružatelja također zahtijeva implementaciju SORM-3 - koji uključuje, između ostalog, bilježenje nat emitiranja.
Za te potrebe, također smo morali dodati zasebnu opremu za NAT na gornji dijagram (upravo ono o čemu se govori u prvom dijelu). Štoviše, dodajte određenim redoslijedom: budući da SORM mora “vidjeti” promet prije prevođenja adresa, promet mora ići striktno kako slijedi: korisnici -> prebacivanje, kernel -> pristupni poslužitelji -> SORM -> NAT -> prebacivanje, kernel - > Internet. Da bismo to učinili, morali smo doslovno "okrenuti" prometne tokove u drugom smjeru radi zarade, što je također bilo prilično teško.
Ukratko: tijekom proteklih deset godina, osnovni dizajn prosječnog pružatelja usluga postao je višestruko složeniji, a dodatne točke kvara (i u obliku opreme i u obliku pojedinačnih komutacijskih linija) značajno su se povećale. Zapravo, sam zahtjev da se “sve vidi” podrazumijeva svođenje tog “svega” na jednu točku.
Mislim da se ovo može prilično transparentno ekstrapolirati na trenutne inicijative za suverenizaciju Runeta, njegovu zaštitu, stabilizaciju i poboljšanje :)
A Yarovaya je još uvijek ispred.
Izvor: www.habr.com