Disaranake aku menyang kirim iki .
Aku quote kene:
dina iki jam 18:53
Aku seneng karo panyedhiya dina iki. Bebarengan karo nganyari sistem pamblokiran situs, mailer mail.ru dheweke dilarang. Aku wis nelpon dhukungan teknis wiwit esuk, nanging ora bisa nindakake apa-apa. Panyedhiya iku cilik, lan ketoke panyedhiya peringkat sing luwih dhuwur ngalangi. Aku uga ngeweruhi slowdown ing bukaan kabeh situs, Mungkin padha diinstal sawetara jenis DLP bengkong? Sadurunge ora ana masalah karo akses. Karusakan RuNet kedadeyan ing ngarepku ...
Kasunyatane kayane kita minangka panyedhiya sing padha :)
Lan tenan, Aku meh ngira-ngira penyebab masalah karo mail.ru (sanajan kita ora gelem ngandel babagan perkara kasebut kanggo wektu sing suwe).
Ing ngisor iki bakal dipérang dadi rong bagéan:
- alesan kanggo masalah kita saiki karo mail.ru lan nggoleki macem kanggo nggoleki
- eksistensi ISP ing kasunyatan saiki, stabilitas RuNet berdaulat.
Masalah aksesibilitas karo mail.ru
Oh, critane cukup dawa.
Kasunyatane yaiku supaya bisa ngetrapake syarat negara (rincian liyane ing bagean kapindho), kita tuku, ngatur, lan nginstal sawetara peralatan - kanggo nyaring sumber daya sing dilarang lan kanggo implementasine. langganan.
Sawetara wektu kepungkur, pungkasane kita mbangun inti jaringan kanthi cara sing kabeh lalu lintas pelanggan ngliwati peralatan iki kanthi bener ing arah sing bener.
Sawetara dina kepungkur, kita ngaktifake nyaring sing dilarang (nalika ninggalake sistem lawas sing digunakake) - kabeh katon apik.
Sabanjure, mboko sithik wiwit ngaktifake NAT ing peralatan iki kanggo macem-macem bagean saka pelanggan. Saka katon, kabeh uga katon apik.
Nanging dina iki, wis ngaktifake NAT ing peralatan kanggo bagean sabanjure pelanggan, wiwit esuk banget kita wis ngadhepi karo nomer prayoga saka keluhan bab kasedhiyan utawa kasedhiyan sebagean. lan sumber liyane Mail Ru Group.
Padha wiwit mriksa: soko nang endi wae kadhangkala, sok-sok wae ngirim kanggo nanggepi panjalukan khusus kanggo jaringan mail.ru. Menapa malih, iku ngirim salah kui (tanpa ACK), temenan Ponggawa TCP RST. Iki sing katon kaya:
Mesthi, pikirane pisanan babagan peralatan anyar: DPI sing nggegirisi, ora percaya, sampeyan ora ngerti apa sing bisa ditindakake - sawise kabeh, TCP RST minangka perkara sing umum ing antarane alat pamblokiran.
Panyangka Kita uga nganggep manawa ana wong sing "unggul" nyaring, nanging langsung dibuwang.
Kaping pisanan, kita duwe uplink sing cukup waras supaya kita ora kudu nandhang sangsara kaya iki :)
Kapindho, kita disambungake menyang sawetara ing Moskow, lan lalu lintas menyang mail.ru ngliwati wong-wong mau - lan ora duwe tanggung jawab utawa motif liyane kanggo nyaring lalu lintas.
Setengah dina sabanjure digunakake kanggo apa sing biasane diarani shamanisme - bebarengan karo vendor peralatan, sing kita matur nuwun, dheweke ora nyerah :)
- nyaring rampung dipatèni
- NAT dipateni nggunakake skema anyar
- PC test diselehake ing blumbang kapisah kapisah
- Alamat IP diganti
Ing wayah sore, mesin virtual diparengake sing disambungake menyang jaringan miturut skema pangguna biasa, lan wakil vendor diwenehi akses menyang lan peralatan kasebut. Dukun terus :)
Pungkasane, wakil vendor kanthi yakin nyatakake yen hardware pancen ora ana hubungane karo: sing pertama teka saka papan sing luwih dhuwur.
komentarIng jalur iki, wong bisa ngomong: nanging luwih gampang kanggo njupuk mbucal ora saka PC test, nanging saka dalan gedhe ndhuwur DPI?
Ora, sayangé, njupuk mbucal (lan malah mung mirroring) 40+gbps ora sepele.
Sawise iki, ing wayah sore, ora ana sing kudu ditindakake kajaba bali menyang asumsi filtrasi aneh ing endi wae ing ndhuwur.
Aku nggoleki IX lalu lintas menyang jaringan MRG saiki lan mung mbatalake sesi bgp kasebut. Lan - lah lan lah! - kabeh langsung bali normal 🙁
Ing tangan siji, isin yen sedina muput nggoleki masalah kasebut, sanajan wis rampung ing limang menit.
Ing sisih liyane:
- ing memoriku iki minangka perkara sing durung ana sadurunge. Kaya sing wis daktulis ing ndhuwur - IX tenan ora ana gunane nyaring lalu lintas transit. Biasane duwe atusan gigabit / terabit per detik. Aku mung ora bisa mbayangno kaya iki nganti saiki.
- kebetulan sing luar biasa untung saka kahanan: hardware komplèks anyar sing ora dipercaya lan ora jelas apa sing bisa diarep-arep - dirancang khusus kanggo pamblokiran sumber daya, kalebu TCP RST
NOC saka ijol-ijolan internet iki lagi nggoleki masalah. Miturut dheweke (lan aku percaya), dheweke ora duwe sistem filtrasi khusus. Nanging, matur nuwun swarga, upaya luwih lanjut ora dadi masalah :)
Iki minangka upaya cilik kanggo mbenerake aku, muga-muga ngerti lan ngapura :)
PS: Aku sengaja ora menehi jeneng pabrikan DPI / NAT utawa IX (nyatane, aku ora duwe keluhan khusus babagan dheweke, sing utama yaiku ngerti apa iku)
Kasunyatan saiki (uga wingi lan dina sadurunge wingi) saka sudut pandang panyedhiya Internet
Aku wis ngginakaken minggu pungkasan Ngartekno mbangun maneh inti saka jaringan, Performing Bunch saka manipulations "kanggo MediaWiki", karo resiko Ngartekno mengaruhi lalu lintas pangguna urip. Ngelingi gol, asil lan akibat saka kabeh iki, morally iku kabeh cukup angel. Utamane - maneh ngrungokake pidato sing apik babagan nglindhungi stabilitas Runet, kedaulatan, lan liya-liyane. lan liya-liyane.
Ing bagean iki, aku bakal nyoba njlèntrèhaké "évolusi" inti jaringan saka ISP khas sajrone sepuluh taun kepungkur.
Sepuluh taun kepungkur.
Ing wektu sing diberkahi, inti saka jaringan panyedhiya bisa dadi prasaja lan dipercaya kaya macet:
Ing gambar iki banget, banget prasaja, ora ana trunks, dering, ip / mpls nuntun.
Intine yaiku lalu lintas pangguna pungkasane teka ing level kernel switching - saka ngendi dheweke lunga , saka ngendi, minangka aturan, bali menyang ngoper inti, banjur "metu" - liwat siji utawa luwih gateway wewatesan menyang Internet.
Skema kasebut gampang banget kanggo cadangan ing L3 (rute dinamis) lan ing L2 (MPLS).
Sampeyan bisa nginstal N + 1 saka apa wae: ngakses server, switch, wates - lan siji utawa liyane cadangan kanggo failover otomatis.
Sawise sawetara taun Dadi cetha kanggo kabeh wong ing Rusia yen ora bisa urip kaya iki maneh: penting banget kanggo nglindhungi bocah saka pengaruh Internet sing mbebayani.
Ana kabutuhan sing penting kanggo golek cara kanggo nyaring lalu lintas pangguna.
Ana macem-macem pendekatan ing kene.
Ing kasus sing ora apik, ana sing dilebokake "ing celah": antarane lalu lintas pangguna lan Internet. Lalu lintas sing ngliwati "sesuatu" iki dianalisis lan, contone, paket palsu kanthi pangalihan dikirim menyang pelanggan.
Ing kasus sing rada apik - yen volume lalu lintas ngidini - sampeyan bisa nindakake trik cilik nganggo kuping: ngirim kanggo nyaring mung lalu lintas sing asale saka pangguna mung menyang alamat sing kudu disaring (kanggo nindakake iki, sampeyan bisa njupuk alamat IP. ditemtokake ana saka pendaptaran, utawa uga mutusake masalah domain sing wis ana ing pendaptaran).
Ing sawijining wektu, kanggo tujuan kasebut, aku nulis prasaja - sanajan aku ora wani nelpon dheweke. Iku banget prasaja lan ora banget produktif - Nanging, ngidini kita lan Welasan (yen ora atusan) panyedhiya liyane ora langsung Shell metu yuta ing sistem DPI industri, nanging menehi sawetara taun tambahan wektu.
Miturut cara, babagan DPI saiki lan saikiMiturut cara, akeh sing tuku sistem DPI sing kasedhiya ing pasar nalika iku wis dibuwang. Ya, padha ora dirancang kanggo iki: atusan ewu alamat, puluhan ewu URL.
Lan ing wektu sing padha, prodhusèn domestik wis mundhak banget ing pasar iki. Aku ora ngomong babagan komponen hardware - kabeh wis jelas kanggo kabeh wong ing kene, nanging piranti lunak - perkara utama sing diduweni DPI - bisa uga saiki, yen ora paling maju ing donya, mula mesthine a) berkembang kanthi cepet, lan b) ing rega produk kothak - mung incomparable karo saingan manca.
Aku pengen bangga, tapi rada sedih =))
Saiki kabeh katon kaya iki:
Ing saperangan taun maneh kabeh wong wis duwe auditor; Ana sumber daya liyane lan liyane ing pendaptaran. Kanggo sawetara peralatan lawas (contone, Cisco 7600), skema "nyaring sisih" mung dadi ora bisa ditrapake: jumlah rute ing 76 platform diwatesi nganti sangang atus ewu, dene jumlah rute IPv4 saiki wis nyedhaki 800. ewu. Lan yen uga ipv6 ... Lan uga ... pinten ana? 900000 alamat individu ing larangan RKN? =)
Ana sing ngalih menyang skema kanthi mirroring kabeh lalu lintas backbone menyang server panyaring, sing kudu nganalisa kabeh aliran lan, yen ana sing ala, ngirim RST ing loro arah (pangirim lan panampa).
Nanging, luwih akeh lalu lintas, skema iki kurang ditrapake. Yen ana wektu tundha paling sethithik ing proses, lalu lintas sing dicerminake mung bakal mabur tanpa digatekake, lan panyedhiya bakal nampa laporan sing apik.
Panyedhiya liyane lan liyane kepeksa nginstal sistem DPI kanthi tingkat linuwih sing beda-beda ing dalan gedhe.
Setaun utawa rong taun kepungkur miturut gosip, meh kabeh FSB wiwit nuntut instalasi nyata saka peralatan (sadurunge, umume panyedhiya ngatur kanthi persetujuan saka panguwasa rencana SORM - rencana langkah-langkah operasional yen perlu golek barang ing endi wae)
Saliyane dhuwit (ora persis banget, nanging isih mayuta-yuta), SORM mbutuhake luwih akeh manipulasi karo jaringan.
- SORM kudu ndeleng alamat pangguna "abu-abu" sadurunge terjemahan nat
- SORM duwe sawetara antarmuka jaringan sing winates
Mulane, utamane, kita kudu mbangun maneh sepotong kernel - mung kanggo ngumpulake lalu lintas pangguna menyang server akses nang endi wae ing sak panggonan. Supaya kaca ing SORM karo sawetara pranala.
Sing, banget prasaja, iku (kiwa) vs dadi (tengen):
Saiki Umume panyedhiya uga mbutuhake implementasi SORM-3 - sing kalebu, ing antarane, logging siaran nat.
Kanggo tujuan kasebut, kita uga kudu nambah peralatan sing kapisah kanggo NAT menyang diagram ing ndhuwur (persis sing dibahas ing bagean pisanan). Kajaba iku, tambahake urutan tartamtu: amarga SORM kudu "ndeleng" lalu lintas sadurunge nerjemahake alamat, lalu lintas kudu kaya ing ngisor iki: pangguna -> ngoper, kernel -> server akses -> SORM -> NAT -> ngoper, kernel - > Internet. Kanggo nindakake iki, kita kudu "nguripake" aliran lalu lintas ing arah liya kanggo entuk bathi, sing uga angel banget.
Ringkesan: sajrone sepuluh taun kepungkur, desain inti saka panyedhiya rata-rata wis dadi luwih rumit, lan titik kegagalan tambahan (loro ing bentuk peralatan lan ing bentuk garis saklar tunggal) saya tambah akeh. Bener, syarat banget kanggo "ndeleng kabeh" tegese nyuda "kabeh" iki dadi siji titik.
Aku mikir iki bisa diekstrapolasi kanthi transparan kanggo inisiatif saiki kanggo nguwasani Runet, nglindhungi, nyetabilake lan nambah :)
Lan Yarovaya isih ngarep.
Source: www.habr.com