Mi ha spinto a questo post .
Lo riporto qui:
oggi alle 18:53
Oggi il provider mi ha deliziato. Insieme all'aggiornamento del sistema di blocco dei siti, è finito sotto ban il servizio di posta mail.ru. Da stamattina stuzzico il supporto tecnico, non possono farci nulla. Il provider è piccolo e bloccano probabilmente i provider superiori. Ho anche notato un rallentamento nell'apertura di tutti i siti, sarà qualche DLP storto installato? Prima non ci sono mai stati problemi di accesso. La distruzione del Runet sta avvenendo davanti ai miei occhi…
Il fatto è che, a quanto pare, noi siamo proprio quel provider 🙁
E in effetti, ho quasi indovinato la causa dei problemi con mail.ru (anche se abbiamo a lungo rifiutato di credere a una cosa del genere).
Il seguito sarà diviso in due parti:
- le cause dei nostri problemi di oggi con mail.ru e un affascinante quest per cercarle
- 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 le richieste dello Stato (più dettagli nella seconda parte), abbiamo acquistato, configurato e installato alcune attrezzature - sia per la filtrazione delle risorse vietate che per effettuare degli utenti.
Qualche tempo fa, finalmente abbiamo ristrutturato il nucleo della rete in modo che tutto il traffico degli utenti passasse attraverso questa attrezzatura rigorosamente nella direzione giusta.
Qualche giorno fa, abbiamo attivato la filtrazione della pornografia (lasciando funzionare anche il vecchio sistema) - a prima vista è andato tutto bene.
Successivamente - abbiamo iniziato ad attivare gradualmente il NAT su questo hardware per diverse parti degli utenti. Anche a prima vista, tutto sembrava andare bene.
Ma oggi, attivando il NAT per un'altra parte degli utenti - sin dalla mattina ci siamo trovati di fronte a un numero considerevole di lamentele riguardo all'inaccessibilità o all'accessibilità parziale e di altre risorse del Mail Ru Group.
Abbiamo iniziato a verificare: qualcosa da qualche parte a volte, raramente invia in risposta a richieste esclusivamente alle reti mail.ru. Inoltre - invia un TCP RST evidentemente generato in modo errato (senza ACK), chiaramente artificiale. Questo è come si è presentato:
Naturalmente, i primi pensieri riguardavano la nuova attrezzatura: terribile DPI, nessuna fiducia in essa, chissà cosa può combinare - dopo tutto, il TCP RST è un fenomeno piuttosto comune tra i mezzi di blocco.
Ipotesi che qualcuno 'superiore' filtri, l'abbiamo proposta anche noi — ma l'abbiamo subito scartata.
In primo luogo, abbiamo collegamenti sufficientemente adeguati per non subire tali problemi 🙂
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é alcun altro incentivo a filtrare il traffico.
La metà successiva della giornata è stata dedicata a quello che di solito chiamiamo sciamanesimo — insieme al fornitore dell'attrezzatura, per cui li ringraziamo, non ci hanno abbandonato 🙂
- la filtrazione è stata completamente disattivata
- il NAT è stato disattivato secondo un nuovo schema
- il computer di test è stato trasferito in un pool isolato
- è stata modificata l'indirizzamento IP
Nel pomeriggio è stata allocata una macchina virtuale che si connette alla 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 dichiarato con sicurezza che l'hardware non c'entra affatto: i rst arrivano da un livello superiore.
NotaA questo punto, qualcuno potrebbe affermare: ma sarebbe stato molto più semplice catturare il dump non dal PC di test, ma dalla dorsale superiore al DPI?
No, sfortunatamente, catturare un dump (e anche semplicemente mirrorarlo) a 40+gbps non è affatto banale.
Dopo di ciò, già in serata — non rimaneva altro da fare che tornare all'ipotesi di una filtrazione strana da qualche parte sopra.
Ho controllato attraverso quale IX sta transitando attualmente il traffico verso le reti MRG e ho semplicemente disattivato le sessioni BGP. E — oh miracolo! — tutto si è immediatamente normalizzato 🙁
Da un lato — è davvero un peccato che sia stato impiegato un giorno intero per individuare il problema, quando è stato risolto in cinque minuti.
Dall'altro lato:
— a mia memoria questo è un evento senza precedenti. Come ho già scritto sopra — per le IX in effetti non ha senso filtrare il traffico di transito. Di solito hanno centinaia di gigabit / terabit al secondo. Non avrei potuto sospettarlo seriamente fino all'ultimo.
— una coincidenza incredibilmente favorevole: un nuovo hardware complesso, a cui non si dà molta fiducia e di cui non si sa cosa aspettarsi — progettato proprio per bloccare le risorse, inclusi i TCP RST
Attualmente il NOC di questo internet exchange sta cercando il problema. Secondo le loro affermazioni (e io credo in loro) non hanno alcun sistema di filtrazione appositamente implementato. Ma, grazie al cielo, la fase successiva — non è più un nostro problema 🙂
È stata una piccola tentativo di giustificarsi, vi chiediamo di capire e perdonare 🙂
P.S.: non nomino intenzionalmente né il produttore DPI/NAT, né IX (in realtà, non ho particolari lamentele nei loro confronti, l'importante è capire che è successo)
La realtà odierna (così come quella di ieri e dell'altro ieri) dal punto di vista di un fornitore di servizi internet
Le ultime settimane le ho passate a ristrutturare significativamente il nucleo della rete, effettuando un sacco di manipolazioni "dal vivo", con il rischio di influenzare notevolmente il traffico degli utenti. Considerati gli obiettivi, i risultati e le conseguenze di tutto questo, moralmente è tutto piuttosto difficile. Specialmente quando si ascoltano per l'ennesima volta discorsi idealistici sulla protezione della stabilità del Runet, sulla sovranità, ecc.
In questa sezione cercherò di raccontare l'"evoluzione" del nucleo della rete di un tipico fornitore di servizi internet nell'ultimo decennio.
Dieci anni fa.
In quei gloriosi tempi, il nucleo della rete del fornitore poteva essere semplice e affidabile, come un tappo:
In questa immagine molto, molto semplificata mancano le autostrade, gli anelli, la routing ip/MPLS.
La sua essenza è che il traffico degli utenti alla fine arrivava alla commutazione del livello di nucleo — da dove andava a , da dove, di solito — tornava alla commutazione del nucleo, e oltre "all'uscita" — attraverso uno o più border gateway verso internet.
Uno schema simile è molto, molto facilmente riservato sia su L3 (routing dinamico), che su L2 (MPLS).
Si possono mettere N+1 di qualsiasi cosa: server di accesso, switch, border — e così o in altro modo riservarli per il failover automatico.
Dopo alcuni anni è diventato chiaro a tutti in Russia che non si può continuare a vivere così: è necessario proteggere urgentemente i bambini dall'influenza dannosa della rete.
È sorta la necessità di trovare urgentemente modi per filtrare il traffico degli utenti.
Qui ci sono vari approcci.
Nel caso non molto positivo — si installa qualcosa "in incrocio": tra il traffico degli utenti e internet. Il traffico che passa attraverso questo "qualcosa" viene analizzato e, per esempio, viene inviato un pacchetto falso con un redirect verso l'utente.
Nel miglior dei casi, se i volumi di traffico lo permettono, è possibile fare un piccolo trucco: filtrare solo il traffico in uscita degli utenti verso quegli indirizzi che devono essere filtrati (per questo si possono prendere gli indirizzi IP specificati nel registro o risolvere ulteriormente i domini già presenti nel registro).
A suo tempo, per questi scopi ho scritto un semplice — anche se non è proprio giusto chiamarlo così. È molto semplice e non molto performante, ma ci ha permesso, così come a decine (se non centinaia) di altri provider, di non dover spendere subito milioni in sistemi DPI industriali, dandoci qualche anno in più di tempo.
A proposito dei DPI di allora e di oggiMolti, tra coloro che hanno acquistato i sistemi DPI disponibili sul mercato a quel tempo, li hanno già scartati. Non sono adatti a simili esigenze: centinaia di migliaia di indirizzi, decine di migliaia di URL.
In contemporanea, il mercato ha visto un forte sviluppo da parte dei produttori domestici. Non parlo della componente hardware — qui è tutto chiaro, però il software — che è la parte principale dei DPI — è, oggi, se non il più avanzato al mondo, sicuramente a) si sta sviluppando a grandi passi e b) in termini di prezzo del pacchetto — è semplicemente incomparabile con i concorrenti stranieri.
Vorrei vantarmene, ma è un po' triste =)
Ora tutto sembrava così:
Dopo un paio di anni tutti avevano già installato i revisori; le risorse nel registro aumentavano sempre di più. Per alcune attrezzature vecchie (ad esempio, cisco 7600) diventava semplicemente impraticabile lo schema di 'filtrazione laterale': il numero di rotte sulle piattaforme 76 è limitato a circa novecentomila, mentre il numero di rotte IPv4 è già vicino agli 800 mila. E se consideriamo anche l'ipv6... E poi... quanti sono? 900000 indirizzi separati bannati dal RKN? =)
Alcuni passavano a uno schema di mirroring di tutto il traffico di backbone su un server di filtraggio, che doveva analizzare l'intero flusso e, se trovava qualcosa di sospetto, inviare un RST in entrambe le direzioni (al mittente e al destinatario).
Tuttavia, più alto è il traffico, meno applicabile è tale schema. Con il minimo ritardo nell'elaborazione, il traffico mirrorato può semplicemente volare nell'ignoto, e al provider arriverà un protocollo di multa.
Sempre più provider sono costretti a implementare sistemi DPI di vari livelli di affidabilità all'interno delle dorsali.
Un anno o due fa si diceva che praticamente tutti i FSB avessero iniziato a richiedere l'installazione effettiva dell'attrezzatura (in precedenza la maggior parte dei fornitori si limitava a ottenere l'approvazione dalle autorità del piano SORM — il piano delle attività operative nel caso si rendesse necessario trovare qualcosa da qualche parte)
Oltre ai soldi (non proprio in somme astronomiche, ma comunque milioni), il SORM ha richiesto a molti anche ulteriori manovre con la rete.
- Il SORM deve vedere gli indirizzi "grigi" degli utenti, prima della traduzione NAT
- Il SORM ha un numero limitato di interfacce di rete
Pertanto, a noi, in particolare, è stato necessario ristrutturare notevolmente una parte del core — semplicemente per raccogliere da qualche parte il traffico degli utenti verso i server di accesso. Per poterlo riflettere nel SORM attraverso diverse connessioni.
Cioè, molto semplicemente, era (a sinistra) vs è diventato (a destra):
Attualmente la maggior parte dei provider richiede anche l'implementazione del SORM-3 — che include, tra l'altro, anche la registrazione delle traduzioni NAT.
A questo scopo, nello schema sopra, ci è stato necessario aggiungere anche un'apparecchiatura separata per il NAT (quella di cui si parla nella prima parte). Inoltre, è stata necessaria un'aggiunta in un ordine specifico: poiché il SORM deve "vedere" il traffico prima della traduzione degli indirizzi — il traffico deve seguire esattamente il seguente percorso: utenti -> commutazione, core -> server di accesso -> SORM -> NAT -> commutazione, core -> internet. Per questo abbiamo dovuto, letteralmente, "invertire" i flussi di traffico dall'altra parte dal vivo, il che non è stato affatto semplice.
In sintesi: in dieci anni, lo schema del core di un provider medio si è complicato notevolmente, e i punti di guasto aggiuntivi (sia sotto forma di attrezzature che sotto forma di uniche linee di commutazione) sono aumentati significativamente. In sostanza, la richiesta di "vedere tutto" implica la concentrazione di questo "tutto" in un unico punto.
Ritengo che questo possa essere facilmente esteso alle attuali iniziative per la sovranità del Runet, la sua protezione, la stabilizzazione e il miglioramento 🙂
E davanti a noi c'è ancora Yarovaya.
Fonte: habr.com
