Nag-prompt sa akin sa post na ito .
quote ko dito:
ngayon sa 18:53
Natuwa ako sa provider ngayon. Kasabay ng pag-update ng site blocking system, ang kanyang mailer mail.ru ay na-ban. Tumawag ako ng teknikal na suporta mula pa noong umaga, ngunit wala silang magagawa. Maliit ang provider, at tila hinaharangan ito ng mga provider na may mataas na ranggo. Napansin ko rin ang paghina sa pagbubukas ng lahat ng mga site, marahil ay nag-install sila ng ilang uri ng baluktot na DLP? Dati walang problema sa pag-access. Ang pagkasira ng RuNet ay nangyayari sa harap ng aking mga mata...
Ang katotohanan ay tila kami ay ang parehong provider :)
At walang pag aalinlangan, Halos nahulaan ko ang sanhi ng mga problema sa mail.ru (bagaman tumanggi kaming maniwala sa ganoong bagay sa loob ng mahabang panahon).
Ang mga sumusunod ay mahahati sa dalawang bahagi:
- ang mga dahilan para sa aming kasalukuyang mga problema sa mail.ru at ang kapana-panabik na paghahanap upang mahanap ang mga ito
- ang pagkakaroon ng ISP sa mga realidad ngayon, ang katatagan ng soberanong RuNet.
Mga problema sa accessibility sa mail.ru
Oh, medyo mahabang kwento.
Ang katotohanan ay upang maipatupad ang mga kinakailangan ng estado (higit pang mga detalye sa ikalawang bahagi), bumili kami, na-configure, at nag-install ng ilang kagamitan - kapwa para sa pag-filter ng mga ipinagbabawal na mapagkukunan at para sa pagpapatupad mga subscriber.
Ilang oras na ang nakalipas, sa wakas ay itinayong muli namin ang core ng network sa paraang ang lahat ng trapiko ng subscriber ay dumaan sa kagamitang ito nang mahigpit sa tamang direksyon.
Ilang araw na ang nakalipas na-on namin ang ipinagbabawal na pag-filter dito (habang iniiwan ang lumang sistema na gumagana) - tila maayos ang lahat.
Susunod, unti-unti nilang sinimulan na paganahin ang NAT sa kagamitang ito para sa iba't ibang bahagi ng mga subscriber. Sa hitsura nito, tila naging maayos din ang lahat.
Ngunit ngayon, na pinagana ang NAT sa kagamitan para sa susunod na bahagi ng mga tagasuskribi, mula sa umaga ay nahaharap kami sa isang disenteng bilang ng mga reklamo tungkol sa kawalan ng kakayahang magamit o bahagyang kakayahang magamit. at iba pang mapagkukunan ng Mail Ru Group.
Sinimulan nilang suriin: isang bagay sa isang lugar kung minsan, paminsan-minsan nagpapadala bilang tugon sa mga kahilingan na eksklusibo sa mail.ru network. Bukod dito, nagpapadala ito ng maling nabuo (walang ACK), malinaw na artipisyal na TCP RST. Ito ang hitsura nito:
Naturally, ang mga unang iniisip ay tungkol sa bagong kagamitan: kahila-hilakbot na DPI, walang tiwala dito, hindi mo alam kung ano ang magagawa nito - pagkatapos ng lahat, ang TCP RST ay isang medyo pangkaraniwang bagay sa mga tool sa pagharang.
Palagay Iniharap din namin ang ideya na may "superior" ang nag-filter, ngunit agad itong itinapon.
Una, mayroon tayong sapat na mga uplink upang hindi tayo magdusa ng ganito :)
Pangalawa, konektado kami sa ilan sa Moscow, at ang trapiko sa mail.ru ay dumadaan sa kanila - at wala silang mga responsibilidad o anumang iba pang motibo upang i-filter ang trapiko.
Ang susunod na kalahati ng araw ay ginugol sa karaniwang tinatawag na shamanism - kasama ang nagbebenta ng kagamitan, kung saan pinasasalamatan namin sila, hindi sila sumuko :)
- ganap na hindi pinagana ang pag-filter
- Na-disable ang NAT gamit ang bagong scheme
- ang test PC ay inilagay sa isang hiwalay na nakahiwalay na pool
- Binago ang IP addressing
Sa hapon, ang isang virtual machine ay inilaan na konektado sa network ayon sa pamamaraan ng isang regular na gumagamit, at ang mga kinatawan ng vendor ay binigyan ng access dito at ang kagamitan. Nagpatuloy ang shamanism :)
Sa huli, kumpiyansa na sinabi ng kinatawan ng vendor na ang hardware ay talagang walang kinalaman dito: ang mga una ay nagmumula sa mas mataas na lugar.
NotaSa puntong ito, maaaring sabihin ng isang tao: ngunit mas madaling kumuha ng dump hindi mula sa test PC, ngunit mula sa highway sa itaas ng DPI?
Hindi, sa kasamaang-palad, ang pagtatapon (at kahit na pag-mirror lang) ng 40+gbps ay hindi mahalaga.
Pagkatapos nito, sa gabi, wala nang magagawa kundi bumalik sa pag-aakala ng kakaibang pagsasala sa isang lugar sa itaas.
Tiningnan ko kung saan IX dinadaanan ngayon ng trapiko sa MRG network at kinansela lang ang mga bgp session dito. At - narito at narito! - bumalik agad sa normal ang lahat π
Sa isang banda, isang kahihiyan na ang buong araw ay ginugol sa paghahanap para sa problema, kahit na ito ay nalutas sa loob ng limang minuto.
Sa kabilang banda:
β sa aking alaala ito ay isang bagay na hindi pa nagagawa. Tulad ng naisulat ko na sa itaas - IX talaga walang kwenta sa pagsala ng trapiko ng transit. Karaniwang mayroon silang daan-daang gigabits/terabits bawat segundo. Hindi ko lang maisip ang isang bagay na ganito hanggang kamakailan lamang.
β isang hindi kapani-paniwalang mapalad na pagkakataon ng mga pangyayari: isang bagong kumplikadong hardware na hindi partikular na pinagkakatiwalaan at kung saan hindi malinaw kung ano ang maaaring asahan β partikular na iniakma para sa pagharang ng mga mapagkukunan, kabilang ang mga TCP RST
Ang NOC ng internet exchange na ito ay kasalukuyang naghahanap ng problema. Ayon sa kanila (at naniniwala ako sa kanila), wala silang anumang espesyal na naka-deploy na sistema ng pagsasala. Ngunit, salamat sa langit, ang karagdagang paghahanap ay hindi na aming problema :)
Ito ay isang maliit na pagtatangka upang bigyang-katwiran ang aking sarili, mangyaring unawain at patawarin :)
PS: Sinadya kong hindi pinangalanan ang tagagawa ng DPI/NAT o IX (sa katunayan, wala akong anumang mga espesyal na reklamo tungkol sa kanila, ang pangunahing bagay ay upang maunawaan kung ano ito)
Ang katotohanan ngayon (pati na rin ang kahapon at ang araw bago ang kahapon) mula sa pananaw ng isang Internet provider
Ginugol ko ang mga huling linggo nang makabuluhang muling itayo ang core ng network, nagsasagawa ng isang grupo ng mga manipulasyon "para sa kita", na may panganib na makabuluhang makaapekto sa live na trapiko ng user. Kung isasaalang-alang ang mga layunin, mga resulta at mga kahihinatnan ng lahat ng ito, sa moral, ang lahat ng ito ay medyo mahirap. Lalo na - muling nakikinig sa magagandang talumpati tungkol sa pagprotekta sa katatagan ng Runet, soberanya, atbp. at iba pa.
Sa seksyong ito, susubukan kong ilarawan ang "ebolusyon" ng network core ng isang tipikal na ISP sa nakalipas na sampung taon.
Sampung taon na ang nakalipas.
Sa mga pinagpalang panahong iyon, ang ubod ng isang network ng tagapagkaloob ay maaaring kasing simple at maaasahan gaya ng masikip na trapiko:
Sa napakasimpleng larawang ito, walang trunks, ring, ip/mpls routing.
Ang kakanyahan nito ay ang trapiko ng gumagamit sa huli ay dumating sa paglipat ng antas ng kernel - mula sa kung saan ito napunta , mula sa kung saan, bilang panuntunan, bumalik sa core switching, at pagkatapos ay "out" - sa pamamagitan ng isa o higit pang mga gateway ng hangganan sa Internet.
Ang ganitong pamamaraan ay napakadaling ireserba pareho sa L3 (dynamic na pagruruta) at sa L2 (MPLS).
Maaari kang mag-install ng N+1 ng anumang bagay: i-access ang mga server, switch, border - at sa isang paraan o iba pa, ireserba ang mga ito para sa awtomatikong failover.
Pagkaraan ng ilang taon Naging malinaw sa lahat sa Russia na imposibleng mamuhay nang ganito: ito ay kagyat na protektahan ang mga bata mula sa nakapipinsalang impluwensya ng Internet.
Nagkaroon ng agarang pangangailangan na maghanap ng mga paraan upang i-filter ang trapiko ng user.
Mayroong iba't ibang mga diskarte dito.
Sa isang hindi masyadong magandang kaso, may inilalagay "sa puwang": sa pagitan ng trapiko ng user at ng Internet. Ang trapikong dumadaan sa "isang bagay" na ito ay sinusuri at, halimbawa, isang pekeng packet na may redirect ay ipinadala patungo sa subscriber.
Sa isang bahagyang mas mahusay na kaso - kung pinapayagan ang dami ng trapiko - maaari kang gumawa ng isang maliit na trick gamit ang iyong mga tainga: ipadala para sa pag-filter lamang ng trapiko na nagmumula sa mga user lamang sa mga address na kailangang i-filter (upang magawa ito, maaari mong kunin ang mga IP address tinukoy doon mula sa registry, o bilang karagdagan, lutasin ang mga umiiral nang domain sa registry).
Sa isang pagkakataon, para sa mga layuning ito, nagsulat ako ng isang simple - kahit na hindi ako maglakas-loob na tawagin siya ng ganoon. Ito ay napaka-simple at hindi masyadong produktibo - gayunpaman, pinahintulutan kami at ang dose-dosenang (kung hindi man daan-daan) ng iba pang mga provider na hindi agad maglabas ng milyun-milyon sa mga pang-industriyang DPI system, ngunit nagbigay ng ilang karagdagang taon ng oras.
Sa pamamagitan ng paraan, tungkol sa noon at kasalukuyang DPISa pamamagitan ng paraan, marami sa mga bumili ng mga sistema ng DPI na magagamit sa merkado sa oras na iyon ay itinapon na ang mga ito. Well, hindi sila idinisenyo para dito: daan-daang libong mga address, sampu-sampung libong mga URL.
At sa parehong oras, ang mga domestic producer ay tumaas nang napakalakas sa merkado na ito. Hindi ko pinag-uusapan ang bahagi ng hardware - ang lahat ay malinaw sa lahat dito, ngunit ang software - ang pangunahing bagay na mayroon ang DPI - ay marahil ngayon, kung hindi man ang pinaka-advanced sa mundo, kung gayon ay tiyak na a) umuunlad nang mabilis, at b) sa presyo ng isang naka-box na produkto - simpleng hindi maihahambing sa mga dayuhang kakumpitensya.
Gusto kong ipagmalaki, pero medyo malungkot =)
Ngayon ang lahat ay mukhang ganito:
Sa loob ng ilang taon lahat ay mayroon nang mga auditor; Nagkaroon ng higit at higit pang mga mapagkukunan sa pagpapatala. Para sa ilang mas lumang kagamitan (halimbawa, Cisco 7600), ang scheme ng "side-filtering" ay naging hindi naaangkop: ang bilang ng mga ruta sa 76 na mga platform ay limitado sa isang bagay tulad ng siyam na raang libo, habang ang bilang ng mga ruta ng IPv4 lamang ngayon ay papalapit na sa 800 libo. At kung ipv6 din... At saka... magkano ang meron? 900000 indibidwal na address sa RKN ban? =)
May lumipat sa isang scheme na may pagsasalamin ng lahat ng backbone na trapiko sa isang filtering server, na dapat suriin ang buong daloy at, kung may makitang hindi maganda, magpadala ng RST sa parehong direksyon (nagpadala at tatanggap).
Gayunpaman, kung mas maraming trapiko, hindi gaanong naaangkop ang scheme na ito. Kung may kaunting pagkaantala sa pagproseso, ang na-mirror na trapiko ay lilipad nang hindi napapansin, at ang provider ay makakatanggap ng magandang ulat.
Parami nang paraming provider ang napipilitang mag-install ng mga DPI system na may iba't ibang antas ng pagiging maaasahan sa mga highway.
Isang taon o dalawang taon na ang nakalipas ayon sa mga alingawngaw, halos lahat ng FSB ay nagsimulang humingi ng aktwal na pag-install ng kagamitan (noon, karamihan sa mga provider ay pinamamahalaan nang may pag-apruba mula sa mga awtoridad plano ng SORM - isang plano ng mga hakbang sa pagpapatakbo sa kaso ng pangangailangan upang makahanap ng isang bagay sa isang lugar)
Bilang karagdagan sa pera (hindi eksaktong labis, ngunit milyon-milyon pa rin), ang SORM ay nangangailangan ng higit pang mga manipulasyon sa network.
- Kailangang makita ng SORM ang mga "grey" na address ng user bago ang nat translation
- Ang SORM ay may limitadong bilang ng mga interface ng network
Samakatuwid, sa partikular, kinailangan naming lubos na buuin ang isang piraso ng kernel - para lamang mangolekta ng trapiko ng gumagamit sa mga server ng pag-access sa isang lugar sa isang lugar. Upang i-mirror ito sa SORM na may ilang mga link.
Ibig sabihin, napakasimple, ito ay (kaliwa) vs naging (kanan):
Ngayon Karamihan sa mga provider ay nangangailangan din ng pagpapatupad ng SORM-3 - na kinabibilangan, bukod sa iba pang mga bagay, pag-log ng nat broadcast.
Para sa mga layuning ito, kailangan din naming magdagdag ng hiwalay na kagamitan para sa NAT sa diagram sa itaas (eksaktong kung ano ang tinalakay sa unang bahagi). Dagdag pa rito, magdagdag sa isang tiyak na pagkakasunud-sunod: dahil ang SORM ay dapat "makita" ang trapiko bago isalin ang mga address, ang trapiko ay dapat pumunta nang mahigpit tulad ng sumusunod: mga user -> switching, kernel -> access server -> SORM -> NAT -> switching, kernel - > Internet. Para magawa ito, kailangan naming literal na "iikot" ang mga daloy ng trapiko sa kabilang direksyon para kumita, na medyo mahirap din.
Sa buod: sa nakalipas na sampung taon, ang pangunahing disenyo ng isang karaniwang provider ay naging maraming beses na mas kumplikado, at ang mga karagdagang punto ng pagkabigo (kapwa sa anyo ng kagamitan at sa anyo ng mga solong linya ng paglipat) ay tumaas nang malaki. Sa totoo lang, ang mismong pangangailangan na "makita ang lahat" ay nagpapahiwatig ng pagbabawas ng "lahat" na ito sa isang punto.
Sa palagay ko ito ay maaaring maging malinaw na i-extrapolated sa mga kasalukuyang inisyatiba upang gawing soberanya ang Runet, protektahan ito, patatagin ito at pagbutihin ito :)
At nauuna pa rin si Yarovaya.
Pinagmulan: www.habr.com