გაგრძელდა Linux/OpenWrt/Lede-ზე დაფუძნებული მოწყობილობების დისტანციური მონიტორინგი და მართვა 80-ე პორტის საშუალებით

ეს არის სტატიის ბოლო ნაწილი, აქ არის დასაწყისი habr.com/en/post/445568
ბოლო დროს დავწერე იმის შესახებ, თუ როგორ განვახორციელე მოწყობილობის მონიტორინგი, ახლა ვისაუბრებთ მენეჯმენტზე. მომხმარებელთა მხრიდან „ტექნიკოსებთან“ დისკუსიისას ხშირად ვაწყდები ასეთი მცირე მოწყობილობების შესაძლებლობების შეზღუდულ აღქმას (დაბალი მეხსიერების რესურსებითა და წარმადობით), ბევრი თვლის, რომ „ყველაზე მეტად ჩვენ გვჭირდება გადატვირთვის გაგზავნა, რაღაც მეტისთვის. სერიოზულად, ჩვენ გუნდს გამოვგზავნით“.
მაგრამ პრაქტიკა გვიჩვენებს, რომ ეს მთლად ასე არ არის. აქ არის საერთო ტიპიური ამოცანების მცირე ჩამონათვალი:

1. ქსელის დიაგნოსტიკა და პრობლემების მოგვარება. თქვენი როუტერის ეთერნეტის პორტის უკან, როგორც წესი, არის სხვა აპარატურა, რომელსაც აქვს საკუთარი შიდა IP მისამართი. ზოგჯერ შეგიძლიათ (უნდა) „პინგოთ“ ის. ან გვირაბის მართვა - თუ გვირაბი მოულოდნელად არ ამოდის როუტერზე, რომელიც მუშაობს 3G მოდემის საშუალებით, მაგრამ ჩვენ შეგვიძლია დავინახოთ თავად როუტერი.
2. სისტემის მოვლა. პროგრამული უზრუნველყოფის განახლება, სერვისის სკრიპტის განახლება.
3. ბალანსირების აქტი. ამას შეიძლება ეწოდოს "გარყვნილება", მაგრამ "წონასწორობის" ცნება, როგორც, მე ციტირებს, "ცირკის შემსრულებლის უნარი შეინარჩუნოს წონასწორობა სხეულის არასტაბილურ მდგომარეობაში" - უკეთ ჯდება. ასეთი სიტუაციები წარმოიქმნება მომხმარებლის შეზღუდული ბიუჯეტის გამო. ქვემოთ რამდენიმე მაგალითი მოვიყვანე, მაგრამ... ისინი უშუალოდ არ არის დაკავშირებული მოთხრობის თემასთან, ჩანაწერებში ჩავდე

Wi-Fi მონიტორინგიმოდური თემა ბოლო ხუთი წლის განმავლობაში, ძირითადად ფედერალურ საცალო ქსელებს შორის. თქვენ მშვიდად სეირნობთ სავაჭრო სართულებში და თქვენი მობილური ტელეფონი ჩართული Wi-Fi-ით, ქსელის რომელიმე ძაფზე „დაჭერის“ მცდელობისას, რეგულარულად აგზავნის გამოძიების მოთხოვნის პაკეტებს, რომელთა გაანალიზება შესაძლებელია, რათა გამოვთვალოთ თქვენ: რამდენად ხშირად მოდიხართ ამ მაღაზიაში, რა მიზეზების გამო დადიხართ ტრაექტორიებით და ა.შ. შემდეგ ხდება მონაცემების შეგროვება, ანალიზი, სითბური რუქების შედგენა და მენეჯერები მენეჯმენტს ან ინვესტორებს ფულს „სძალავენ“ ასეთი სურათებისთვის. კარგი, ჯერ-ჯერობით... „ფული არ არის, მაგრამ გამართე...“, და შედეგი (რეალური) უკვე უნდა აჩვენო, ძველი კარგი სიმღერა იწყება: „დიახ, დიახ, მაშინ რა თქმა უნდა ჩვენ დააინსტალირებს cis-ს და ყველაფერს, რაც გსურთ, მაგრამ ახლა ჩვენ უნდა ვაჩვენოთ კლიენტს შედეგი! სხვათა შორის, დაგვავიწყდა გვეთქვა, რომ მომხმარებელმა მოგვცა საშუალება დაგვეკავშირებინა ჩვენი აღჭურვილობა მის ცხელ წერტილში Wi-Fi-ის საშუალებით, ოღონდ ზოგადად, ისე, თითქოს სტუმარი კლიენტები ვიყოთ“. ასე რომ, ჩვენ უნდა შევქმნათ დაბალანსებული მარშრუტიზატორები - ამაღლებულია რამდენიმე WiFi ქვეინტერფეისი, რომელთაგან ერთი ჩერდება ცხელ წერტილზე, მეორე კი აკონტროლებს გარემოს, თავდავიწყებით ატვირთავს tcpdump შედეგს საკუთარ თავში, შემდეგ ათავსებს ფაილის შიგთავსს არქივში და რისკავს. კვდება „ჭარბი ჭამისგან“ ცდილობს FTP სერვერზე შიგთავსის გაფურცვლას. გასაკვირი არ არის, რომ დამაბალანსებელი როუტერი ხშირად "იფუჭება" და რატომღაც უნდა მოხდეს "რეანიმაცია" დისტანციურად.

