Laillinen liikenne DDoS-Guard-verkossa ylitti äskettäin sadan gigabitin sekunnissa. Tällä hetkellä 50 % kaikesta liikenteestämme syntyy asiakasverkkopalveluista. Nämä ovat monia kymmeniä tuhansia toimialueita, hyvin erilaisia ja vaativat useimmiten yksilöllistä lähestymistapaa.
Leikkauksen alla kerrotaan, kuinka hallitsemme etusolmuja ja myönnämme SSL-varmenteita sadoille tuhansille sivustoille.
Etuosan asettaminen yhdelle, jopa erittäin suurelle, sivustolle on helppoa. Otamme nginxin tai haproxyn tai lighttpd:n, konfiguroimme sen ohjeiden mukaan ja unohdamme sen. Jos meidän on muutettava jotain, lataamme uudelleen ja unohdamme uudelleen.
Kaikki muuttuu, kun käsittelet suuria liikennemääriä lennossa, arvioit pyyntöjen laillisuuden, pakkaat ja tallennat käyttäjän sisältöä ja samalla muutat parametreja useita kertoja sekunnissa. Käyttäjä haluaa nähdä tuloksen kaikissa ulkoisissa solmuissa heti, kun hän on muuttanut henkilökohtaisen tilinsä asetuksia. Käyttäjä voi myös ladata useita tuhansia (ja joskus kymmeniä tuhansia) verkkotunnuksia yksittäisillä liikenteenkäsittelyparametreilla API:n kautta. Kaiken tämän pitäisi toimia välittömästi myös Amerikassa, Euroopassa ja Aasiassa - tehtävä ei ole kaikkein triviaalisin, kun otetaan huomioon, että pelkästään Moskovassa on useita fyysisesti erotettuja suodatussolmuja.
Miksi ympäri maailmaa on monia suuria luotettavia solmuja?
-
Palvelun laatu asiakasliikenteelle - Yhdysvalloista tulevat pyynnöt tulee käsitellä Yhdysvalloissa (mukaan lukien hyökkäykset, jäsennys ja muut poikkeamat), eikä niitä saa vetää Moskovaan tai Eurooppaan, mikä lisää ennakoimattomasti käsittelyviivettä.
-
Hyökkäysliikenteen tulee olla lokalisoitua – siirtooperaattorit voivat huonontua hyökkäysten aikana, joiden määrä ylittää usein 1 Tbps. Hyökkäysliikenteen kuljettaminen transatlanttisten tai transasialaisten linkkien kautta ei ole hyvä idea. Meillä oli todellisia tapauksia, kun Tier-1-operaattorit sanoivat: "Saamasi hyökkäysten määrä on vaarallinen meille." Siksi hyväksymme saapuvat streamit mahdollisimman lähellä niiden lähdettä.
-
Tiukat vaatimukset palvelun jatkuvuudelle - siivouskeskukset eivät saa olla riippuvaisia toisistaan tai paikallisista tapahtumista nopeasti muuttuvassa maailmassamme. Katkaisitko virran kaikista MMTS-11:n 9 kerroksesta viikoksi? - Ei ongelmaa. Yksikään asiakas, jolla ei ole fyysistä yhteyttä kyseisessä paikassa, ei kärsi, eivätkä verkkopalvelut missään olosuhteissa.
Kuinka hallita tätä kaikkea?
Palvelukonfiguraatiot tulisi jakaa kaikille etusolmuille mahdollisimman nopeasti (mieluiten välittömästi). Et voi vain ottaa ja rakentaa uudelleen tekstikonfiguraatioita ja käynnistää demoneja uudelleen jokaisen muutoksen yhteydessä - sama nginx pitää prosessit sammutettuina (työntekijän sammuttamisena) vielä muutaman minuutin (tai ehkä tuntien ajan, jos verkkosocket-istunnot ovat pitkiä).
Kun lataat nginx-kokoonpanon uudelleen, seuraava kuva on aivan normaali:
Muistin käytöstä:
Vanhat työntekijät syövät muistia, myös muistia, joka ei ole lineaarisesti riippuvainen yhteyksien määrästä - tämä on normaalia. Kun asiakasyhteydet suljetaan, tämä muisti vapautuu.
Miksi tämä ei ollut ongelma, kun nginx oli juuri alkamassa? Ei ollut HTTP/2:ta, ei WebSocketia, ei massiivisia pitkiä ylläpitoyhteyksiä. 70 % verkkoliikenteestämme on HTTP/2:ta, mikä tarkoittaa erittäin pitkiä yhteyksiä.
Ratkaisu on yksinkertainen - älä käytä nginxiä, älä hallitse rintamia tekstitiedostojen perusteella, äläkä todellakaan lähetä pakattuja tekstimäärityksiä transpacific-kanavien kautta. Kanavat ovat tietysti taattuja ja varattuja, mutta se ei tee niistä vähemmän mannertenvälisiä.
Meillä on oma etupalvelin-balancer, jonka sisäosista kerron seuraavissa artikkeleissa. Tärkein asia, jonka se voi tehdä, on tehdä tuhansia konfiguraatiomuutoksia sekunnissa lennossa ilman uudelleenkäynnistämistä, uudelleenlatauksia, äkillisiä muistinkulutuksen lisäyksiä ja kaikkea muuta. Tämä on hyvin samanlainen kuin Hot Code Reload, esimerkiksi Erlangissa. Tiedot tallennetaan maantieteellisesti hajautettuun avainarvotietokantaan, ja etutoimilaitteet lukevat ne välittömästi. Nuo. lataat SSL-varmenteen verkkorajapinnan tai API:n kautta Moskovaan, ja muutamassa sekunnissa se on valmis menemään Los Angelesin siivouskeskukseemme. Jos yhtäkkiä syttyy maailmansota ja Internet katoaa kaikkialta maailmasta, solmumme jatkavat toimintaansa itsenäisesti ja korjaavat jakautuneet aivot heti, kun yksi omistetuista kanavista Los Angeles-Amsterdam-Moskova, Moskova-Amsterdam-Hongkong- Los-Los tulee saataville. Angeles tai ainakin yksi GRE-varmuuskopiopeittokuvista.
Tämän saman mekanismin avulla voimme välittömästi myöntää ja uusia Let's Encrypt -varmenteita. Hyvin yksinkertaisesti se toimii näin:
-
Heti kun näemme asiakkaamme verkkotunnukselle vähintään yhden HTTPS-pyynnön ilman varmennetta (tai vanhentuneen varmenteen kanssa), pyynnön hyväksynyt ulkoinen solmu ilmoittaa siitä sisäiselle varmenteen myöntäjälle.
-
Jos käyttäjä ei ole kieltänyt Let's Encryptin myöntämistä, varmenneviranomainen luo CSR:n, vastaanottaa vahvistustunnuksen LE:ltä ja lähettää sen kaikille rintamille salattua kanavaa pitkin. Nyt mikä tahansa solmu voi vahvistaa LE:n vahvistuspyynnön.
-
Muutaman hetken kuluttua saamme oikean varmenteen ja yksityisen avaimen ja lähetämme sen rintamille samalla tavalla. Jälleen, käynnistämättä demoneja uudelleen
-
7 päivää ennen viimeistä voimassaolopäivää käynnistetään menettely todistuksen vastaanottamiseksi
Tällä hetkellä kierrätämme 350 XNUMX varmennetta reaaliajassa, täysin läpinäkyvästi käyttäjille.
Sarjan seuraavissa artikkeleissa puhun muista suuren verkkoliikenteen reaaliaikaisen käsittelyn ominaisuuksista - esimerkiksi RTT:n analysoinnista epätäydellisten tietojen avulla liikenneasiakkaiden palvelun laadun parantamiseksi ja ylipäätään kauttakulkuliikenteen suojaamisesta terabitin hyökkäykset, liikennetietojen toimittamisesta ja yhdistämisestä, WAF:sta, lähes rajattomasta CDN:stä ja monista sisällön toimituksen optimointimekanismeista.
Vain rekisteröityneet käyttäjät voivat osallistua kyselyyn. , ole kiltti.
Mitä haluaisit tietää ensin?
-
14,3%Algoritmit klusterointiin ja verkkoliikenteen laadun analysointiin<3
-
33,3%DDoS-Guard7 -tasapainottimien sisäosat
-
9,5%Transit L3/L4 -liikenteen suojaaminen2
-
0,0%Verkkosivustojen suojaaminen liikenneliikenteeltä0
-
14,3%Verkkosovellusten palomuuri 3
-
28,6%Suojaus jäsentämistä ja napsautusta vastaan6
21 käyttäjää äänesti. 6 käyttäjää pidättyi äänestämästä.
Lähde: will.com