Mi ha ispirato a scrivere questo post .
Lo riporto qui:
oggi alle 18:53
Oggi mi ha sorpreso il provider. Insieme all'aggiornamento del sistema di blocco dei siti, ha incluso mail.ru nella lista nera. Questa mattina ho contattato il supporto tecnico, non possono fare nulla. Il provider è piccolo, e probabilmente bloccano a causa di provider superiori. Ho anche notato un rallentamento nell'apertura di tutti i siti, forse hanno installato qualche DLP malfunzionante? Prima non c'erano problemi di accesso. La distruzione del Runet avviene davanti ai miei occhi…
Il fatto è che, pare, siamo proprio noi quel provider 🙁
E in effetti, ho quasi indovinato la causa dei problemi con mail.ru (anche se a lungo abbiamo rifiutato di crederci).
Il seguito sarà diviso in due parti:
- le ragioni dei nostri problemi odierni con mail.ru e un coinvolgente quest per trovarle
- l'esistenza degli ISP nelle attuali realtà, la stabilità del Runet sovrano.
Problemi di accesso a mail.ru
Oh, è una storia piuttosto lunga.
Il fatto è che per soddisfare i requisiti statali (dettagli nella seconda parte) abbiamo acquistato, configurato e installato alcune attrezzature — sia per filtrare le risorse vietate, sia per realizzare degli abbonati.
Qualche tempo fa abbiamo finalmente ristrutturato il nucleo della rete in modo che tutto il traffico degli abbonati passasse attraverso questa attrezzatura rigorosamente nella direzione corretta.
Qualche giorno fa abbiamo attivato la filtrazione dei contenuti vietati su di essa (lasciando funzionare anche il vecchio sistema) — a prima vista, tutto è andato bene.
Successivamente, abbiamo iniziato ad attivare gradualmente il NAT su questa attrezzatura per diverse parti degli abbonati. Anche qui, tutto sembrava andare abbastanza bene.
Ma oggi, attivando il NAT per un'altra parte degli abbonati — al mattino ci siamo trovati di fronte a un numero considerevole di lamentele riguardo l'inaccessibilità o la parziale accessibilità di e di altre risorse di Mail Ru Group.
Abbiamo cominciato a controllare: qualcosa da qualche parte a volte, di tanto in tanto invie in risposta a richieste esclusivamente per le reti mail.ru. Inoltre, invia in modo errato un TCP RST generato (senza ACK), evidentemente artificiale. Ecco come è apparso:
Naturalmente, i primi pensieri erano rivolti a nuovi dispositivi: DPI inquietante, nessuna fiducia in esso, chissà cosa potrebbe combinare — d'altronde il TCP RST è piuttosto comune tra gli strumenti di blocco.
Supposizione che qualcuno "superiore" stesse filtrando, l'abbiamo avanzata anche noi — ma l'abbiamo subito scartata.
In primo luogo, abbiamo uplink piuttosto sensati, quindi non abbiamo di che preoccuparci 🙂
In secondo luogo, siamo collegati a diversi a Mosca, e il traffico verso mail.ru passa proprio attraverso di loro — e loro non hanno né obblighi né motivi per filtrare il traffico.
La seconda metà della giornata è stata dedicata a quello che di solito chiamiamo sciamanesimo — insieme al fornitore dell'attrezzatura, per cui li ringraziamo, non ci hanno abbandonati 🙂
- è stata completamente disattivata la filtrazione
- è stata disattivata la NAT secondo un nuovo schema
- il PC di test è stato posto in un pool isolato
- è stata cambiata l'assegnazione degli indirizzi IP
Nel pomeriggio è stata dedicata una virtual machine, che usciva in rete secondo lo schema di un utente normale, e a essa e all'attrezzatura è stato dato accesso ai rappresentanti del fornitore. Lo sciamanesimo è continuato 🙂
Alla fine il rappresentante del fornitore ha affermato con certezza che l'hardware non c'entrava assolutamente nulla: i rst provengono da qualche punto superiore.
NotaA questo punto qualcuno potrebbe affermare: ma sarebbe stato molto più semplice catturare il dump non dal PC di test, bensì dall'autostrada sopra il DPI?
No, purtroppo catturare un dump (e anche solo effettuare un mirroring) a 40+ gbps è tutt'altro che banale.
Dopo di ciò, già in serata, non restava altro che tornare all'ipotesi di una strana filtrazione da qualche parte sopra.
Ho controllato quale IX gestisce attualmente il traffico verso le reti MRG e ho semplicemente disattivato le sessioni BGP. E — oh meraviglia! — tutto si è immediatamente normalizzato 🙁
Da un lato, è davvero un peccato che ci sia voluto un giorno intero per cercare il problema, mentre si è risolto in cinque minuti.
Dall'altro lato:
— a mia memoria, è una cosa senza precedenti. Come ho già scritto sopra — per gli IX davvero non ha alcun senso filtrare il traffico in transito. Di solito hanno centinaia di gigabit / terabit al secondo. Semplicemente, fino all'ultimo, non ero riuscito a pensare seriamente a una cosa del genere.
— un incontro fortunato e straordinario: una nuova attrezzatura complessa, della quale non ci si fida molto e da cui non si sa cosa aspettarsi — progettata proprio per bloccare le risorse, incluso TCP RST.
Attualmente, il NOC di questo internet exchange sta cercando il problema. Secondo quanto affermano (e io ci credo), non hanno alcun sistema di filtraggio appositamente implementato. Ma, grazie al cielo, la questione successiva non è più un nostro problema 🙂.
È stata un piccolo tentativo di scusarsi, vi chiediamo di capire e perdonare 🙂.
P.S.: non menziono volutamente né il produttore DPI/NAT, né l'IX (in effetti, non ho nemmeno particolari lamentele nei loro confronti, l'importante è capire che cos'è stato).
La realtà odierna (così come quella di ieri e dell'altro ieri) dal punto di vista del fornitore di servizi internet.
Negli ultimi giorni ho passato il tempo ristrutturando notevolmente il nucleo della rete, effettuando una serie di manipolazioni 'in tempo reale', con il rischio di colpire notevolmente il traffico degli utenti attivi. Considerando gli obiettivi, i risultati e le conseguenze di tutto ciò — moralmente è tutto piuttosto pesante. Soprattutto ascoltando ancora una volta i discorsi idealisti sulla protezione della stabilità del runet, sulla sovranità, ecc.
In questa sezione cercherò di raccontare l'«evoluzione» del nucleo di rete di un tipico provider Internet nell'ultimo decennio.
Dieci anni fa.
In quei tempi benedetti, il nucleo della rete di un provider poteva essere semplice e affidabile come un tappo:
In questa immagine molto, molto semplificata mancano i backbone, gli anelli e la routing IP/MPLS.
La sua essenza è che il traffico degli utenti alla fine arrivava alla commutazione di livello core — da lì andava a , da dove, di regola, tornava alla commutazione di core e poi «in uscita» — attraverso uno o più border gateway verso Internet.
Questo schema è molto, molto facilmente ridondabile sia su L3 (routing dinamico) che su L2 (MPLS).
È possibile impostare N+1 di qualsiasi cosa: server di accesso, switch, border — e in un modo o nell'altro garantirli per un failover automatico.
Dopo alcuni anni tutti in Russia hanno capito che non si poteva andare avanti in questo modo: era necessario trovare urgentemente modi per proteggere i bambini dall'influenza perversa della rete.
C'era la necessità di trovare urgentemente modi per filtrare il traffico degli utenti.
Ci sono diversi approcci.
In a not-so-great scenario, something is set up "in opposition": between user traffic and the internet. The traffic that passes through this "something" is analyzed, and, for example, a counterfeit packet with a redirect is sent to the subscriber.
In a slightly better case — if the traffic volumes allow — a small trick can be done: filter only the outgoing user traffic to the addresses that need to be filtered (for this, either the specified IP addresses from the registry can be used, or the domains listed in the registry can be resolved additionally).
At one time, I wrote a simple — although it's hard to even call it that. It is very simple and not very efficient — however, it allowed us, as well as dozens (if not hundreds) of other providers, not to spend millions on industrial DPI systems right away and gave us a few extra years.
By the way, about the DPI of then and nowA proposito, molti di coloro che hanno acquistato i sistemi DPI disponibili sul mercato li hanno già scartati. Non sono adatti a questo scopo: centinaia di migliaia di indirizzi, decine di migliaia di URL.
E allo stesso tempo, i produttori nazionali sono emersi fortemente in questo mercato. Non parlo dell'hardware — questo è chiaro a tutti, ma il software — è ciò che conta nel DPI — è forse, oggi, se non il più avanzato al mondo, sicuramente a) si sta sviluppando a ritmi vertiginosi e b) per il prezzo di un pacchetto — semplicemente incomparabile con i concorrenti stranieri.
Vorrei potermi vantare, ma è un po' triste =)
Ora tutto appariva così:
Ancora dopo un paio di anni tutti avevano già installato i revisori; le risorse nel registro aumentavano sempre di più. Per alcuni vecchi hardware (ad esempio, cisco 7600) lo schema della "filtrazione laterale" diventava semplicemente inapplicabile: il numero di rotte su 76 piattaforme è limitato a circa novecentonovantamila, mentre il numero di rotte IPv4 oggi si avvicina a 800 mila. E se consideriamo anche l'IPv6... E poi... quanti sono? 900000 indirizzi separati nel ban di RKN? =)
Qualcuno ha adottato uno schema di mirroraggio di tutto il traffico di rete verso un server filtrante, che deve analizzare tutto il flusso e, nel caso di qualcosa di sospetto, inviare un RST in entrambe le direzioni (al mittente e al destinatario).
Tuttavia, più è il traffico, meno è applicabile tale schema. Anche il minimo ritardo nel trattamento — il traffico mirrorato passa semplicemente inosservato, e il fornitore riceverà un protocollo di penalizzazione.
Sempre più fornitori sono costretti a installare sistemi DPI di varia affidabilità lungo le dorsali.
Un anno o due fa ci sono voci che praticamente tutti i servizi di sicurezza russi abbiano richiesto un'installazione reale di attrezzature. (precedentemente, la maggior parte dei fornitori si adattava a concordare con le autorità il piano SORM — un piano di operazioni preventive nel caso fosse necessario trovare qualcosa da qualche parte)
Oltre ai costi (non astronomici, ma comunque milioni), SORM ha richiesto a molti ulteriori manipolazioni della rete.
- SORM ha bisogno di vedere gli indirizzi "grigi" degli utenti, prima della traduzione NAT.
- SORM ha un numero limitato di interfacce di rete.
Pertanto, ci siamo trovati a dover ristrutturare una parte del nucleo — semplicemente per concentrare il traffico degli utenti sui server di accesso in un unico luogo. Questo ci ha portato a doverlo rispecchiare in SORM tramite alcuni link.
In altre parole, semplificando molto, era (a sinistra) vs è diventato (a destra):
Adesso la maggior parte dei fornitori richiede anche l'implementazione di SORM-3 — che include, tra l'altro, la registrazione delle traduzioni NAT.
A tal fine, nella schema sopra, abbiamo dovuto aggiungere anche un'apparecchiatura separata per NAT (proprio quella di cui si parla nella prima parte). Inoltre, dovevamo aggiungerla in un ordine specifico: poiché SORM deve "vedere" il traffico prima della traduzione degli indirizzi — il traffico deve seguire rigorosamente il seguente percorso: utenti -> commutazione, nucleo -> server di accesso -> SORM -> NAT -> commutazione, nucleo -> internet. Per questo motivo, abbiamo dovuto, letteralmente, "invertire" i flussi di traffico in direzione opposta dal vivo, il che era piuttosto complesso.
In totale: nel corso di un decennio, lo schema del nucleo di un fornitore medio si è complicato enormemente, e i punti di guasto aggiuntivi (sia in termini di hardware che di linee di commutazione uniche) sono notevolmente aumentati. In effetti, la richiesta di "vedere tutto" implica la centralizzazione di tutto questo in un unico punto.
Mi sembra che questo possa essere chiaramente estrapolato alle attuali iniziative per la sovranità del Runet, la sua protezione, stabilizzazione e miglioramento 🙂
E davanti a noi c'è ancora Yarovaya.
Fonte: habr.com