რადიუსიაქ სიტუაციის აღწერა უფრო ადვილია მომხმარებლის ასეთი განცხადებით: „ჩვენ გვსურს ცხელ წერტილების დეცენტრალიზებული ქსელი, რომელიც იმუშავებს მოწყობილობებზე, რომელთა მოდელი წინასწარ უცნობია, არხებით, მაგრამ რომელი ჯერ არ ვიცით. ოჰ, დაგვავიწყდა გვეთქვა, რომ ჩვენ არა მხოლოდ გვინდა ვაჩვენოთ რეკლამა კლიენტებს, არამედ გავაანალიზოთ ყველაფერი იმ ადგილის ირგვლივ, სადაც დაინსტალირებულია ცხელი წერტილი. არა, ჯერ არ ვიცით რატომ, მაგრამ ამას გავარკვევთ, ეჭვი არ შეგეპაროთ, ჩვენ შევძელით ამ იდეის გამომუშავება.

და არ უნდა დაგვავიწყდეს, რომ მრავალი მანამდე უცნობი გარემოების გამო, კონტროლი უნდა განხორციელდეს არასტანდარტულ პირობებში, როდესაც ჩვენ ვერ ვუკავშირდებით როუტერს პირდაპირ IP: პორტის საშუალებით და იძულებულნი ვართ, უბრალოდ დაველოდოთ მისგან აქტივობას. თუ ჩვენ აბსტრაქციას ვაკეთებთ, დიალოგი სერვერსა და როუტერს შორის შეიძლება ასე იყოს წარმოდგენილი:

• Router: გამარჯობა. მე ვარ ასეთი და ასეთი როუტერი, რამე დავალება ხომ არ მაქვს?
• სერვერი: როუტერი ასეთი და ასეთი, დაგირეგისტრირე, რომ ცოცხალი ხარ. აქ არის გამოწვევა: მაჩვენე ifconfig ბრძანების შედეგი?
• Router: გამარჯობა. მე ვარ ასეთი და ასეთი როუტერი, ბოლოს რომ გთხოვეთ ifconfig-ის შედეგის ჩვენება, აი ეს არის. არის რაიმე დავალება ჩემთვის?
• სერვერი: როუტერი ასეთი და ასეთი, დაგირეგისტრირე, რომ ცოცხალი ხარ. შენთვის დავალებები არ არის.

ყველაზე საინტერესო კითხვა: როგორ შეუძლია დისტანციურ როუტერს გარკვეული რაოდენობის ინფორმაციის გაგზავნა? ბოლო ნაწილში მე აღვწერე, რომ შეზღუდული რესურსების გამო, როუტერს აქვს მხოლოდ „ჩამოხსნილი“ wget, რომელიც მუშაობს მხოლოდ GET-ის საშუალებით და სხვა არაფერი; არ არსებობს FTP კლიენტი ან curl. უფრო ზუსტად, ჩვენ გვჭირდება უნივერსალური მეთოდი, მიუხედავად გამოსახულების აწყობის მახასიათებლებისა. გადავწყვიტე wget-ის გამოყენება. უფრო სწორად, როგორ "გაჩერდა" - უბრალოდ არჩევანი არ მქონდა :)

უბრალოდ უარის თქმაჩემი მენეჯმენტის გადაწყვეტა მუშაობს, არ არის ძალიან შეზღუდული და დარწმუნებული ვარ, რომ ის მრუდეა, თუნდაც ის მოერგოს ჩემს კლიენტებს. როგორ შეგეძლოთ ამის გაკეთება გონივრულად - დაწერეთ პატარა პროგრამა, რომელიც აგზავნის POST ორობით მონაცემებს პორტის 80-ით. ჩართეთ იგი (კომუნალური პროგრამა) როუტერის firmware-ში და შედით მასზე bash-ის გამოყენებით. მაგრამ რეალობა ის არის, რომ: ა) ჩვენ გვჭირდება სწრაფად ბ) ალბათ ყველაფერი უნდა გავაკეთოთ არსებულ „როუტერების ზოოპარკზე“ გ) „არავითარი ზიანი არ მიაყენო!“ — თუ როუტერი მუშაობს და სხვა დავალებებს ასრულებს, შეეცადეთ განახორციელოთ ცვლილებები, რომლებიც არ იმოქმედებს არსებულ ფუნქციონირებაზე.

