Sebuah jawaban terperinci untuk komentar tersebut, serta sedikit tentang kehidupan penyedia di Federasi Rusia

Pindahkan saya ke posting ini yang ini adalah komentar .

Saya membawanya ke sini:

kaleman hari ini jam 18:53

Hari ini saya senang dengan provider. Seiring dengan memperbarui sistem pemblokiran situs, ia mendapat mailer mail.ru di bawah larangan. Di pagi hari saya menarik dukungan teknis, mereka tidak dapat melakukan apa pun. Penyedia kecil, dan tampaknya penyedia hulu memblokirnya. Saya juga melihat perlambatan dalam pembukaan semua situs, mungkin semacam DLP kurva digantung? Sebelumnya, tidak ada masalah dengan akses. Kehancuran Runet tepat di depan mataku ...

Faktanya adalah, tampaknya, kami adalah penyedia :(

Memang, kaleman hampir menebak dengan penyebab masalah dengan mail.ru (meskipun untuk waktu yang lama kami menolak untuk percaya pada hal seperti itu).

Selanjutnya akan dibagi menjadi dua bagian:

1. penyebab masalah kita hari ini dengan mail.ru dan pencarian yang menarik untuk menemukannya
2. keberadaan ISP dalam realitas saat ini, stabilitas sovereign runet.

Masalah dengan ketersediaan mail.ru

Oh, itu cerita yang cukup panjang.

Faktanya adalah bahwa untuk mengimplementasikan persyaratan negara (lebih terinci di bagian kedua), kami membeli, mengkonfigurasi, memasang beberapa peralatan - baik untuk menyaring sumber daya terlarang dan untuk melakukan siaran NAT pelanggan.

Beberapa waktu yang lalu, kami akhirnya membangun kembali inti jaringan sehingga semua lalu lintas pelanggan melewati peralatan ini ke arah yang benar.

Beberapa hari yang lalu kami mengaktifkan pemfilteran konten terlarang di dalamnya (pada saat yang sama meninggalkan sistem lama untuk bekerja) - semuanya tampak berjalan dengan baik.

Selanjutnya - secara bertahap mulai memasukkan untuk berbagai bagian pelanggan NAT pada peralatan ini. Dalam penampilan - semuanya juga tampaknya berjalan dengan baik.

Tetapi hari ini, setelah menyalakan peralatan NAT untuk bagian pelanggan berikutnya, di pagi hari kami menemukan sejumlah keluhan tentang tidak tersedianya atau ketersediaan sebagian mail.ru dan sumber daya Grup Ru lainnya.

Mereka mulai memeriksa: sesuatu di suatu tempat kadang-kadang , sesekali mengirimkan TCP RST sebagai tanggapan atas permintaan secara eksklusif ke jaringan mail.ru. Selain itu, ia mengirimkan yang salah dihasilkan (tanpa ACK), jelas TCP RST buatan. Sesuatu seperti ini terlihat:







Secara alami, pikiran pertama adalah tentang peralatan baru: DPI yang mengerikan, tidak ada kepercayaan di dalamnya, Anda tidak pernah tahu apa yang dapat dilakukannya - TCP RST adalah hal yang cukup umum di antara alat pemblokir.

Asumsi kaleman bahwa seseorang memfilter "superior", kami juga mengedepankan - tetapi kemudian dibuang.

Pertama, kita memiliki uplink yang cukup waras agar tidak menderita seperti itu :)

Kedua, kami terhubung ke beberapa IX di Moskow, dan lalu lintas ke mail.ru melewati mereka - dan mereka tidak memiliki tugas atau motif lain untuk menyaring lalu lintas.

Setengah hari berikutnya dihabiskan untuk apa yang biasanya disebut perdukunan - bersama dengan vendor peralatan, yang mereka syukuri, tidak ditinggalkan :)

• pemfilteran sepenuhnya dinonaktifkan
• NAT terputus sesuai dengan skema baru
• tes PC dipindahkan ke kolam terisolasi yang terpisah
• Pengalamatan IP berubah

Pada sore hari, mesin virtual dialokasikan yang masuk ke jaringan sesuai dengan skema pengguna biasa, dan perwakilan vendor diberi akses ke sana dan peralatan. Shamanisme berlanjut :)

Pada akhirnya, perwakilan vendor dengan percaya diri menyatakan bahwa perangkat keras sama sekali tidak bisa disalahkan: pertama kali datang dari tempat yang lebih tinggi.


