Trafiku legjitim në rrjetin DDoS-Guard kohët e fundit ka tejkaluar njëqind gigabit për sekondë. Aktualisht, 50% e të gjithë trafikut tonë gjenerohet nga shërbimet e internetit të klientëve. Këto janë shumë dhjetëra mijëra domene, shumë të ndryshme dhe në shumicën e rasteve kërkojnë një qasje individuale.
Më poshtë është se si ne menaxhojmë nyjet e përparme dhe lëshojmë certifikata SSL për qindra mijëra sajte.
Vendosja e një ballore për një vend, qoftë edhe shumë të madh, është e lehtë. Ne marrim nginx ose haproxy ose lighttpd, e konfigurojmë atë sipas udhëzuesve dhe e harrojmë atë. Nëse duhet të ndryshojmë diçka, bëjmë një ringarkim dhe harrojmë përsëri.
Gjithçka ndryshon kur përpunoni vëllime të mëdha trafiku në fluturim, vlerësoni legjitimitetin e kërkesave, kompresoni dhe ruani përmbajtjen e përdoruesit dhe në të njëjtën kohë ndryshoni parametrat disa herë në sekondë. Përdoruesi dëshiron të shohë rezultatin në të gjitha nyjet e jashtme menjëherë pasi të ketë ndryshuar cilësimet në llogarinë e tij personale. Një përdorues mund të shkarkojë gjithashtu disa mijëra (dhe nganjëherë dhjetëra mijëra) domene me parametra individualë të përpunimit të trafikut nëpërmjet API-së. E gjithë kjo gjithashtu duhet të funksionojë menjëherë në Amerikë, dhe në Evropë dhe në Azi - detyra nuk është më e parëndësishme, duke pasur parasysh që vetëm në Moskë ka disa nyje filtrimi të ndara fizikisht.
Pse ka shumë nyje të mëdha të besueshme në mbarë botën?
-
Cilësia e shërbimit për trafikun e klientëve - kërkesat nga SHBA duhet të përpunohen në SHBA (përfshirë sulmet, analizimin dhe anomalitë e tjera), dhe të mos tërhiqen në Moskë ose Evropë, duke rritur në mënyrë të paparashikueshme vonesën e përpunimit.
-
Trafiku i sulmeve duhet të lokalizohet - operatorët e tranzitit mund të degradojnë gjatë sulmeve, vëllimi i të cilave shpesh kalon 1 Tbps. Transportimi i trafikut të sulmeve mbi lidhjet transatlantike ose transaziane nuk është një ide e mirë. Ne kishim raste reale kur operatorët e nivelit 1 thanë: "Vëllimi i sulmeve që merrni është i rrezikshëm për ne". Kjo është arsyeja pse ne pranojmë transmetimet hyrëse sa më afër burimeve të tyre.
-
Kërkesat strikte për vazhdimësinë e shërbimit - qendrat e pastrimit nuk duhet të varen as nga njëra-tjetra, as nga ngjarjet lokale në botën tonë që ndryshon me shpejtësi. A e keni ndërprerë energjinë në të 11 katet e MMTS-9 për një javë? - nuk ka problem. Asnjë klient i vetëm që nuk ka një lidhje fizike në këtë vendndodhje të veçantë nuk do të vuajë dhe shërbimet e internetit nuk do të vuajnë në asnjë rrethanë.
Si të menaxhoni të gjitha këto?
Konfigurimet e shërbimit duhet të shpërndahen në të gjitha nyjet e përparme sa më shpejt që të jetë e mundur (në mënyrë ideale në çast). Ju nuk mund të merrni dhe rindërtoni konfigurimet e tekstit dhe të rindizni demonët në çdo ndryshim - i njëjti nginx i mban proceset të mbyllen (punëtori mbyllet) për disa minuta të tjera (ose ndoshta orë nëse ka seanca të gjata të rrjetit të internetit).
Kur ringarkoni konfigurimin nginx, fotografia e mëposhtme është mjaft normale:
Për përdorimin e kujtesës:
Punëtorët e vjetër hanë kujtesën, duke përfshirë kujtesën që nuk varet në mënyrë lineare nga numri i lidhjeve - kjo është normale. Kur lidhjet e klientit mbyllen, kjo memorie do të lirohet.
Pse nuk ishte ky një problem kur nginx sapo kishte filluar? Nuk kishte HTTP/2, asnjë WebSocket, asnjë lidhje masive të gjata për të mbajtur gjallë. 70% e trafikut tonë në ueb është HTTP/2, që do të thotë lidhje shumë të gjata.
Zgjidhja është e thjeshtë - mos përdorni nginx, mos menaxhoni frontet e bazuara në skedarë teksti dhe sigurisht mos dërgoni konfigurime të tekstit të zip mbi kanalet transpaqësore. Kanalet, natyrisht, janë të garantuara dhe të rezervuara, por kjo nuk i bën ato më pak transkontinentale.
Ne kemi balancuesin tonë të përparmë të serverit, për të brendshmet e të cilit do të flas në artikujt në vijim. Gjëja kryesore që mund të bëjë është të aplikojë mijëra ndryshime konfigurimi në sekondë në fluturim, pa rinisje, ringarkime, rritje të papritura të konsumit të memories dhe të gjitha këto. Kjo është shumë e ngjashme me Hot Code Reload, për shembull në Erlang. Të dhënat ruhen në një bazë të dhënash me vlerë kyçe të shpërndarë gjeografikisht dhe lexohen menjëherë nga aktivizuesit e përparmë. Ato. ju ngarkoni certifikatën SSL nëpërmjet ndërfaqes së internetit ose API-së në Moskë dhe në pak sekonda ajo është gati për të shkuar në qendrën tonë të pastrimit në Los Angeles. Nëse një luftë botërore ndodh papritur dhe interneti zhduket në të gjithë botën, nyjet tona do të vazhdojnë të punojnë në mënyrë autonome dhe të riparojnë trurin e ndarë sapo një nga kanalet e dedikuara Los Angeles-Amsterdam-Moskë, Moskë-Amsterdam-Hong Kong- Los-Los bëhet i disponueshëm. Angeles ose të paktën një nga mbivendosjet rezervë GRE.
I njëjti mekanizëm na lejon të lëshojmë dhe rinovojmë menjëherë certifikatat Let's Encrypt. Shumë thjesht funksionon si kjo:
-
Sapo shohim të paktën një kërkesë HTTPS për domenin e klientit tonë pa certifikatë (ose me një certifikatë të skaduar), nyja e jashtme që pranoi kërkesën e raporton këtë tek autoriteti i brendshëm i certifikimit.
-
Nëse përdoruesi nuk e ka ndaluar lëshimin e Let's Encrypt, autoriteti i certifikimit gjeneron një CSR, merr një token konfirmimi nga LE dhe e dërgon atë në të gjitha frontet përmes një kanali të koduar. Tani çdo nyje mund të konfirmojë një kërkesë vërtetuese nga LE.
-
Në pak çaste do të marrim certifikatën e saktë dhe çelësin privat dhe do ta dërgojmë në fronte në të njëjtën mënyrë. Përsëri, pa rifilluar demonët
-
7 ditë para datës së skadencës, fillon procedura për rimarrjen e certifikatës
Tani për tani ne po rrotullojmë 350 mijë certifikata në kohë reale, plotësisht transparente për përdoruesit.
Në artikujt vijues të serisë, do të flas për veçori të tjera të përpunimit në kohë reale të trafikut të madh të internetit - për shembull, në lidhje me analizimin e RTT duke përdorur të dhëna jo të plota për të përmirësuar cilësinë e shërbimit për klientët transit dhe në përgjithësi për mbrojtjen e trafikut transit nga Sulmet terabit, për shpërndarjen dhe grumbullimin e informacionit të trafikut, për WAF, CDN pothuajse të pakufizuar dhe shumë mekanizma për optimizimin e shpërndarjes së përmbajtjes.
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , te lutem
Çfarë dëshironi të dini së pari?
-
14,3%Algoritme për grupimin dhe analizimin e cilësisë së trafikut në ueb<3
-
33,3%Të brendshmet e balancuesve DDoS-Guard7
-
9,5%Mbrojtja e trafikut transit L3/L4
-
0,0%Mbrojtja e faqeve të internetit në trafikun transit0
-
14,3%Firewall i aplikacionit në ueb3
-
28,6%Mbrojtje kundër analizimit dhe klikimit6
21 përdorues votuan. 6 përdorues abstenuan.
Burimi: www.habr.com