Proyek saya yang belum direalisasi. Jaringan 200 MikroTik Router

Halo semuanya. Artikel ini ditujukan bagi mereka yang memiliki banyak perangkat Mikrotik di taman, dan yang ingin membuat penyatuan maksimum agar tidak terhubung ke setiap perangkat secara individual. Dalam artikel ini, saya akan menjelaskan sebuah proyek yang, sayangnya, tidak mencapai kondisi pertempuran karena faktor manusia. Singkatnya: lebih dari 200 router, konfigurasi cepat dan pelatihan staf, penyatuan berdasarkan wilayah, jaringan pemfilteran dan host tertentu, kemampuan untuk dengan mudah menambahkan aturan ke semua perangkat, logging dan kontrol akses.

Apa yang dijelaskan di bawah ini tidak mengklaim sebagai kasus yang selesai, tetapi saya harap ini akan bermanfaat bagi Anda ketika merencanakan jaringan Anda dan meminimalkan kesalahan. Mungkin beberapa poin dan keputusan tampaknya tidak tepat bagi Anda - jika demikian, tulis di komentar. Kritik dalam hal ini akan menjadi pengalaman di celengan umum. Oleh karena itu, pembaca, lihat komentar, mungkin penulis membuat kesalahan serius - komunitas akan membantu.

Jumlah router adalah 200-300, tersebar di berbagai kota dengan kualitas koneksi internet yang berbeda. Penting untuk melakukan semuanya dengan indah dan mudah menjelaskan kepada administrator lokal bagaimana semuanya akan bekerja.

Jadi, dari mana proyek dimulai? Tentu saja, dengan TK .

1. Organisasi rencana jaringan untuk semua cabang sesuai dengan kebutuhan pelanggan, segmentasi jaringan (dari 3 hingga 20 jaringan di cabang tergantung pada jumlah perangkat).
2. Konfigurasikan perangkat di setiap cabang. Memeriksa bandwidth nyata penyedia dalam kondisi kerja yang berbeda.
3. Organisasi perlindungan perangkat, manajemen daftar putih, deteksi otomatis serangan dengan daftar hitam otomatis untuk jangka waktu tertentu, minimalisasi penggunaan berbagai cara teknis yang digunakan untuk mencegat akses kontrol dan menolak layanan.
4. Organisasi koneksi vpn aman dengan penyaringan jaringan sesuai dengan kebutuhan pelanggan. Setidaknya 3 koneksi vpn dari setiap cabang ke pusat.
5. Berdasarkan paragraf 1, 2. Pilih cara optimal untuk membangun vpn toleran-kesalahan. Teknologi routing dinamis, jika dibenarkan dengan benar, dapat dipilih oleh kontraktor.
6. Organisasi prioritas lalu lintas oleh protokol, port, host dan layanan spesifik lainnya yang digunakan pelanggan. (VOIP, host dengan layanan penting)
7. Organisasi pemantauan dan pencatatan kejadian router untuk tanggapan staf dukungan teknis.

Seperti yang kita pahami, dalam beberapa kasus TK dikompilasi dari persyaratan. Saya merumuskan persyaratan ini sendiri, setelah mendengarkan masalah utama. Saya mengakui kemungkinan bahwa orang lain dapat menerapkan poin-poin ini.

Alat apa yang akan digunakan untuk memenuhi persyaratan ini:

1. Tumpukan ELK (setelah beberapa waktu, muncul pengertian bahwa fluentd akan digunakan sebagai ganti logstash).
2. Mungkin. Untuk kemudahan administrasi dan berbagi akses, kami akan menggunakan AWX.
3. GITLAB. Tidak perlu dijelaskan. Di mana tanpa kontrol versi dari konfigurasi kami.
4. PowerShell Akan ada skrip sederhana untuk generasi awal konfigurasi.
5. Doku wiki untuk menulis dokumentasi dan manual. Dalam hal ini, gunakan habr.com.
6. Pemantauan akan dilakukan melalui zabbix. Diagram koneksi akan dibuat di sana untuk pemahaman umum.

Momen Pengaturan EFK

Dalam paragraf pertama saya hanya akan menjelaskan ideologi yang dengannya indeks akan dibangun. Ada banyak
artikel bagus tentang pengaturan dan penerimaan log dari perangkat yang menjalankan mikrotik.

Saya akan membahas beberapa poin:

1. Menurut skema, ada baiknya mempertimbangkan menerima log dari tempat yang berbeda dan di pelabuhan yang berbeda. Untuk ini, kami akan menggunakan agregator log. Dan kami juga ingin membuat jadwal universal untuk semua router dengan kemungkinan berbagi akses. Kemudian kami membuat indeks sebagai berikut:


Dengan demikian kita dapat menggabungkan router dan segmen sesuai dengan plan- mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Mengapa menyulitkan ini? Kami memahami bahwa kami akan memiliki 200 perangkat atau lebih. Jangan melacak semuanya. Sejak versi 6.8 dari elasticsearch, kami memiliki akses ke pengaturan keamanan (tanpa membeli lisensi), sehingga kami dapat mendistribusikan hak penayangan antara karyawan dukungan teknis atau administrator sistem lokal.
Tabel, grafik - di sini Anda hanya perlu setuju - baik menggunakan yang sama, atau masing-masing sesuai dengan keinginannya.

2. Dengan login. Jika kami mengaktifkan log in aturan firewall, maka kami melakukan nama tanpa spasi. Dapat dilihat bahwa menggunakan konfigurasi sederhana dalam fluentd, kita dapat memfilter data dan membuat panel yang nyaman. Pada gambar di bawah ini, router rumah saya.