Setelah itu, pada malam hari, tidak ada lagi yang bisa dilakukan selain kembali ke asumsi penyaringan aneh di suatu tempat di atas.

Saya melihat melalui apa lalu lintas IX sekarang ke jaringan IWG dan hanya membayar sesi bgp untuk itu. Dan - lihatlah! - semuanya segera kembali ke normal :(

Di satu sisi, sangat disayangkan sepanjang hari dihabiskan untuk mencari masalah, meskipun diselesaikan dalam lima menit.

Di sisi lain:

- Dalam ingatanku ini adalah hal yang belum pernah terjadi sebelumnya. Seperti yang saya tulis di atas - IX benar - benar tidak ada gunanya menyaring lalu lintas transit. Mereka biasanya memiliki ratusan gigabit / terabit per detik. Saya hanya sampai yang terakhir tidak bisa serius membayangkan ini.

- seperangkat keadaan yang sangat sukses: perangkat keras baru yang kompleks, yang tidak memiliki banyak kepercayaan dan dari mana tidak jelas apa yang diharapkan - dipertajam hanya di bawah pemblokiran sumber daya, termasuk TCP RSTs

Saat ini, NOC dari pertukaran internet ini sedang mencari masalah. Menurut mereka (dan saya percaya mereka) mereka tidak memiliki sistem penyaringan yang dikembangkan secara khusus. Tapi, terima kasih ke surga, pencarian selanjutnya bukan lagi masalah kita :)

Itu adalah upaya kecil untuk membenarkan diri kita sendiri, tolong mengerti dan memaafkan :)

PS: Saya sengaja tidak menyebutkan nama pembuat DPI / NAT, atau IX (saya bahkan tidak punya keluhan khusus terhadap mereka, yang utama adalah mengerti apa itu)

Hari ini (dan juga kemarin dan hari sebelumnya) kenyataan dari sudut pandang penyedia Internet

Saya menghabiskan minggu-minggu terakhir, membangun kembali inti jaringan secara signifikan, melakukan banyak manipulasi "keuntungan", dengan risiko secara signifikan memengaruhi lalu lintas pengguna langsung. Mengingat tujuan, hasil dan konsekuensi dari semua ini - secara moral, semua ini cukup sulit. Terutama - sekali lagi mendengarkan pidato murah hati tentang melindungi stabilitas Runet, kedaulatan, dll. dll.

Pada bagian ini saya akan mencoba untuk memberitahu "evolusi" dari jaringan inti dari penyedia layanan Internet khas selama sepuluh tahun terakhir.

Sepuluh tahun yang lalu.

Di masa-masa yang diberkati itu, inti dari jaringan penyedia bisa sesederhana dan dapat diandalkan seperti kemacetan lalu lintas:



Pada gambar yang sangat, sangat sederhana ini, tidak ada jalan raya, dering, ip / mpls routing.

Intinya adalah bahwa lalu lintas pengguna pada akhirnya beralih ke kernel-level - dari mana ia pergi ke BNG , dari mana, sebagai aturan, kembali ke switching kernel, dan kemudian "untuk keluar" - melalui satu atau lebih gateway perbatasan ke Internet.

Skema seperti itu sangat, sangat mudah dicadangkan baik pada L3 (dynamic routing) dan pada L2 (MPLS).

Anda dapat menempatkan N + 1 apa saja: mengakses server, sakelar, asrama - dan entah bagaimana mencadangkannya untuk failover otomatis.

Setelah beberapa tahun, menjadi jelas bagi semua orang di Rusia bahwa tidak mungkin untuk terus hidup seperti itu: sangat penting untuk melindungi anak-anak dari pengaruh jaringan yang berbahaya.

Ada kebutuhan mendesak untuk menemukan cara untuk menyaring lalu lintas pengguna.

Ada beberapa pendekatan berbeda.

Dalam kasus yang tidak begitu baik, ada sesuatu yang “dipotong”: antara lalu lintas pengguna dan Internet. Lalu lintas yang melewati "sesuatu" ini dianalisis dan, misalnya, paket redirect palsu dikirim ke sisi pelanggan.

Dalam kasus yang sedikit lebih baik - jika volume lalu lintas memungkinkan - Anda dapat membuat tipuan kecil dengan telinga Anda: kirim hanya lalu lintas keluar dari pengguna ke alamat yang perlu disaring (untuk ini Anda dapat mengambil alamat IP yang ditentukan di sana dari registri, atau juga menyelesaikan yang sudah ada domain dalam registri).

