M'hà invitatu à questu post .
Citu quì:
oghje à 18:53
Eru cuntentu di u fornitore oghje. Inseme à l'aghjurnamentu di u sistema di bloccu di u situ, u so mailer mail.ru hè statu pruibitu, aghju chjamatu supportu tecnicu da a matina, ma ùn ponu fà nunda. U fornitore hè chjuca, è apparentemente i fornituri di ranking più altu u bluccanu. Aghju nutatu ancu una rallentazione in l'apertura di tutti i siti, forsi anu stallatu un tipu di DLP stortu? Prima ùn ci era micca prublemi cù l'accessu. A distruzzione di RuNet hè accaduta davanti à i mo ochji...
U fattu hè chì pare chì simu u listessu fornitore :)
È veramente, I quasi guessed a causa di i prublemi cù mail.ru (ancu se avemu ricusatu di crede in una cosa cusì per un bellu pezzu).
Ciò chì seguita serà divisu in dui parti:
- i mutivi di i nostri prublemi attuali cù mail.ru è a ricerca eccitante per truvà
- l'esistenza di l'ISP in a realità d'oghje, a stabilità di u RuNet sovranu.
Problemi di accessibilità cù mail.ru
Oh, hè una storia abbastanza longa.
U fattu hè chì per implementà i requisiti di u statu (più dettagli in a seconda parte), avemu acquistatu, cunfiguratu è installatu qualchi equipamentu - sia per filtrà e risorse pruibiti sia per implementà. abbonati.
Qualchì tempu fà, avemu infine ricustruitu u core di a rete in modu chì tuttu u trafficu di l'abbonati passava per questu equipamentu strettamente in a direzione ghjusta.
Qualchi ghjorni fà avemu attivatu u filtru pruibitu nantu à questu (mentre lasciendu u vechju sistema di travagliu) - tuttu pareva andà bè.
In seguitu, gradualmenti cuminciaru à attivà NAT nantu à questu equipamentu per e diverse parti di l'abbonati. Da l'aspettu, tuttu pareva ancu andà bè.
Ma oghje, dopu avè attivatu NAT nantu à l'equipaggiu per a prossima parte di l'abbonati, da a matina stessa ci hè statu affruntatu cù un numeru decentu di lagnanza nantu à indisponibilità o dispunibilità parziale. è altre risorse Mail Ru Group.
Anu cuminciatu à verificà: qualcosa in qualchì locu иногда, occasionalmente manda in risposta à e dumande esclusivamente à e rete mail.ru. Inoltre, manda un generatu incorrectamente (senza ACK), ovviamente artificiale TCP RST. Questu hè ciò chì pareva:
Naturalmente, i primi pinsamenti eranu nantu à u novu equipamentu: terribili DPI, senza fiducia in questu, ùn sapete mai ciò chì pò fà - dopu tuttu, TCP RST hè una cosa abbastanza cumuna trà l'arnesi di bloccu.
Assunzione Avemu dinò l'idea chì qualcunu "superior" hè filtru, ma immediatamente l'hà scartatu.
Prima, avemu uplinks abbastanza sani per ùn avè micca da soffre cusì :)
Siconda, simu cunnessi à parechji in Mosca, è u trafficu à mail.ru passa per elli - è ùn anu nè rispunsabilità nè alcunu altru mutivu per filtrà u trafficu.
A prossima mità di u ghjornu hè stata passata nantu à ciò chì hè di solitu chjamatu sciamanisimu - inseme cù u venditore di l'equipaggiu, per quale li ringraziemu, ùn anu micca rinunciatu :)
- u filtru hè statu completamente disattivatu
- NAT hè stata disattivata cù u novu schema
- u PC di prova hè stata piazzata in una piscina isolata separata
- L'indirizzu IP hè cambiatu
In u dopu meziornu, una macchina virtuale hè stata attribuita chì cunnessu à a reta secondu u schema di un usu regulare, è i rapprisentanti di u venditore anu datu accessu à questu è l'equipaggiu. U sciamanismu cuntinuava :)
À a fine, u rapprisentante di u venditore hà dichjaratu cun fiducia chì u hardware ùn avia assolutamente nunda di fà cù questu: i primi venenu da un locu più altu.
VitaÀ questu puntu, qualchissia pò dì: ma era assai più faciule per piglià un dump micca da u PC di prova, ma da l'autostrada sopra à u DPI?
No, sfurtunatamenti, piglià un dump (è ancu solu mirroring) 40 + gbps ùn hè micca in tuttu triviale.
Dopu questu, à a sera, ùn ci era nunda di fà, ma di vultà à l'assunzione di filtrazione strana in qualchì locu sopra.
Aghju guardatu per quale IX u trafficu à e rete MRG hè avà chì passanu è simpricimenti annullatu e sessioni bgp à questu. È - eccu ! - tuttu hè tornatu immediatamente à a normalità 🙁
Da una banda, hè una vergogna chì u ghjornu sanu hè passatu per circà u prublema, ancu s'ellu hè statu risoltu in cinque minuti.
Da l'altra parte:
- in a mo memoria hè una cosa senza precedente. Comu dighjà scrittu sopra - IX veramente ùn ci hè nunda di filtrà u trafficu di transitu. Di solitu anu centinaie di gigabits / terabits per seconda. Solu ùn pudia micca seriamente imagine qualcosa cusì finu à pocu tempu.
- una coincidenza incredibbilmente furtunata di circustanze: un novu hardware cumplessu chì ùn hè micca particularmente affidatu è da quale ùn hè micca chjaru ciò chì si pò aspittà - adattatu specificamente per bluccà risorse, cumprese TCP RST
U NOC di stu scambiu internet hè attualmente à circà un prublema. Sicondu elli (è li crede), ùn anu micca un sistema di filtrazione apposta. Ma, grazie à u celu, a ricerca più avanzata ùn hè più u nostru prublema :)
Questu era un picculu tentativu di ghjustificà mi stessu, per piacè capisce è perdona :)
PS: Deliberatamente ùn nome micca u fabricatore di DPI / NAT o IX (in fatti, ùn aghju mancu alcuna lagnanza speciale per elli, a cosa principal hè di capisce ciò chì era)
A realità d'oghje (cum'è d'ayer è di l'avanti) da u puntu di vista di un fornitore di Internet
Aghju passatu l'ultime settimane à ricustruisce significativamente u core di a reta, eseguendu una mansa di manipulazioni "per prufittu", cù u risicu di affettà significativamente u trafficu di l'utilizatori in diretta. In cunsiderà i scopi, i risultati è e cunsequenze di tuttu questu, morale hè tuttu abbastanza difficiule. In particulare - una volta à sente belli discorsi nantu à a prutezzione di a stabilità di u Runet, a sovranità, etc. eccetera.
In questa rùbbrica, pruvaraghju à descriverà l'"evoluzione" di u core di a rete di un ISP tipicu in l'ultimi deci anni.
Dieci anni fà.
In quelli tempi benedetti, u core di una rete di fornitore puderia esse simplice è affidabile cum'è un inghjustu di trafficu:
In questa stampa assai simplificata, ùn ci sò micca tronchi, anelli, routing ip/mpls.
A so essenza hè chì u trafficu di l'utilizatori hè finalmente ghjuntu à u cambiamentu di livellu di u kernel - da induve andò , da induve, in regula, torna à u core switching, è dopu "fora" - attraversu una o più porte di cunfini à Internet.
Un tali schema hè assai, assai faciule di riservà sia in L3 (routing dinamicu) sia in L2 (MPLS).
Pudete installà N + 1 di qualcosa: servitori d'accessu, switches, frontiere - è un modu o un altru riservate per fallu automaticu.
Dopu qualchì annu Hè diventatu chjaru per tutti in Russia chì era impussibile di campà cusì più: era urgente per prutege i zitelli da l'influenza perniciosa di l'Internet.
Ci era un bisognu urgente di truvà modi per filtrà u trafficu di l'utilizatori.
Ci sò diversi approcci quì.
In un casu micca assai bonu, qualcosa hè messu "in u distaccu": trà u trafficu di l'utilizatori è l'Internet. U trafficu chì passa per questu "qualcosa" hè analizatu è, per esempiu, un pacchettu falsu cù un redirect hè mandatu versu l'abbonatu.
In un casu un pocu megliu - se i volumi di trafficu permettenu - pudete fà un picculu truccu cù l'arechje: mandate per filtru solu u trafficu originatu da l'utilizatori solu à quelli indirizzi chì devenu esse filtrati (per fà questu, pudete piglià l'indirizzi IP). specificatu quì da u registru, o ancu risolve i domini esistenti in u registru).
À un tempu, per questi scopi, aghju scrittu un simplice - ancu s'ellu ùn l'aghju mancu azzaru à chjamà cusì. Hè assai simplice è micca assai pruduttivu - in ogni modu, hà permessu à noi è decine (se micca centinaie) di altri fornituri per ùn sbuccà immediatamente milioni di sistemi DPI industriali, ma hà datu parechji anni supplementari di tempu.
Per via, circa u DPI allora è attualeA propositu, parechji chì anu acquistatu i sistemi DPI dispunibuli nantu à u mercatu in quellu tempu l'avianu digià cacciatu. Eppo, ùn sò micca pensati per questu: centinaie di millaie di indirizzi, decine di millaie di URL.
È à u stessu tempu, i pruduttori domestici anu risuscitatu assai forte à stu mercatu. Ùn parlu micca di u cumpunente di hardware - tuttu hè chjaru per tutti quì, ma u software - a cosa principale chì DPI hà - hè forse oghje, se micca u più avanzatu in u mondu, allora certamente a) sviluppatu à salti è limiti, è b) à u prezzu di un pruduttu boxed - simpliciamente incomparabile cù i cuncurrenti stranieri.
Vogliu esse fieru, ma un pocu tristu =)
Avà tuttu pareva cusì:
In un paru d'anni più tutti avianu digià auditori; Ci era più è più risorse in u registru. Per certi equipaghji più vechji (per esempiu, Cisco 7600), u schema di "filtru laterale" hè diventatu simpliciamente inapplicabile: u numeru di rotte nantu à e plataforme 76 hè limitatu à qualcosa cum'è nove centu mila, mentre chì u numeru di rotte IPv4 solu oghje hè vicinu à 800. milla. È s'ellu hè ancu ipv6 ... È ancu ... quantu ci hè ? 900000 XNUMX indirizzi individuali in a prohibizione RKN? =)
Qualchissia hà cambiatu à un schema cù mirroring di tuttu u trafficu di backbone à un servitore di filtrazione, chì deve analizà u flussu tutale è, se si trova qualcosa di male, mandate RST in e duie direzzione (mittente è destinatariu).
Tuttavia, u più trafficu, u menu applicabile stu schema hè. S'ellu ci hè u minimu ritardu in u processu, u trafficu specchiu simpricamente volarà senza avvistà, è u fornitore riceverà un rapportu bellu.
Sempre più fornituri sò furzati à installà sistemi DPI di varii gradi di affidabilità attraversu l'autostrade.
Un annu o dui fà sicondu i rumuri, quasi tuttu u FSB hà cuminciatu à dumandà a stallazione attuale di l'equipaggiu (prima, a maiò parte di i fornituri gestiti cù l'appruvazioni di l'autorità Pianu SORM - un pianu di misure operative in casu di bisognu di truvà qualcosa in qualchì locu)
In più di soldi (micca esattamente esorbitanti, ma ancu milioni), SORM necessitava assai più manipulazioni cù a reta.
- SORM hà bisognu di vede l'indirizzi di l'utilizatori "grigi" prima di a traduzzione nat
- SORM hà un numeru limitatu di interfacce di rete
Dunque, in particulare, avemu avutu a ricustruisce assai un pezzu di u kernel - solu per cullà u trafficu di l'utilizatori à i servitori d'accessu in un locu in un locu. Per specularlu in SORM cù parechji ligami.
Hè, assai simplificatu, era (a manca) vs hè diventatu (a diritta):
Avà A maiò parte di i fornituri necessitanu ancu l'implementazione di SORM-3 - chì include, frà altre cose, u logu di emissioni nat.
Per questi scopi, avemu avutu ancu aghjunghje un equipamentu separatu per NAT à u diagramma sopra (esattamente ciò chì hè discututu in a prima parte). Inoltre, aghjunghje in un certu ordine: postu chì SORM deve "vede" u trafficu prima di traduzzione di l'indirizzi, u trafficu deve andà strettamente cusì: utilizatori -> switching, kernel -> access servers -> SORM -> NAT -> switching, kernel - > Internet. Per fà questu, avemu avutu literalmente "turnà" i flussi di trafficu in l'altru direzzione per u prufittu, chì era ancu abbastanza difficiule.
In riassuntu: in l'ultimi deci anni, u disignu core di un fornitore mediu hè diventatu parechje volte più cumplessu, è i punti supplementari di fallimentu (sia in a forma di l'equipaggiu è in a forma di linee di commutazione uniche) anu aumentatu significativamente. In realtà, u requisitu stessu di "vede tuttu" implica riducendu questu "tuttu" à un puntu.
Pensu chì questu pò esse estrapolatu in modu abbastanza trasparente à l'iniziativi attuali per sovranizà u Runet, prutege, stabilizzà è migliurà :)
È Yarovaya hè sempre avanti.
Source: www.habr.com