นี่เป็นส่วนสุดท้ายของบทความ นี่คือจุดเริ่มต้น
ครั้งล่าสุดที่ฉันเขียนเกี่ยวกับวิธีการใช้งานการตรวจสอบอุปกรณ์ ตอนนี้เราจะพูดถึงการจัดการ ในการหารือกับ “ช่างเทคนิค” ฝั่งลูกค้า ฉันมักจะพบกับการรับรู้ที่จำกัดเกี่ยวกับความสามารถของอุปกรณ์ขนาดเล็กดังกล่าว (ที่มีทรัพยากรหน่วยความจำและประสิทธิภาพต่ำ) หลายคนเชื่อว่า “สิ่งที่เราต้องทำมากที่สุดคือส่งการรีบูตเพื่อบางสิ่งที่มากกว่านั้น เอาจริงเราจะส่งทีม”
แต่การปฏิบัติแสดงให้เห็นว่าสิ่งนี้ไม่เป็นความจริงทั้งหมด ต่อไปนี้เป็นรายการเล็กๆ น้อยๆ ของงานทั่วไปทั่วไป:
- การวินิจฉัยเครือข่ายและการแก้ไขปัญหา ด้านหลังพอร์ตอีเธอร์เน็ตของเราเตอร์ของคุณมักจะมีฮาร์ดแวร์อีกชิ้นหนึ่งที่มีที่อยู่ IP ภายในของตัวเอง บางครั้งคุณสามารถ (ควร) “ส่ง Ping” มันได้ หรือการจัดการทันเนล - หากทันเนลไม่เพิ่มขึ้นบนเราเตอร์ที่ทำงานผ่านโมเด็ม 3G แต่เราสามารถมองเห็นเราเตอร์ได้เอง
- การบำรุงรักษาระบบ อัพเดตเฟิร์มแวร์ อัปเกรดสคริปต์บริการ
- การกระทำที่สมดุล สิ่งนี้อาจเรียกว่า "ความวิปริต" แต่แนวคิดของ "ความสมดุล" ตามที่ฉันพูด “ความสามารถของนักแสดงละครสัตว์ในการรักษาสมดุลในตำแหน่งของร่างกายที่ไม่มั่นคง” - เข้ากันได้ดีกว่า. สถานการณ์ดังกล่าวเกิดขึ้นเนื่องจากงบประมาณของลูกค้าที่จำกัด ด้านล่างนี้ฉันยกตัวอย่างบางส่วน แต่... พวกเขาไม่ได้เกี่ยวข้องโดยตรงกับธีมของเรื่อง ฉันใส่ไว้ในบันทึก
การตรวจสอบ Wi-Fiหัวข้อยอดนิยมในช่วงห้าปีที่ผ่านมา ส่วนใหญ่อยู่ในเครือข่ายค้าปลีกของรัฐบาลกลาง คุณกำลังเดินเล่นสบาย ๆ ผ่านชั้นการซื้อขาย และโทรศัพท์มือถือของคุณที่เปิด Wi-Fi อยู่ ด้วยความพยายามที่จะ "ติด" กับเธรดบางส่วนของเครือข่าย จะส่งแพ็กเก็ต Probe Request ออกไปเป็นประจำ ซึ่งสามารถวิเคราะห์เพื่อคำนวณหา คุณ : มาร้านนี้บ่อยแค่ไหน เพราะอะไร เดินตามทาง และอื่นๆ จากนั้นข้อมูลจะถูกรวบรวม วิเคราะห์ วาดแผนที่ความร้อน และผู้จัดการ "รีดไถ" เงินจากฝ่ายบริหารหรือนักลงทุนสำหรับรูปภาพดังกล่าว คือตอนนี้.... “ไม่มีเงิน แต่ต้องอดทน...” และผล(จริง)ก็ต้องแสดงอยู่แล้ว เพลงเก่าๆ ดีๆ ก็เริ่มขึ้น “ใช่แล้ว แน่นอนพวกเรา” จะติดตั้ง cis และทุกสิ่งที่คุณต้องการ แต่ตอนนี้เราต้องแสดงให้ลูกค้าเห็นผลลัพธ์! อย่างไรก็ตาม เราลืมบอกว่าลูกค้าอนุญาตให้เราเชื่อมต่ออุปกรณ์ของเรากับฮอตสปอตของเขาผ่าน Wi-Fi แต่โดยทั่วไปแล้ว เหมือนกับว่าเราเป็นลูกค้ารับเชิญ” ดังนั้นเราจึงต้องทำเราเตอร์ที่สมดุล - อินเทอร์เฟซย่อย WiFi หลายตัวถูกยกขึ้น หนึ่งในนั้นเชื่อมต่อกับฮอตสปอต และตัวที่สองตรวจสอบสภาพแวดล้อม อัปโหลดผลลัพธ์ tcpdump ไปยังตัวมันเองอย่างเมามัน จากนั้นบรรจุเนื้อหาของไฟล์ลงในไฟล์เก็บถาวรและมีความเสี่ยง กำลังจะตายจาก "การกินมากเกินไป" พยายามที่จะคายเนื้อหาบนเซิร์ฟเวอร์ FTP ออกมา ไม่น่าแปลกใจที่เราเตอร์ที่ปรับสมดุลมักจะ "พัง" และต้อง "ช่วยชีวิต" จากระยะไกลด้วยวิธีใดวิธีหนึ่ง
รัศมีการอธิบายสถานการณ์ที่นี่ทำได้ง่ายกว่าด้วยคำกล่าวจากลูกค้า: “เราต้องการเครือข่ายฮอตสปอตแบบกระจายอำนาจที่จะทำงานบนอุปกรณ์ที่ไม่ทราบรุ่นล่วงหน้าผ่านช่องทาง แต่อุปกรณ์ใดบ้างที่เรายังไม่รู้ โอ้ เราลืมบอกไปว่าเราไม่เพียงแต่ต้องการแสดงโฆษณาต่อลูกค้าเท่านั้น แต่ยังวิเคราะห์ทุกอย่างรอบๆ ตำแหน่งที่ติดตั้งฮอตสปอตอีกด้วย ไม่ เรายังไม่รู้ว่าทำไม แต่เราจะคิดออก ไม่ต้องสงสัยเลย เราสามารถคิดไอเดียนี้ขึ้นมาได้”
และเราต้องไม่ลืมว่าเนื่องจากสถานการณ์ที่ไม่ทราบมาก่อนหน้านี้มากมาย การควบคุมจะต้องดำเนินการในสภาวะที่ไม่ได้มาตรฐาน เมื่อเราไม่สามารถเชื่อมต่อกับเราเตอร์โดยตรงผ่านพอร์ต IP: และถูกบังคับให้รอกิจกรรมจากมัน หากเราสรุปตัวเอง บทสนทนาระหว่างเซิร์ฟเวอร์และเราเตอร์สามารถแสดงได้ดังนี้:
- เราเตอร์: สวัสดี. ฉันเป็นเช่นนี้และเป็นเราเตอร์ มีงานใดบ้างสำหรับฉัน
- เซิร์ฟเวอร์: เราเตอร์เช่นนั้นฉันลงทะเบียนคุณแล้วว่าคุณยังมีชีวิตอยู่ นี่คือความท้าทาย: แสดงผลลัพธ์ของคำสั่ง ifconfig ให้ฉันดูหรือไม่
- เราเตอร์: สวัสดี. ฉันเป็นเราเตอร์เช่นนี้ ครั้งล่าสุดที่คุณขอให้แสดงผลลัพธ์ของ ifconfig นี่ไง มีงานให้ฉันบ้างไหม?
- เซิร์ฟเวอร์: เราเตอร์เช่นนั้นฉันลงทะเบียนคุณแล้วว่าคุณยังมีชีวิตอยู่ ไม่มีงานสำหรับคุณ
คำถามที่น่าสนใจที่สุด: เราเตอร์ระยะไกลสามารถส่งข้อมูลจำนวนหนึ่งได้อย่างไร ในส่วนสุดท้าย ฉันอธิบายว่าเนื่องจากมีทรัพยากรที่จำกัด เราเตอร์จึงมีเพียง wget แบบ "แยกส่วน" ซึ่งใช้งานได้ผ่าน GET เท่านั้นและไม่มีอะไรอื่นอีก ไม่มีไคลเอ็นต์ FTP หรือ Curl แม่นยำยิ่งขึ้น เราต้องการวิธีการสากล โดยไม่คำนึงถึงคุณสมบัติของการประกอบภาพ ฉันตัดสินใจใช้ wget แม่นยำยิ่งขึ้นว่าฉัน "หยุด" ได้อย่างไร - ฉันไม่มีทางเลือก :)
เพียงแค่ข้อจำกัดความรับผิดชอบโซลูชันการจัดการของฉันใช้งานได้ดี ไม่จำกัดมาก และฉันแน่ใจว่ามันคด แม้ว่ามันจะเหมาะกับลูกค้าส่วนใหญ่ของฉันก็ตาม คุณจะทำอย่างชาญฉลาดได้อย่างไร - เขียนยูทิลิตี้ขนาดเล็กที่ส่งข้อมูลไบนารี POST ผ่านพอร์ต 80 รวมมัน (ยูทิลิตี้) ไว้ในเฟิร์มแวร์เราเตอร์และเข้าถึงได้โดยใช้ bash แต่ความจริงก็คือ: ก) เราต้องดำเนินการอย่างรวดเร็ว ข) เราอาจจำเป็นต้องทำทุกอย่างใน “สวนสัตว์ของเราเตอร์” ที่มีอยู่ ค) “อย่าทำอันตราย!” — หากเราเตอร์กำลังทำงานและทำงานอื่นอยู่ ให้ลองทำการเปลี่ยนแปลงที่จะไม่ส่งผลกระทบต่อฟังก์ชันการทำงานที่มีอยู่
เรามาดำเนินการกันต่อ สมมติว่าลูกค้าของคุณต้องการรีบูตเราเตอร์จาก zabbix ได้อย่างง่ายดายและเป็นธรรมชาติ ด้วยการ "คลิกเมาส์" วันนี้เราจะมาเริ่มอธิบายการใช้งานกับ Zabbix กัน
ในเมนู "การดูแลระบบ" -> "สคริปต์" ให้เพิ่มสคริปต์ใหม่ เราเรียกมันว่า "Reboot" ป้อน "php /usr/share/zabbix/reboot.php {HOST.HOST}" เป็นคำสั่ง
ถัดไป: เมนู “การตรวจสอบ” -> “ข้อมูลล่าสุด” -> “คลิกขวาที่โหนดเครือข่ายที่ต้องการ” นี่คือลักษณะของเมนูหลังจากเพิ่มสคริปต์
ดังนั้นเราจึงใส่สคริปต์ boot.php ไว้ในไดเร็กทอรี /usr/share/zabbix (ของคุณอาจแตกต่างกัน ฉันใช้ไดเร็กทอรีรากของ zabbixa)
ข้อสงวนสิทธิ์ด้านความปลอดภัยเพื่อให้คำอธิบายชัดเจนยิ่งขึ้นในสคริปต์ ฉันใช้เพียงรหัสเราเตอร์เท่านั้น แต่อย่าใช้รหัสผ่าน ไม่แนะนำให้ทำเช่นนี้ในเวอร์ชันที่ใช้งานจริง! ทำไมฉันถึงทำเช่นนี้: เพราะคำถามใหญ่คือจะเก็บรหัสผ่านสำหรับเราเตอร์ได้ที่ไหน ใน zabbixe อยู่ใน "ข้อมูลสินค้าคงคลัง" หรือไม่? การปฏิบัติที่ขัดแย้ง อีกทางหนึ่ง: จำกัดการเข้าถึงไฟล์ restart.php จากภายนอก
ไฟล์รีบูท.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
ได้เลย " — สคริปต์ a.php ของเราที่ลงทะเบียนเราเตอร์และรับข้อความจากเราเตอร์เหล่านั้น
u=user&p=password!&m=$message — หนังสือรับรองและค่าของตัวแปรคำขอ m — กำหนดเนื้อหาของตัวแปร $message
-O /tmp/out.txt — เราไม่ต้องการเอาต์พุตไปยังไฟล์ /tmp/out.txt ในกรณีนี้ แต่หากไม่ได้ระบุพารามิเตอร์นี้ wget จะไม่ทำงาน
ทำไมสิ่งนี้ถึงไม่ทำงาน?เพราะมันเป็นช่องโหว่ด้านความปลอดภัยที่อาจเกิดขึ้น ข้อผิดพลาดที่ไม่เป็นอันตรายที่สุดที่อาจเกิดขึ้นได้ เช่น มีอักขระ “&” ในผลลัพธ์ของคำสั่งของคุณ ดังนั้นจึงจำเป็นต้องกรองทั้งทุกสิ่งที่ส่งจากเราเตอร์และทุกสิ่งที่มาถึงเซิร์ฟเวอร์ ใช่ ฉันละอายใจจริงๆ ในการป้องกันของฉัน ฉันสามารถเขียนได้ว่าบทความทั้งหมดเกี่ยวกับวิธีจัดการเราเตอร์ด้วยเฟิร์มแวร์ที่กำหนดไว้ล่วงหน้าและช่องทางการสื่อสารที่ไม่ได้กำหนดไว้ล่วงหน้า
การเริ่มต้นสำหรับอนาคต: ฉันยังไม่ทราบวิธีใช้เครื่องมือ zabbix มาตรฐานเพื่อสะท้อนผลลัพธ์ (เช่นผลลัพธ์ของการดำเนินการคำสั่ง) ที่มาถึงเซิร์ฟเวอร์
ฉันขอเตือนคุณว่าสามารถรับแหล่งข้อมูลทั้งหมดได้จากที่เก็บ Git ที่:
ที่มา: will.com