Pada suatu waktu, untuk keperluan ini, saya menulis mini-dpi sederhana - walaupun bahasanya tidak berani menyebutnya demikian. Ini sangat sederhana dan tidak terlalu produktif - namun, itu memungkinkan kami, dan lusinan (jika bukan ratusan) penyedia lain, tidak langsung menghabiskan jutaan dolar untuk sistem DPI industri, tetapi diberikan beberapa tahun tambahan waktu.


Sekarang terlihat seperti ini:



Setelah beberapa tahun , semua orang sudah memiliki auditor; sumber daya dalam registri menjadi semakin banyak. Untuk beberapa peralatan lama (misalnya, cisco 7600), skema “penyaringan samping” menjadi tidak dapat diterapkan: jumlah rute pada 76 platform terbatas pada sesuatu sekitar sembilan ratus ribu, sementara jumlah rute IPv4 saat ini sudah mendekati 800 ribu. Dan jika juga ipv6 ... Dan juga ... berapa banyak yang ada? 900.000 alamat individual di pemandian RCN? =)

Seseorang beralih ke skema dengan mencerminkan semua lalu lintas utama ke server penyaringan, yang akan menganalisis seluruh aliran dan mengirim sesuatu RST ke kedua sisi (pengirim dan penerima) ketika menemukan sesuatu yang buruk.

Namun, semakin banyak lalu lintas, skema semacam itu kurang berlaku. Pada keterlambatan paling sedikit dalam pemrosesan, lalu lintas cermin hanya akan terbang tanpa disadari, dan penyedia akan menerima laporan yang baik.

Semakin banyak penyedia dipaksa untuk menempatkan sistem DPI dengan tingkat keandalan yang berbeda-beda dalam konteks jalan raya.

Setahun atau dua tahun yang lalu, menurut rumor, hampir semua FSB mulai menuntut pemasangan peralatan SORM yang sebenarnya (sebelumnya, sebagian besar penyedia berhasil mengoordinasikan rencana SORM dengan pihak berwenang - rencana tindakan operasional jika perlu menemukan sesuatu di suatu tempat)

Selain uang (tidak setinggi langit, tetapi masih jutaan), SORM membutuhkan lebih banyak manipulasi jaringan bagi banyak orang.

• SORM perlu melihat alamat "abu-abu" pengguna, sebelum siaran nat
• SORM memiliki sejumlah antarmuka jaringan yang terbatas

Oleh karena itu, khususnya, kami harus membangun kembali kernel dengan dingin - hanya untuk mengumpulkan lalu lintas pengguna untuk mengakses server di suatu tempat di satu tempat. Untuk mencerminkannya dengan beberapa tautan di SORM.

Artinya, sangat disederhanakan, itu (di sebelah kiri) vs menjadi (di sebelah kanan):



Sekarang , sebagian besar penyedia membutuhkan pengenalan SORM-3 juga - yang mencakup, tetapi tidak terbatas pada, logging siaran NAT.

Untuk tujuan ini, kami harus menambahkan peralatan terpisah untuk NAT pada diagram di atas (hanya yang dibahas di bagian pertama). Dan untuk menambahkan dalam urutan tertentu: karena SORM harus "melihat" lalu lintas sebelum terjemahan alamat - lalu lintas harus tepat seperti berikut: pengguna -> switching, kernel -> server akses -> SORM -> NAT -> switching, core -> Internet. Untuk melakukan ini, kami harus benar-benar "mengerahkan" arus lalu lintas ke arah lain, yang juga cukup sulit.

Total: selama belasan tahun, sirkuit inti penyedia inti telah menjadi semakin kompleks pada suatu waktu, dan titik-titik kegagalan tambahan (baik dalam bentuk peralatan maupun dalam bentuk jalur-jalur tunggal) telah meningkat secara signifikan. Sebenarnya, persyaratan untuk "melihat segalanya" dengan sendirinya menyiratkan pengurangan "segalanya" ini ke satu titik.

Tampak bagi saya bahwa ini bisa secara transparan diekstrapolasi dengan inisiatif saat ini tentang kedaulatan Runet, perlindungannya, stabilisasi dan peningkatan :)

Dan di depan adalah Yarovaya.