Em va convidar a aquesta publicació .
Ho cito aquí:
avui a les 18:53
Avui estic satisfet amb el proveïdor. Juntament amb l'actualització del sistema de bloqueig de llocs, es va prohibir el seu correu mail.ru. He estat trucant al servei tècnic des del matí, però no poden fer res. El proveïdor és petit i, aparentment, els proveïdors de rang superior el bloquegen. També vaig notar una desacceleració en l'obertura de tots els llocs, potser van instal·lar algun tipus de DLP tort? Abans no hi havia problemes d'accés. La destrucció de RuNet està passant davant dels meus ulls...
El fet és que sembla que som el mateix proveïdor :)
I de fet, Gairebé vaig endevinar la causa dels problemes amb mail.ru (tot i que ens vam negar a creure en una cosa així durant molt de temps).
El que segueix es dividirà en dues parts:
- els motius dels nostres problemes actuals amb mail.ru i l'apassionant recerca per trobar-los
- l'existència d'ISP en les realitats actuals, l'estabilitat de la RuNet sobirà.
Problemes d'accessibilitat amb mail.ru
Oh, és una història bastant llarga.
El fet és que per implementar els requisits de l'estat (més detalls a la segona part), vam comprar, configurar i instal·lar alguns equips, tant per filtrar recursos prohibits com per implementar subscriptors.
Fa un temps, finalment vam reconstruir el nucli de la xarxa de manera que tot el trànsit d'abonats passava per aquest equip estrictament en la direcció correcta.
Fa uns dies vam activar-hi el filtratge prohibit (tot i deixaràvem funcionant l'antic sistema): semblava que tot anava bé.
A continuació, a poc a poc van començar a habilitar NAT en aquest equip per a diferents parts dels abonats. Pel que sembla, també semblava que tot anava bé.
Però avui, havent habilitat el NAT a l'equip per a la següent part d'abonats, des del mateix matí ens hem enfrontat a un bon nombre de queixes per indisponibilitat o disponibilitat parcial. i altres recursos de Mail Ru Group.
Van començar a comprovar: alguna cosa en algun lloc de vegades, de tant en tant envia en resposta a sol·licituds exclusivament a les xarxes mail.ru. A més, envia un RST TCP generat incorrectament (sense ACK), òbviament artificial. Aquest és el que semblava:
Naturalment, els primers pensaments van ser sobre el nou equip: DPI terrible, no hi confies, mai saps què pot fer; després de tot, TCP RST és una cosa bastant comú entre les eines de bloqueig.
Assumpció També vam plantejar la idea que algú "superior" s'està filtrant, però immediatament la vam descartar.
En primer lloc, tenim enllaços amunt prou sensats perquè no hàgim de patir així :)
En segon lloc, estem connectats a diversos a Moscou, i el trànsit a mail.ru passa per ells, i no tenen responsabilitats ni cap altre motiu per filtrar el trànsit.
La següent meitat del dia es va dedicar al que normalment s'anomena xamanisme; juntament amb el venedor d'equips, que els donem les gràcies, no es van rendir :)
- el filtrat estava completament desactivat
- NAT es va desactivar mitjançant el nou esquema
- el PC de prova es va col·locar en una piscina aïllada separada
- L'adreça IP ha canviat
A la tarda, es va assignar una màquina virtual que es connectava a la xarxa segons l'esquema d'un usuari habitual, i els representants del venedor hi van accedir i els equips. El xamanisme va continuar :)
Al final, el representant del venedor va afirmar amb confiança que el maquinari no hi tenia absolutament res a veure: els primers provenen d'un lloc més alt.
NotaEn aquest punt, algú pot dir: però era molt més fàcil fer un abocador no des del PC de prova, sinó des de l'autopista per sobre del DPI?
No, malauradament, fer un abocador (i fins i tot només duplicar) 40 + gbps no és gens trivial.
Després d'això, al vespre, no hi havia res més a fer que tornar a la suposició d'una filtració estranya en algun lloc superior.
Vaig mirar per quin IX passa el trànsit a les xarxes MRG i simplement vaig cancel·lar-hi les sessions bgp. I, vet aquí! - Tot va tornar a la normalitat immediatament 🙁
D'una banda, és una llàstima que s'hagi passat tot el dia buscant el problema, tot i que es va solucionar en cinc minuts.
D'altra banda:
—En la meva memòria això és una cosa sense precedents. Com ja he escrit més amunt - IX de veritat no té sentit filtrar el trànsit de trànsit. Normalment tenen centenars de gigabits/terabits per segon. No em podia imaginar seriosament una cosa així fins fa poc.
— una increïblement afortunada coincidència de circumstàncies: un nou maquinari complex del qual no es confia especialment i del qual no està clar què es pot esperar, dissenyat específicament per bloquejar recursos, inclosos els RST TCP
Actualment, el NOC d'aquest intercanvi d'Internet està buscant un problema. Segons ells (i jo els crec), no tenen cap sistema de filtració especialment desplegat. Però, gràcies al cel, la recerca posterior ja no és el nostre problema :)
Aquest va ser un petit intent de justificar-me, si us plau, entén i perdona :)
PD: deliberadament no anomena el fabricant de DPI/NAT o IX (de fet, ni tan sols tinc cap queixa especial sobre ells, el més important és entendre què era)
La realitat d'avui (així com la d'ahir i abans d'ahir) des del punt de vista d'un proveïdor d'Internet
He passat les últimes setmanes reconstruint significativament el nucli de la xarxa, realitzant un munt de manipulacions "per ànim de lucre", amb el risc d'afectar significativament el trànsit d'usuaris en directe. Tenint en compte els objectius, resultats i conseqüències de tot això, moralment tot és bastant difícil. Especialment, una vegada més, escoltant bells discursos sobre la protecció de l'estabilitat del Runet, la sobirania, etc. etcètera.
En aquesta secció, intentaré descriure l'"evolució" del nucli de xarxa d'un ISP típic durant els darrers deu anys.
Fa deu anys.
En aquells temps beneïts, el nucli d'una xarxa de proveïdors podria ser tan senzill i fiable com un embussos de trànsit:
En aquesta imatge molt, molt simplificada, no hi ha troncals, anells, encaminament ip/mpls.
La seva essència és que el trànsit d'usuaris va arribar finalment al canvi de nivell del nucli, des d'on va anar , des d'on, per regla general, torna a la commutació central i després "fora" - a través d'una o més passarel·les frontereres a Internet.
Aquest esquema és molt i molt fàcil de reservar tant a L3 (encaminament dinàmic) com a L2 (MPLS).
Podeu instal·lar N+1 de qualsevol cosa: servidors d'accés, commutadors, fronteres, i d'una manera o altra reservar-los per a la migració automàtica.
Després d'uns anys Tothom a Rússia va quedar clar que era impossible viure més temps així: era urgent protegir els nens de la influència perniciosa d'Internet.
Hi havia una necessitat urgent de trobar maneres de filtrar el trànsit dels usuaris.
Aquí hi ha diferents enfocaments.
En un cas no molt bo, alguna cosa es posa “a la bretxa”: entre el trànsit d'usuaris i Internet. S'analitza el trànsit que passa per aquest “alguna cosa” i, per exemple, s'envia un paquet fals amb una redirecció cap a l'abonat.
En un cas una mica millor, si els volums de trànsit ho permeten, podeu fer un petit truc amb les orelles: enviar per filtrar només trànsit provinent dels usuaris només a aquelles adreces que cal filtrar (per fer-ho, podeu agafar les adreces IP). especificat allà des del registre, o resoldre, addicionalment, els dominis existents al registre).
En un moment, amb aquests propòsits, vaig escriure un senzill - encara que no m'atreveixo a dir-li així. És molt senzill i poc productiu; tanmateix, ens va permetre que tant a nosaltres com a desenes (si no centenars) d'altres proveïdors no desembolsar immediatament milions en sistemes de DPI industrials, però ens va oferir uns quants anys addicionals de temps.
Per cert, sobre el DPI aleshores i actualPer cert, molts dels que van adquirir els sistemes DPI disponibles al mercat en aquell moment ja els havien llençat. Bé, no estan dissenyats per a això: centenars de milers d'adreces, desenes de milers d'URL.
I al mateix temps, els productors nacionals han pujat molt fortament a aquest mercat. No parlo del component de maquinari -tot està clar per a tothom aquí, però el programari -el principal que té DPI- és potser avui, si no el més avançat del món, sens dubte a) desenvolupant-se a passos de gegant, i b) al preu d'un producte en caixa, simplement incomparable amb els competidors estrangers.
M'agradaria estar orgullós, però una mica trist =)
Ara tot semblava així:
En un parell d'anys més tothom ja tenia auditors; Cada cop hi havia més recursos al registre. Per a alguns equips antics (per exemple, Cisco 7600), l'esquema de "filtratge lateral" simplement es va convertir en inaplicable: el nombre de rutes en 76 plataformes es limita a una mica com nou-cents mil, mentre que el nombre de rutes IPv4 només avui s'acosta als 800. milers. I si també és ipv6... I també... quant hi ha? 900000 adreces individuals a la prohibició de RKN? =)
Algú va canviar a un esquema amb duplicació de tot el trànsit troncal a un servidor de filtratge, que hauria d'analitzar tot el flux i, si es troba alguna cosa dolenta, enviar RST en ambdues direccions (emissor i destinatari).
Tanmateix, com més trànsit, menys aplicable serà aquest esquema. Si hi ha el més mínim retard en el processament, el trànsit reflectit simplement passarà desapercebut i el proveïdor rebrà un informe correcte.
Cada cop més proveïdors es veuen obligats a instal·lar sistemes DPI de diferents graus de fiabilitat a les carreteres.
Fa un any o dos segons els rumors, gairebé tots els FSB van començar a exigir la instal·lació real d'equips (anteriorment, la majoria de proveïdors gestionaven amb l'aprovació de les autoritats Pla SORM - un pla de mesures operatives en cas de necessitat de trobar alguna cosa en algun lloc)
A més dels diners (no precisament desorbitats, però encara milions), SORM va requerir moltes més manipulacions amb la xarxa.
- SORM ha de veure les adreces d'usuari "grises" abans de la traducció nat
- SORM té un nombre limitat d'interfícies de xarxa
Per tant, en particular, vam haver de reconstruir en gran mesura una part del nucli, simplement per recollir el trànsit d'usuaris als servidors d'accés en algun lloc en un sol lloc. Per tal de reflectir-lo a SORM amb diversos enllaços.
És a dir, molt simplificat, era (esquerra) vs convertit (dreta):
Ara La majoria de proveïdors també requereixen la implementació de SORM-3, que inclou, entre altres coses, el registre de les emissions nat.
Amb aquests propòsits, també hem hagut d'afegir equips separats per a NAT al diagrama anterior (exactament el que es parla a la primera part). A més, afegiu-hi un cert ordre: com que SORM ha de "veure" el trànsit abans de traduir adreces, el trànsit ha de ser estrictament de la següent manera: usuaris -> commutació, nucli -> servidors d'accés -> SORM -> NAT -> commutació, nucli - > Internet. Per fer-ho, vam haver de "girar" literalment els fluxos de trànsit en l'altra direcció per obtenir beneficis, cosa que també era bastant difícil.
En resum: durant els darrers deu anys, el disseny bàsic d'un proveïdor mitjà s'ha tornat moltes vegades més complex i els punts de fallada addicionals (tant en forma d'equip com en forma de línies de commutació individuals) han augmentat significativament. De fet, el mateix requisit de "veure-ho tot" implica reduir aquest "tot" a un punt.
Crec que això es pot extrapolar de manera bastant transparent a les iniciatives actuals per sobiranitzar el Runet, protegir-lo, estabilitzar-lo i millorar-lo :)
I Yarovaya encara està per davant.
Font: www.habr.com