El trànsit legítim a la xarxa DDoS-Guard ha superat recentment els cent gigabits per segon. Actualment, el 50% de tot el nostre trànsit el genera els serveis web dels clients. Es tracta de moltes desenes de milers de dominis, molt diferents i que en la majoria dels casos requereixen un enfocament individual.
A sota del tall hi ha com gestionem els nodes frontals i emetem certificats SSL per a centenars de milers de llocs.
Configurar un front per a un lloc, fins i tot un de molt gran, és fàcil. Prenem nginx o haproxy o lighttpd, el configurem segons les guies i ens oblidem. Si hem de canviar alguna cosa, fem una recàrrega i oblidem de nou.
Tot canvia quan processeu grans volums de trànsit sobre la marxa, avalueu la legitimitat de les sol·licituds, comprimiu i emmagatzemeu el contingut de l'usuari a la memòria cau i, al mateix temps, canvieu els paràmetres diverses vegades per segon. L'usuari vol veure el resultat a tots els nodes externs immediatament després d'haver canviat la configuració del seu compte personal. Un usuari també pot descarregar diversos milers (i de vegades desenes de milers) de dominis amb paràmetres de processament de trànsit individuals mitjançant l'API. Tot això també hauria de funcionar immediatament a Amèrica, a Europa i a Àsia: la tasca no és la més trivial, tenint en compte que només a Moscou hi ha diversos nodes de filtració separats físicament.
Per què hi ha molts nodes fiables a tot el món?
-
Qualitat del servei per al trànsit de clients: les sol·licituds dels EUA s'han de processar als EUA (inclosos atacs, anàlisis i altres anomalies) i no s'han de portar a Moscou o Europa, augmentant de manera imprevisible el retard de processament.
-
El trànsit d'atac s'ha de localitzar: els operadors de trànsit poden degradar-se durant els atacs, el volum dels quals sovint supera 1 Tbps. Transportar trànsit d'atac per enllaços transatlàntics o transasiàtics no és una bona idea. Vam tenir casos reals en què els operadors de nivell 1 van dir: "El volum d'atacs que rebeu és perillós per a nosaltres". És per això que acceptem les reproduccions entrants el més a prop possible de les seves fonts.
-
Requisits estrictes per a la continuïtat del servei: els centres de neteja no haurien de dependre els uns dels altres ni dels esdeveniments locals en el nostre món que canvia ràpidament. Heu tallat l'alimentació als 11 pisos de l'MMTS-9 durant una setmana? - cap problema. Ni un sol client que no tingui una connexió física en aquesta ubicació concreta patirà, i els serveis web no patiran sota cap circumstància.
Com gestionar tot això?
Les configuracions del servei s'han de distribuir a tots els nodes frontals tan aviat com sigui possible (idealment a l'instant). No podeu simplement agafar i reconstruir les configuracions de text i reiniciar els dimonis a cada canvi: el mateix nginx manté els processos tancats (el treballador s'apaga) durant uns minuts més (o potser hores si hi ha sessions llargues de websocket).
Quan torneu a carregar la configuració de nginx, la imatge següent és bastant normal:
Sobre l'ús de la memòria:
Els treballadors antics consumeixen memòria, inclosa la memòria que no depèn linealment del nombre de connexions, això és normal. Quan es tanquin les connexions de client, aquesta memòria s'alliberarà.
Per què no era un problema quan nginx començava? No hi havia HTTP/2, ni WebSocket, ni connexions massives de llarga durada. El 70% del nostre trànsit web és HTTP/2, el que significa connexions molt llargues.
La solució és senzilla: no utilitzeu nginx, no gestioneu fronts basats en fitxers de text i, certament, no envieu configuracions de text comprimit per canals transpacífics. Els canals estan, és clar, garantits i reservats, però això no els fa menys transcontinentals.
Tenim el nostre propi equilibrador de servidor frontal, dels quals parlaré en els articles següents. El més important que pot fer és aplicar milers de canvis de configuració per segon sobre la marxa, sense reinicis, recàrregues, augments sobtats del consum de memòria i tot això. Això és molt similar a Hot Code Reload, per exemple a Erlang. Les dades s'emmagatzemen en una base de dades de valor-clau distribuïda geogràficament i els actuadors frontals llegeixen immediatament. Aquells. carregueu el certificat SSL a través de la interfície web o API de Moscou, i en pocs segons ja està llest per anar al nostre centre de neteja de Los Angeles. Si de sobte es produeix una guerra mundial i Internet desapareix a tot el món, els nostres nodes continuaran treballant de manera autònoma i reparant el cervell dividit tan aviat com un dels canals dedicats Los Angeles-Amsterdam-Moscou, Moscou-Amsterdam-Hong Kong- Los-Los està disponible. Angeles o almenys una de les superposicions de còpia de seguretat GRE.
Aquest mateix mecanisme ens permet emetre i renovar instantàniament els certificats de Let's Encrypt. Molt senzillament funciona així:
-
Tan bon punt veiem almenys una sol·licitud HTTPS per al domini del nostre client sense certificat (o amb un certificat caducat), el node extern que va acceptar la sol·licitud ho informa a l'autoritat de certificació interna.
-
Si l'usuari no ha prohibit l'emissió de Let's Encrypt, l'autoritat de certificació genera un CSR, rep un testimoni de confirmació de LE i l'envia a tots els fronts a través d'un canal xifrat. Ara qualsevol node pot confirmar una sol·licitud de validació de LE.
-
En uns instants rebrem el certificat i la clau privada correctes i l'enviarem als fronts de la mateixa manera. De nou, sense reiniciar els dimonis
-
7 dies abans de la data de caducitat, s'inicia el procediment per tornar a rebre el certificat
Ara mateix estem rotant 350 certificats en temps real, totalment transparents per als usuaris.
En els següents articles de la sèrie, parlaré d'altres característiques del processament en temps real de trànsit web gran; per exemple, sobre l'anàlisi de RTT utilitzant dades incompletes per millorar la qualitat del servei per als clients de trànsit i, en general, sobre la protecció del trànsit de trànsit de atacs terabit, sobre el lliurament i l'agregació d'informació de trànsit, sobre WAF, CDN gairebé il·limitat i molts mecanismes per optimitzar el lliurament de contingut.
Només els usuaris registrats poden participar en l'enquesta. si us plau.
Què t'agradaria saber primer?
-
14,3%Algorismes per agrupar i analitzar la qualitat del trànsit web<3
-
33,3%Interns dels equilibradors DDoS-Guard7
-
9,5%Protecció del trànsit de trànsit L3/L4
-
0,0%Protecció de llocs web en trànsit de trànsit 0
-
14,3%Tallafoc d'aplicacions web 3
-
28,6%Protecció contra l'anàlisi i els clics6
Han votat 21 usuaris. 6 usuaris es van abstenir.
Font: www.habr.com