Poticaj za ovaj post .
Donosim ga ovdje:
danas u 18:53
Danas me obradovao davatelj usluga. Uz ažuriranje sustava blokiranja web stranica, pod banom se našao e-mail servis mail.ru. Ujutro zovem tehničku podršku, ništa ne mogu učiniti. Davatelj je mali i očito ih blokiraju nadležne kompanije. Također sam primijetio usporavanje otvaranja svih web stranica, možda su postavili neki loš DLP? Prije nije bilo nikakvih problema s pristupom. Uništavanje RuNet-a odvija se pred mojim očima…
Ispostavlja se da smo mi taj davatelj 🙁
I doista, skoro si pogodio uzrok problema s mail.ru (iako smo dugo odbijali povjerovati u to).
Daljnji dio će biti podijeljen na dva dijela:
- uzroci naših današnjih problema s mail.ru i zanimljiva potraga za njihovim pronalaženjem
- postojanje davatelja usluga u današnjim stvarnostima, stabilnost suverenog RuNet-a.
Problemi s dostupnošću mail.ru
Oh, to je prilično duga priča.
Naime, kako bismo ispunili zahtjeve države (detaljnije u drugom dijelu), nabavili smo, postavili i instalirali određenu opremu — kako za filtriranje zabranjenih resursa, tako i za realizaciju pretplatnika.
Prije nekoliko vremena konačno smo preuredili jezgru mreže tako da sav promet pretplatnika prolazi kroz tu opremu isključivo u pravom smjeru.
Prije nekoliko dana aktivirali smo filtriranje zabranjenog sadržaja (uz istovremeno zadržavanje stare sustava) — na izgled je sve prošlo dobro.
Kasnije — postupno smo počeli aktivirati NAT za različite dijelove pretplatnika na toj opremi. Na izgled — i tu je sve, činilo se, bilo u redu.
Ali danas, kada smo aktivirali NAT na opremi za još jedan dio pretplatnika — od samog jutra suočili smo se s velikim brojem pritužbi o nedostupnosti ili djelomičnoj dostupnosti i drugih resursa Mail Ru Grupa.
Počeli smo provjeravati: nešto negdje ponekad, rijetko šalje kao odgovor na zahtjeve isključivo za mreže mail.ru. Štoviše — šalje pogrešno generirani (bez ACK), očito umjetni TCP RST. Otprilike ovako je to izgledalo:
Naravno, prve misli bile su o novoj opremi: zastrašujući DPI, nikakvo povjerenje u njega, tko zna što sve može učiniti — jer TCP RST je dosta rasprostranjena pojava među alatima za blokiranje.
Pretpostavka da netko 'viši' filtrira, također je iznesena — ali smo je odmah odbacili.
Prvo, imamo dovoljno razumnu propusnost da ne patimo od takvih stvari 🙂
Drugo, povezani smo s nekoliko u Moskvi, i promet do mail.ru ide isključivo kroz njih — a oni nemaju nikakve obaveze niti motivaciju za filtriranje prometa.
Sljedeća polovica dana potrošena je na ono što obično nazivamo šamanizmom — zajedno s dobavljačem opreme, za što im hvala, nisu nas napustili 🙂
- potpuno je isključena filtracija
- NAT je isključen po novoj shemi
- testni PC je prebačen u posebni izolirani sklop
- promijenjena je IP-adresacija
U drugoj polovici dana dodijeljen je virtualni poslužitelj, koji se povezao na mrežu prema shemi običnog korisnika, i njemu i opremi je omogućen pristup predstavnicima dobavljača. Šamanizam se nastavio 🙂
Na kraju je predstavnik dobavljača sigurno izjavio da uređaj ni na koji način nije uzrok: rst-ovi dolaze negdje iznad.
NapomenaNa ovom mjestu bi netko mogao reći: ali bilo bi puno lakše snimiti dump ne s testnog PC-a, već iz čvora iznad DPI-a?
Nažalost, snimanje dumpa (čak i samo odmirroriranje) 40+gbps — nije nimalo trivijalno.
Nakon toga, već navečer — nije ostalo ništa drugo nego se vratiti pretpostavci o čudnom filtriranju negdje iznad.
Pogledao sam kroz koji IX sada prolazi promet do mreža MRG i jednostavno sam ugasio bgp sesije prema njemu. I — o čudo! — sve se odmah normaliziralo 🙁
S jedne strane — jako je žao što je cijeli dan potrošen na pronalaženje problema, iako se on rješava za pet minuta.
S druge strane:
— u mom sjećanju, ovo je bez presedana. Kao što sam već spomenuo — IX-ima zaista nema nikakvog smisla filtrirati tranzitni promet. Obično imaju stotine gigabita / terabita u sekundi. Jednostavno nisam mogao ozbiljno pretpostaviti nešto tako do posljednjeg trenutka.
— nevjerojatna sreća: nova složena oprema, kojoj se ne može previše vjerovati i od koje nije jasno što se može očekivati — prilagođena upravo za blokiranje resursa, uključujući TCP RST-ove.
Trenutno NOC ovog internetskog izmjenjivača istražuje problem. Prema njihovim tvrdnjama (i vjerujem im) nemaju specijalno postavljeni sustav filtracije. No, zahvaljujući nebu, sljedeća potjera 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 (u principu, nemam im nikakvih posebnih zamjerki, važno je samo razumjeti što se dogodilo)
Današnja (kao i jučerašnja i prekjučerašnja) stvarnost s gledišta internet provajdera
Posljednje tjedne proveo sam značajno prestrukturirajući jezgru mreže, izvodeći hrpu manipulacija „uživo“, s rizikom da značajno utječem na aktivni korisnički promet. Uzimajući u obzir ciljeve, rezultate i posljedice svega ovoga — moralno je to prilično teško. Osobito — ponovno slušajući plemenite govore o održavanju stabilnosti Runeta, suverenitetu, itd.
U ovom dijelu pokušat ću ispričati „evoluciju“ jezgre mreže tipičnog internet provajdera u posljednjih deset godina.
Deset godina unazad.
U tim blagoslovljenim vremenima jezgra provajderske mreže mogla je biti jednostavna i pouzdana poput čepa:
Na ovoj vrlo, vrlo pojednostavljenoj slici nedostaju magistrale, prstenovi, ip/mpls usmjeravanje.
Njena suština je da je korisnički promet na kraju dolazio u jezgri - odakle je išao u , odakle se obično vraćao nazad u jezgru, i dalje „na izlaz“ - kroz jedan ili više border gateway-a u internet.
Slična shema vrlo, vrlo lako se rezervira kako na L3 (dinamičko usmjeravanje), tako i na L2 (MPLS).
Može se postaviti N+1 bilo čega: pristupnih servera, prekidača, border-a— i tako ili onako ih rezervirati za automatski failover.
Nekoliko godina kasnije svima u Rusiji postalo je jasno da ne možemo dalje tako živjeti: potrebno je hitno zaštititi djecu od štetnog utjecaja mreže.
Pojavila se potreba za hitnim pronalaženjem načina za filtriranje korisničkog prometa.
Tu postoji različitih pristupa.
U ne baš dobrom slučaju - nešto se postavlja „u presjeku“: između korisničkog prometa i interneta. Promet koji prolazi kroz to „nešto“ podvrgava se analizi i, primjerice, korisniku se šalje lažni paket s preusmjeravanjem.
U nešto boljem slučaju — ako obujmi prometa to omogućuju — može se napraviti mala varijanta: filtrirati samo odlazni promet korisnika samo na one adrese koje je potrebno filtrirati (za to se mogu koristiti IP adrese navedene u registru ili dodatno rezolvirati domene koje su u registru).
Nekada sam za te svrhe napisao jednostavan — iako mi se čak i jezik ne okreće da ga tako nazovem. Vrlo je jednostavan i nije jako učinkovit — no i nama, kao i desecima (ako ne i stotinama) drugih pružatelja usluga, omogućio je da ne uložimo odmah milijune u industrijske DPI sustave, nego je dao nekoliko dodatnih godina.
Usput, o tadašnjim i današnjim DPITreba reći da su mnogi koji su kupili dostupne DPI sustave na tržištu u to vrijeme — već ih bacili. Nisu prilagođeni za takvo nešto: stotine tisuća adresa, deseci tisuća URL-ova.
I u isto vrijeme, domaći proizvođači su za taj tržišni segment jako napredovali. Ne govorim o hardverskoj komponenti — tu je svima sve jasno, no softver — glavno što postoji u DPI — danas možda nije najnapredniji na svijetu, ali sigurno a) napreduje velikim koracima, i b) cijena kutijica — jednostavno nije usporediva s inozemnim konkurentima.
Želio bih se ponositi, ali je malo tužno =)
Sada je sve izgledalo ovako:
Još za par godina svi su već imali revizore; resursi u registru su postajali sve brojniji. Za određenu staru opremu (primjerice, Cisco 7600) postao je jednostavno neprimjenjiv plan s "filtracijom sa strane": broj ruta na 76 platformama ograničen je na otprilike devetsto tisuća, dok se broj samo IPv4 ruta danas već približava 800 tisuća. A ako uzmemo i IPv6… A još i… koliko ih već? 900000 zasebnih adresa u banama RKN? =)
Netko je prešao na shemu s mirrorsanjem cijelog magistralnog prometa na filtrirajući poslužitelj, koji treba analizirati cijeli tok i prilikom pronalaska nečega lošeg slati u oba smjera (pošiljatelju i primatelju) RST.
Međutim, što je veći promet, to je manje primjenjiva takva shema. Pri najmanjoj kašnjenju u obradi — mirrorirani promet jednostavno neprimjetno prolazi u nirvanu, a pružatelju usluga dolazi protokol o kazni.
Sve više i više pružatelja usluga prisiljeno je postaviti DPI sustave različitih razina pouzdanosti na glavnim otvorima.
Prije godinu-dvije prema glasinama, gotovo svi FSB zahtijevaju stvarnu instalaciju opreme (prije su se najvećim dijelom pružatelji usluga snalazili dogovorom s vlastima plan SORM — plan operativnih aktivnosti u slučaju da nešto negdje treba pronaći)
Osim novca (ne tako da su to preveliki iznosi, ali opet — milijuni), SORM je od mnogih zahtijevao dodatne manipulacije s mrežom.
- SORMu je potrebno vidjeti 'sive' adrese korisnika, prije nat-prevođenja
- SORM ima ograničen broj mrežnih sučelja
Stoga smo, između ostalog, morali značajno rekonstruirati dio jezgre — samo da bismo negdje na jednom mjestu prikupili korisnički promet za pristupne poslužitelje. Da bismo ga reflektirali u SORM s nekoliko veza.
Odnosno, vrlo pojednostavljeno, bilo je (s lijeve strane) nasuprot (s desne strane):
Sada većina pružatelja zahtijeva uvođenje SORM-3 — koji uključuje, između ostalog, i logiranje nat-prevođenja.
U te svrhe u gornju shemu morali smo dodati dodatnu opremu za NAT (točno onu o kojoj se radi u prvom dijelu). Osim toga, trebali smo to dodati u određenom redoslijedu: budući da SORM mora "vidjeti" promet prije prevođenja adresa — promet mora ići strogo na sljedeći način: korisnici -> preklapanje, jezgra -> pristupni poslužitelji -> SORM -> NAT -> preklapanje, jezgra -> internet. Za to smo morali, doslovno, "preokrenuti" tokove prometa u drugom smjeru uživo, što je također bilo prilično teško.
U konačnici: tijekom deset godina shema jezgre prosječnog pružatelja usluga znatno se zakomplicirala, a dodatne točke kvara (kako u obliku opreme, tako i u obliku jedinstvenih komunikacijskih linija) su se znatno povećale. U biti, zahtjev "vidjeti sve" podrazumijeva sabiranje tog "svega" na jednu točku.
Čini mi se da se to prilično prozirno može extrapolirati na trenutne inicijative za suverenizaciju runeta, njegovu zaštitu, stabilizaciju i poboljšanje 🙂
A ispred nas je još uvijek Jarovaja.
Izvor: habr.com
