Mendorong saya ke posting ini .
Saya mengutipnya di sini:
Hari ini di 18: 53
Saya senang dengan penyedia hari ini. Seiring dengan pembaruan sistem pemblokiran situs, mail.ru-nya diblokir. Saya sudah menelepon dukungan teknis sejak pagi, tetapi mereka tidak bisa berbuat apa-apa. Penyedianya kecil, dan tampaknya penyedia dengan peringkat lebih tinggi memblokirnya. Saya juga melihat adanya perlambatan dalam pembukaan semua situs, mungkin mereka memasang semacam DLP yang bengkok? Sebelumnya tidak ada masalah akses. Kehancuran RuNet terjadi tepat di depan mata saya...
Faktanya adalah sepertinya kita adalah penyedia yang sama :)
Dan memang, Saya hampir menebak penyebab masalah dengan mail.ru (meskipun kami sudah lama menolak untuk mempercayai hal seperti itu).
Berikut ini akan dibagi menjadi dua bagian:
- alasan masalah kami saat ini dengan mail.ru dan pencarian menarik untuk menemukannya
- keberadaan ISP dalam realitas saat ini, stabilitas kedaulatan Runet.
Masalah aksesibilitas dengan mail.ru
Oh, ceritanya cukup panjang.
Faktanya adalah bahwa untuk menerapkan persyaratan negara (detail lebih lanjut di bagian kedua), kami membeli, mengonfigurasi, dan memasang beberapa peralatan - baik untuk menyaring sumber daya yang dilarang maupun untuk mengimplementasikan pelanggan.
Beberapa waktu lalu, kami akhirnya membangun kembali inti jaringan sedemikian rupa sehingga semua lalu lintas pelanggan melewati peralatan ini dengan arah yang benar.
Beberapa hari yang lalu kami mengaktifkan pemfilteran terlarang (sambil membiarkan sistem lama berfungsi) - semuanya tampak berjalan dengan baik.
Selanjutnya, mereka secara bertahap mulai mengaktifkan NAT pada peralatan ini untuk berbagai bagian pelanggan. Dari kelihatannya, semuanya juga tampak berjalan baik.
Namun hari ini, setelah mengaktifkan NAT pada peralatan untuk pelanggan berikutnya, sejak pagi hari kami dihadapkan dengan sejumlah keluhan tentang ketidaktersediaan atau ketersediaan sebagian. dan sumber daya Grup Mail Ru lainnya.
Mereka mulai memeriksa: ada sesuatu di suatu tempat kadang-kadang, sesekali mengirimkan sebagai tanggapan atas permintaan secara eksklusif ke jaringan mail.ru. Selain itu, ia mengirimkan TCP RST yang dibuat secara salah (tanpa ACK), yang jelas-jelas buatan. Ini penampakannya:
Tentu saja, pikiran pertama adalah tentang peralatan baru: DPI yang buruk, tidak ada kepercayaan padanya, Anda tidak pernah tahu apa yang bisa dilakukannya - lagipula, TCP RST adalah hal yang cukup umum di antara alat pemblokiran.
Anggapan Kami juga mengemukakan gagasan bahwa ada yang “superior” sedang menyaring, tapi langsung membuangnya.
Pertama, kami memiliki uplink yang cukup waras sehingga kami tidak mengalami penderitaan seperti ini :)
Kedua, kami terhubung ke beberapa di Moskow, dan lalu lintas ke mail.ru melewati mereka - dan mereka tidak memiliki tanggung jawab atau motif lain untuk menyaring lalu lintas.
Setengah hari berikutnya dihabiskan untuk apa yang biasa disebut perdukunan - bersama dengan vendor peralatan, kami berterima kasih kepada mereka, mereka tidak menyerah :)
- pemfilteran sepenuhnya dinonaktifkan
- NAT dinonaktifkan menggunakan skema baru
- PC uji ditempatkan di kolam terisolasi yang terpisah
- Pengalamatan IP berubah
Pada sore hari, mesin virtual dialokasikan yang terhubung ke jaringan sesuai dengan skema pengguna biasa, dan perwakilan vendor diberikan akses ke sana dan peralatannya. Perdukunan berlanjut :)
Pada akhirnya, perwakilan vendor dengan yakin menyatakan bahwa perangkat keras tersebut sama sekali tidak ada hubungannya dengan hal tersebut: perangkat keras pertama datang dari tempat yang lebih tinggi.
CatatanPada titik ini, seseorang mungkin berkata: tetapi jauh lebih mudah untuk mengambil dump bukan dari PC yang diuji, tetapi dari jalan raya di atas DPI?
Tidak, sayangnya, melakukan dump (dan bahkan hanya mirroring) 40+gbps sama sekali bukan hal yang sepele.
Setelah ini, di malam hari, tidak ada yang bisa dilakukan selain kembali ke asumsi penyaringan aneh di suatu tempat di atas.
Saya melihat IX mana yang sekarang dilalui lalu lintas ke jaringan MRG dan membatalkan sesi bgp ke sana. Dan - lihatlah! - semuanya langsung kembali normal 🙁
Di satu sisi, sangat disayangkan bahwa sepanjang hari dihabiskan untuk mencari masalah, meskipun masalah tersebut diselesaikan dalam lima menit.
Di sisi lain:
— dalam ingatanku ini adalah hal yang belum pernah terjadi sebelumnya. Seperti yang sudah saya tulis di atas - IX benar-benar tidak ada gunanya memfilter lalu lintas transit. Mereka biasanya memiliki ratusan gigabit/terabit per detik. Saya benar-benar tidak bisa membayangkan hal seperti ini sampai saat ini.
— sebuah kebetulan yang sangat menguntungkan: perangkat keras kompleks baru yang tidak terlalu dipercaya dan tidak jelas apa yang dapat diharapkan — dirancang khusus untuk memblokir sumber daya, termasuk TCP RST
NOC pertukaran internet ini sedang mencari masalah. Menurut mereka (dan saya percaya mereka), mereka tidak memiliki sistem penyaringan khusus. Tapi alhamdulillah pencarian selanjutnya bukan lagi masalah kami :)
Ini adalah upaya kecil untuk membenarkan diri sendiri, mohon pengertiannya dan maafkan :)
PS: Sengaja saya tidak menyebutkan nama pabrikan DPI/NAT atau IX (bahkan saya tidak punya keluhan khusus tentangnya, yang penting paham apa itu)
Realitas hari ini (dan juga kemarin dan lusa) dari sudut pandang penyedia Internet
Saya telah menghabiskan beberapa minggu terakhir secara signifikan membangun kembali inti jaringan, melakukan banyak manipulasi “demi keuntungan”, dengan risiko mempengaruhi lalu lintas pengguna langsung secara signifikan. Mengingat tujuan, hasil dan konsekuensi dari semua ini, secara moral semuanya cukup sulit. Terutama - sekali lagi mendengarkan pidato indah tentang melindungi stabilitas Runet, kedaulatan, dll. dan seterusnya.
Pada bagian ini, saya akan mencoba menjelaskan “evolusi” inti jaringan ISP pada umumnya selama sepuluh tahun terakhir.
Sepuluh tahun yang lalu.
Di masa-masa yang diberkati ini, inti dari jaringan penyedia bisa sesederhana dan dapat diandalkan seperti kemacetan lalu lintas:
Dalam gambaran yang sangat, sangat sederhana ini, tidak ada trunk, ring, routing ip/mpls.
Esensinya adalah bahwa lalu lintas pengguna pada akhirnya sampai pada peralihan tingkat kernel - dari mana ia pergi , dari mana, sebagai suatu peraturan, kembali ke peralihan inti, dan kemudian “keluar” - melalui satu atau lebih gerbang perbatasan ke Internet.
Skema seperti ini sangat-sangat mudah untuk dicadangkan baik di L3 (routing dinamis) maupun di L2 (MPLS).
Anda dapat menginstal N+1 apa saja: mengakses server, switch, border - dan dengan satu atau lain cara mencadangkannya untuk failover otomatis.
Setelah beberapa tahun Menjadi jelas bagi semua orang di Rusia bahwa tidak mungkin lagi hidup seperti ini: sangat penting untuk melindungi anak-anak dari pengaruh buruk Internet.
Ada kebutuhan mendesak untuk menemukan cara memfilter lalu lintas pengguna.
Ada pendekatan berbeda di sini.
Dalam kasus yang tidak terlalu baik, ada sesuatu yang “di celah”: antara lalu lintas pengguna dan Internet. Lalu lintas yang melewati "sesuatu" ini dianalisis dan, misalnya, paket palsu dengan pengalihan dikirim ke pelanggan.
Dalam kasus yang sedikit lebih baik - jika volume lalu lintas memungkinkan - Anda dapat melakukan sedikit trik dengan telinga Anda: kirim untuk memfilter hanya lalu lintas yang berasal dari pengguna hanya ke alamat yang perlu difilter (untuk melakukan ini, Anda dapat mengambil alamat IP ditentukan di sana dari registri, atau juga menyelesaikan domain yang sudah ada di registri).
Pada suatu waktu, untuk tujuan ini, saya menulis yang sederhana - meskipun aku bahkan tidak berani memanggilnya seperti itu. Ini sangat sederhana dan tidak terlalu produktif - namun, ini memungkinkan kami dan lusinan (jika bukan ratusan) penyedia lain untuk tidak segera mengeluarkan jutaan dolar untuk sistem DPI industri, tetapi memberikan waktu tambahan beberapa tahun.
Ngomong-ngomong, tentang DPI dulu dan sekarangOmong-omong, banyak orang yang membeli sistem DPI yang tersedia di pasaran saat itu sudah membuangnya. Ya, mereka tidak dirancang untuk ini: ratusan ribu alamat, puluhan ribu URL.
Dan pada saat yang sama, produsen dalam negeri telah meningkat pesat dalam memasuki pasar ini. Saya tidak berbicara tentang komponen perangkat keras - semuanya jelas bagi semua orang di sini, tetapi perangkat lunak - hal utama yang dimiliki DPI - mungkin saat ini, jika bukan yang paling maju di dunia, maka tentu saja a) berkembang dengan pesat, dan b) dengan harga produk dalam kotak - tidak dapat dibandingkan dengan pesaing asing.
Saya ingin bangga, tapi sedikit sedih =)
Sekarang semuanya tampak seperti ini:
Dalam beberapa tahun lagi setiap orang sudah memiliki auditor; Ada lebih banyak sumber daya di registri. Untuk beberapa peralatan yang lebih tua (misalnya, Cisco 7600), skema “penyaringan samping” menjadi tidak dapat diterapkan: jumlah rute pada 76 platform dibatasi sekitar sembilan ratus ribu, sedangkan jumlah rute IPv4 saja saat ini mendekati 800 ribu. Dan kalau itu juga ipv6... Dan juga...berapa harganya? 900000 alamat individu dalam larangan RKN? =)
Seseorang beralih ke skema dengan mencerminkan semua lalu lintas tulang punggung ke server pemfilteran, yang harus menganalisis seluruh aliran dan, jika ditemukan sesuatu yang buruk, mengirim RST ke kedua arah (pengirim dan penerima).
Namun, semakin banyak lalu lintas, semakin kurang penerapan skema ini. Jika ada penundaan sekecil apa pun dalam pemrosesan, lalu lintas yang dicerminkan akan berlalu begitu saja tanpa disadari, dan penyedia akan menerima laporan yang bagus.
Semakin banyak penyedia layanan yang terpaksa memasang sistem DPI dengan berbagai tingkat keandalan di seluruh jalan raya.
Satu atau dua tahun yang lalu Menurut rumor yang beredar, hampir seluruh FSB mulai menuntut pemasangan peralatan yang sebenarnya (sebelumnya, sebagian besar penyedia mengelola dengan persetujuan pihak berwenang rencana SORM - rencana tindakan operasional jika perlu mencari sesuatu di suatu tempat)
Selain uang (tidak bisa dibilang selangit, tapi tetap jutaan), SORM membutuhkan lebih banyak manipulasi dengan jaringan.
- SORM perlu melihat alamat pengguna “abu-abu” sebelum terjemahan nat
- SORM memiliki jumlah antarmuka jaringan yang terbatas
Oleh karena itu, khususnya, kami harus membangun kembali sebagian dari kernel - hanya untuk mengumpulkan lalu lintas pengguna ke server akses di suatu tempat di satu tempat. Untuk mencerminkannya di SORM dengan beberapa tautan.
Artinya, sangat disederhanakan, tadi (kiri) vs menjadi (kanan):
Sekarang Sebagian besar penyedia juga memerlukan penerapan SORM-3 - yang mencakup, antara lain, pencatatan siaran nat.
Untuk tujuan ini, kami juga harus menambahkan peralatan terpisah untuk NAT ke diagram di atas (persis seperti yang dibahas di bagian pertama). Selain itu, tambahkan dalam urutan tertentu: karena SORM harus “melihat” lalu lintas sebelum menerjemahkan alamat, lalu lintas harus berjalan dengan ketat sebagai berikut: pengguna -> peralihan, kernel -> server akses -> SORM -> NAT -> peralihan, kernel - > Internet. Untuk melakukan ini, kami harus benar-benar “mengubah” arus lalu lintas ke arah lain untuk mendapatkan keuntungan, yang juga cukup sulit.
Ringkasnya: selama sepuluh tahun terakhir, desain inti dari penyedia rata-rata menjadi berkali-kali lipat lebih kompleks, dan titik kegagalan tambahan (baik dalam bentuk peralatan maupun dalam bentuk jalur peralihan tunggal) telah meningkat secara signifikan. Sebenarnya, persyaratan untuk “melihat segala sesuatu” berarti mereduksi “segalanya” menjadi satu titik.
Saya pikir hal ini dapat diekstrapolasi secara transparan ke inisiatif saat ini untuk mendaulat, melindungi, menstabilkan, dan meningkatkan Runet :)
Dan Yarovaya masih di depan.
Sumber: www.habr.com