To me je spodbudilo k temu prispevku .
Tukaj ga navajam:
danes ob 18:53
Danes me je razveselil ponudnik. Skupaj z nadgradnjo sistema za blokiranje spletnih strani je njegov filtr zmanjšal dostop do poštnega nabiralnika mail.ru. Od jutra pognem tehnično podporo, ne morejo ničesar storiti. Ponudnik je majhen, očitno blokirajo višje ponudnike. Opazil sem tudi upočasnitev odpiranja vseh spletnih strani, morda so dodali kakšen čuden DLP? Prej ni bilo nobenih težav z dostopom. Uničenje Runeta se odvija pred mojimi očmi…
Dejansko smo mi tisti ponudnik 🙁
In res je, skoraj sem uganil vzrok težav z mail.ru (čeprav smo dolgo nočili verjeti v to).
Daleč bo razdeljeno na dva dela:
- vzroki naših današnjih težav z mail.ru in zanimiv iskalni izlet po njihovi rešitvi
- obstoja ISP v današnjih razmerah, stabilnost suverenega Runeta.
Težave z dostopnostjo mail.ru
Ah, to je kar dolga zgodba.
Dejstvo je, da smo v skladu z zahtevami države (podrobnosti v drugem delu) kupili, nastavili in namestili določeno opremo — tako za filtriranje prepovedanih virov kot za izvajanje uporabnikov.
Pred časom smo končno prestrukturirali jedro omrežja tako, da je ves promet uporabnikov potekal preko te opreme v ustrezni smeri.
Pred nekaj dnevi smo na njej vključili filtriranje prepovedanih virov (hkrati pa ohranili delovanje starega sistema) — na videz je vse potekalo dobro.
Nato smo postopoma začeli vključevati NAT za različne dele uporabnikov na tem aparatu. Videz — tudi vse se je zdelo, da gre dobro.
Toda danes, ko smo vključili NAT za naslednji del uporabnikov — smo se že zjutraj soočili z znatnim številom pritožb o nedostopnosti ali delni dostopnosti in drugih virov Mail Ru Group.
Začeli smo preverjati: nekaj nekje včasih, redko pošilja v odgovor na zahteve zgolj do omrežij mail.ru. Poleg tega — pošilja nepravilno generiran (brez ACK), očitno umetni TCP RST. Približno tako je izgledalo:
Seveda, prve misli so bile o novi opremi: strašen DPI, brez zaupanja vanj, kdo ve, kaj lahko stori — saj je TCP RST kar razširjena stvar med sredstvi za blokiranje.
Domneva da nekdo 'z višje ravni' filtrira, smo prav tako predložili — a to smo takoj zavrgli.
Prvič, imamo dovolj smiselne uplinke, da s tem nismo obremenjeni 🙂
Drugič, povezani smo z več v Moskvi, in promet do mail.ru poteka prav skozi njih — in oni nimajo nobenih obveznosti ali kakršnegakoli drugega motiva za filtriranje prometa.
Naslednja polovica dneva je bila namenjena tistemu, kar običajno imenujejo šamanstvo — skupaj z dobaviteljem opreme, za kar se jim zahvaljujem, nismo obupali 🙂
- popolnoma je bila izklopljena filtracija
- je bil izklopljen NAT po novi shemi
- testni računalnik je bil prenesen v ločen izoliran bazen
- spremenila se je IP-naslovitev
V drugi polovici dneva je bila dodeljena virtualka, ki je imela dostop do omrežja po shemi običajnega uporabnika, in dostop do nje in do opreme je bil podeljen predstavnikom dobavitelja. Šamanstvo se je nadaljevalo 🙂
Na koncu je predstavnik dobavitelja samozavestno izjavil, da oprema zagotovo ni kriva: rst prihajajo od nekje višje.
NapomenaNa tem mestu bi nekdo lahko trdil: toda veliko lažje bi bilo narediti dump ne s testnega računalnika, temveč z magistrale nad DPI-jem?
Ne, na žalost, narediti dump (in celo samo na mirror) 40+ gbps — sploh ni enostavno.
Potem, že zvečer — ni bilo drugega, kot da se vrne k domnevi o nenavadni filtraciji nekje višje.
Pogledal sem, čez kateri IX trenutno poteka promet do omrežij MRG in preprosto ugasnil bgp-seje. In — oh čudež! — vse se je takoj normaliziralo 🙁
Po eni strani — zelo žal, da je cel dan bil porabljen za iskanje težave, čeprav se je rešila v petih minutah.
Po drugi strani:
— v spominu imam to brezprecedenčno zadevo. Kot sem že napisal zgoraj — IX-om resnično ni nobenega smisla filtrirati tranzitnega prometa. Običajno ga imajo na stotine gigabitov / terabitov na sekundo. Preprosto si do zadnjega nisem mogel resno predstavljati takšnega.
— neverjetno ugodno naključje: nova zapletena oprema, ki ji ni posebno zaupati in od katere ni jasno, kaj pričakovati — zasnovana prav za blokiranje virov, vključno s TCP RST-ji.
Trenutno NOC ove internet razmjene traži problem. Prema njihovim tvrdnjama (a ja im vjerujem), nemaju nikakvog posebno postavljenog sustava filtracije. No, hvala nebu, daljnji zadatak — više nije naš problem 🙂
To je bio mali pokušaj opravdanja, molimo vas da razumijete i oprostite 🙂
P.S.: namjerno ne spominjem niti proizvođača DPI/NAT, niti IX (inače, uopće nemam posebnih pritužbi na njih, bitno je razumjeti što se dogodilo)
Današnja (a također jučerašnja i pretprošla) stvarnost s gledišta davatelja internetskih usluga
Zadnjih nekoliko tjedana proveo sam, značajno prestrukturirajući jezgru mreže, radeći hrpu manipulacija „u živo”, s rizikom da značajno utječem na stvarni korisnički promet. Uzimajući u obzir ciljeve, rezultate i posljedice svega ovoga — moralno je sve to prilično teško. Osobito — opet slušajući plemenite govore o zaštiti stabilnosti ruskog interneta, suverenitetu itd.
U ovom odjeljku pokušat ću ispričati "evoluciju" jezgre mreže tipičnog davatelja internetskih usluga u posljednjem desetljeću.
Desetak godina unazad.
U tim blagoslovljenim vremenima jezgra davateljske mreže mogla je biti jednostavna i pouzdana, poput čepa:
Na ovoj vrlo pojednostavljenoj slici nedostaju magistrale, prstenovi, ip/mpls usmjeravanje.
Njena suština je da je promet korisnika na kraju dolazio u prebacivanje razine jezgre — odakle je išao u , odakle, obično — natrag u prebacivanje jezgre, i dalje "na izlaz" — kroz jedan ili više border gateway-a u internet.
Slična shema vrlo lako se rezervira kako na L3 (dinamičko usmjeravanje), tako i na L2 (MPLS).
Može se postaviti N+1 čega god: pristupnih servera, preklopnika, granica — i tako ili onako ih rezervirati za automatsku prebacivanje.
Nakon nekoliko godina svima u Rusiji postalo je jasno da se tako ne može nastaviti: potrebno je hitno zaštititi djecu od zla utjecaja mreže.
Pojavila se potreba za hitnim pronalaženjem načina za filtriranje korisničkog prometa.
Tu postoje različiti pristupi.
U manje dobrom slučaju — nešto se postavlja "u razrezu": između korisničkog prometa i interneta. Promet koji prolazi kroz to "nešto" podliježe analizi i, na primjer, šalje se lažni paket s preusmjeravanjem prema korisniku.
V nekoliko boljšem primeru — če obsegi prometa omogočajo — lahko naredimo majhen trik: filtrirati le odhodni promet uporabnikov le na tiste naslove, ki jih je treba filtrirati (za to lahko bodisi vzamemo IP-naslove iz registra, bodisi dodatno razrešimo obstoječe domene v registru).
Nekoč sem za te namene napisal preprost — čeprav se mi jezik ne obrača, da bi ga tako imenoval. Je zelo preprost in ne posebej zmogljiv — vendar je nam, kot tudi desetinam (če ne stotinam) drugih ponudnikov omogočil, da nismo takoj morali porabiti milijonov za industrijske DPI-sisteme, temveč smo dobili še nekaj dodatnih let časa.
Kar se tiče takratnih in današnjih DPIKar se tiče tega, mnogi, ki so kupili takrat na trgu obstoječe DPI-sisteme — so jih že vrgli stran. No, niso prilagojeni za to: stotine tisoč naslovov, deset tisoč URL-jev.
Hkrati pa je zelo naraslo število domačih proizvajalcev na tem trgu. Ne govorim o strojni opremi — to je jasno, ampak programska oprema — glavno, kar obstaja v DPI — je morda danes, če ne najnaprednejša na svetu, pa zagotovo a) se razvija s hitrimi koraki in b) glede cene paketa — preprosto neprimerljivo z zunanjimi konkurenti.
Rad bi se ponašal, ampak je malo žalostno =)
Zdaj je vse izgledalo tako:
Še čez dve leti so imeli vsi že revidente; virov v registru je bilo vedno več. Za nekatero staro opremo (na primer, cisco 7600) je postala shema s 'filtriranjem s strani' preprosto neuporabna: število poti na 76 platformah je omejeno na okoli devetsto tisoč, medtem ko se je število samo IPv4-poti danes že približalo 800 tisoč. In če dodamo še ipv6… In še… koliko tam? 900000 ločenih naslovov v prepovedi rkn? =)
Nekateri so prešli na shemo z зеркалированием celotnega magistralnega prometa na filtrirni strežnik, ki mora analizirati celoten tok in ob odkritju nečesa slabega poslati v obe smeri (pošiljatelju in prejemniku) RST.
Vendar pa je bolj kot je promet, manj je taka shema uporabna. Pri najmanjši zamudi pri obdelavi — ogledani promet preprosto neopazno preleti nikamor, ponudniku pa prijde protokol o kazni.
Vedno več ponudnikov je prisiljenih uvajati sisteme DPI različnih ravni zanesljivosti na glavnih komunikacijskih povezavah.
Pred enim do dvema letoma so po govoricah praktično od vseh obveščevalnih služb zahtevali dejansko namestitev opreme (prej je večina ponudnikov zadostovala z usklajevanjem z organi plana SORM – načrt operativnih ukrepov za primer, da bo potrebno kaj nekje najti)
Poleg denarja (ne točno astronomski zneski, a še vedno – milijoni) je SORM od mnogih zahteval dodatne manipulacije z omrežjem.
- SORMu je potrebno videti 'sive' naslove uporabnikov pred NAT-prevajanjem
- SORMo ima omejeno število omrežnih vmesnikov
Zato smo se, med drugim, morali zelo preurediti del jedra – preprosto zato, da smo lahko zbirali promet uporabnikov na dostopne strežnike. Da bi ta promet z več povezavami odražali v SORM.
Z drugimi besedami, poenostavljeno, je bilo (levo) v primerjavi s tem, kar je postalo (desno):
Zdaj večina ponudnikov zahteva, da se vključi tudi SORM-3 – ki med drugim vključuje tudi beleženje NAT-translacij.
Za te namene smo morali v zgoraj prikazano shemo dodati še posebno opremo za NAT (prav to, o čemer govorimo v prvem delu). In to dodati v določenem vrstnem redu: ker mora SORM 'videti' promet pred prevajanjem naslovov – promet mora iti strogo v naslednjem vrstnem redu: uporabniki -> preklapljanje, jedro -> dostopni strežniki -> SORM -> NAT -> preklapljanje, jedro -> internet. Zato smo morali dobesedno 'obrati' prometne tokove v drugo smer v živo, kar je bilo tudi precej zahtevno.
Skupaj: v desetih letih se je shema jedra povprečnega ponudnika močno zapletla, dodatnih točk odpovedi (tako v obliki opreme kot enotnih komunikacijskih linij) pa se je znatno povečalo. Samo zahteva 'videti vse' pomeni združevanje 'vsega' na enem mestu.
Zdi se mi, da je to možno povsem transparentno ekstrapolirati na trenutne pobude za suverenizacijo ruskega interneta, njegovo zaščito, stabilizacijo in izboljšanje 🙂
In pred nami je še Jarovaja.
Izvor: habr.com
