DDoS-Guard võrgu seaduslik liiklus ületas hiljuti saja gigabiti sekundis. Praegu genereerivad 50% kogu meie liiklusest klientide veebiteenused. Need on kümned tuhanded domeenid, mis on väga erinevad ja nõuavad enamikul juhtudel individuaalset lähenemist.
Allpool on kirjeldatud, kuidas haldame esisõlmi ja väljastame SSL-sertifikaate sadade tuhandete saitide jaoks.
Ühe, isegi väga suure saidi esipaneeli seadistamine on lihtne. Võtame nginxi või haproxy või lighttpd, konfigureerime selle juhendite järgi ja unustame selle ära. Kui meil on vaja midagi muuta, laadime uuesti ja unustame uuesti.
Kõik muutub, kui töötlete käigult suuri liiklusmahtusid, hindate päringute õiguspärasust, tihendate ja vahemällu salvestate kasutaja sisu ning muudate samal ajal parameetreid mitu korda sekundis. Kasutaja soovib tulemust näha kõigis välistes sõlmedes kohe pärast seda, kui ta on oma isiklikul kontol seadeid muutnud. Kasutaja saab API kaudu alla laadida ka mitu tuhat (ja mõnikord ka kümneid tuhandeid) domeene koos üksikute liikluse töötlemise parameetritega. Kõik see peaks kohe toimima ka Ameerikas, Euroopas ja Aasias - ülesanne pole just kõige triviaalsem, arvestades, et ainuüksi Moskvas on mitu füüsiliselt eraldatud filtreerimissõlme.
Miks on maailmas palju suuri usaldusväärseid sõlme?
-
Kliendiliikluse teenuse kvaliteet - USA-st saabuvaid taotlusi tuleb töödelda USA-s (sh rünnakute, sõelumise ja muude kõrvalekallete puhul), mitte tõmmata Moskvasse või Euroopasse, suurendades ettearvamatult töötlemise viivitust.
-
Ründeliiklus peab olema lokaliseeritud – transiidioperaatorid võivad rünnete ajal, mille maht ületab sageli 1Tbps, degradeeruda. Rünnakuliikluse transport Atlandi-üleste või transaasia ühenduste kaudu ei ole hea mõte. Meil oli reaalseid juhtumeid, kui Tier-1 operaatorid ütlesid: "Teie saadavate rünnakute hulk on meie jaoks ohtlik." Seetõttu aktsepteerime sissetulevaid vooge nende allikatele võimalikult lähedal.
-
Ranged nõuded teenuse järjepidevusele – puhastuskeskused ei tohiks meie kiiresti muutuvas maailmas sõltuda üksteisest ega kohalikest sündmustest. Kas katkestasite nädalaks toite MMTS-11 kõigil 9 korrusel? - pole probleemi. Ükski klient, kellel pole selles konkreetses asukohas füüsilist ühendust, ei kannata ja veebiteenused ei kannata mingil juhul.
Kuidas seda kõike juhtida?
Teenuse konfiguratsioonid tuleks võimalikult kiiresti (ideaaljuhul koheselt) levitada kõikidele esisõlmedele. Te ei saa lihtsalt teksti konfiguratsioone ümber ehitada ja deemoneid iga muudatuse korral taaskäivitada – seesama nginx hoiab protsesse välja lülitatuna (töötaja sulgub) veel mõne minuti (või võib-olla tundide jooksul, kui on pikki veebipesa seansse).
Nginxi konfiguratsiooni uuesti laadimisel on järgmine pilt üsna tavaline:
Mälu kasutamise kohta:
Vanad töötajad söövad mälu, sealhulgas mälu, mis ei sõltu lineaarselt ühenduste arvust – see on normaalne. Kui kliendiühendused on suletud, vabastatakse see mälu.
Miks see probleem ei olnud, kui nginx alles alustas? Ei olnud HTTP/2, WebSocketit ega tohutuid pikki elushoidmise ühendusi. 70% meie veebiliiklusest on HTTP/2, mis tähendab väga pikki ühendusi.
Lahendus on lihtne – ära kasuta nginxi, ära halda tekstifailide põhjal fronte ja kindlasti ära saada pakitud tekstikonfiguratsioone üle transpacific kanalite. Kanalid on loomulikult garanteeritud ja reserveeritud, kuid see ei muuda neid vähem mandriüleseks.
Meil on oma esiserver-balancer, mille sisemustest räägin järgmistes artiklites. Peamine, mida see teha saab, on tuhandete konfiguratsioonimuudatuste rakendamine sekundis lennult, ilma taaskäivituste, uuesti laadimiste, mälutarbimise järsu suurenemise ja muuta. See on väga sarnane Hot Code Reloadiga, näiteks Erlangis. Andmed salvestatakse geograafiliselt hajutatud võtmeväärtuste andmebaasis ja eesmised täiturmehhanismid loevad neid kohe. Need. laadite SSL-sertifikaadi Moskvas asuva veebiliidese või API kaudu üles ja mõne sekundi pärast on see valmis minema meie puhastuskeskusesse Los Angeleses. Kui maailmasõda äkitselt juhtub ja Internet kaob kõikjalt maailmast, jätkavad meie sõlmed autonoomselt tööd ja parandavad lõhenenud aju niipea, kui üks spetsiaalsetest kanalitest Los Angeles-Amsterdam-Moskva, Moskva-Amsterdam-Hongkong- Los-Los muutub kättesaadavaks. Angeles või vähemalt üks GRE varuülekatetest.
Sama mehhanism võimaldab meil Let's Encrypti sertifikaate kohe väljastada ja uuendada. Väga lihtsalt töötab see nii:
-
Niipea, kui näeme oma kliendi domeeni jaoks vähemalt ühte HTTPS-i päringut ilma sertifikaadita (või aegunud sertifikaadiga), teatab päringu vastu võtnud väline sõlm sellest sisemisele sertifitseerimisasutusele.
-
Kui kasutaja pole Let's Encrypti väljastamist keelanud, genereerib sertifitseerimisasutus CSR-i, saab LE-lt kinnitusloa ja saadab selle krüpteeritud kanali kaudu kõigile rinnetele. Nüüd saab iga sõlm kinnitada LE valideerimistaotluse.
-
Mõne hetke pärast saame õige sertifikaadi ja privaatvõtme ning saadame selle samamoodi esindustele. Jällegi, ilma deemonite taaskäivitamiseta
-
7 päeva enne kehtivusaja lõppu alustatakse tunnistuse uuesti kättesaamise menetlust
Praegu vahetame reaalajas 350 XNUMX sertifikaati, mis on kasutajatele täiesti läbipaistev.
Sarja järgmistes artiklites räägin muudest suure veebiliikluse reaalajas töötlemise funktsioonidest – näiteks RTT analüüsimisest mittetäielike andmete abil, et parandada transiidiklientide teenuse kvaliteeti ja üldiselt transiidiliikluse kaitsmisest terabiidsed rünnakud, liiklusteabe edastamise ja koondamise, WAF-i, peaaegu piiramatu CDN-i ja paljude sisu edastamise optimeerimise mehhanismide kohta.
Küsitluses saavad osaleda ainult registreerunud kasutajad. palun.
Mida sa kõigepealt teada tahaksid?
-
14,3%Algoritmid veebiliikluse rühmitamiseks ja kvaliteedi analüüsimiseks<3
-
33,3%DDoS-Guard7 tasakaalustajate sisemised osad
-
9,5%Transiit L3/L4 liikluse kaitse2
-
0,0%Veebisaitide kaitsmine ühistranspordiliikluses0
-
14,3%Veebirakenduse tulemüür3
-
28,6%Kaitse sõelumise ja klõpsamise eest6
21 kasutajat hääletas. 6 kasutajat jäi erapooletuks.
Allikas: www.habr.com