3. Menurut tempat yang ditempati dan log. Rata-rata, dengan 1000 pesan per jam, log membutuhkan 2-3 mb per hari, yang Anda lihat, tidak terlalu banyak. Elasticsearch versi 7.5.

ANSIBLE.AWX

Untungnya bagi kami, kami memiliki modul yang siap pakai untuk routeros
Saya menunjuk tentang AWX, tetapi perintah di bawah ini hanya sekitar mungkin dalam bentuk paling murni - saya pikir bagi mereka yang telah bekerja dengan mungkin tidak akan ada masalah menggunakan gui awx.

Saya mengakui dengan jujur, sebelum itu saya melihat panduan lain di mana mereka menggunakan ssh, dan semua orang memiliki masalah yang berbeda dengan waktu tanggapan dan banyak masalah lainnya. Saya ulangi, itu tidak sampai ke pertempuran , ambil informasi ini sebagai percobaan yang tidak melampaui stand 20 router.

Kita perlu menggunakan sertifikat atau akuntansi. Terserah Anda, saya untuk sertifikat. Beberapa poin halus tentang hak. Saya memberikan izin menulis - setidaknya "reset config" tidak dapat dilakukan.

Seharusnya tidak ada masalah dengan menghasilkan, menyalin sertifikat dan impor:



Seperti yang dapat Anda lihat dari konfigurasi di atas, kompilasi playbook Anda sangat mudah. Cukup bagus untuk menguasai cli mikrotik. Bayangkan situasi di mana pada semua router Anda perlu menghapus daftar alamat dengan data tertentu, lalu:


Saya sengaja tidak memasukkan seluruh daftar firewall di sini. Ini akan bersifat individual untuk setiap proyek. Tapi satu hal yang pasti, gunakan hanya daftar alamat.

Oleh GITLAB, semuanya jelas. Saya tidak akan tinggal pada saat ini. Semuanya indah untuk tugas, templat, penangan yang terpisah.

Powershell

Akan ada 3 file. Mengapa PowerShell? Alat untuk menghasilkan konfigurasi dapat dipilih oleh siapa saja yang lebih nyaman. Dalam hal ini, setiap orang memiliki windows di PC, jadi mengapa melakukannya di bash ketika PowerShell lebih nyaman. Kepada siapa lebih nyaman.



Maafkan saya, saya tidak bisa menata semua aturan karena itu tidak akan cukup indah. Anda dapat membuat aturan sendiri, dipandu oleh praktik terbaik.



Saya sengaja mengubah alamat dalam contoh untuk alasan yang jelas.

Saya melewatkan titik mendeteksi serangan dan perilaku abnormal - ini layak mendapat artikel terpisah. Tetapi perlu menunjukkan bahwa dalam kategori ini Anda dapat menggunakan nilai-nilai data pemantauan dengan Zabbix + bekerja data ikal dengan elasticsearch.

Pada titik mana Anda perlu fokus:

1. Rencana Jaringan. Lebih baik menulis segera dalam bentuk yang dapat dibaca. Cukup sudah. Sayangnya, saya sering melihat bahwa jaringan dikompilasi sesuai dengan prinsip: "Cabang baru telah muncul, di sini Anda / 24". Tidak ada yang tahu berapa banyak perangkat yang seharusnya berada di tempat tertentu dan apakah akan ada pertumbuhan lebih lanjut. Misalnya, toko kecil dibuka, di mana pada awalnya jelas bahwa perangkat tidak akan lebih dari 10, mengapa mengalokasikan / 24? Di cabang besar - sebaliknya, mereka mengalokasikan / 24, dan ada 500 perangkat - Anda bisa menambahkan jaringan, tetapi Anda ingin segera memikirkan semuanya.
2. Aturan penyaringan. Jika proyek mengasumsikan bahwa akan ada pemisahan jaringan dan segmentasi maksimum. Praktik terbaik berubah seiring waktu. Sebelumnya, mereka berbagi jaringan PC dan jaringan printer, sekarang normal untuk tidak berbagi jaringan ini. Layak menggunakan akal sehat dan tidak membuat banyak subnet di mana mereka tidak diperlukan dan tidak menghubungkan semua perangkat ke satu jaringan.
3. Pengaturan "Emas" di semua router. Yaitu jika Anda telah memutuskan suatu rencana. Ada baiknya segera meramalkan semuanya dan berusaha memastikan bahwa semua pengaturannya identik - hanya ada daftar alamat dan alamat ip yang berbeda. Jika terjadi masalah, waktu debug akan lebih sedikit.
4. Masalah organisasi tidak kalah pentingnya dengan masalah teknis. Seringkali, karyawan yang malas mengikuti rekomendasi ini “secara manual”, tanpa menggunakan konfigurasi dan skrip yang sudah jadi, yang pada akhirnya menyebabkan masalah dari awal.

Dengan routing dinamis. OSPF bekas dengan divisi zonal. Tapi ini adalah bangku tes, dalam kondisi pertempuran lebih menarik untuk mengatur hal-hal seperti itu.

Saya harap tidak ada yang kesal karena saya tidak memposting konfigurasi router. Saya pikir akan ada cukup banyak tautan, dan kemudian semuanya tergantung pada persyaratan. Dan tentu saja tes, tes lagi diperlukan.

Saya berharap semua orang untuk mengimplementasikan proyek mereka di tahun baru. Ya, akses yang diberikan akan datang dengan Anda !!!