მოდით გადავიდეთ განხორციელებაზე. ვთქვათ, თქვენს მომხმარებელს სურს გადატვირთოს როუტერი zabbix-დან მარტივად და ბუნებრივად, „მაუსის დაწკაპუნებით“. დღეს ჩვენ დავიწყებთ განხორციელების აღწერას Zabbix-ით.
მენიუში "ადმინისტრაცია" -> "სკრიპტები" დაამატეთ ახალი სკრიპტი. ჩვენ მას ვუწოდებთ "გადატვირთვას", შეიტანეთ ბრძანება "php /usr/share/zabbix/reboot.php {HOST.HOST}".

შემდეგი: მენიუ "მონიტორინგი" -> "უახლესი მონაცემები" -> "დააწკაპუნეთ მარჯვენა ღილაკით სასურველ ქსელის კვანძზე." ასე გამოიყურება მენიუ სკრიპტის დამატების შემდეგ.

შესაბამისად, ჩვენ ვდებთ reboot.php სკრიპტს /usr/share/zabbix დირექტორიაში (თქვენი შეიძლება განსხვავებული იყოს, მე ვიყენებ zabbixa root დირექტორიას).

უსაფრთხოების უარყოფასკრიპტში ახსნა უფრო გასაგებად რომ იყოს, მე მხოლოდ როუტერის ID-ს ვიყენებ, მაგრამ არ ვიყენებ პაროლს. არ არის რეკომენდებული ამის გაკეთება საწარმოო ვერსიაში! რატომ გავაკეთე ეს: იმიტომ, რომ დიდი კითხვაა სად უნდა შეინახოს როუტერების პაროლები? თავად zabbixe-ში „ინვენტარის მონაცემებში“? საკამათო პრაქტიკა. ალტერნატიულად: შეზღუდეთ გარე წვდომა თავად reboot.php ფაილზე

ფაილი reboot.php

<?php
	// присваиваем параметры с консоли переменным
	$user = $argv[1];
	// ВНИМАНИЕ. Вот здесь в целях безопасности все-таки прописывать пароль устройства! Но для демонстрации мы будем обращаться к базе данных без использования пароля. 
	//$password = $argv[2];
		
	$conn=new mysqli("localhost","db_user","db_password","db_name");
	if (mysqli_connect_errno()) {
		exit();
	}
	$conn->set_charset("utf8");
			
	// "Отправляем" команду reboot за счет изменения поля task таблицы users. В поле task можно отправлять любую команду.
	$sql_users=$conn->prepare("UPDATE users SET task='reboot' WHERE id=? AND status='active';");
	$sql_users->bind_param('s', $user);
	$sql_users->execute();
	$sql_users->close();
?>

Სულ ეს არის. კითხვა ღია რჩება: ”როგორ მივიღოთ მოწყობილობადან ბრძანების შესრულების შედეგი”. მოდით შევხედოთ ამოცანას ifconfig ბრძანების გამოყენებით, როგორც მაგალითი. ეს ბრძანება შეიძლება გაიგზავნოს მოწყობილობაზე:

message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt

სად:
შეტყობინება = `ifconfig` — ifconfig ბრძანების გამომავალი შედეგს ვაძლევთ $message ცვლადს
wget "xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php — ჩვენი a.php სკრიპტი, რომელიც არეგისტრირებს მარშრუტიზატორებს და იღებს მათგან შეტყობინებებს
u=მომხმარებლის&p=პაროლი!&m=$შეტყობინება — რწმუნებათა სიგელები და მოთხოვნის ცვლადის მნიშვნელობა m — ანიჭებს $message ცვლადის შინაარსს
-O /tmp/out.txt — ამ შემთხვევაში არ გვჭირდება ფაილში გამოსავალი /tmp/out.txt, მაგრამ თუ ეს პარამეტრი არ არის მითითებული, wget არ მუშაობს

რატომ არ მუშაობს ეს?რადგან ეს არის უსაფრთხოების პოტენციური ხვრელი. ყველაზე უვნებელი შეცდომა, რომელიც შეიძლება მოხდეს, არის, თუ, მაგალითად, თქვენი ბრძანების გამომავალში არის "&" სიმბოლო. აქედან გამომდინარე, აუცილებელია გაფილტრული იყოს როგორც ყველაფერი, რაც იგზავნება როუტერებიდან, ასევე ყველაფერი, რაც სერვერზე მოდის. ჰო, მრცხვენია, მართლა. ჩემს დასაცავად, შემიძლია მხოლოდ დავწერო, რომ მთელი სტატია ეძღვნება იმას, თუ როგორ უნდა მართოთ მარშრუტიზატორები წინასწარ განსაზღვრული პროგრამული უზრუნველყოფით და საკომუნიკაციო არხებით, რომლებიც წინასწარ არ არის განსაზღვრული.

კარგი, დასაწყისი მომავლისთვის: მე ჯერ ვერ გავიგე, როგორ გამოვიყენო სტანდარტული zabbix ინსტრუმენტები, რათა ასახავდეს სერვერზე მოსულ შედეგებს (მაგალითად, ბრძანების შესრულების შედეგი).

შეგახსენებთ, რომ ყველა წყაროს მიღება შესაძლებელია Git საცავიდან: github.com/BazDen/iotnet.online.git

წყარო: www.habr.com