Mi ha spinto a questo post .
Lo cito qui:
oggi in 18: 53
Sono rimasto soddisfatto del fornitore oggi. Insieme all'aggiornamento del sistema di blocco del sito, il suo mailer mail.ru è stato bannato, ho chiamato l'assistenza tecnica dalla mattina, ma non possono fare nulla. Il fornitore è piccolo e apparentemente i fornitori di rango superiore lo bloccano. Ho notato anche un rallentamento nell'apertura di tutti i siti, forse hanno installato qualche tipo di DLP storto? In precedenza non c'erano problemi con l'accesso. La distruzione di RuNet sta accadendo proprio davanti ai miei occhi...
Il fatto è che sembra che siamo lo stesso fornitore :)
Infatti, Ho quasi indovinato la causa dei problemi con mail.ru (anche se per molto tempo ci siamo rifiutati di credere in una cosa del genere).
Quanto segue sarà diviso in due parti:
- le ragioni dei nostri attuali problemi con mail.ru e l'entusiasmante ricerca per trovarli
- l'esistenza dell'ISP nelle realtà odierne, la stabilità della RuNet sovrana.
Problemi di accessibilità con mail.ru
Oh, è una storia piuttosto lunga.
Il fatto è che per attuare i requisiti dello Stato (maggiori dettagli nella seconda parte), abbiamo acquistato, configurato e installato alcune apparecchiature, sia per filtrare le risorse vietate che per implementare iscritti.
Qualche tempo fa, abbiamo finalmente ricostruito il nucleo della rete in modo tale che tutto il traffico degli abbonati passasse attraverso queste apparecchiature rigorosamente nella giusta direzione.
Qualche giorno fa abbiamo attivato il filtraggio proibito (lasciando in funzione il vecchio sistema): tutto sembrava andare bene.
Successivamente, hanno gradualmente iniziato ad abilitare NAT su queste apparecchiature per diverse parti di abbonati. A quanto pare, anche tutto sembrava andare per il meglio.
Ma oggi, avendo abilitato il NAT sull'apparecchiatura per la parte successiva di abbonati, fin dal mattino ci siamo trovati di fronte a un discreto numero di reclami per indisponibilità o disponibilità parziale e altre risorse di Mail Ru Group.
Cominciarono a controllare: qualcosa da qualche parte a volte, occasionalmente invia in risposta alle richieste esclusivamente alle reti mail.ru. Inoltre, invia un TCP RST generato in modo errato (senza ACK), ovviamente artificiale. Ecco come appariva:
Naturalmente il primo pensiero è andato al nuovo equipaggiamento: DPI terribile, nessuna fiducia in esso, non si sa mai cosa può fare - dopotutto TCP RST è una cosa abbastanza comune tra gli strumenti di blocco.
Assunzione Abbiamo anche avanzato l’idea che qualcuno “superiore” stia filtrando, ma l’abbiamo subito scartata.
In primo luogo, abbiamo uplink sufficientemente sani da non dover soffrire in questo modo :)
In secondo luogo, siamo collegati a diversi a Mosca, e il traffico verso mail.ru passa attraverso di loro - e non hanno né responsabilità né altro motivo per filtrare il traffico.
La metà successiva della giornata è stata dedicata a quello che di solito viene chiamato sciamanesimo - insieme al venditore dell'attrezzatura, per il quale li ringraziamo, non si sono arresi :)
- il filtraggio era completamente disabilitato
- NAT è stato disabilitato utilizzando il nuovo schema
- il PC di prova è stato collocato in un pool isolato separato
- L'indirizzamento IP è cambiato
Nel pomeriggio è stata assegnata una macchina virtuale che si collegava alla rete secondo lo schema di un utente abituale, e ai rappresentanti del venditore è stato concesso l'accesso ad essa e all'apparecchiatura. Lo sciamanesimo continua :)
Alla fine il rappresentante del venditore ha dichiarato con sicurezza che l’hardware non c’entra assolutamente nulla: i primi provengono da un posto più in alto.
NotaA questo punto qualcuno potrebbe dire: ma era molto più semplice fare una discarica non dal PC di prova, ma dall'autostrada sopra il DPI?
No, purtroppo fare un dump (e anche solo un mirroring) di 40+gbps non è affatto banale.
Dopodiché, in serata, non restava altro da fare che ritornare all'ipotesi di una strana filtrazione da qualche parte in alto.
Ho esaminato attraverso quale IX passa ora il traffico verso le reti MRG e ho semplicemente annullato le sessioni bgp su di esso. E - ecco! - tutto è tornato subito alla normalità 🙁
Da un lato è un peccato che sia stata trascorsa tutta la giornata a cercare il problema, anche se questo è stato risolto in cinque minuti.
D'altra parte:
– nella mia memoria questa è una cosa senza precedenti. Come ho già scritto sopra - IX davvero non ha senso filtrare il traffico in transito. Di solito hanno centinaia di gigabit/terabit al secondo. Non potevo seriamente immaginare qualcosa del genere fino a poco tempo fa.
— una coincidenza di circostanze incredibilmente fortunata: un nuovo hardware complesso che non è particolarmente affidabile e dal quale non è chiaro cosa ci si può aspettare — adattato specificamente per bloccare le risorse, inclusi gli RST TCP
Il NOC di questo scambio Internet è attualmente alla ricerca di un problema. Secondo loro (e io ci credo), non hanno alcun sistema di filtraggio appositamente implementato. Ma, grazie al cielo, l'ulteriore ricerca non è più un nostro problema :)
Questo è stato un piccolo tentativo di giustificarmi, per favore capisci e perdona :)
PS: volutamente non nomino il produttore di DPI/NAT o IX (in effetti non ho nemmeno particolari lamentele al riguardo, l'importante è capire di cosa si trattasse)
La realtà di oggi (così come quella di ieri e dell'altro ieri) dal punto di vista di un provider Internet
Ho passato le ultime settimane a ricostruire in modo significativo il nucleo della rete, eseguendo una serie di manipolazioni “a scopo di lucro”, con il rischio di influenzare in modo significativo il traffico degli utenti live. Considerando gli obiettivi, i risultati e le conseguenze di tutto ciò, moralmente è tutto abbastanza difficile. Soprattutto - ascoltando ancora una volta bellissimi discorsi sulla protezione della stabilità della Runet, della sovranità, ecc. e così via.
In questa sezione cercherò di descrivere l’“evoluzione” del nucleo di rete di un tipico ISP negli ultimi dieci anni.
Dieci anni fa.
In quei tempi benedetti, il nucleo di una rete di fornitori poteva essere semplice e affidabile come un ingorgo:
In questa immagine molto, molto semplificata, non ci sono trunk, anelli, routing ip/mpls.
La sua essenza è che il traffico degli utenti alla fine è arrivato al passaggio a livello di kernel, da dove è andato , da dove, di regola, si torna al nucleo centrale e poi "fuori" - attraverso uno o più gateway di confine verso Internet.
Un tale schema è molto, molto semplice da prenotare sia su L3 (instradamento dinamico) che su L2 (MPLS).
Puoi installare N+1 di qualsiasi cosa: accedere a server, switch, confini e, in un modo o nell'altro, riservarli per il failover automatico.
Dopo pochi anni In Russia è diventato chiaro a tutti che era impossibile vivere ancora così: era urgente proteggere i bambini dall'influenza perniciosa di Internet.
C'era un urgente bisogno di trovare modi per filtrare il traffico degli utenti.
Ci sono diversi approcci qui.
In un caso non molto positivo, qualcosa viene messo “nel divario”: tra il traffico degli utenti e Internet. Il traffico che passa attraverso questo “qualcosa” viene analizzato e, ad esempio, viene inviato all'abbonato un pacchetto falso con un reindirizzamento.
In un caso leggermente migliore - se i volumi di traffico lo consentono - puoi fare un piccolo trucco con le tue orecchie: inviare a filtrare solo il traffico proveniente dagli utenti solo a quegli indirizzi che devono essere filtrati (per fare questo, puoi prendere gli indirizzi IP specificato lì dal registro o risolvere ulteriormente i domini esistenti nel registro).
Un tempo, per questi scopi, ho scritto un semplice - anche se non oso nemmeno chiamarlo così. È molto semplice e poco produttivo, tuttavia ha consentito a noi e a dozzine (se non centinaia) di altri fornitori di non sborsare immediatamente milioni per sistemi DPI industriali, ma ha concesso diversi anni di tempo aggiuntivi.
A proposito, riguardo al DPI allora e attualeTra l'altro molti di coloro che acquistarono i sistemi DPI allora disponibili sul mercato li avevano già buttati via. Ebbene, non sono progettati per questo: centinaia di migliaia di indirizzi, decine di migliaia di URL.
E allo stesso tempo, i produttori nazionali sono aumentati fortemente verso questo mercato. Non sto parlando della componente hardware - qui tutto è chiaro a tutti, ma il software - la cosa principale che ha DPI - è forse oggi, se non il più avanzato al mondo, sicuramente a) sviluppandosi a passi da gigante, eb) al prezzo di un prodotto in scatola, semplicemente incomparabile con i concorrenti stranieri.
Vorrei essere orgoglioso, ma un po' triste =)
Ora tutto sembrava così:
Tra un altro paio d'anni tutti avevano già dei revisori dei conti; C'erano sempre più risorse nel registro. Per alcune apparecchiature più vecchie (ad esempio Cisco 7600), lo schema di "filtro laterale" è diventato semplicemente inapplicabile: il numero di percorsi su 76 piattaforme è limitato a qualcosa come novecentomila, mentre il numero di percorsi IPv4 da solo oggi si avvicina a 800 mille. E se è anche ipv6... E anche... quanto costa? 900000 indirizzi individuali nel divieto RKN? =)
Qualcuno è passato a uno schema con mirroring di tutto il traffico della dorsale su un server di filtraggio, che dovrebbe analizzare l'intero flusso e, se viene trovato qualcosa di brutto, inviare RST in entrambe le direzioni (mittente e destinatario).
Tuttavia, maggiore è il traffico, meno applicabile è questo schema. Se si verifica il minimo ritardo nell'elaborazione, il traffico rispecchiato passerà semplicemente inosservato e il provider riceverà un rapporto di multa.
Sempre più fornitori sono costretti a installare sistemi DPI con vari gradi di affidabilità sulle autostrade.
Un anno o due fa secondo alcune indiscrezioni, quasi tutto l'FSB ha iniziato a richiedere l'effettiva installazione delle apparecchiature (in precedenza, la maggior parte dei fornitori gestiva con l'approvazione delle autorità Piano SORM - un piano di misure operative in caso di necessità di trovare qualcosa da qualche parte)
Oltre al denaro (non proprio esorbitante, ma pur sempre milioni), SORM richiedeva molte più manipolazioni con la rete.
- SORM deve vedere gli indirizzi utente "grigi" prima della traduzione nat
- SORM ha un numero limitato di interfacce di rete
Pertanto, in particolare, abbiamo dovuto ricostruire in modo significativo una parte del kernel, semplicemente per raccogliere il traffico degli utenti verso i server di accesso da qualche parte in un unico posto. Per rispecchiarlo in SORM con diversi collegamenti.
Cioè, molto semplificato, era (a sinistra) vs è diventato (a destra):
in questo momento La maggior parte dei provider richiede anche l'implementazione di SORM-3, che include, tra le altre cose, la registrazione delle trasmissioni nazionali.
A tal fine abbiamo dovuto aggiungere allo schema precedente anche apparecchiature separate per NAT (esattamente ciò di cui si parla nella prima parte). Inoltre, aggiungiamo in un certo ordine: poiché SORM deve “vedere” il traffico prima di tradurre gli indirizzi, il traffico deve procedere rigorosamente come segue: utenti -> commutazione, kernel -> server di accesso -> SORM -> NAT -> commutazione, kernel - >Internet. Per fare ciò, abbiamo dovuto letteralmente “invertire” i flussi di traffico nella direzione opposta a scopo di lucro, il che era anche piuttosto difficile.
In sintesi: negli ultimi dieci anni la struttura principale di un fornitore medio è diventata molte volte più complessa e i punti di guasto aggiuntivi (sia sotto forma di apparecchiature che sotto forma di singole linee di commutazione) sono aumentati in modo significativo. In realtà, l’esigenza stessa di “vedere tutto” implica ridurre questo “tutto” a un punto.
Penso che questo possa essere estrapolato in modo abbastanza trasparente alle attuali iniziative per sovranizzare la Runet, proteggerla, stabilizzarla e migliorarla :)
E Yarovaya è ancora avanti.
Fonte: habr.com