Hello semua, nama saya Sergey Emelyanchik. Saya adalah ketua syarikat Audit-Telekom, pembangun utama dan pengarang sistem Veliam. Saya memutuskan untuk menulis artikel tentang cara saya dan rakan saya mencipta syarikat penyumberan luar, menulis perisian untuk diri kita sendiri dan seterusnya mula mengedarkannya kepada semua orang melalui sistem SaaS. Mengenai bagaimana saya secara mutlak tidak percaya bahawa ini mungkin. Artikel itu akan mengandungi bukan sahaja cerita, tetapi juga butiran teknikal tentang cara produk Veliam dicipta. Termasuk beberapa keping kod sumber. Saya akan memberitahu anda apa kesilapan yang kami lakukan dan bagaimana kami membetulkannya kemudian. Terdapat keraguan sama ada untuk menerbitkan artikel sedemikian. Tetapi saya fikir adalah lebih baik untuk melakukannya, mendapatkan maklum balas dan menambah baik, daripada tidak menerbitkan artikel dan memikirkan apa yang akan berlaku jika...
prasejarah
Saya bekerja di satu syarikat sebagai pekerja IT. Syarikat itu agak besar dengan struktur rangkaian yang luas. Saya tidak akan memikirkan tanggungjawab pekerjaan saya, saya hanya akan mengatakan bahawa mereka pasti tidak termasuk pembangunan apa-apa.
Kami mempunyai pemantauan, tetapi semata-mata kerana minat akademik saya ingin cuba menulis yang paling mudah saya sendiri. Ideanya ialah ini: Saya mahu ia berada di web, supaya saya boleh masuk dengan mudah tanpa memasang mana-mana pelanggan dan melihat apa yang berlaku dengan rangkaian daripada sebarang peranti, termasuk peranti mudah alih melalui Wi-Fi, dan saya juga benar-benar ingin cepat memahami apa Ada peralatan di dalam bilik yang telah menjadi "mopey" kerana... terdapat keperluan yang sangat ketat untuk masa tindak balas kepada masalah tersebut. Akibatnya, rancangan telah lahir di kepala saya untuk menulis halaman web ringkas yang terdapat latar belakang jpeg dengan gambar rajah rangkaian, memotong peranti itu sendiri dengan alamat IP mereka dalam gambar ini, dan memaparkan kandungan dinamik dalam bentuk alamat IP hijau atau merah berkelip di atas gambar dalam koordinat yang diperlukan. Tugasan telah ditetapkan, mari kita mulakan.
Sebelum ini, saya mengaturcarakan dalam Delphi, PHP, JS dan sangat cetek C++. Saya tahu betul cara rangkaian berfungsi. VLAN, Penghalaan (OSPF, EIGRP, BGP), NAT. Ini sudah cukup untuk saya menulis prototaip pemantauan primitif sendiri.
Saya menulis apa yang saya rancang dalam PHP. Pelayan Apache dan PHP berada pada Windows kerana... Linux bagi saya pada masa itu adalah sesuatu yang tidak dapat difahami dan sangat kompleks, kerana ternyata kemudian, saya sangat tersilap dan di banyak tempat Linux jauh lebih mudah daripada Windows, tetapi ini adalah topik yang berasingan dan kita semua tahu berapa banyak holivar yang terdapat pada topik ini. Penjadual tugas Windows menarik pada selang kecil (saya tidak ingat dengan tepat, tetapi kira-kira sekali setiap tiga saat) skrip PHP yang meninjau semua objek dengan ping cetek dan menyimpan keadaan ke fail.
system(βping -n 3 -w 100 {$ip_address}β);
Ya, ya, bekerja dengan pangkalan data pada masa itu juga tidak dikuasai untuk saya. Saya tidak tahu bahawa adalah mungkin untuk menyelaraskan proses, dan melalui semua nod rangkaian mengambil masa yang lama, kerana... ini berlaku dalam satu thread. Masalah timbul terutamanya apabila beberapa nod tidak tersedia, kerana masing-masing melengahkan skrip selama 300 ms. Di sisi klien terdapat fungsi gelung mudah yang, pada selang beberapa saat, memuat turun maklumat yang dikemas kini dari pelayan dengan permintaan Ajax dan mengemas kini antara muka. Jadi, selepas 3 ping yang tidak berjaya berturut-turut, jika halaman web dengan pemantauan dibuka pada komputer, komposisi ceria dimainkan.
Apabila semuanya berjaya, saya sangat terinspirasi dengan hasilnya dan berfikir bahawa saya boleh menambah lebih banyak lagi (disebabkan pengetahuan dan keupayaan saya). Tetapi saya sentiasa tidak menyukai sistem dengan sejuta carta, yang saya fikir ketika itu, dan masih fikir sehingga hari ini, adalah tidak perlu dalam kebanyakan kes. Saya mahu meletakkan di sana hanya apa yang benar-benar akan membantu saya dalam kerja saya. Prinsip ini kekal asas kepada perkembangan Veliam sehingga hari ini. Selanjutnya, saya menyedari bahawa ia akan menjadi sangat keren jika saya tidak perlu terus memantau dan mengetahui tentang masalah, dan apabila ia berlaku, kemudian buka halaman dan lihat di mana nod rangkaian bermasalah ini terletak dan apa yang perlu dilakukan dengannya seterusnya . Entah bagaimana saya tidak membaca e-mel ketika itu, saya langsung tidak menggunakannya. Saya terjumpa di Internet bahawa terdapat gerbang SMS yang anda boleh hantar permintaan GET atau POST, dan mereka akan menghantar SMS ke telefon mudah alih saya dengan teks yang saya tulis. Saya segera menyedari bahawa saya benar-benar mahukan ini. Dan saya mula mengkaji dokumentasi. Selepas beberapa lama saya berjaya, dan kini saya menerima SMS mengenai masalah pada rangkaian pada telefon bimbit saya dengan nama "objek jatuh". Walaupun sistem itu primitif, ia ditulis oleh saya sendiri, dan perkara yang paling penting yang mendorong saya untuk membangunkannya ialah ia adalah program aplikasi yang sangat membantu saya dalam kerja saya.
Dan kemudian harinya tiba apabila salah satu saluran Internet terputus di tempat kerja, dan pemantauan saya tidak memberitahu saya mengenainya. Memandangkan Google DNS masih melakukan ping dengan sempurna. Sudah tiba masanya untuk memikirkan bagaimana anda boleh memantau bahawa saluran komunikasi masih hidup. Terdapat idea yang berbeza tentang cara melakukan ini. Saya tidak mempunyai akses kepada semua peralatan. Kami terpaksa memikirkan cara untuk memahami saluran mana yang disiarkan, tetapi tanpa dapat melihatnya pada peralatan rangkaian itu sendiri. Kemudian seorang rakan sekerja datang dengan idea bahawa ada kemungkinan bahawa pengesanan laluan ke pelayan awam mungkin berbeza bergantung pada saluran komunikasi yang digunakan untuk mengakses Internet pada masa ini. Saya periksa dan ternyata begitu. Terdapat laluan yang berbeza semasa mengesan.
system(βtracert -d -w 500 8.8.8.8β);
Jadi skrip lain muncul, atau lebih tepat, atas sebab tertentu jejak telah ditambahkan pada penghujung skrip yang sama, yang melakukan ping pada semua peranti pada rangkaian. Lagipun, ini adalah satu lagi proses panjang yang telah dilaksanakan dalam urutan yang sama dan memperlahankan kerja keseluruhan skrip. Tetapi kemudian ia tidak begitu jelas. Tetapi satu cara atau yang lain, dia melakukan tugasnya, kod itu dengan tegas menentukan jenis pengesanan yang sepatutnya untuk setiap saluran. Beginilah sistem mula berfungsi, yang sudah dipantau (dengan lantang berkata, kerana tiada pengumpulan sebarang metrik, tetapi hanya ping) peranti rangkaian (penghala, suis, wi-fi, dll.) dan saluran komunikasi dengan dunia luar . Mesej SMS tiba dengan kerap dan rajah sentiasa menunjukkan dengan jelas di mana masalahnya.
Tambahan pula, dalam kerja seharian saya terpaksa melakukan silang silang. Dan saya bosan pergi ke suis Cisco setiap kali untuk melihat antara muka yang hendak digunakan. Betapa hebatnya untuk mengklik pada objek dalam pemantauan dan melihat senarai antara mukanya dengan penerangan. Ia akan menjimatkan masa saya. Selain itu, dalam skim ini tidak perlu menjalankan Putty atau SecureCRT untuk memasukkan akaun dan arahan. Saya hanya mengklik pada pemantauan, melihat apa yang diperlukan dan pergi melakukan tugas saya. Saya mula mencari cara untuk berinteraksi dengan suis. Saya segera menemui 2 pilihan: SNMP atau log masuk ke suis melalui SSH, memasukkan arahan yang saya perlukan dan menghuraikan hasilnya. Saya menolak SNMP kerana kerumitan pelaksanaannya; Saya tidak sabar untuk mendapatkan hasilnya. dengan SNMP, anda perlu menggali ke dalam MIB untuk masa yang lama dan, berdasarkan data ini, menjana data tentang antara muka. Terdapat pasukan yang hebat di CISCO
show interface statusIa menunjukkan dengan tepat apa yang saya perlukan untuk lintasan silang. Mengapa perlu bersusah payah dengan SNMP sedangkan saya hanya mahu melihat output arahan ini, saya fikir. Selepas beberapa lama, saya menyedari peluang ini. Diklik pada objek pada halaman web. Satu peristiwa telah dicetuskan di mana pelanggan AJAX menghubungi pelayan, dan ia, seterusnya, disambungkan melalui SSH ke suis yang saya perlukan (kelayakan telah dikodkan keras ke dalam kod, tidak ada keinginan untuk memperhalusinya, untuk membuat beberapa menu berasingan di mana ia mungkin untuk menukar akaun dari antara muka, saya memerlukan hasilnya dan dengan cepat) Saya memasukkan arahan di atas di sana dan menghantarnya kembali ke penyemak imbas. Jadi saya mula melihat maklumat mengenai antara muka dengan satu klik tetikus. Ini sangat mudah, terutamanya apabila anda perlu melihat maklumat ini pada suis yang berbeza sekaligus.
Pemantauan saluran berasaskan jejak akhirnya bukan idea terbaik, kerana... kadangkala kerja telah dijalankan pada rangkaian, dan pengesanan boleh berubah dan pemantauan mula menjerit kepada saya bahawa terdapat masalah dengan saluran. Tetapi selepas menghabiskan banyak masa untuk analisis, saya menyedari bahawa semua saluran berfungsi, dan pemantauan saya telah menipu saya. Akibatnya, saya meminta rakan sekerja saya yang menguruskan suis pembentuk saluran supaya menghantar syslog kepada saya apabila status keterlihatan jiran berubah. Oleh itu, ia adalah lebih mudah, lebih pantas dan lebih tepat daripada mengesan. Peristiwa seperti kehilangan jiran telah tiba dan saya serta-merta mengeluarkan pemberitahuan tentang saluran ke bawah.
Selanjutnya, beberapa lagi arahan muncul apabila mengklik pada objek, dan SNMP telah ditambahkan untuk mengumpul beberapa metrik, dan itu pada asasnya. Sistem ini tidak pernah dibangunkan lagi. Ia melakukan semua yang saya perlukan, ia adalah alat yang baik. Ramai pembaca mungkin akan memberitahu saya bahawa sudah terdapat banyak perisian di Internet untuk menyelesaikan masalah ini. Tetapi sebenarnya, saya tidak mencari produk percuma seperti itu pada masa itu dan saya benar-benar mahu mengembangkan kemahiran pengaturcaraan saya, dan cara yang lebih baik untuk mengatasi masalah ini daripada masalah aplikasi sebenar. Pada ketika ini, versi pertama pemantauan telah selesai dan tidak lagi diubah suai.
Penciptaan syarikat Audit-Telecom
Masa berlalu, saya mula bekerja sambilan di syarikat lain, mujur jadual kerja saya membolehkan saya melakukan ini. Apabila anda bekerja di syarikat yang berbeza, kemahiran anda dalam pelbagai bidang berkembang dengan cepat, dan ufuk anda berkembang dengan baik. Terdapat syarikat di mana, seperti yang mereka katakan, anda adalah orang Sweden, penuai, dan pemain trompet. Di satu pihak, sukar, sebaliknya, jika anda tidak malas, anda menjadi generalis dan ini membolehkan anda menyelesaikan masalah dengan lebih cepat dan lebih cekap kerana anda tahu bagaimana bidang berkaitan berfungsi.
Rakan saya Pavel (juga pakar IT) sentiasa cuba menggalakkan saya untuk memulakan perniagaannya sendiri. Terdapat banyak idea dengan variasi yang berbeza dari apa yang mereka lakukan. Ini telah dibincangkan selama bertahun-tahun. Dan pada akhirnya, ia tidak sepatutnya menjadi apa-apa kerana saya seorang yang ragu-ragu, dan Pavel adalah seorang pemimpi. Setiap kali dia mencadangkan idea, saya selalu tidak percaya dan enggan mengambil bahagian. Tetapi kami benar-benar ingin membuka perniagaan kami sendiri.
Akhirnya, kami dapat mencari pilihan yang sesuai dengan kami berdua dan melakukan apa yang kami tahu. Pada 2016, kami memutuskan untuk mewujudkan syarikat IT yang akan membantu perniagaan menyelesaikan masalah IT. Ini ialah penggunaan sistem IT (1C, pelayan terminal, pelayan mel, dll.), penyelenggaraannya, HelpDesk klasik untuk pengguna dan pentadbiran rangkaian.
Terus terang, pada masa mewujudkan syarikat itu, saya tidak mempercayainya kira-kira 99,9%. Tetapi entah bagaimana Pavel dapat membuat saya mencuba, dan melihat ke hadapan, dia ternyata betul. Pavel dan saya menyumbang 300 rubel setiap satu, mendaftarkan LLC "Audit-Telecom" baru, menyewa pejabat kecil, membuat kad perniagaan yang hebat, secara amnya, seperti ahli perniagaan baru yang mungkin tidak berpengalaman, dan mula mencari pelanggan. Mencari pelanggan adalah cerita yang sama sekali berbeza. Mungkin kami akan menulis artikel berasingan sebagai sebahagian daripada blog korporat jika ada yang berminat. Panggilan sejuk, risalah, dll. Ini tidak memberikan apa-apa hasil. Seperti yang saya baca sekarang dari banyak cerita tentang perniagaan, satu cara atau yang lain, banyak bergantung pada nasib. Kami bernasib baik. dan secara harfiah beberapa minggu selepas penciptaan syarikat itu, saudara saya Vladimir mendekati kami, yang membawa kami pelanggan pertama. Saya tidak akan membosankan anda dengan butiran bekerja dengan pelanggan, bukan itu maksud artikel itu, saya hanya akan mengatakan bahawa kami pergi untuk audit, mengenal pasti kawasan kritikal dan kawasan ini rosak semasa keputusan dibuat sama ada untuk bekerjasama dengan kami secara berterusan sebagai penyumber luar. Selepas ini, keputusan positif segera dibuat.
Kemudian, terutamanya melalui mulut ke mulut melalui rakan-rakan, syarikat perkhidmatan lain mula muncul. Meja bantuan berada dalam satu sistem. Sambungan ke peralatan rangkaian dan pelayan adalah berbeza, atau lebih tepatnya berbeza. Sesetengah orang menyimpan pintasan, yang lain menggunakan buku alamat RDP. Pemantauan adalah satu lagi sistem yang berasingan. Adalah sangat menyusahkan bagi satu pasukan untuk bekerja dalam sistem yang berbeza. Maklumat penting hilang dari pandangan. Nah, sebagai contoh, pelayan terminal pelanggan menjadi tidak tersedia. Permohonan daripada pengguna pelanggan ini segera diterima. Pakar sokongan membuka permintaan (ia diterima melalui telefon). Jika insiden dan permintaan didaftarkan dalam satu sistem, maka pakar sokongan akan segera melihat masalah pengguna dan memberitahunya mengenainya, sambil menyambung ke objek yang diperlukan untuk menyelesaikan situasi tersebut. Semua orang menyedari situasi taktikal dan bekerja dengan harmoni. Kami tidak menemui sistem di mana semua ini digabungkan. Ia menjadi jelas bahawa sudah tiba masanya untuk membuat produk kami sendiri.
Teruskan kerja pada sistem pemantauan anda
Adalah jelas bahawa sistem yang ditulis sebelum ini tidak sesuai sama sekali untuk tugas semasa. Baik dari segi fungsi mahupun dari segi kualiti. Dan ia telah memutuskan untuk menulis sistem dari awal. Secara grafik ia sepatutnya kelihatan berbeza. Ia mestilah sistem hierarki supaya ia boleh dengan cepat dan mudah membuka objek yang sesuai untuk pelanggan yang betul. Skim seperti dalam versi pertama sama sekali tidak wajar dalam kes semasa, kerana Pelanggan adalah berbeza dan tidak penting sama sekali di premis mana peralatan itu berada. Ini telah dipindahkan ke dokumentasi.
Jadi, tugasan:
- Struktur hierarki;
- Beberapa jenis bahagian pelayan yang boleh diletakkan di premis pelanggan dalam bentuk mesin maya untuk mengumpul metrik yang kami perlukan dan menghantarnya ke pelayan pusat, yang akan meringkaskan semua ini dan menunjukkannya kepada kami;
- Makluman. Yang tidak boleh dilepaskan, kerana... pada masa itu tidak mungkin seseorang duduk dan hanya melihat monitor;
- Sistem aplikasi. Pelanggan mula muncul untuk mereka yang kami servis bukan sahaja peralatan pelayan dan rangkaian, tetapi juga stesen kerja;
- Keupayaan untuk menyambung dengan cepat ke pelayan dan peralatan daripada sistem;
Tugasan telah ditetapkan, kami mula menulis. Sepanjang perjalanan, memproses permintaan daripada pelanggan. Masa tu kami dah ada 4 orang. Kami mula menulis kedua-dua bahagian serentak: pelayan pusat dan pelayan untuk pemasangan kepada pelanggan. Pada ketika ini, Linux bukan lagi asing bagi kami dan telah diputuskan bahawa mesin maya yang pelanggan akan ada akan berada di Debian. Tidak akan ada pemasang, kami hanya akan membuat projek bahagian pelayan pada satu mesin maya tertentu, dan kemudian kami hanya akan mengklonkannya kepada klien yang dikehendaki. Ini adalah satu lagi kesilapan. Kemudian menjadi jelas bahawa dalam skema sedemikian mekanisme kemas kini tidak dibangunkan sepenuhnya. Itu. kami telah menambah beberapa ciri baharu, dan kemudian terdapat masalah untuk mengedarkannya kepada semua pelayan pelanggan, tetapi kami akan kembali kepada perkara ini kemudian, semuanya teratur.
Kami membuat prototaip pertama. Dia dapat ping peranti rangkaian pelanggan dan pelayan yang kami perlukan dan menghantar data ini ke pelayan pusat kami. Dan dia pula mengemas kini data ini secara pukal pada pelayan pusat. Di sini saya akan menulis bukan sahaja cerita tentang bagaimana dan apa yang berjaya, tetapi juga kesilapan amatur yang dibuat dan bagaimana kemudiannya saya terpaksa membayarnya dengan masa. Jadi, keseluruhan pokok objek disimpan dalam satu fail tunggal dalam bentuk objek bersiri. Walaupun kami menyambungkan beberapa pelanggan kepada sistem, semuanya adalah lebih kurang normal, walaupun kadangkala terdapat beberapa artifak yang tidak dapat difahami sepenuhnya. Tetapi apabila kami menyambungkan sedozen pelayan ke sistem, keajaiban mula berlaku. Kadangkala, atas sebab yang tidak diketahui, semua objek dalam sistem hilang begitu sahaja. Adalah penting untuk diperhatikan di sini bahawa pelayan yang pelanggan telah menghantar data ke pelayan pusat setiap beberapa saat melalui permintaan POST. Pembaca yang penuh perhatian dan pengaturcara yang berpengalaman sudah meneka bahawa terdapat masalah berbilang akses kepada fail yang mana objek bersiri disimpan daripada benang berbeza pada masa yang sama. Dan ketika ini berlaku, keajaiban berlaku dengan kehilangan objek. Fail itu menjadi kosong. Tetapi semua ini tidak ditemui serta-merta, tetapi hanya semasa operasi dengan beberapa pelayan. Pada masa ini, fungsi pengimbasan port telah ditambahkan (pelayan yang dihantar ke pusat bukan sahaja maklumat tentang ketersediaan peranti, tetapi juga tentang port yang dibuka padanya). Ini dilakukan dengan memanggil arahan:
$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);
keputusan sering tidak betul dan imbasan mengambil masa yang lama untuk diselesaikan. Saya benar-benar terlupa tentang ping, ia dilakukan melalui fping:
system("fping -r 3 -t 100 {$this->ip}");
Ini juga tidak selari dan oleh itu prosesnya sangat panjang. Kemudian, keseluruhan senarai alamat IP yang diperlukan untuk pengesahan telah dihantar ke fping sekali gus, dan kembali kami menerima senarai siap sedia bagi mereka yang memberi respons. Tidak seperti kami, fping dapat menyelaraskan proses.
Satu lagi kerja rutin biasa ialah menyediakan beberapa perkhidmatan melalui WEB. Nah, sebagai contoh, ECP dari MS Exchange. Pada asasnya ia hanya pautan. Dan kami memutuskan bahawa kami perlu dapat menambah pautan sedemikian terus ke sistem, supaya tidak perlu melihat dalam dokumentasi atau tempat lain dalam penanda halaman untuk cara mengakses ECP pelanggan tertentu. Ini adalah bagaimana konsep pautan sumber untuk sistem muncul, fungsinya tersedia hingga ke hari ini dan tidak berubah, baik, hampir.
Cara pautan sumber berfungsi dalam Veliam
Sambungan jauh
Inilah yang kelihatan seperti dalam tindakan dalam versi semasa Veliam
Salah satu tugasnya adalah untuk menyambung ke pelayan dengan cepat dan mudah, yang mana sudah ada banyak (lebih daripada seratus) dan menyusun berjuta-juta pintasan RDP pra-simpan adalah amat menyusahkan. Alat diperlukan. Terdapat perisian di Internet yang seperti buku alamat untuk sambungan RDP sedemikian, tetapi ia tidak disepadukan dengan sistem pemantauan, dan akaun tidak boleh disimpan. Memasuki akaun untuk pelanggan yang berbeza setiap kali adalah neraka tulen apabila anda menyambung berpuluh-puluh kali sehari ke pelayan yang berbeza. Dengan SSH, keadaan menjadi lebih baik sedikit; terdapat banyak perisian yang baik yang membolehkan anda mengatur sambungan sedemikian ke dalam folder dan mengingati akaun daripadanya. Tetapi ada 2 masalah. Yang pertama ialah kami tidak menemui satu program untuk sambungan RDP dan SSH. Yang kedua ialah jika pada satu ketika saya tidak berada di komputer saya dan saya perlu menyambung dengan cepat, atau saya baru memasang semula sistem, saya perlu pergi ke dokumentasi untuk melihat akaun daripada pelanggan ini. Ia menyusahkan dan membuang masa.
Struktur hierarki yang kami perlukan untuk pelayan pelanggan telah tersedia dalam produk dalaman kami. Saya hanya perlu memikirkan cara untuk melampirkan sambungan cepat ke peralatan yang diperlukan di sana. Sebagai permulaan, sekurang-kurangnya dalam rangkaian anda.
Mengambil kira hakikat bahawa pelanggan dalam sistem kami adalah penyemak imbas yang tidak mempunyai akses kepada sumber tempatan komputer, untuk melancarkan aplikasi yang kami perlukan dengan beberapa arahan, ia dicipta untuk melakukan segala-galanya melalui "Windows skema url tersuaiβ. Beginilah cara "plugin" tertentu muncul untuk sistem kami, yang hanya menyertakan Putty dan Remote Desktop Plus dan, semasa pemasangan, hanya mendaftarkan skema URI dalam Windows. Sekarang, apabila kami ingin menyambung ke objek melalui RDP atau SSH, kami mengklik tindakan ini pada sistem kami dan URI Tersuai berfungsi. Mstsc.exe standard terbina dalam Windows atau putty, yang merupakan sebahagian daripada "plugin," telah dilancarkan. Saya meletakkan perkataan plugin dalam petikan kerana ini bukan pemalam pelayar dalam erti kata klasik.
Sekurang-kurangnya itu adalah sesuatu. Buku alamat yang mudah. Selain itu, dalam kes Putty, semuanya secara amnya baik; ia boleh diberikan sambungan IP, log masuk dan kata laluan sebagai parameter input. Itu. Kami telah pun menyambung ke pelayan Linux pada rangkaian kami dengan satu klik tanpa memasukkan kata laluan. Tetapi dengan RDP ia tidak semudah itu. Mstsc standard tidak boleh membekalkan kelayakan sebagai parameter. Remote Desktop Plus datang untuk menyelamatkan. Dia membenarkan perkara ini berlaku. Kini kami boleh melakukannya tanpa itu, tetapi untuk masa yang lama ia adalah pembantu yang setia dalam sistem kami. Dengan tapak HTTP(S) semuanya mudah, objek sedemikian hanya dibuka dalam penyemak imbas dan itu sahaja. Mudah dan praktikal. Tetapi ini adalah kebahagiaan hanya pada rangkaian dalaman.
Memandangkan kami menyelesaikan sebahagian besar masalah dari jauh dari pejabat, perkara paling mudah ialah menyediakan VPN kepada pelanggan. Dan kemudian adalah mungkin untuk menyambung kepada mereka dari sistem kami. Tetapi ia masih agak menyusahkan. Untuk setiap pelanggan, adalah perlu untuk menyimpan sekumpulan sambungan VPN yang diingati pada setiap komputer, dan sebelum menyambung kepada mana-mana, adalah perlu untuk mendayakan VPN yang sepadan. Kami menggunakan penyelesaian ini untuk masa yang agak lama. Tetapi bilangan pelanggan semakin meningkat, bilangan VPN juga semakin meningkat, dan semua ini mula tegang dan sesuatu perlu dilakukan mengenainya. Terutama sekali air mata saya mengalir selepas memasang semula sistem, apabila saya terpaksa memasukkan semula berpuluh-puluh sambungan VPN dalam profil Windows baharu. Berhenti bersabar dengan ini, saya berkata, dan mula berfikir tentang apa yang boleh saya lakukan mengenainya.
Kebetulan semua pelanggan mempunyai peranti dari syarikat terkenal Mikrotik sebagai penghala. Mereka sangat berfungsi dan mudah untuk melaksanakan hampir semua tugas. Kelemahannya ialah mereka "dirampas". Kami menyelesaikan masalah ini hanya dengan menutup semua akses dari luar. Tetapi ia adalah perlu untuk entah bagaimana mempunyai akses kepada mereka tanpa datang ke tempat pelanggan, kerana... ia panjang. Kami hanya membuat terowong untuk setiap Mikrotik tersebut dan memisahkannya ke dalam kolam yang berasingan. tanpa sebarang penghalaan, supaya tiada sambungan rangkaian anda dengan rangkaian pelanggan dan rangkaian mereka antara satu sama lain.
Idea ini dilahirkan untuk memastikan bahawa apabila saya mengklik pada objek yang saya perlukan dalam sistem, pelayan pemantauan pusat, mengetahui akaun SSH semua pelanggan Mikrotik, menyambung kepada yang dikehendaki, mencipta peraturan pemajuan ke hos yang dikehendaki dengan pelabuhan yang diperlukan. Terdapat beberapa titik di sini. Penyelesaiannya tidak universal - ia hanya berfungsi untuk Mikrotik, kerana sintaks arahan berbeza untuk semua penghala. Selain itu, pemajuan sedemikian kemudiannya terpaksa dipadamkan, dan bahagian pelayan sistem kami pada dasarnya tidak dapat menjejaki dalam apa cara sekalipun sama ada saya telah menamatkan sesi RDP saya. Nah, pemajuan sedemikian adalah lubang untuk pelanggan. Tetapi kami tidak mengejar kesejagatan, kerana... produk itu hanya digunakan dalam syarikat kami dan tidak ada pemikiran untuk mengeluarkannya kepada orang ramai.
Setiap masalah diselesaikan dengan cara tersendiri. Apabila peraturan dibuat, pemajuan ini hanya tersedia untuk satu alamat IP luaran tertentu (dari mana sambungan itu dimulakan). Jadi lubang keselamatan telah dielakkan. Tetapi dengan setiap sambungan sedemikian, peraturan Mikrotik telah ditambahkan pada halaman NAT dan tidak dikosongkan. Dan semua orang tahu bahawa lebih banyak peraturan yang ada, lebih banyak pemproses penghala dimuatkan. Dan secara umum, saya tidak dapat menerima bahawa suatu hari nanti saya akan pergi ke beberapa Mikrotik, dan akan ada beratus-ratus peraturan yang mati dan tidak berguna.
Memandangkan pelayan kami tidak dapat menjejaki status sambungan, biarkan Mikrotik menjejakinya sendiri. Dan saya menulis skrip yang sentiasa memantau semua peraturan pemajuan dengan penerangan khusus dan menyemak sama ada sambungan TCP mempunyai peraturan yang sesuai. Jika tidak ada untuk beberapa lama, maka sambungan mungkin telah selesai dan pemajuan ini boleh dipadamkan. Semuanya berjaya, skrip berfungsi dengan baik.
By the way, 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
}
}
Sudah tentu ia boleh dibuat lebih cantik, lebih cepat, dan lain-lain, tetapi ia berfungsi, tidak memuatkan Mikrotik dan melakukan kerja yang sangat baik. Kami akhirnya dapat menyambung ke pelayan pelanggan dan peralatan rangkaian dengan hanya satu klik. Tanpa membuka VPN atau memasukkan kata laluan. Sistem ini telah menjadi sangat mudah untuk digunakan. Masa perkhidmatan telah dikurangkan, dan kami semua menghabiskan masa bekerja daripada menyambung ke objek yang diperlukan.
Sandaran Mikrotik
Kami mengkonfigurasi sandaran semua Mikrotik ke FTP. Dan secara keseluruhan semuanya baik-baik saja. Tetapi apabila anda perlu mendapatkan sandaran, anda perlu membuka FTP ini dan mencarinya di sana. Kami mempunyai sistem di mana semua penghala disambungkan; kami boleh berkomunikasi dengan peranti melalui SSH. Mengapa kita tidak membuatnya supaya sistem itu sendiri mengambil sandaran dari semua Mikrotik setiap hari, saya fikir. Dan dia mula melaksanakannya. Kami menyambung, membuat sandaran dan membawanya ke storan.
Kod skrip dalam PHP untuk mengambil sandaran 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');
?>
Sandaran diambil dalam dua bentuk - binari dan konfigurasi teks. Binari membantu memulihkan konfigurasi yang diperlukan dengan cepat, dan teks yang membolehkan anda memahami perkara yang perlu dilakukan jika terdapat penggantian paksa peralatan dan binari tidak boleh dimuat naik ke dalamnya. Hasilnya, kami mendapat satu lagi fungsi mudah dalam sistem. Lebih-lebih lagi, apabila menambah Mikrotik baru, tidak perlu mengkonfigurasi apa-apa; Saya hanya menambah objek ke sistem dan menetapkan akaun untuknya melalui SSH. Kemudian sistem itu sendiri menguruskan mengambil sandaran. Versi semasa SaaS Veliam belum lagi mempunyai fungsi ini, tetapi kami akan mengalihkannya tidak lama lagi.
Tangkapan skrin rupanya dalam sistem dalaman
Peralihan kepada storan pangkalan data biasa
Saya sudah menulis di atas bahawa artifak muncul. Kadangkala keseluruhan senarai objek dalam sistem hilang begitu sahaja, kadangkala apabila mengedit objek, maklumat tidak disimpan dan objek itu perlu dinamakan semula tiga kali. Ini sangat menjengkelkan semua orang. Kehilangan objek jarang berlaku, dan mudah dipulihkan dengan memulihkan fail ini, tetapi kegagalan semasa mengedit objek berlaku agak kerap. Mungkin, saya pada mulanya tidak melakukan ini melalui pangkalan data kerana ia tidak sesuai dalam fikiran saya bagaimana mungkin untuk menyimpan pokok dengan semua sambungan dalam meja rata. Ia rata, tetapi pokok itu berhierarki. Tetapi penyelesaian yang baik untuk berbilang akses, dan seterusnya (apabila sistem menjadi lebih kompleks) transaksional, ialah DBMS. Saya mungkin bukan orang pertama yang menghadapi masalah ini. Saya mula googling. Ternyata semuanya telah dicipta sebelum saya dan terdapat beberapa algoritma yang membina pokok dari meja rata. Selepas melihat setiap satu, saya melaksanakan salah satu daripadanya. Tetapi ini sudah pun versi sistem baharu, kerana... Malah, kerana ini, saya terpaksa menulis semula dengan agak banyak. Hasilnya adalah semula jadi, masalah tingkah laku rawak sistem telah hilang. Sesetengah orang mungkin mengatakan bahawa ralat itu sangat amatur (skrip satu-utas, menyimpan maklumat yang telah diakses berbilang kali serentak daripada urutan yang berbeza dalam fail, dsb.) dalam bidang pembangunan perisian. Mungkin ini benar, tetapi tugas utama saya adalah pentadbiran, dan pengaturcaraan adalah kesibukan sampingan untuk jiwa saya, dan saya tidak mempunyai pengalaman bekerja dalam pasukan pengaturcara, di mana perkara asas seperti itu akan dicadangkan dengan segera oleh senior saya. rakan seperjuangan. Oleh itu, saya mengisi semua benjolan ini sendiri, tetapi saya mempelajari bahan dengan baik. Dan juga, tugas saya melibatkan pertemuan dengan pelanggan, tindakan yang bertujuan untuk mempromosikan syarikat, banyak isu pentadbiran dalam syarikat, dan banyak lagi. Tetapi satu cara atau yang lain, apa yang sudah ada adalah permintaan. Saya dan lelaki itu sendiri menggunakan produk itu dalam kerja harian kami. Terdapat idea dan penyelesaian yang tidak berjaya secara terang-terangan yang membuang masa, tetapi akhirnya menjadi jelas bahawa ini bukan alat yang berfungsi dan tiada siapa yang menggunakannya dan ia tidak berakhir di Veliam.
Helpdesk - HelpDesk
Tidak salah untuk menyebut bagaimana HelpDesk dibentuk. Ini adalah cerita yang sama sekali berbeza, kerana... di Veliam ini sudah menjadi versi ke-3 yang benar-benar baharu, yang berbeza daripada semua yang sebelumnya. Kini ia adalah sistem yang mudah, intuitif tanpa loceng dan wisel yang tidak perlu, dengan keupayaan untuk menyepadukan dengan domain, serta keupayaan untuk mengakses profil pengguna yang sama dari mana-mana sahaja menggunakan pautan daripada e-mel. Dan yang paling penting, adalah mungkin untuk menyambung kepada pemohon melalui VNC dari mana-mana sahaja (di rumah atau di pejabat) terus dari aplikasi tanpa VPN atau penghantaran port. Saya akan memberitahu anda bagaimana kami sampai kepada perkara ini, apa yang berlaku sebelum ini dan apa keputusan yang teruk dibuat.
Kami berhubung dengan pengguna melalui TeamViewer yang terkenal. Semua komputer yang penggunanya kami layani telah memasang TV. Perkara pertama yang kami lakukan salah, dan kemudiannya mengalih keluarnya, adalah memautkan setiap pelanggan HD kepada perkakasan. Bagaimanakah pengguna log masuk ke sistem HD untuk meninggalkan permintaan? Selain TV, setiap orang mempunyai utiliti khas yang dipasang pada komputer mereka, ditulis dalam Lazarus (ramai orang di sini akan melelapkan mata, dan mungkin juga pergi ke Google apa itu, tetapi bahasa kompilasi terbaik yang saya tahu ialah Delphi, dan Lazarus hampir perkara yang sama, hanya percuma). Secara umum, pengguna melancarkan fail kumpulan khas yang melancarkan utiliti ini, yang seterusnya membaca HWID sistem dan selepas itu pelayar dilancarkan dan kebenaran berlaku. Mengapa ini dilakukan? Dalam sesetengah syarikat, bilangan pengguna yang diservis dikira secara individu dan harga perkhidmatan untuk setiap bulan adalah berdasarkan bilangan orang. Ini boleh difahami, anda berkata, tetapi mengapa ia terikat dengan perkakasan? Ia sangat mudah, sesetengah individu pulang ke rumah dan membuat permintaan daripada komputer riba rumah mereka dalam gaya "jadikan segala-galanya cantik untuk saya di sini." Selain membaca sistem HWID, utiliti menarik ID Teamviewer semasa daripada pendaftaran dan juga menghantarnya kepada kami. Teamviewer mempunyai API untuk penyepaduan. Dan kami melakukan penyepaduan ini. Tetapi ada satu tangkapan. Melalui API ini, adalah mustahil untuk menyambung ke komputer pengguna apabila dia tidak memulakan sesi ini secara eksplisit dan selepas cuba menyambung kepadanya, dia juga mesti mengklik "sahkan". Pada masa itu, nampaknya logik kepada kami bahawa tiada siapa yang harus menyambung tanpa permintaan pengguna, dan memandangkan orang itu berada di komputer, dia akan memulakan sesi dan bertindak balas secara afirmatif kepada permintaan sambungan jauh. Semuanya ternyata salah. Pemohon terlupa untuk menekan memulakan sesi, dan terpaksa memberitahu mereka perkara ini dalam perbualan telefon. Ini membuang masa dan mengecewakan pada kedua-dua belah proses. Lebih-lebih lagi, ia sama sekali tidak biasa untuk saat-saat seperti itu apabila seseorang meninggalkan permintaan, tetapi dibenarkan untuk menyambung hanya apabila dia pergi untuk makan tengah hari. Kerana masalahnya tidak kritikal dan dia tidak mahu proses kerjanya terganggu. Sehubungan itu, dia tidak akan menekan sebarang butang untuk membenarkan sambungan. Beginilah kefungsian tambahan muncul semasa log masuk ke HelpDesk - membaca ID Teamviewer. Kami tahu kata laluan kekal yang digunakan semasa memasang Teamviewer. Lebih tepat lagi, hanya sistem yang mengetahuinya, kerana ia telah dibina ke dalam pemasang dan ke dalam sistem kami. Sehubungan itu, terdapat butang sambungan dari aplikasi dengan mengklik di mana tidak perlu menunggu apa-apa, tetapi Teamviewer segera dibuka dan sambungan berlaku. Akibatnya, terdapat dua jenis sambungan yang mungkin. Melalui API Teamviewer rasmi dan yang kami buat sendiri. Saya terkejut, mereka berhenti menggunakan yang pertama hampir serta-merta, walaupun terdapat arahan untuk menggunakannya hanya dalam kes-kes khas dan apabila pengguna itu sendiri memberi kebenaran. Namun, berikan saya keselamatan sekarang. Tetapi ternyata pemohon tidak memerlukan ini. Mereka semua baik-baik saja dengan disambungkan kepada mereka tanpa butang pengesahan.
Beralih kepada multithreading dalam Linux
Persoalan mempercepatkan laluan pengimbas rangkaian untuk keterbukaan senarai port yang telah ditetapkan dan ping mudah objek rangkaian telah lama mula timbul. Di sini, sudah tentu, penyelesaian pertama yang terlintas di fikiran ialah multithreading. Memandangkan masa utama yang dihabiskan untuk ping adalah menunggu paket dikembalikan, dan ping seterusnya tidak boleh bermula sehingga paket sebelumnya dikembalikan, dalam syarikat yang mempunyai 20+ pelayan serta peralatan rangkaian, ini telah berfungsi dengan agak perlahan. Intinya ialah satu pakej mungkin hilang, tetapi jangan segera memberitahu pentadbir sistem mengenainya. Dia hanya akan berhenti menerima spam sedemikian dengan cepat. Ini bermakna anda perlu ping setiap objek lebih daripada sekali sebelum membuat kesimpulan tentang ketidakbolehcapaian. Tanpa terlalu banyak perincian, adalah perlu untuk menyelaraskannya kerana jika ini tidak dilakukan, kemungkinan besar pentadbir sistem akan belajar tentang masalah daripada klien, dan bukan dari sistem pemantauan.
PHP sendiri tidak menyokong multithreading di luar kotak. Mampu multiprocessing, anda boleh fork. Tetapi, sebenarnya, saya sudah mempunyai mekanisme pengundian yang ditulis dan saya ingin membuatnya supaya saya akan mengira semua nod yang saya perlukan dari pangkalan data, ping semuanya sekaligus, tunggu jawapan daripada setiap satu dan hanya selepas itu segera tulis data itu. Ini menjimatkan bilangan permintaan baca. Multithreading sesuai dengan idea ini. Untuk PHP terdapat modul PThreads yang membolehkan anda melakukan multithreading sebenar, walaupun ia mengambil masa yang agak lama untuk menyediakannya pada PHP 7.2, tetapi ia telah dilakukan. Pengimbasan port dan ping kini pantas. Dan bukannya, sebagai contoh, 15 saat setiap pusingan lebih awal, proses ini mula mengambil masa 2 saat. Ia adalah keputusan yang baik.
Audit cepat syarikat baru
Bagaimanakah kefungsian untuk mengumpul pelbagai metrik dan ciri perkakasan terhasil? Mudah sahaja. Kadang-kadang kami hanya diperintahkan untuk mengaudit infrastruktur IT semasa. Nah, perkara yang sama perlu untuk mempercepatkan audit pelanggan baru. Kami memerlukan sesuatu yang membolehkan kami datang ke syarikat sederhana atau besar dan dengan cepat mengetahui apa yang mereka ada. Pada pendapat saya, ping pada rangkaian dalaman disekat hanya oleh mereka yang ingin merumitkan kehidupan mereka sendiri, dan dalam pengalaman kami terdapat sedikit daripada mereka. Tetapi ada juga orang seperti itu. Sehubungan itu, anda boleh mengimbas rangkaian dengan cepat untuk kehadiran peranti dengan ping mudah. Kemudian kita boleh menambahnya dan mengimbas port terbuka yang menarik minat kita. Malah, kefungsian ini sudah wujud; ia hanya perlu menambah arahan daripada pelayan pusat kepada hamba supaya ia akan mengimbas rangkaian yang ditentukan dan menambah semua yang ditemuinya pada senarai. Saya terlupa untuk menyebut, telah diandaikan bahawa kami sudah mempunyai imej siap pakai dengan sistem yang dikonfigurasikan (pelayan pemantauan hamba) yang kami hanya boleh melancarkan daripada pelanggan semasa audit dan menyambungkannya ke awan kami.
Tetapi hasil audit biasanya termasuk sekumpulan maklumat yang berbeza, dan salah satunya ialah jenis peranti yang ada pada rangkaian. Pertama sekali, kami berminat dengan pelayan Windows dan stesen kerja Windows sebagai sebahagian daripada domain. Oleh kerana dalam syarikat sederhana dan besar, kekurangan domain mungkin merupakan pengecualian kepada peraturan. Untuk bercakap satu bahasa, purata, pada pendapat saya, adalah 100+ orang. Ia adalah perlu untuk menghasilkan satu cara untuk mengumpul data daripada semua mesin dan pelayan Windows, mengetahui IP dan akaun pentadbir domain mereka, tetapi tanpa memasang sebarang perisian pada setiap daripada mereka. Antara muka WMI datang untuk menyelamatkan. Instrumentasi Pengurusan Windows (WMI) secara literal bermaksud alatan pengurusan Windows. WMI ialah salah satu teknologi asas untuk pengurusan terpusat dan pemantauan operasi pelbagai bahagian infrastruktur komputer yang menjalankan platform Windows. Diambil dari wiki. Seterusnya, saya terpaksa bermain-main lagi untuk menyusun wmic (ini adalah klien WMI) untuk Debian. Selepas segala-galanya siap, yang tinggal hanyalah untuk meninjau nod yang diperlukan melalui wmic untuk mendapatkan maklumat yang diperlukan. Melalui WMI anda boleh mendapatkan hampir semua maklumat daripada komputer Windows, dan lebih-lebih lagi, anda juga boleh mengawal komputer melaluinya, sebagai contoh, menghantarnya untuk but semula. Beginilah cara pengumpulan maklumat tentang stesen dan pelayan Windows dalam sistem kami muncul. Di samping itu, terdapat maklumat semasa tentang penunjuk beban sistem semasa. Kami meminta mereka lebih kerap, dan maklumat tentang perkakasan kurang kerap. Selepas ini, pengauditan menjadi lebih menyeronokkan.
Keputusan pengedaran perisian
Kami sendiri menggunakan sistem ini setiap hari, dan ia sentiasa terbuka untuk setiap pekerja teknikal. Dan kami fikir kami boleh berkongsi dengan orang lain apa yang kami sudah ada. Sistem itu masih belum bersedia untuk diedarkan. Banyak yang perlu diolah semula supaya versi tempatan bertukar menjadi SaaS. Ini termasuk perubahan dalam pelbagai aspek teknikal sistem (sambungan jauh, perkhidmatan sokongan), analisis modul untuk pelesenan, pembahagian pangkalan data pelanggan, penskalaan setiap perkhidmatan, dan pembangunan sistem kemas kini automatik untuk semua bahagian. Tetapi ini akan menjadi bahagian kedua artikel itu.
Update
Sumber: www.habr.com