Halo semuanya, nama saya Sergey Emelyanchik. Saya adalah kepala perusahaan Audit-Telecom, pengembang utama dan penulis sistem Veliam. Saya memutuskan untuk menulis artikel tentang bagaimana saya dan teman saya mendirikan perusahaan outsourcing, menulis perangkat lunak untuk diri kami sendiri, dan kemudian mulai mendistribusikannya ke semua orang melalui sistem SaaS. Tentang betapa saya sangat tidak percaya bahwa ini mungkin. Artikel ini tidak hanya berisi cerita, tetapi juga detail teknis tentang bagaimana produk Veliam dibuat. Termasuk beberapa potongan kode sumber. Saya akan memberi tahu Anda kesalahan apa yang kami buat dan bagaimana kami memperbaikinya nanti. Ada keraguan apakah akan menerbitkan artikel seperti itu. Namun saya pikir lebih baik melakukannya, mendapatkan masukan dan melakukan perbaikan, daripada tidak mempublikasikan artikel dan memikirkan apa yang akan terjadi jika...
prasejarah
Saya bekerja di satu perusahaan sebagai karyawan IT. Perusahaan ini cukup besar dengan struktur jaringan yang luas. Saya tidak akan memikirkan tanggung jawab pekerjaan saya, saya hanya akan mengatakan bahwa itu tidak termasuk pengembangan apa pun.
Kami melakukan pemantauan, tetapi semata-mata karena kepentingan akademis, saya ingin mencoba menulis yang paling sederhana. Idenya adalah ini: Saya ingin itu ada di web, sehingga saya dapat dengan mudah masuk tanpa menginstal klien apa pun dan melihat apa yang terjadi dengan jaringan dari perangkat apa pun, termasuk perangkat seluler melalui Wi-Fi, dan saya juga sangat menyukainya. ingin cepat memahami apa yang ada peralatan di dalam ruangan yang menjadi “mopey” karena... ada persyaratan yang sangat ketat untuk waktu respons terhadap masalah seperti itu. Hasilnya, sebuah rencana lahir di kepala saya untuk menulis halaman web sederhana dengan latar belakang jpeg dengan diagram jaringan, memotong perangkat itu sendiri dengan alamat IP-nya di gambar ini, dan menampilkan konten dinamis di atas. gambar pada koordinat yang diperlukan berupa alamat IP berwarna hijau atau merah berkedip. Tugas telah ditetapkan, mari kita mulai.
Sebelumnya, saya memprogram dalam Delphi, PHP, JS dan secara dangkal C++. Saya tahu betul cara kerja jaringan. VLAN, Perutean (OSPF, EIGRP, BGP), NAT. Ini cukup bagi saya untuk menulis sendiri prototipe pemantauan primitif.
Saya menulis apa yang saya rencanakan di PHP. Server Apache dan PHP ada di Windows karena... Linux bagi saya pada saat itu adalah sesuatu yang tidak dapat dipahami dan sangat kompleks, ternyata kemudian, saya sangat salah dan di banyak tempat Linux jauh lebih sederhana daripada Windows, tetapi ini adalah topik tersendiri dan kita semua tahu berapa banyak holivar yang ada di sana. topik ini. Penjadwal tugas Windows menarik dalam interval kecil (saya tidak ingat persisnya, tapi sekitar sekali setiap tiga detik) skrip PHP yang menyurvei semua objek dengan ping dangkal dan menyimpan status ke file.
system(“ping -n 3 -w 100 {$ip_address}“);
Ya, bekerja dengan database pada saat itu juga belum saya kuasai. Saya tidak tahu bahwa proses paralel dapat dilakukan, dan melewati semua node jaringan membutuhkan waktu lama, karena... ini terjadi di satu thread. Masalah terutama muncul ketika beberapa node tidak tersedia, karena masing-masing menunda skrip selama 300 ms. Di sisi klien terdapat fungsi perulangan sederhana yang, dengan interval beberapa detik, mengunduh informasi terbaru dari server dengan permintaan Ajax dan memperbarui antarmuka. Nah, setelah 3 ping gagal berturut-turut, jika halaman web dengan pemantauan terbuka di komputer, komposisi ceria diputar.
Ketika semuanya berjalan lancar, saya sangat terinspirasi dengan hasilnya dan berpikir bahwa saya bisa menambahkan lebih banyak lagi (karena pengetahuan dan kemampuan saya). Namun saya selalu tidak menyukai sistem dengan sejuta grafik, yang menurut saya saat itu, dan masih saya anggap hingga hari ini, tidak diperlukan dalam banyak kasus. Saya hanya ingin memasukkan apa yang benar-benar membantu saya dalam pekerjaan saya. Prinsip ini tetap menjadi dasar perkembangan Veliam hingga saat ini. Selanjutnya, saya menyadari bahwa akan sangat keren jika saya tidak harus terus memantau dan mengetahui masalahnya, dan ketika itu terjadi, buka halaman tersebut dan lihat di mana lokasi node jaringan yang bermasalah ini dan apa yang harus dilakukan selanjutnya. . Entah bagaimana saya tidak membaca email saat itu, saya tidak menggunakannya. Saya menemukan di Internet bahwa ada gateway SMS tempat Anda dapat mengirim permintaan GET atau POST, dan mereka akan mengirim SMS ke ponsel saya dengan teks yang saya tulis. Saya segera menyadari bahwa saya sangat menginginkan ini. Dan saya mulai mempelajari dokumentasinya. Setelah beberapa waktu saya berhasil, dan sekarang saya menerima SMS tentang masalah jaringan di ponsel saya dengan nama “benda jatuh”. Walaupun sistemnya masih primitif, namun saya sendiri yang menulisnya, dan yang terpenting yang memotivasi saya untuk mengembangkannya adalah program aplikasinya yang sangat membantu saya dalam pekerjaan saya.
Dan kemudian tibalah saatnya ketika salah satu saluran Internet mati di tempat kerja, dan pemantauan saya tidak memberi tahu saya tentang hal itu. Karena DNS Google masih melakukan ping dengan sempurna. Saatnya memikirkan bagaimana Anda dapat memantau apakah saluran komunikasi masih hidup. Ada berbagai gagasan berbeda tentang cara melakukan ini. Saya tidak memiliki akses ke semua peralatan. Kami harus memikirkan cara memahami saluran mana yang disiarkan langsung, tetapi tanpa bisa melihatnya di peralatan jaringan itu sendiri. Kemudian seorang kolega mengemukakan gagasan bahwa penelusuran rute ke server publik mungkin berbeda tergantung pada saluran komunikasi mana yang saat ini digunakan untuk mengakses Internet. Saya memeriksanya dan ternyata seperti itu. Ada rute berbeda saat menelusuri.
system(“tracert -d -w 500 8.8.8.8”);
Jadi skrip lain muncul, atau lebih tepatnya, karena alasan tertentu jejak ditambahkan ke akhir skrip yang sama, yang melakukan ping ke semua perangkat di jaringan. Bagaimanapun, ini adalah proses panjang lainnya yang dijalankan di thread yang sama dan memperlambat kerja seluruh skrip. Namun saat itu hal itu tidak begitu jelas. Tapi dengan satu atau lain cara, dia melakukan tugasnya, kode tersebut secara ketat menentukan jenis penelusuran apa yang harus dilakukan untuk setiap saluran. Beginilah cara sistem mulai bekerja, yang sudah memonitor (berkata lantang, karena tidak ada kumpulan metrik apa pun, tetapi hanya ping) perangkat jaringan (router, switch, wi-fi, dll.) dan saluran komunikasi dengan dunia luar . Pesan SMS tiba secara teratur dan diagram selalu menunjukkan dengan jelas letak masalahnya.
Selanjutnya, dalam pekerjaan sehari-hari saya harus melakukan cross-crossing. Dan saya bosan membuka switch Cisco setiap saat untuk melihat antarmuka mana yang akan digunakan. Betapa kerennya mengklik suatu objek dalam pemantauan dan melihat daftar antarmukanya beserta deskripsinya. Ini akan menghemat waktu saya. Selain itu, dalam skema ini tidak perlu menjalankan Putty atau SecureCRT untuk memasukkan akun dan perintah. Saya cukup mengklik pemantauan, melihat apa yang diperlukan dan mulai melakukan pekerjaan saya. Saya mulai mencari cara untuk berinteraksi dengan sakelar. Saya langsung menemukan 2 opsi: SNMP atau masuk ke switch melalui SSH, memasukkan perintah yang saya perlukan dan menguraikan hasilnya. Saya menolak SNMP karena rumitnya implementasinya; saya tidak sabar untuk mendapatkan hasilnya. dengan SNMP, Anda harus menggali MIB untuk waktu yang lama dan, berdasarkan data ini, menghasilkan data tentang antarmuka. Ada tim yang luar biasa di CISCO
show interface statusIni menunjukkan dengan tepat apa yang saya butuhkan untuk penyeberangan silang. Mengapa repot-repot menggunakan SNMP ketika saya hanya ingin melihat output dari perintah ini, pikir saya. Setelah beberapa waktu, saya menyadari peluang ini. Mengklik objek di halaman web. Suatu peristiwa dipicu oleh klien AJAX yang menghubungi server, dan, pada gilirannya, terhubung melalui SSH ke sakelar yang saya perlukan (kredensialnya di-hardcode ke dalam kode, tidak ada keinginan untuk memperbaikinya, untuk membuat beberapa menu terpisah di mana dimungkinkan untuk mengubah akun dari antarmuka, saya membutuhkan hasilnya dan cepat) Saya memasukkan perintah di atas di sana dan mengirimkannya kembali ke browser. Jadi saya mulai melihat informasi tentang antarmuka dengan satu klik mouse. Ini sangat nyaman, terutama ketika Anda harus melihat informasi ini pada switch yang berbeda secara bersamaan.
Pemantauan saluran berbasis jejak akhirnya bukan ide terbaik, karena... terkadang pekerjaan dilakukan di jaringan, dan penelusuran dapat berubah dan pemantauan mulai berteriak kepada saya bahwa ada masalah dengan saluran. Namun setelah menghabiskan banyak waktu untuk menganalisis, saya menyadari bahwa semua saluran berfungsi, dan pemantauan saya menipu saya. Akibatnya, saya meminta rekan-rekan saya yang mengelola saklar pembentuk saluran untuk mengirimi saya syslog ketika status visibilitas tetangga berubah. Oleh karena itu, ini jauh lebih sederhana, lebih cepat dan lebih akurat daripada penelusuran. Peristiwa seperti tetangga hilang telah tiba, dan saya segera mengeluarkan pemberitahuan tentang saluran tersebut down.
Selanjutnya, beberapa perintah muncul saat mengklik suatu objek, dan SNMP ditambahkan untuk mengumpulkan beberapa metrik, dan itu pada dasarnya. Sistem ini tidak pernah berkembang lebih jauh. Itu melakukan semua yang saya butuhkan, itu adalah alat yang bagus. Banyak pembaca mungkin akan memberi tahu saya bahwa sudah ada banyak perangkat lunak di Internet untuk mengatasi masalah ini. Namun kenyataannya, saya tidak mencari produk gratis seperti itu di Google saat itu dan saya benar-benar ingin mengembangkan keterampilan pemrograman saya, dan cara apa yang lebih baik untuk mencapai hal ini selain masalah aplikasi sebenarnya. Pada titik ini, pemantauan versi pertama telah selesai dan tidak lagi diubah.
Penciptaan perusahaan Audit-Telecom
Seiring berjalannya waktu, saya mulai bekerja paruh waktu di perusahaan lain, untungnya jadwal kerja saya memungkinkan saya melakukan hal ini. Ketika Anda bekerja di perusahaan yang berbeda, keterampilan Anda di berbagai bidang berkembang sangat cepat, dan wawasan Anda berkembang dengan baik. Ada perusahaan di mana, seperti yang mereka katakan, Anda adalah orang Swedia, penuai, dan pemain terompet. Di satu sisi sulit, di sisi lain jika Anda tidak malas, Anda menjadi seorang generalis dan ini memungkinkan Anda menyelesaikan masalah dengan lebih cepat dan efisien karena Anda tahu cara kerja bidang terkait.
Teman saya Pavel (juga seorang spesialis IT) terus-menerus berusaha mendorong saya untuk memulai bisnisnya sendiri. Ada banyak sekali ide dengan variasi berbeda dari apa yang mereka lakukan. Hal ini telah dibahas selama bertahun-tahun. Dan pada akhirnya, hal itu tidak akan terjadi apa-apa karena saya seorang yang skeptis, dan Pavel adalah seorang pemimpi. Setiap kali dia mengajukan ide, saya selalu tidak percaya dan menolak untuk berpartisipasi. Tapi kami sangat ingin membuka usaha sendiri.
Akhirnya, kami dapat menemukan opsi yang cocok untuk kami berdua dan melakukan apa yang kami tahu caranya. Pada tahun 2016, kami memutuskan untuk mendirikan perusahaan IT yang akan membantu bisnis memecahkan masalah TI. Ini adalah penerapan sistem TI (1C, server terminal, server email, dll.), pemeliharaannya, HelpDesk klasik untuk pengguna dan administrasi jaringan.
Sejujurnya, pada saat mendirikan perusahaan, saya tidak mempercayainya sekitar 99,9%. Namun entah bagaimana, Pavel berhasil membuatku mencobanya, dan ke depan, dia ternyata benar. Pavel dan saya masing-masing mengumpulkan 300 rubel, mendaftarkan LLC Audit-Telecom baru, menyewa kantor kecil, membuat kartu nama yang keren, secara umum, seperti pengusaha pemula yang mungkin paling tidak berpengalaman, dan mulai mencari klien. Menemukan klien adalah cerita yang sangat berbeda. Mungkin kami akan menulis artikel tersendiri sebagai bagian dari blog perusahaan jika ada yang tertarik. Panggilan dingin, pamflet, dll. Ini tidak membuahkan hasil apa pun. Seperti yang saya baca sekarang dari banyak cerita tentang bisnis, dengan satu atau lain cara, banyak hal bergantung pada keberuntungan. Kita beruntung. dan beberapa minggu setelah pendirian perusahaan, saudara laki-laki saya Vladimir mendekati kami, yang memberi kami klien pertama. Saya tidak akan membuat Anda bosan dengan detail bekerja dengan klien, bukan itu inti artikelnya, saya hanya akan mengatakan bahwa kami melakukan audit, mengidentifikasi area kritis dan area ini rusak saat keputusan dibuat tentang apakah akan melakukannya. bekerja sama dengan kami secara berkelanjutan sebagai agen outsourcing. Setelah itu, keputusan positif segera diambil.
Kemudian, terutama dari mulut ke mulut melalui teman, perusahaan jasa lain mulai bermunculan. Helpdesk berada dalam satu sistem. Koneksi ke peralatan jaringan dan server berbeda, atau lebih tepatnya berbeda. Beberapa orang menyimpan pintasan, yang lain menggunakan buku alamat RDP. Pemantauan adalah sistem terpisah lainnya. Sangat merepotkan bagi sebuah tim untuk bekerja dalam sistem yang berbeda. Informasi penting hilang dari pandangan. Misalnya, server terminal klien menjadi tidak tersedia. Aplikasi dari pengguna klien ini segera diterima. Spesialis dukungan membuka permintaan (diterima melalui telepon). Jika insiden dan permintaan didaftarkan dalam satu sistem, maka spesialis dukungan akan segera melihat apa masalah pengguna dan memberitahunya tentang hal itu, sekaligus menghubungkan ke objek yang diperlukan untuk mengatasi situasi tersebut. Semua orang menyadari situasi taktis dan bekerja secara harmonis. Kami belum menemukan sistem yang menggabungkan semua ini. Menjadi jelas bahwa sudah waktunya untuk membuat produk kita sendiri.
Lanjutkan bekerja pada sistem pemantauan Anda
Jelas bahwa sistem yang ditulis sebelumnya sama sekali tidak cocok untuk tugas saat ini. Baik dari segi fungsionalitas maupun kualitas. Dan diputuskan untuk menulis sistem dari awal. Secara grafis seharusnya terlihat sangat berbeda. Itu harus menjadi sistem hierarki sehingga memungkinkan untuk dengan cepat dan mudah membuka objek yang tepat untuk klien yang tepat. Skema seperti pada versi pertama sama sekali tidak dapat dibenarkan dalam kasus saat ini, karena Kliennya berbeda-beda dan tidak masalah di lokasi mana peralatan itu berada. Ini sudah ditransfer ke dokumentasi.
Jadi tugasnya adalah:
- Struktur hierarki;
- Semacam bagian server yang dapat ditempatkan di lokasi klien dalam bentuk mesin virtual untuk mengumpulkan metrik yang kita perlukan dan mengirimkannya ke server pusat, yang akan merangkum semua ini dan menunjukkannya kepada kita;
- Peringatan. Yang tidak boleh dilewatkan, karena... pada saat itu tidak mungkin ada orang yang duduk dan hanya melihat monitor;
- Sistem aplikasi. Klien mulai bermunculan yang kami layani tidak hanya server dan peralatan jaringan, tetapi juga workstation;
- Kemampuan untuk terhubung dengan cepat ke server dan peralatan dari sistem;
Tugas sudah ditetapkan, kami mulai menulis. Sepanjang jalan, memproses permintaan dari klien. Saat itu kami sudah berempat. Kami mulai menulis kedua bagian sekaligus: server pusat dan server untuk instalasi ke klien. Pada titik ini, Linux tidak lagi asing bagi kami dan diputuskan bahwa mesin virtual yang dimiliki klien akan menggunakan Debian. Tidak akan ada installer, kita hanya akan membuat proyek bagian server pada satu mesin virtual tertentu, dan kemudian kita hanya akan mengkloningnya ke klien yang diinginkan. Ini adalah kesalahan lainnya. Belakangan menjadi jelas bahwa dalam skema seperti itu, mekanisme pembaruan sama sekali tidak dikembangkan. Itu. kami menambahkan beberapa fitur baru, dan kemudian ada masalah dalam mendistribusikannya ke semua server klien, tetapi kami akan membahasnya lagi nanti, semuanya beres.
Kami membuat prototipe pertama. Dia dapat melakukan ping ke perangkat jaringan klien dan server yang kami butuhkan dan mengirimkan data ini ke server pusat kami. Dan dia, pada gilirannya, memperbarui data ini secara massal di server pusat. Di sini saya tidak hanya akan menulis cerita tentang bagaimana dan apa yang berhasil, tetapi juga kesalahan amatir apa yang dilakukan dan bagaimana kemudian saya harus membayarnya seiring berjalannya waktu. Jadi, seluruh pohon objek disimpan dalam satu file dalam bentuk objek berseri. Saat kami menghubungkan beberapa klien ke sistem, semuanya kurang lebih normal, meskipun terkadang ada beberapa artefak yang sama sekali tidak dapat dipahami. Namun ketika kami menghubungkan selusin server ke sistem, keajaiban mulai terjadi. Terkadang, karena alasan yang tidak diketahui, semua objek dalam sistem menghilang begitu saja. Penting untuk dicatat di sini bahwa server tempat klien mengirimkan data ke server pusat setiap beberapa detik melalui permintaan POST. Pembaca yang penuh perhatian dan pemrogram berpengalaman sudah menebak bahwa ada masalah akses ganda ke file tempat objek serial disimpan dari utas berbeda pada waktu yang sama. Dan ketika hal ini terjadi, keajaiban terjadi dengan hilangnya benda-benda. File itu menjadi kosong. Namun semua ini tidak serta merta ditemukan, melainkan hanya saat beroperasi dengan beberapa server. Selama waktu ini, fungsionalitas pemindaian port telah ditambahkan (server mengirim ke pusat tidak hanya informasi tentang ketersediaan perangkat, tetapi juga tentang port yang terbuka pada perangkat tersebut). Ini dilakukan dengan memanggil perintah:
$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);
hasilnya sering kali salah dan pemindaian membutuhkan waktu lama untuk diselesaikan. Saya benar-benar lupa tentang ping, itu dilakukan melalui fping:
system("fping -r 3 -t 100 {$this->ip}");
Ini juga tidak diparalelkan sehingga prosesnya sangat lama. Kemudian, seluruh daftar alamat IP yang diperlukan untuk verifikasi dikirim ke fping sekaligus, dan kami kembali menerima daftar siap pakai dari mereka yang merespons. Berbeda dengan kami, fping mampu memparalelkan proses.
Pekerjaan rutin umum lainnya adalah menyiapkan beberapa layanan melalui WEB. Misalnya, ECP dari MS Exchange. Pada dasarnya itu hanya sebuah tautan. Dan kami memutuskan bahwa kami harus dapat menambahkan tautan tersebut langsung ke sistem, agar tidak perlu mencari di dokumentasi atau di tempat lain di bookmark tentang cara mengakses ECP klien tertentu. Beginilah konsep tautan sumber daya untuk sistem muncul, fungsinya tersedia hingga hari ini dan hampir tidak berubah.
Cara kerja tautan sumber daya di Veliam
Koneksi jarak jauh
Ini adalah apa yang tampak dalam aksi di versi Veliam saat ini
Salah satu tugasnya adalah terhubung dengan cepat dan mudah ke server, yang sudah ada banyak (lebih dari seratus) dan memilah jutaan pintasan RDP yang disimpan sebelumnya sangatlah merepotkan. Dibutuhkan sebuah alat. Ada perangkat lunak di Internet yang mirip dengan buku alamat untuk koneksi RDP tersebut, tetapi perangkat lunak tersebut tidak terintegrasi dengan sistem pemantauan, dan akun tidak dapat disimpan. Memasukkan akun untuk klien yang berbeda setiap saat adalah hal yang sangat buruk ketika Anda terhubung puluhan kali sehari ke server yang berbeda. Dengan SSH, segalanya menjadi sedikit lebih baik; ada banyak perangkat lunak bagus yang memungkinkan Anda mengatur koneksi tersebut ke dalam folder dan mengingat akun di dalamnya. Tapi ada 2 masalah. Yang pertama adalah kami tidak menemukan satu program pun untuk koneksi RDP dan SSH. Yang kedua adalah jika suatu saat saya tidak berada di depan komputer dan saya perlu terhubung dengan cepat, atau saya baru saja menginstal ulang sistem, saya harus membuka dokumentasi untuk melihat akun dari klien ini. Itu tidak nyaman dan membuang-buang waktu.
Struktur hierarki yang kami butuhkan untuk server klien sudah tersedia di produk internal kami. Saya hanya perlu memikirkan cara menyambungkan koneksi cepat ke peralatan yang diperlukan di sana. Sebagai permulaan, setidaknya dalam jaringan Anda.
Mempertimbangkan fakta bahwa klien di sistem kami adalah browser yang tidak memiliki akses ke sumber daya lokal komputer, untuk meluncurkan aplikasi yang kami perlukan dengan beberapa perintah, diciptakan untuk melakukan semuanya melalui "Windows skema url khusus”. Ini adalah bagaimana “plugin” tertentu muncul untuk sistem kami, yang hanya menyertakan Putty dan Remote Desktop Plus dan, selama instalasi, cukup mendaftarkan skema URI di Windows. Sekarang, ketika kami ingin terhubung ke suatu objek melalui RDP atau SSH, kami mengklik tindakan ini di sistem kami dan URI Kustom berfungsi. Mstsc.exe standar yang terpasang di Windows atau dempul, yang merupakan bagian dari "plugin", diluncurkan. Saya memberi tanda kutip pada kata plugin karena ini bukan plugin browser dalam pengertian klasik.
Setidaknya itu adalah sesuatu. Buku alamat yang nyaman. Selain itu, dalam kasus Putty, secara umum semuanya baik-baik saja; dapat diberikan koneksi IP, login dan kata sandi sebagai parameter input. Itu. Kami telah terhubung ke server Linux di jaringan kami dengan satu klik tanpa memasukkan kata sandi. Namun dengan RDP tidak sesederhana itu. Mstsc standar tidak dapat memberikan kredensial sebagai parameter. Remote Desktop Plus datang untuk menyelamatkan. Dia membiarkan hal ini terjadi. Sekarang kita bisa melakukannya tanpa itu, tapi untuk waktu yang lama itu adalah asisten setia dalam sistem kami. Dengan situs HTTP(S) semuanya sederhana, objek tersebut cukup dibuka di browser dan hanya itu. Nyaman dan praktis. Tapi kebahagiaan ini hanya ada di jaringan internal.
Karena kami menyelesaikan sebagian besar masalah dari jarak jauh dari kantor, hal termudah adalah menyediakan VPN untuk klien. Dan kemudian dimungkinkan untuk menyambungkannya dari sistem kami. Tapi itu masih terasa kurang nyaman. Untuk setiap klien, penting untuk menyimpan banyak koneksi VPN yang diingat di setiap komputer, dan sebelum menghubungkan ke klien mana pun, VPN yang sesuai harus diaktifkan. Kami menggunakan solusi ini cukup lama. Namun jumlah klien meningkat, jumlah VPN juga meningkat, dan semua ini mulai membebani dan sesuatu harus dilakukan untuk mengatasinya. Air mata terutama mengalir di mata saya setelah menginstal ulang sistem, ketika saya harus memasukkan kembali lusinan koneksi VPN di profil Windows baru. Berhentilah bertahan dengan hal ini, kataku, dan mulailah memikirkan apa yang bisa kulakukan.
Kebetulan semua klien memiliki perangkat dari perusahaan terkenal Mikrotik sebagai router. Mereka sangat fungsional dan nyaman untuk melakukan hampir semua tugas. Sisi negatifnya adalah mereka “dibajak”. Kami memecahkan masalah ini hanya dengan menutup semua akses dari luar. Tapi entah bagaimana, perlu untuk memiliki akses ke sana tanpa datang ke tempat klien, karena... itu panjang. Kami cukup membuat terowongan untuk masing-masing Mikrotik tersebut dan memisahkannya ke dalam kumpulan terpisah. tanpa routing apapun, sehingga tidak ada koneksi jaringan Anda dengan jaringan klien dan jaringannya satu sama lain.
Ide ini lahir untuk memastikan bahwa ketika saya mengklik objek yang saya butuhkan di sistem, server pemantauan pusat, mengetahui akun SSH semua klien Mikrotik, terhubung ke yang diinginkan, membuat aturan penerusan ke host yang diinginkan dengan pelabuhan yang diperlukan. Ada beberapa poin di sini. Solusinya tidak universal - ini hanya akan berfungsi untuk Mikrotik, karena sintaks perintahnya berbeda untuk semua router. Selain itu, penerusan tersebut kemudian harus dihapus, dan bagian server dari sistem kami pada dasarnya tidak dapat melacak dengan cara apa pun apakah saya telah menyelesaikan sesi RDP saya. Nah, penerusan seperti itu merupakan lubang bagi klien. Namun kami tidak mengejar universalitas, karena... produk tersebut hanya digunakan di dalam perusahaan kami dan tidak ada pemikiran untuk merilisnya ke publik.
Setiap masalah diselesaikan dengan caranya sendiri. Saat aturan dibuat, penerusan ini hanya tersedia untuk satu alamat IP eksternal tertentu (dari mana koneksi diinisialisasi). Jadi lubang keamanan dapat dihindari. Namun dengan setiap koneksi tersebut, aturan Mikrotik ditambahkan ke halaman NAT dan tidak dihapus. Dan semua orang tahu bahwa semakin banyak aturan yang ada, semakin banyak pula prosesor router yang dimuat. Dan secara umum, saya tidak dapat menerima bahwa suatu hari saya akan pergi ke Mikrotik, dan akan ada ratusan aturan yang mati dan tidak berguna.
Karena server kami tidak dapat melacak status koneksi, biarkan Mikrotik melacaknya sendiri. Dan saya menulis skrip yang terus memantau semua aturan penerusan dengan deskripsi spesifik dan memeriksa apakah koneksi TCP memiliki aturan yang sesuai. Jika sudah lama tidak ada, maka koneksi mungkin sudah selesai dan penerusan ini dapat dihapus. Semuanya berhasil, naskahnya bekerja dengan baik.
Ngomong-ngomong, ini dia:
global atmonrulecounter {"dontDelete"="dontDelete"}
:foreach i in=[/ip firewall nat find comment~"atmon_script_main"] do={
local dstport [/ip firewall nat get value-name="dst-port" $i]
local dstaddress [/ip firewall nat get value-name="dst-address" $i]
local dstaddrport "$dstaddress:$dstport"
#log warning message=$dstaddrport
local thereIsCon [/ip firewall connection find dst-address~"$dstaddrport"]
if ($thereIsCon = "") do={
set ($atmonrulecounter->$dstport) ($atmonrulecounter->$dstport + 1)
#:log warning message=($atmonrulecounter->$dstport)
if (($atmonrulecounter->$dstport) > 5) do={
#log warning message="Removing nat rules added automaticaly by atmon_script"
/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_main_$dstport"]
/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_sub_$dstport"]
set ($atmonrulecounter->$dstport) 0
}
} else {
set ($atmonrulecounter->$dstport) 0
}
}
Tentunya bisa dibuat lebih indah, lebih cepat, dll, tetapi berhasil, tidak memuat Mikrotik dan berfungsi dengan baik. Kami akhirnya dapat terhubung ke server klien dan peralatan jaringan hanya dengan satu klik. Tanpa membuka VPN atau memasukkan kata sandi. Sistem ini menjadi sangat nyaman untuk digunakan. Waktu layanan berkurang, dan kami semua menghabiskan waktu bekerja daripada terhubung ke objek yang diperlukan.
Cadangan Mikrotik
Kami mengkonfigurasi cadangan semua Mikrotik ke FTP. Dan secara keseluruhan semuanya baik-baik saja. Namun ketika Anda perlu mendapatkan cadangan, Anda harus membuka FTP ini dan mencarinya di sana. Kami memiliki sistem di mana semua router terhubung; kami dapat berkomunikasi dengan perangkat melalui SSH. Mengapa kita tidak membuatnya agar sistemnya sendiri yang mengambil backup dari seluruh Mikrotik setiap hari, pikir saya. Dan dia mulai menerapkannya. Kami terhubung, membuat cadangan, dan menyimpannya.
Kode script di PHP untuk mengambil backup dari Mikrotik:
<?php
$IP = '0.0.0.0';
$LOGIN = 'admin';
$PASSWORD = '';
$BACKUP_NAME = 'test';
$connection = ssh2_connect($IP, 22);
if (!ssh2_auth_password($connection, $LOGIN, $PASSWORD)) exit;
ssh2_exec($connection, '/system backup save name="atmon" password="atmon"');
stream_get_contents($connection);
ssh2_exec($connection, '/export file="atmon.rsc"');
stream_get_contents($connection);
sleep(40); // Waiting bakup makes
$sftp = ssh2_sftp($connection);
// Download backup file
$size = filesize("ssh2.sftp://$sftp/atmon.backup");
$stream = fopen("ssh2.sftp://$sftp/atmon.backup", 'r');
$contents = '';
$read = 0;
$len = $size;
while ($read < $len && ($buf = fread($stream, $len - $read))) {
$read += strlen($buf);
$contents .= $buf;
}
file_put_contents ($BACKUP_NAME . ‘.backup’,$contents);
@fclose($stream);
sleep(3);
// Download RSC file
$size = filesize("ssh2.sftp://$sftp/atmon.rsc");
$stream = fopen("ssh2.sftp://$sftp/atmon.rsc", 'r');
$contents = '';
$read = 0;
$len = $size;
while ($read < $len && ($buf = fread($stream, $len - $read))) {
$read += strlen($buf);
$contents .= $buf;
}
file_put_contents ($BACKUP_NAME . ‘.rsc’,$contents);
@fclose($stream);
ssh2_exec($connection, '/file remove atmon.backup');
ssh2_exec($connection, '/file remove atmon.rsc');
?>
Cadangan diambil dalam dua bentuk - konfigurasi biner dan teks. Biner membantu memulihkan konfigurasi yang diperlukan dengan cepat, dan biner memungkinkan Anda memahami apa yang perlu dilakukan jika ada penggantian peralatan secara paksa dan biner tidak dapat diunggah ke dalamnya. Hasilnya, kami mendapatkan fungsionalitas lain yang nyaman di sistem. Selain itu, ketika menambahkan Mikrotik baru, tidak perlu mengkonfigurasi apa pun; saya cukup menambahkan objek ke sistem dan membuat akun melalui SSH. Kemudian sistem itu sendiri yang mengurus pengambilan cadangan. Versi SaaS Veliam saat ini belum memiliki fungsi ini, namun kami akan segera mem-portingnya.
Tangkapan layar seperti apa di sistem internal
Transisi ke penyimpanan database normal
Saya sudah menulis di atas bahwa artefak muncul. Terkadang seluruh daftar objek dalam sistem hilang begitu saja, terkadang saat mengedit suatu objek, informasinya tidak disimpan dan objek harus diganti namanya sebanyak tiga kali. Ini sangat membuat jengkel semua orang. Hilangnya objek jarang terjadi, dan mudah dipulihkan dengan memulihkan file ini, namun kegagalan saat mengedit objek cukup sering terjadi. Mungkin, awalnya saya tidak melakukan ini melalui database karena tidak terlintas dalam pikiran saya bagaimana mungkin menyimpan pohon dengan semua koneksi dalam tabel datar. Itu datar, tetapi pohonnya hierarkis. Tapi solusi yang baik untuk akses ganda, dan selanjutnya (saat sistem menjadi lebih kompleks) transaksional, adalah DBMS. Saya mungkin bukan orang pertama yang mengalami masalah ini. Saya mulai mencari di Google. Ternyata semuanya sudah ditemukan sebelum saya dan ada beberapa algoritma yang membangun pohon dari meja datar. Setelah melihat masing-masing, saya menerapkan salah satunya. Tapi ini sudah merupakan sistem versi baru, karena... Faktanya, karena itu, saya harus menulis ulang cukup banyak. Hasilnya wajar, masalah perilaku acak sistem hilang. Beberapa orang mungkin mengatakan bahwa kesalahannya sangat amatir (skrip berulir tunggal, menyimpan informasi yang diakses beberapa kali secara bersamaan dari utas berbeda dalam sebuah file, dll.) di bidang pengembangan perangkat lunak. Mungkin ini benar, tetapi pekerjaan utama saya adalah administrasi, dan pemrograman adalah pekerjaan sampingan bagi jiwa saya, dan saya sama sekali tidak memiliki pengalaman bekerja dalam tim pemrogram, di mana hal-hal mendasar seperti itu akan langsung disarankan kepada saya oleh senior saya. kawan. Oleh karena itu, saya mengisi semua kekurangan ini sendiri, tetapi saya mempelajari materinya dengan sangat baik. Dan juga, pekerjaan saya melibatkan pertemuan dengan klien, tindakan yang bertujuan untuk mempromosikan perusahaan, banyak masalah administratif dalam perusahaan, dan masih banyak lagi. Tapi bagaimanapun juga, apa yang sudah ada tetap diminati. Saya dan teman-teman sendiri menggunakan produk ini dalam pekerjaan kami sehari-hari. Ada ide dan solusi yang sejujurnya tidak berhasil dan membuang-buang waktu, tetapi pada akhirnya menjadi jelas bahwa ini bukanlah alat yang berfungsi dan tidak ada yang menggunakannya dan tidak berakhir di Veliam.
Meja Bantuan - Meja Bantuan
Tidak salah jika disebutkan bagaimana HelpDesk terbentuk. Ini adalah cerita yang sama sekali berbeda, karena... di Veliam ini sudah merupakan versi ke-3 yang benar-benar baru, yang berbeda dari semua versi sebelumnya. Sekarang ini adalah sistem yang sederhana, intuitif tanpa embel-embel yang tidak perlu, dengan kemampuan untuk berintegrasi dengan domain, serta kemampuan untuk mengakses profil pengguna yang sama dari mana saja menggunakan tautan dari email. Dan yang paling penting, pemohon dapat terhubung melalui VNC dari mana saja (di rumah atau di kantor) langsung dari aplikasi tanpa VPN atau penerusan porta. Saya akan memberi tahu Anda bagaimana kami sampai pada hal ini, apa yang terjadi sebelumnya, dan keputusan buruk apa yang telah dibuat.
Kami terhubung dengan pengguna melalui TeamViewer yang terkenal. Semua komputer yang penggunanya kami layani telah terpasang TV. Kesalahan pertama yang kami lakukan, dan kemudian menghapusnya, adalah menghubungkan setiap klien HD ke perangkat keras. Bagaimana cara pengguna masuk ke sistem HD untuk meninggalkan permintaan? Selain TV, setiap orang memiliki utilitas khusus yang diinstal di komputer mereka, ditulis dalam Lazarus (banyak orang di sini akan memutar mata mereka, dan bahkan mungkin mencari di Google apa itu, tetapi bahasa kompilasi terbaik yang saya tahu adalah Delphi, dan Lazarus hampir hal yang sama, hanya gratis). Secara umum, pengguna meluncurkan file batch khusus yang meluncurkan utilitas ini, yang pada gilirannya membaca HWID sistem dan setelah itu browser diluncurkan dan terjadi otorisasi. Mengapa hal ini dilakukan? Di beberapa perusahaan, jumlah pengguna layanan dihitung secara individual, dan harga layanan setiap bulan didasarkan pada jumlah orang. Hal ini dapat dimengerti, kata Anda, tetapi mengapa hal ini terkait dengan perangkat keras? Caranya sangat sederhana, beberapa orang pulang ke rumah dan mengajukan permintaan dari laptop di rumah mereka dengan gaya “jadikan semuanya indah untukku di sini”. Selain membaca HWID sistem, utilitas tersebut menarik ID Teamviewer saat ini dari registri dan juga mengirimkannya kepada kami. Teamviewer memiliki API untuk integrasi. Dan kami melakukan integrasi ini. Tapi ada satu tangkapan. Melalui API ini, tidak mungkin untuk terhubung ke komputer pengguna ketika dia tidak secara eksplisit memulai sesi ini dan setelah mencoba menyambungkannya, dia juga harus mengklik "konfirmasi". Pada saat itu, tampak logis bagi kami bahwa tidak seorang pun boleh terhubung tanpa permintaan pengguna, dan karena orang tersebut berada di depan komputer, dia akan memulai sesi dan merespons dengan tegas permintaan koneksi jarak jauh. Semuanya menjadi salah. Pelamar lupa untuk menekan tombol memulai sesi, dan harus memberitahu mereka hal ini melalui percakapan telepon. Ini membuang-buang waktu dan membuat frustrasi kedua sisi proses. Selain itu, tidak jarang seseorang meninggalkan permintaan, tetapi diperbolehkan untuk terhubung hanya ketika dia pergi untuk makan siang. Sebab masalahnya tidak kritis dan ia tidak ingin proses pekerjaannya terganggu. Oleh karena itu, dia tidak akan menekan tombol apa pun untuk mengizinkan koneksi. Ini adalah bagaimana fungsi tambahan muncul saat masuk ke HelpDesk - membaca ID Teamviwer. Kami mengetahui kata sandi permanen yang digunakan saat menginstal Teamviwer. Lebih tepatnya, hanya sistem yang mengetahuinya, karena sudah terpasang di dalam penginstal dan di sistem kami. Oleh karena itu, ada tombol koneksi dari aplikasi, dengan mengkliknya tidak perlu menunggu apa pun, tetapi Teamviewer segera terbuka dan terjadi koneksi. Hasilnya, ada dua jenis kemungkinan koneksi. Melalui API Teamviewer resmi dan buatan kami sendiri. Yang mengejutkan saya, mereka segera berhenti menggunakan yang pertama, meskipun ada instruksi untuk menggunakannya hanya dalam kasus-kasus khusus dan ketika pengguna sendiri memberikan izin. Tetap saja, beri aku keamanan sekarang. Namun ternyata pelamar tidak membutuhkan hal tersebut. Semuanya baik-baik saja jika dihubungkan tanpa tombol konfirmasi.
Beralih ke multithreading di Linux
Pertanyaan tentang mempercepat perjalanan pemindai jaringan untuk keterbukaan daftar port yang telah ditentukan dan ping sederhana ke objek jaringan sudah lama mulai muncul. Di sini, tentu saja, solusi pertama yang terlintas dalam pikiran adalah multithreading. Karena waktu utama yang dihabiskan untuk ping adalah menunggu paket dikembalikan, dan ping berikutnya tidak dapat dimulai sampai paket sebelumnya dikembalikan, di perusahaan yang bahkan memiliki 20+ server ditambah peralatan jaringan, hal ini sudah berjalan cukup lambat. Intinya satu paket mungkin hilang, tapi jangan langsung memberitahu administrator sistem tentang hal itu. Dia akan berhenti menerima spam seperti itu dengan sangat cepat. Ini berarti Anda perlu melakukan ping ke setiap objek lebih dari satu kali sebelum membuat kesimpulan tentang tidak dapat diaksesnya. Tanpa terlalu detail, perlu diparalelkan karena jika hal ini tidak dilakukan, kemungkinan besar administrator sistem akan mengetahui masalahnya dari klien, dan bukan dari sistem pemantauan.
PHP sendiri tidak mendukung multithreading. Mampu melakukan multiproses, Anda dapat melakukan fork. Tapi sebenarnya saya sudah menulis mekanisme polling dan saya ingin membuatnya agar saya bisa menghitung semua node yang saya butuhkan dari database, melakukan ping semuanya sekaligus, menunggu respon dari masing-masing node dan baru setelah itu segera tulis data. Ini menghemat jumlah permintaan baca. Multithreading sangat cocok dengan ide ini. Untuk PHP terdapat modul PThreads yang memungkinkan Anda melakukan multithreading sebenarnya, meskipun perlu banyak penyesuaian untuk menyiapkannya di PHP 7.2, tetapi sudah selesai. Pemindaian port dan ping kini cepat. Dan bukannya, misalnya, 15 detik per putaran sebelumnya, proses ini mulai memakan waktu 2 detik. Itu adalah hasil yang bagus.
Audit cepat terhadap perusahaan baru
Bagaimana fungsi pengumpulan berbagai metrik dan karakteristik perangkat keras muncul? Itu mudah. Terkadang kita hanya diperintahkan untuk mengaudit infrastruktur TI saat ini. Nah, hal yang sama juga diperlukan untuk mempercepat audit klien baru. Kami membutuhkan sesuatu yang memungkinkan kami datang ke perusahaan menengah atau besar dan dengan cepat mengetahui apa yang mereka miliki. Menurut pendapat saya, ping di jaringan internal hanya diblokir oleh mereka yang ingin mempersulit hidup mereka sendiri, dan menurut pengalaman kami, hanya sedikit dari mereka. Tapi ada juga orang seperti itu. Oleh karena itu, Anda dapat dengan cepat memindai jaringan untuk mengetahui keberadaan perangkat dengan ping sederhana. Kemudian kita dapat menambahkannya dan memindai port terbuka yang kita minati. Faktanya, fungsi ini sudah ada; hanya perlu menambahkan perintah dari server pusat ke server budak sehingga dapat memindai jaringan yang ditentukan dan menambahkan semua yang ditemukan ke dalam daftar. Saya lupa menyebutkan, diasumsikan bahwa kami sudah memiliki gambar siap pakai dengan sistem yang dikonfigurasi (server pemantauan budak) yang dapat kami luncurkan dari klien selama audit dan menghubungkannya ke cloud kami.
Namun hasil audit biasanya mencakup banyak informasi berbeda, dan salah satunya adalah jenis perangkat apa yang ada di jaringan. Pertama-tama, kami tertarik pada server Windows dan workstation Windows sebagai bagian dari domain. Karena di perusahaan menengah dan besar, kurangnya domain mungkin merupakan pengecualian dari aturan tersebut. Untuk berbicara satu bahasa, rata-rata menurut saya adalah 100+ orang. Penting untuk menemukan cara untuk mengumpulkan data dari semua mesin dan server Windows, mengetahui IP dan akun administrator domainnya, tetapi tanpa menginstal perangkat lunak apa pun di masing-masing mesin dan server tersebut. Antarmuka WMI hadir untuk menyelamatkan. Instrumentasi Manajemen Windows (WMI) secara harfiah berarti alat manajemen Windows. WMI adalah salah satu teknologi dasar untuk manajemen terpusat dan pemantauan pengoperasian berbagai bagian infrastruktur komputer yang menjalankan platform Windows. Diambil dari wiki. Selanjutnya, saya harus mengotak-atik lagi untuk mengkompilasi wmic (ini adalah klien WMI) untuk Debian. Setelah semuanya siap, yang tersisa hanyalah melakukan polling pada node yang diperlukan melalui wmic untuk mendapatkan informasi yang diperlukan. Melalui WMI Anda dapat memperoleh hampir semua informasi dari komputer Windows, dan terlebih lagi, Anda juga dapat mengontrol komputer melaluinya, misalnya mengirimkannya untuk reboot. Beginilah kumpulan informasi tentang stasiun dan server Windows di sistem kami muncul. Selain itu, terdapat informasi terkini tentang indikator beban sistem saat ini. Kami lebih sering memintanya, dan informasi tentang perangkat keras lebih jarang. Setelah ini, audit menjadi sedikit lebih menyenangkan.
Keputusan distribusi perangkat lunak
Kami sendiri menggunakan sistem ini setiap hari, dan selalu terbuka untuk setiap karyawan teknis. Dan kami berpikir bahwa kami dapat berbagi dengan orang lain apa yang sudah kami miliki. Sistem belum siap untuk didistribusikan. Banyak yang harus dikerjakan ulang agar versi lokalnya berubah menjadi SaaS. Hal ini mencakup perubahan dalam berbagai aspek teknis sistem (koneksi jarak jauh, layanan dukungan), analisis modul untuk perizinan, sharding database pelanggan, penskalaan setiap layanan, dan pengembangan sistem pembaruan otomatis untuk semua bagian. Tapi ini akan menjadi artikel bagian kedua.
Memperbarui
Sumber: www.habr.com