Pamudināja mani uz šo ziņu .
Es to citēju šeit:
šodien 18:53
Es šodien biju apmierināts ar pakalpojumu sniedzēju. Līdz ar vietņu bloķēšanas sistēmas atjaunināšanu tika aizliegts viņa pastnieks mail.ru Kopš rīta zvanīju tehniskajam atbalstam, bet viņi neko nevar darīt. Pakalpojumu sniedzējs ir mazs, un acīmredzot augstāka ranga pakalpojumu sniedzēji to bloķē. Es arī pamanīju visu saitu atvēršanas palēnināšanos, varbūt viņi uzstādīja kaut kādu greizu DLP? Iepriekš nebija nekādu problēmu ar piekļuvi. RuNet iznīcināšana notiek tieši manu acu priekšā...
Fakts ir tāds, ka šķiet, ka mēs esam viens un tas pats pakalpojumu sniedzējs :)
Un tiešām, Es gandrīz uzminēju problēmu cēloni ar mail.ru (lai gan mēs ilgu laiku atteicāmies ticēt šādai lietai).
Tālāk norādītais tiks sadalīts divās daļās:
- iemeslus mūsu pašreizējām problēmām ar mail.ru un aizraujošajiem meklējumiem tos atrast
- ISP esamība mūsdienu realitātē, suverēnā RuNet stabilitāte.
Pieejamības problēmas ar mail.ru
Ak, tas ir diezgan garš stāsts.
Fakts ir tāds, ka, lai īstenotu valsts prasības (sīkāk otrajā daļā), mēs iegādājāmies, konfigurējām un uzstādījām dažas iekārtas - gan aizliegto resursu filtrēšanai, gan ieviešanai. abonenti.
Pirms kāda laika mēs beidzot pārbūvējām tīkla kodolu tā, lai visa abonentu plūsma caur šo aprīkojumu gāja stingri pareizajā virzienā.
Pirms dažām dienām ieslēdzām tai aizliegto filtrēšanu (atstājot veco sistēmu darboties) - viss it kā gāja labi.
Pēc tam viņi pakāpeniski sāka iespējot NAT šajā iekārtā dažādām abonentu daļām. Arī pēc izskata viss šķita labi.
Bet šodien, iespējojot NAT aprīkojumā nākamajai abonentu daļai, jau no paša rīta mēs saskārāmies ar pienācīgu skaitu sūdzību par nepieejamību vai daļēju pieejamību. un citi Mail Ru Group resursi.
Viņi sāka pārbaudīt: kaut kas kaut kur dažreiz, reizēm sūta atbildot uz pieprasījumiem tikai mail.ru tīkliem. Turklāt tas nosūta nepareizi ģenerētu (bez ACK), acīmredzami mākslīgu TCP RST. Tas izskatījās šādi:
Protams, pirmās domas bija par jauno aprīkojumu: drausmīgs DPI, nav uzticības, jūs nekad nezināt, ko tas var darīt - galu galā TCP RST ir diezgan izplatīta lieta starp bloķēšanas rīkiem.
Pieņēmums Mēs arī izvirzījām domu, ka kāds “priekšnieks” filtrē, taču nekavējoties to atmetām.
Pirmkārt, mums ir pietiekami saprātīgi augšupsaites, lai mums nebūtu šādi jācieš :)
Otrkārt, mēs esam saistīti ar vairākiem Maskavā, un caur tiem iet trafiks uz mail.ru - un viņiem nav ne pienākumu, ne citu motīvu filtrēt trafiku.
Nākamā dienas puse tika veltīta tam, ko parasti sauc par šamanismu - kopā ar ekipējuma pārdevēju, par ko viņiem paldies, viņi nepadevās :)
- filtrēšana tika pilnībā atspējota
- NAT tika atspējots, izmantojot jauno shēmu
- testa dators tika ievietots atsevišķā izolētā baseinā
- IP adrese mainīta
Pēcpusdienā tika piešķirta virtuālā mašīna, kas pieslēdzās tīklam pēc parastā lietotāja shēmas, un pārdevēja pārstāvjiem tika dota piekļuve tai un aprīkojumam. Šamanisms turpinājās :)
Beigās pārdevēja pārstāvis pārliecinoši paziņoja, ka aparatūrai ar to nav nekāda sakara: pirmie nāk no kaut kur augstāk.
PiezīmeŠajā brīdī kāds var teikt: bet daudz vieglāk bija ņemt izgāztuvi nevis no testa datora, bet gan no šosejas virs DPI?
Nē, diemžēl izmest (un pat tikai spoguļattēlu) 40+gb/s nebūt nav triviāli.
Pēc šī, vakarā, nekas cits neatlika, kā atgriezties pie dīvainas filtrācijas pieņēmuma kaut kur augšā.
Paskatījos caur kuru IX tagad iet trafika uz MRG tīkliem un vienkārši atcēlu tam bgp sesijas. Un - lūk, lūk! - viss uzreiz atgriezās normālā stāvoklī 🙁
No vienas puses, žēl, ka visa diena tika pavadīta, meklējot problēmu, lai gan tā tika atrisināta piecās minūtēs.
No otras puses:
— manā atmiņā tas ir bezprecedenta lieta. Kā jau rakstīju augstāk – IX tiešām nav jēgas filtrēt tranzīta satiksmi. Viņiem parasti ir simtiem gigabitu/terabitu sekundē. Es vienkārši nevarēju kaut ko tādu nopietni iedomāties vēl nesen.
— neticami laimīga apstākļu sakritība: jauna sarežģīta aparatūra, kurai nav īpaši uzticama un no kuras nav skaidrs, ko var sagaidīt — īpaši pielāgota resursu, tostarp TCP RST, bloķēšanai.
Šīs interneta biržas NOC pašlaik meklē problēmu. Pēc viņu domām (un es viņiem ticu), viņiem nav nekādas īpaši izvietotas filtrēšanas sistēmas. Bet, paldies debesīm, tālākie meklējumi vairs nav mūsu problēma :)
Šis bija neliels mēģinājums sevi attaisnot, lūdzu saproti un piedod :)
PS: es apzināti nenosaucu DPI/NAT vai IX ražotāju (patiesībā man pat nav īpašu sūdzību par tiem, galvenais ir saprast, kas tas bija)
Šodienas (kā arī vakardienas un aizvakardienas) realitāte interneta pakalpojumu sniedzēja skatījumā
Pēdējās nedēļas esmu pavadījis būtiski pārbūvējot tīkla kodolu, veicot virkni manipulāciju “peļņas nolūkos”, riskējot būtiski ietekmēt reāllaika lietotāju trafiku. Ņemot vērā šī visa mērķus, rezultātus un sekas, morāli tas viss ir diezgan grūti. Īpaši - kārtējo reizi klausoties skaistas runas par Runetes stabilitātes sargāšanu, suverenitāti utt. un tā tālāk.
Šajā sadaļā es mēģināšu aprakstīt tipiska ISP tīkla kodola “evolūciju” pēdējo desmit gadu laikā.
Pirms desmit gadiem.
Tajos svētīgajos laikos pakalpojumu sniedzēja tīkla kodols varētu būt tikpat vienkāršs un uzticams kā satiksmes sastrēgums:
Šajā ļoti, ļoti vienkāršotajā attēlā nav stumbru, gredzenu, ip/mpls maršrutēšanas.
Tās būtība ir tāda, ka lietotāju datplūsma galu galā nonāca kodola līmeņa pārslēgšanās vietā — no kurienes tā nonāca , no kurienes, kā likums, atpakaļ uz galveno pārslēgšanu un pēc tam “ārā” - caur vienu vai vairākiem robežas vārtejiem uz internetu.
Šādu shēmu ir ļoti, ļoti viegli rezervēt gan L3 (dinamiskā maršrutēšana), gan L2 (MPLS).
Varat instalēt N+1 jebko: piekļūt serveriem, slēdžiem, robežām un vienā vai otrā veidā rezervēt tos automātiskai kļūmjpārlēcei.
Pēc dažiem gadiem Ikvienam Krievijā kļuva skaidrs, ka tā dzīvot vairs nav iespējams: bija steidzami jāpasargā bērni no interneta kaitīgās ietekmes.
Steidzami bija jāatrod veidi, kā filtrēt lietotāju trafiku.
Šeit ir dažādas pieejas.
Ne pārāk labā gadījumā kaut kas tiek ievietots “plaisā”: starp lietotāju trafiku un internetu. Tiek analizēta trafika, kas iet caur šo “kaut ko”, un, piemēram, uz abonentu tiek nosūtīta viltota pakete ar novirzīšanu.
Nedaudz labākā gadījumā - ja trafika apjoms atļauj - ar ausīm var izdarīt nelielu triku: nosūtīt filtrēšanai tikai trafiku, kas nāk no lietotājiem tikai uz tām adresēm, kuras ir jāfiltrē (lai to izdarītu, varat ņemt IP adreses no reģistra vai papildus atrisiniet esošos domēnus reģistrā).
Savulaik šiem nolūkiem es uzrakstīju vienkāršu - lai gan es pat neuzdrošinos viņu tā saukt. Tas ir ļoti vienkāršs un ne pārāk produktīvs - tomēr tas ļāva mums un desmitiem (ja ne simtiem) citu pakalpojumu sniedzēju nekavējoties neiztērēt miljonus par rūpnieciskajām DPI sistēmām, bet deva vairākus papildu gadus.
Starp citu, par toreizējo un pašreizējo DPIStarp citu, daudzi, kas tolaik iegādājās tirgū pieejamās DPI sistēmas, tās jau bija izmetuši. Nu, tie nav paredzēti šim nolūkam: simtiem tūkstošu adrešu, desmitiem tūkstošu URL.
Un tajā pašā laikā vietējie ražotāji ir ļoti spēcīgi pacēlušies uz šo tirgu. Es nerunāju par aparatūras komponentu - šeit visiem viss ir skaidrs, bet programmatūra - galvenais, kas ir DPI - šodien, iespējams, ir ja ne vismodernākā pasaulē, tad noteikti a) attīstās lēcieniem un robežām, un b) par iepakotas preces cenu - vienkārši nesalīdzināma ar ārvalstu konkurentiem.
Gribētos lepoties, bet mazliet skumji =)
Tagad viss izskatījās šādi:
Vēl pēc pāris gadiem visiem jau bija auditori; Reģistrā bija arvien vairāk resursu. Dažām vecākām iekārtām (piemēram, Cisco 7600) “sānu filtrēšanas” shēma vienkārši kļuva nepiemērota: maršrutu skaits uz 76 platformām ir ierobežots līdz aptuveni deviņsimt tūkstošiem, savukārt IPv4 maršrutu skaits vien šodien tuvojas 800. tūkst. Un ja tas ir arī ipv6... Un arī... cik tur ir? 900000 XNUMX individuālu adrešu RKN aizliegumā? =)
Kāds pārgāja uz shēmu ar visas mugurkaula trafika atspoguļošanu uz filtrēšanas serveri, kam jāanalizē visa plūsma un, ja tiek atrasts kaut kas slikts, jānosūta RST abos virzienos (sūtītājs un saņēmējs).
Tomēr, jo vairāk satiksmes, jo mazāk piemērojama šī shēma. Ja apstrāde tiek aizkavēta, spoguļattēls vienkārši nepamanīti lidos garām, un pakalpojumu sniedzējs saņems smalku ziņojumu.
Arvien vairāk pakalpojumu sniedzēju uz lielceļiem ir spiesti instalēt dažādas uzticamības pakāpes DPI sistēmas.
Pirms gada vai diviem saskaņā ar baumām gandrīz visa FSB sāka pieprasīt faktisku aprīkojuma uzstādīšanu (iepriekš lielākā daļa pakalpojumu sniedzēju tika pārvaldīti ar iestāžu apstiprinājumu SORM plāns - operatīvo pasākumu plāns, ja nepieciešams kaut kur kaut ko atrast)
Papildus naudai (ne gluži pārmērīgi, bet tomēr miljoniem), SORM prasīja vēl daudzas manipulācijas ar tīklu.
- Pirms nat tulkošanas SORM ir jāredz “pelēkās” lietotāju adreses
- SORM ir ierobežots tīkla saskarņu skaits
Tāpēc jo īpaši mums bija ļoti jāpārbūvē daļa no kodola - vienkārši, lai savāktu lietotāju trafiku uz piekļuves serveriem kaut kur vienuviet. Lai to atspoguļotu SORM ar vairākām saitēm.
Tas ir, ļoti vienkāršoti, tas bija (pa kreisi) pret kļuva (pa labi):
Tagad Lielākā daļa pakalpojumu sniedzēju pieprasa arī SORM-3 ieviešanu, kas cita starpā ietver nat apraides reģistrēšanu.
Šiem nolūkiem mums bija arī jāpievieno atsevišķs NAT aprīkojums iepriekš redzamajai diagrammai (tieši tas, kas ir apspriests pirmajā daļā). Turklāt pievienojiet noteiktā secībā: tā kā SORM ir “jāredz” trafiks pirms adrešu tulkošanas, trafikam ir jānotiek stingri šādi: lietotāji -> pārslēgšana, kodols -> piekļuves serveri -> SORM -> NAT -> pārslēgšana, kodols - > Internets. Lai to izdarītu, peļņas nolūkos bija burtiski “jāpagriež” satiksmes plūsmas otrā virzienā, kas arī bija diezgan grūti.
Rezumējot: pēdējo desmit gadu laikā vidusmēra pakalpojumu sniedzēja galvenais dizains ir kļuvis daudzkārt sarežģītāks, un ievērojami palielinājušies papildu atteices punkti (gan aprīkojuma, gan atsevišķu komutācijas līniju veidā). Patiesībā pati prasība “redzēt visu” nozīmē šī “visa” samazināšanu līdz vienam punktam.
Es domāju, ka to var diezgan pārredzami ekstrapolēt uz pašreizējām iniciatīvām, lai padarītu Runet suverenu, aizsargātu, stabilizētu un uzlabotu to :)
Un Yarovaya joprojām ir priekšā.
Avots: www.habr.com
