เนื้อหาวันที่ : 2011-06-24 17:15:44 จำนวนผู้เข้าชมแล้ว : 18471 views

มารู้จักโปรโตคอล SNMP (ตอนที่ 1)

โปรโตคอล SNMP (Simple Network Management Protocol) โปรโตคอลระดับแอพพลิเคชั่นตัวหนึ่งที่ใช้โปรโตคอล UDP ในการรับส่งข้อมูล

การสื่อสารข้อมูลในงานอุตสาหกรรม
ตอนที่ 12 มารู้จักโปรโตคอล SNMP (ตอนที่ 1)

พิชิต จินตโกศลวิทย์ 
pichitor@yahoo.com

          ในบทความที่แล้วได้กล่าวถึงโปรโตคอล UDP (User Datagram Protocol) ซึ่งเป็นโปรโตคอลที่ใช้ในการขนย้ายข้อมูล (Transport) ที่มีฟังก์ชันการทำงานไม่ซับซ้อน สำหรับในบทความฉบับนี้จะกล่าวถึงโปรโตคอลระดับแอพพลิเคชั่นตัวหนึ่งที่ใช้โปรโตคอล UDP ในการรับส่งข้อมูล นั่นคือโปรโตคอล SNMP (Simple Network Management Protocol)

          ปัจจุบันนี้ระบบเครือข่ายมีความซับซ้อนมากขึ้น และมีความวิกฤติมากขึ้น การบริหารจัดการระบบเครือข่ายไม่ใช่แค่เพียงติดตั้ง และใช้งาน แต่ต้องมีการตรวจสอบเฝ้าระวังประสิทธิภาพการทำงานเพื่อทำการบำรุงรักษาให้ระบบทำงานได้อย่างมีประสิทธิภาพและต่อเนื่อง การลดลงหรือถดถอยของประสิทธิภาพการทำงานของระบบเครือข่ายในบางระบบงานอาจทำให้เกิดความเสียหายมูลค่าสูง ทั้งทางการเงิน หรือทรัพย์สิน รวมทั้งชีวิตได้ เช่น ระบบจำหน่ายไฟฟ้า หรือระบบท่อส่งแก๊สและน้ำมัน  และนั่นคือที่มาของความต้องการโปรโตคอลในการบริหารจัดการระบบเครือข่าย หรือโปรโตคอล SNMP ซึ่งอยู่ในชุดโปรโตคอล TCP/IP (Transmission Control Protocol/Internet Protocol)

          โปรโตคอล SNMP ได้ถูกพัฒนาขึ้นในปี พ.ศ.2531 เนื่องจากมีความเจริญเติบโตในการใช้อุปกรณ์ที่สนับสนุนโปรโตคอล TCP/IP อย่างสูง โปรโตคอล SNMP ถูกออกแบบให้มีฟังก์ชันและการทำงานแบบง่าย ๆ เหมาะกับคำว่าซิมเปิล (Simple) ตามชื่อของมัน โดยมีจุดประสงค์หลักเพื่อให้ผู้ดูแลระบบเครือข่ายสามารถเข้ามาจัดการอุปกรณ์เครือข่ายได้จากระยะไกลโดยง่าย

การจัดการเครือข่ายและการเฝ้าระวัง
          สิ่งที่สำคัญของโปรโตคอล SNMP ก็คือความง่ายในการใช้งาน ทำให้ผู้ดูแลระบบเครือข่ายสามารถควบคุมอุปกรณ์ที่สนับสนุน SNMP ได้จากที่ไหนก็ได้ที่ระบบเครือข่ายนั้นไปถึง ตัวอย่างคือ ผู้ดูแลระบบเครือข่ายสามารถทดลองแก้ไขปัญหาอย่างเร่งด่วนโดยทำการรีเซตพอร์ตอีเทอร์เน็ตสวิตช์ที่ต่อเข้ากับ PLC (Programmable Logic Controller) ที่ไม่สามารถติดต่อระบบควบคุมได้ หรือสามารถตรวจสอบอัตราการเข้าใช้งาน (Utilized Rate) หรือการเกิดความเฟรมผิดพลาดของพอร์ต (Error Rate) หรือแม้กระทั่งตรวจสอบอุณหภูมิของอุปกรณ์เครือข่ายว่าเป็นปกติหรือไม่ เพื่อเข้าทำการบำรุงรักษาก่อนที่ระบบเครือข่ายจะขัดข้อง ซึ่งถือว่าเป็นการบำรุงรักษาแบบ CBM (Condition-based Maintenance)

          โดยทั่วไปแล้ว คนส่วนใหญ่คิดว่าโปรโตคอล SNMP ใช้จัดการกับอุปกรณ์ประเภทเราเตอร์ หรือสวิตช์เท่านั้น แต่อันที่จริงแล้วโปรโตคอล SNMP ใช้ได้กับอุปกรณ์บนเครือข่ายทุกประเภท ไม่ว่าจะเป็น ตัวเซิร์ฟเวอร์ประเภทต่าง ๆ เช่น UNIX หรือกับคอมพิวเตอร์ทั่วไปที่ใช้ระบบปฏิบัติการ Microsoft Windows เครื่องใช้สำนักงาน เช่น ปริ๊นเตอร์, โมเด็ม รวมแม้กระทั่งเครื่องสำรองไฟฟ้า UPS

          อีกหน้าที่หนึ่งของ SNMP ที่สำคัญคือ การใช้เฝ้าระวัง หรือมอนิเตอร์ระบบเครือข่ายทั้งระบบ แตกต่างจากการเข้าจัดการอุปกรณ์แบบรายอุปกรณ์ ซึ่งฟังก์ชันการมอนิเตอร์ระบบเครือข่ายดังกล่าวเรียกอีกอย่างว่า RMON (Remote Network Monitoring) ซึ่งได้ถูกพัฒนาเพื่อช่วยในการวิเคราะห์การทำงานของระบบเครือข่าย เก็บข้อมูลต่าง ๆ ไว้ได้ด้วยตัวเอง และยังสามารถวิเคราะห์ว่าการทำงานของอุปกรณ์ตัวใดส่งผลกระทบต่อภาพรวมของระบบเครือข่าย ซึ่งรายละเอียดของ RMON จะถูกนำเสนอในบทความถัดถัดไป
    
* ทำไมต้องมี SNMP
          สมมุติว่าถ้ามีระบบเครือข่ายที่มีอุปกรณ์หลาย ๆ ชนิดจำนวน 100 ตัวทำงานด้วยกัน อุปกรณ์เหล่านั้นอาจเป็นไฟล์เซิร์ฟเวอร์ หรือเซิร์ฟเวอร์สำหรับปริ๊นเตอร์ หรือเซิร์ฟเวอร์ที่ทำธุรกรรมเกี่ยวกับบัตรเครดิต ในระบบเครือข่ายขนาดใหญ่ยังต้องประกอบด้วยอุปกรณ์เครือข่ายประเภทสวิตช์ และเราเตอร์ ที่ทำให้ระบบงานสามารถเชื่อมโยงกัน โดยมีวงจรสื่อสารแบบ WAN (Wide Area Network) เช่น วงจร T1 ที่ทำให้ระบบเชื่อมโยงข้ามประเทศได้ คำถามว่าอะไรจะเกิดขึ้นเมื่อมีเซิร์ฟเวอร์หลัก เช่น เซิร์ฟเวอร์ของบัตรเครดิตไม่สามารถติดต่อได้

สมมุติว่าเหตุการณ์เกิดขึ้นระหว่างสัปดาห์ ผลลัพธ์ที่ได้อาจไม่ส่งผลกระทบ หรือเกิดความเสียหายที่ร้ายแรง อันเนื่องจากมีพนักงานทำงานอยู่ และทำการแก้ไข หรือเรียกผู้ดูแลเซิร์ฟเวอร์เข้ามาซ่อม แต่ถ้าโชคไม่ดีเหตุการณ์เกิดในช่วงในเวลานอกทำการ พนักงานกลับที่พักเรียบร้อย หรือแม้กระทั่งเกิดขึ้นในช่วงวันหยุด ระบบงาน หรือระบบบัตรเครดิตอาจจะใช้การไม่ได้เลย ตั้งแต่ช่วงเย็นของวันศุกร์จนถึงช่วงเช้าของวันจันทร์ ถ้าปัญหาเกิดจากตัวเราเตอร์ การแก้ไขปัญหาอาจง่ายเพียงแค่เปลี่ยนตัวเราเตอร์ แต่ผลลัพธ์ที่เกิดจากระบบบัตรเครดิตขัดข้องได้อาจทำให้การทำธุรกรรมจำนวนหลายล้านไม่สามารถทำได้ ซึ่งเป็นปัญหาที่ไม่สมเหตุสมผลเลย

          ดังนั้นจึงเป็นที่ชัดเจนว่าสภาวะปัญหาเช่นนี้ เป็นสิ่งที่ต้องดำเนินการป้องกัน เนื่องจากจริง ๆ แล้ว ในโลกแห่งการแข่งขันทางธุรกิจมันอาจจะเป็นตัวชี้ถึงความอยู่รอดของธุรกิจนั้น ๆ ได้ และนี่คือเหตุผลหนึ่งที่ว่าทำไมต้องมีโปรโตคอลประเภท SNMP แทนที่จะรอคอยพนักงานซักคนสังเกตพบความผิดปกติ และเรียกผู้ดูแลเข้าไปดำเนินการแก้ไขปัญหา ระบบจัดการระบบเครือข่ายด้วยโปรโตคอล SNMP สามารถทำให้มีการมอนิเตอร์ระบบเครือข่ายอัตโนมัติตลอดเวลา ถึงแม้ว่าจะไม่มีพนักงานอยู่ที่ทำงานก็ตาม

ตัวอย่างเช่น ระบบจัดการระบบเครือข่ายด้วยโปรโตคอล SNMP สามารถตรวจสอบจำนวนของแพ็กเกจเสียหายที่เกิดขึ้นที่พอร์ตใด ๆ ของเราเตอร์ ถ้าอัตราการเกิดแพ็กเกจเสียหายมีแนวโน้มเพิ่มขึ้น ระบบอาจประเมินว่าเราเตอร์ตัวนั้นอาจจะขัดข้อง หรือใช้งานไม่ได้ในอีกไม่ช้า ดังนั้นถ้าผู้ดูแลระบบเครือข่ายรับทราบถึงข้อมูลดังกล่าวก่อน ก็สามารถดำเนินการเปลี่ยน หรือแก้ไขซ่อมแซมเราเตอร์ก่อนที่มันจะทำงานล่มเหลวได้ หรือ แม้กระทั้งตัวเซิร์ฟเวอร์ก็สามารถรับทราบได้ว่าเซิร์ฟเวอร์เกิดการขัดข้องหรือไม่ ถึงแม้ว่าจะพักผ่อนอยู่ที่บ้าน และอาจจะสามารถแก้ไขปัญหาจากที่บ้านได้โดยการเข้าเซตติ้งแก้ปัญหา หรือทำการรีเซตระบบระยะไกลได้ เสมือนว่าไม่มีอะไรร้ายแรงเกิดขึ้นเลย

          อันที่จริงไม่มีสิ่งใดจะน่ายินดีเท่ากับที่ผู้ดูแลระบบเครือข่ายสามารถทำการแก้ไขปัญหา หรือทำการบำรุงรักษาเชิงป้องกันก่อนที่จะเกิดปัญหาใหญ่ หรือเกิดการล้มเหลวของระบบอย่างสมบูรณ์ แต่สภาพการทำงานจริงไม่ได้หมายความว่าผู้ดูแลป้องกันที่ดีจะได้รับเงินเดือนสูงขึ้น หรือได้รับการชมเชยจากบริษัท เพราะบ่อยครั้งผู้ดูแลระบบเครือข่ายที่เข้าแก้ไขปัญหาที่หนักอาจจะได้ผลตอบแทน หรือคำชมเชยที่ดีกว่าผู้ดูแลระบบเครือข่ายที่ป้องกันจนปัญหาใหญ่ไม่เกิดขึ้นเลย

          การติดตั้งระบบจัดการระบบเครือข่ายอันที่จริงแล้วอาจต้องมีการเพิ่มจำนวนพนักงานเพื่อทำหน้าที่ในการบำรุงรักษาและใช้งานระบบจัดการเครือข่าย ดังนั้นระบบจัดการระบบเครือข่ายจึงจำเป็นต้องมีพนักงานสำหรับทำหน้าที่ดังต่อไปนี้

          * ดูแลบำรุงรักษาเครื่องเซิร์ฟเวอร์ของระบบจัดการระบบเครือข่าย เพื่อให้แน่ใจว่าระบบสามารถจัดการกับข้อมูลที่ได้จากอุปกรณ์ในเครือข่าย และสามารถรายงานสภาพระบบเครือข่ายได้อย่างถูกต้อง

          * ดูแลบำรุงรักษาอุปกรณ์ในเครือข่ายที่สนับสนุนโปรโตคอล SNMP เพื่อให้แน่ใจว่าอุปกรณ์ดังกล่าวสามารถส่งข้อมูลให้กับเซิร์ฟเวอร์ได้


          * ดูแลบำรุงรักษาระบบเครือข่าย โดยศูนย์หรือกลุ่มงาน มีการจัดสรรตารางเวรแก้ไข 24/7 (24 ชั่วโมง 7 วัน) สำหรับระบบเครือข่ายขนาดเล็กอาจจะใช้วิธีการทำงานแบบรอสแตนด์บาย (Stand-by) รอเรียกให้เข้าดำเนินการจากระบบจัดการระบบเครือข่ายโดยที่พนักงานสามารถพักผ่อนอยู่ที่บ้าน แต่ระบบเครือข่ายนั้นต้องไม่มีระบบงานที่มีความวิกฤติสูง

ข้อมูลทั่วไป RFC กับเวอร์ชันของ SNMP
          สำหรับมาตรฐานโปรโตคอล TCP/IP จะมีหน่วยงานสากลในชื่อ IETF (Internet Engineering Task Force) ที่คอยกำกับดูแลซึ่งรวมไปถึงโปรโตคอล SNMP ด้วย โดยทาง IETF จะทำการตีพิมพ์ข้อกำหนดมาตรฐานในชื่อ RFCs (Request for Comments) โดยเริ่มแรกข้อกำหนดจะถูกนำเสนอให้ทาง IETF ทำการพิจารณา หลังจากรับข้อกำหนด IETF จะพิจารณาขั้นต้น และข้อกำหนดนั้นจะเข้าสู่สถานะฉบับร่าง และท้ายสุดจะเข้าสู่สถานะอนุมัติเมื่อข้อกำหนดนั้นสมบูรณ์ และ RFC ฉบับนั้นจะถูกพิจารณาให้เป็นมาตรฐาน แต่อย่างไรก็ตามอันที่จริงมีไม่กี่ RFC ที่ถูกอนุมัติให้เป็นมาตรฐาน สืบเนื่องมาจากเทคโนโลยีทางด้านการสื่อสารมีความก้าวหน้าแบบก้าวกระโดด ทำให้เกิด RFC ตัวใหม่เข้ามาแทนที่ ทั้ง ๆ ที่ตัวเก่ายังไม่รับอนุมัติให้เป็นมาตรฐาน รายการดังต่อไปนี้เป็นเวอร์ชัน และ RFC ของโปรโตคอล SNMP

          * SNMP Version 1 (SNMPv1) เป็นมาตรฐานปัจจุบันและเป็นที่นิยมเพราะความง่ายของโปรโตคอล SNMP ซึ่งถูกระบุใน RFC1157 และได้รับอนุมัติให้เป็นมาตรฐานที่สมบูรณ์ ระดับความปลอดภัย SNMPv1 จะขึ้นอยู่กับคอมมิวนิตี้สตริง (Community String) ที่ทำหน้าที่เหมือนรหัสผ่าน หรือพาสเวิร์ด (Password) โดยที่จริงแล้วเป็นเพียงข้อความแบบธรรมดา (Plain Text) ที่บ่งบอกถึงสิทธิการเข้าไปจัดการอุปกรณ์เครือข่าย โดยปกติคอมมิวนิตี้จะมีสามประเภทนั้นคือ อ่านอย่างเดียว (Read-only), อ่านเขียน (Read-write)  และแทรป (Trap)

          * SNMP Version 2 (SNMPv2) คือ เวอร์ชันที่ทำงานบนคอมมิวนิตี้ที่ได้รับการปรับปรุง ในทางเทคนิคเรียกว่า SNMPv2c ซึ่งระบุใน RFC1905, RFC1906 และ RFC1907 และอยู่ในขั้นตอนทดสอบใช้งาน แต่ก็มีบางผู้ผลิตได้นำมาใช้งานในอุปกรณ์ของพวกเขา  SNMPv2 ออกแบบมาเพื่อแก้ไขข้อด้อยของ SNMPv1 ในเรื่องการร้องข้อมูลปริมาณมาก และปัญหาในการส่งข้อมูลแบบแทรป

          * SNMP Version 3 (SNMPv3) เป็นเวอร์ชันถัดไปของโปรโตคอล SNMP ที่ถูกคาดหวังให้เป็นมาตรฐานที่สมบูรณ์ ซึ่งในปัจจุบันอยู่ในสถานะนำเสนอระบุใน RFC1905, RFC1906, RFC1907, RFC2571, RFC2572, RFC2573, RFC2574 และ RFC2575 โดยมุ่งเน้นการเพิ่มระดับความปลอดภัยของโปรโตคอล SNMP

เมเนเจอร์และเอเยนต์ (Manager and Agent)
          อันที่จริงแล้วทางเทคนิค อุปกรณ์เครือข่ายที่สนับสนุนโปรโตคอล SNMP แบ่งเป็น 2 ประเภทเท่านั้นคือ เมเนเจอร์ และเอเยนต์

รูปที่ 1 SNMP Manager และ Agent

          ตัวเมเนเจอร์โดยทั่วไป คือเซิร์ฟเวอร์ที่รันซอฟต์แวร์ หรือโปรแกรมประยุกต์สำหรับการบริหารจัดการระบบเครือข่าย  บ่อยครั้งที่เมเนเจอร์ ถูกเรียกว่า NMS (Network Management Stations) เมเนเจอร์มีหน้าที่ร้องขอ (Request บางครั้งเรียกว่า Query) หรือโพลลิ่ง (Polling) หรือรับข้อมูลประเภทแทรป (Trap) ที่ถูกส่งจากตัวเอเยนต์โดยไม่ได้ร้องขอ

          การโพลล์ คือการร้องขอข้อมูลจากเอเยนต์ เช่น จากเราเตอร์ หรือสวิตช์ ข้อมูลเหล่านี้สามารถใช้ประเมินสภาพการทำงานของระบบเครือข่าย ส่วนแทรป คืออีกวิธีการหนึ่งสำหรับเอเยนต์ในการส่งสัญญาณเตือนไปยังเมเนเจอร์ ว่ามีเหตุการณ์สำคัญใดเกิดขึ้น แทรปสามารถจะถูกส่งเมื่อไรก็ได้โดยไม่ต้องรอการร้องขอจากเมเนเจอร์ ตัวเมเนเจอร์จะมีการตอบสนองต่อแทรปตามการตั้งค่าของผู้ดูแลระบบเครือข่าย สำหรับตัวอย่าง เมื่อวงจรสื่อสาร T1 เกิดขัดข้อง เราเตอร์สามารถส่งแทรปไปยังเมเนเจอร์ หลังจากนั้นเมเนเจอร์จะส่ง SMS แจ้งเตือนผู้ดูแลระบบเครือข่ายอีกที ว่ามีวงจรสื่อสาร T1 ขัดข้องเกิดขึ้นในระบบเครือข่ายเป็นต้น

          ประเภทอุปกรณ์ชนิดที่สองคือ เอเยนต์ โดยทั่วไปคือโปรแกรม หรือเฟิร์มแวร์ (Firmware) ที่ติดตั้ง และทำงานบนตัวอุปกรณ์เครือข่ายที่ผู้ดูแลระบบเครือข่ายต้องการจัดการ ซึ่งอาจจะเป็นโปรแกรมเฉพาะ และทำงานเบื้องหลังเป็นแบ็กกราวด์โปรเซส (Background Process) หรือเดมอน (Daemon) เช่น ในไมโครซอฟต์วินโดว์ หรือยูนิกซ์ หรือเป็นส่วนหนึ่งในระบบปฏิบัติการ เช่น ในเราเตอร์ของ CISCO ซึ่งเป็นเฟิร์มแวร์ระดับต่ำ

          ในปัจจุบันอุปกรณ์ที่ใช้โปรโตคอล TCP/IP ส่วนใหญ่จะมาพร้อมกับตัวเอเยนต์ SNMP เพียงแต่อาจต้องมีการเปิดใช้งาน เพราะอันที่จริงแล้วผู้ผลิตต้องการให้ผลิตภัณฑ์ของตนเองง่ายต่อการบำรุงรักษา เอเยนต์จะให้ข้อมูลการทำงานของอุปกรณ์เพื่อการจัดการ และบำรุงรักษา สำหรับตัวอย่าง เอเยนต์บนเราเตอร์สามารถบ่งบอกสถานะของแต่ละพอร์ตว่าทำงานปกติ หรือไม่ปกติ โดยเมเนเจอร์สามารถร้องขอข้อมูลดังกล่าวผ่านโปรโตคอล SNMP หรืออีกวิธีหนึ่ง ถ้าเกิดมีการขัดข้องรุนแรงเกิดขึ้นในตัวอุปกรณ์ และเอเยนต์ตรวจสอบพบ เอเยนต์จะส่งข้อมูลประเภทแทรปแจ้งไปยังเมเนเจอร์โดยไม่ต้องมีการร้องขอ และหลังจากนั้น เมเนเจอร์จะดำเนินการต่อข้อมูลดังกล่าวตามการตั้งค่า หรือเซตติ้ง ในบางอุปกรณ์ยังส่งแทรปแจ้งเมเนเจอร์เมื่อเหตุที่ขัดข้องได้กลับคืนสภาพปกติ (All Clear) ด้วย ซึ่งก็เป็นวิธีการที่ดี ทำให้สามารถตรวจสอบแก้ไขได้ง่าย และเร็วขึ้น ดังรูปที่ 1 ได้แสดงความสัมพันธ์ระหว่าง เมเนเจอร์ และเอเยนต์

          สิ่งที่สำคัญที่ควรรับทราบอย่างหนึ่งก็คือ การร้องขอ และการส่งแทรป สามารถเกิดขึ้นได้ในเวลาเดียวกัน ดังนั้นจึงไม่มีปัญหา ถ้ามีการร้องขอข้อมูลในขณะที่กำลังรับแทรปจากตัวเอเยนต์

SMI และ MIBS
          โครงสร้างของข้อมูลเพื่อการจัดการ (SMI: Structure of Management Information) ระบุถึงวิธีการนิยามออบเจ็กต์ (Object) และพฤติกรรมการทำงาน (Behavior) เอเยนต์ เพื่อติดตามการทำงานของอุปกรณ์ หนึ่งในรายการที่สำคัญก็คือ ออปเจ็กต์ที่แสดงสถานะการทำงานของพอร์ตเราเตอร์ (Up, Down หรือ Testing) รายการดังกล่าวจะเป็นข้อมูลที่ตัวเมเนเจอร์สามารถตรวจสอบสภาพการทำงานของอุปกรณ์เครือข่ายได้

          อีกอย่างหนึ่ง ก็คือ MIB (Management Information Base) ซึ่งเป็นฐานข้อมูล ที่เอเยนต์ใช้ตรวจสอบสภาพการทำงานของอุปกรณ์ เช่น สถานะ ข้อมูลเชิงปริมาณและทางสถิติของอุปกรณ์เครือข่าย โดยรูปแบบโครงสร้างของออบเจ็กต์จะถูกนิยามตาม SMI เสมือนกับพจนานุกรมที่บอกวิธีการอ่านออกเสียงรวมทั้งมีการให้ความหมายโดยย่อ

          ในหนึ่งเอเยนต์อาจมีหลาย MIB แต่ทุกทุกเอเยนต์จะมี MIB ส่วนกลางเพียงตัวเดียวเรียกว่า MIB-II (RFC 1213) ตัว MIB-II เป็นฐานข้อมูลมาตรฐานที่นิยามตัวแปรมาตรฐานต่าง ๆ ที่ตัวอุปกรณ์เครือข่ายต้องมี เช่น ข้อมูลของพอร์ต (ความเร็ว,จำนวนไบต์รับ, จำนวนไบต์ส่ง เป็นต้น) รวมทั้งข้อมูลที่บรรยายถึงตัวอุปกรณ์เอง เช่น ตำแหน่งที่ตั้ง ชื่อผู้ดูแล เป็นต้น จุดประสงค์หลักของ MIB-II คือการให้ข้อมูลทั่วไปเกี่ยวกับการบริหารจัดการโปรโตคอล TCP/IP แต่ไม่ได้หมายความว่าจะครอบคลุมความต้องการทุกส่วนของอุปกรณ์นั้น ๆ และอันที่จริงนั้นมี MIB-I ที่เป็นต้นกำเนิดของ MIB แต่จะไม่กล่าวถึงเนื่องจากไม่ได้ถูกใช้งานเลยหลังจากที่มีการออก MIB-II ให้นำมาใช้งาน

          ข้อมูลใน MIB มีหลายชนิดขึ้นอยู่กับอุปกรณ์ หรือฟังก์ชั่นภายในตัวอุปกรณ์นั้น ๆ ดังนั้นหนึ่งอุปกรณ์สามารถมี หลาย MIB ดังตัวอย่าง MIB ดังต่อไปนี้
          * ATM MIB (RFC 2515)
          * Frame Relay DTE Interface Type MIB (RFC 2115)
          * BGP Version 4 MIB (RFC 1657)
          * RDBMS MIB (RFC 1697)
          * Mail Monitoring MIB (RFC 2249)
          * DNS Server MIB (RFC 1611)

Host Management
          การจัดการโฮสต์ หรือเซิร์ฟเวอร์ (การใช้พื้นที่ดิสก์ และหน่วยความจำ เป็นต้น) เป็นสิ่งหนึ่งที่สำคัญของการจัดการระบบเครือข่ายเช่นกัน เป็นที่แน่ชัดว่าไม่สามารถแยกการจัดการเครือข่ายออกจากการจัดการตัวโฮสต์ ดังวลีการตลาดของบริษัทซันไมโครซิสเต็มที่ว่า “The Network is the Computer” ก็เพราะว่าถ้าเซิร์ฟเวอร์ขัดข้อง ก็ไม่มีประโยชน์ที่ว่าเราเตอร์ หรือสวิตช์จะทำงานเป็นปกติหรือไม่ ตัว MIB ที่ดูแลทรัพยากรของโฮสต์ จะถูกกำหนดในมาตรฐาน RFC2790 เพื่อคอยรายงานจุดที่มีความวิกฤติ ตัวอย่างข้อมูลที่สามารถมอนิเตอร์จาก MIB ของโฮสต์ ได้แก่ พื้นที่ว่างของฮาร์ดดิสก์ ,จำนวนผู้เข้าใช้งาน, จำนวนหรือโปรเซสที่กำลังทำงาน รวมทั้งรายการซอฟต์แวร์ที่ติดตั้งบนโฮสต์

SNMP กับ UDP
          โปรโตคอล SNMP ใช้ UDP เป็นโปรโตคอลในการส่ง และรับข้อมูลระหว่างตัวเมเนเจอร์ และเอเยนต์ ถามว่าทำไมโปรโตคอล UDP ถูกเลือกใช้แทนที่จะเป็น TCP คำตอบก็เพราะว่าโปรโตคอล UDP ใช้การเชื่อมต่อแบบคอนเน็กชันเลส (Connectionless) ซึ่งไม่มีการเชื่อมต่อสื่อสารหรือทำแฮนด์แช็กกิ้งก่อนที่จะรับและส่งข้อมูลระหว่างเมเนเจอร์และเอเยนต์ ลักษณะการทำงานของโปรโตคอล UDP จริง ๆ มีระดับความเชื่อถือได้ที่ไม่สูง เพราะไม่มีการตอบรับแพ็กเกจถ้าเกิดมีการสูญหายระหว่างทาง

ดังนั้นจึงตกเป็นหน้าที่ระดับแอพพลิเคชั่นที่ต้องประเมินว่าแพ็กเกจสูญหายหรือไม่ หรือต้องทำการส่งการร้องขอใหม่หรือไม่ วิธีที่ใช้ทั่วไปคือการใช้ไทเมอร์ หรือไทม์เอาต์ (Timeout) เมเนเจอร์ที่ส่งเมสเซสร้องขอไปยังตัวเอเยนต์จะคอยการตอบสนองในระยะเวลาหนึ่ง ซึ่งระยะเวลานั้นขึ้นอยู่กับการตั้งค่าของผู้ดูแลระบบเครือข่าย ถ้าหมดระยะเวลาการรอคอยแล้วไม่มีการตอบสนองใด ๆ จากเอเยนต์ เมเนเจอร์จะประเมินว่าแพ็กเกจเกิดการสูญหาย และจะทำการส่งเมสเซสการร้องขออีกครั้ง จำนวนครั้งที่การร้องขอซ้ำนั้นขึ้นอยู่กับการตั้งค่าเช่นกัน

          อันที่จริงแล้วปัญหาที่เกิดจากตัวโปรโตคอล UDP จากการส่งเมสเซสร้องขอข้อมูลจากเอเยนต์นั้นไม่ได้เป็นประเด็นเลย แต่ที่เป็นประเด็นแท้จริง ก็คือการส่งแทรปจากเอเยนต์ไปยังเมเนเจอร์ เนื่องจากแทรปสามารถสูญหายได้โดยที่เมเนเจอร์ไม่ได้รับทราบใด ๆ เนื่องจากระบบการทำงานของแทรปไม่ได้ออกแบบให้ยืนยันการได้รับแทรป จึงไม่มีกระบวนการส่งแทรปซ้ำ จึงได้เกิดความคิดที่จะใช้ TCP มาแก้ไขปัญหาดังกล่าว

          ข้อดีของโปรโตคอล UDP คือการที่ UDP มีค่าโอเวอร์เฮดที่ต่ำไม่ไปรบกวน หรือส่งผลกระทบกระเทือนต่อประสิทธิภาพของระบบเครือข่าย หรือตัวระบบงานหลัก อันที่จริงโปรโตคอล SNMP ก็สามารถใช้โปรโตคอล TCP แต่ก็เป็นเฉพาะกรณีพิเศษอย่างยิ่งเท่านั้น สำหรับระบบเครือข่ายที่ความคับคั่งสูงเป็นความคิดที่ไม่ถูกต้องที่จะใช้โปรโตคอล TCP ก็เพราะว่าโปรโตคอล TCP อันที่จริงก็ไม่เหมาะสมกับทุกระบบงานโดยเฉพาะกับระบบเครือข่ายที่ไม่สมบูรณ์ หรือคับคั่งสูง โปรโตคอล SNMP ถูกคาดหวังว่าสามารถทำงานได้ดีแม้ในระบบเครือข่ายที่ไม่สมบูรณ์ แต่ถ้าระบบเครือข่ายมีปัญหาอยู่ และยังมีระบบจัดการเครือข่ายที่เพิ่มปัญหาเข้าไปอีก เช่น การใช้โปรโตคอล TCP ที่มีค่าโอเวอร์เฮดที่สูง เป็นต้น ก็ไม่น่าจะเป็นความคิดที่ถูกต้อง

          โปรโตคอล SMNP ใช้พอร์ต UDP หมายเลข 161 สำหรับส่งและรับแบบการร้องขอข้อมูล และใช้พอร์ตหมายเลข 161 สำหรับรับเมสเซจชนิดแทรปจากเอเยนต์ของอุปกรณ์เครือข่ายที่ถูกจัดการ ทุกทุกอุปกรณ์เครือข่ายต้องใช้พอร์ตหมายเลขดังกล่าวเป็นหมายเลขดีฟอลต์ แต่อย่างไรก็ตามบางผู้ผลิตอนุญาตให้เปลี่ยนหมายเลขพอร์ต ซึ่งเมเนเจอร์ต้องรับทราบ และเปลี่ยนหมายเลขพอร์ตให้ตรงกับอุปกรณ์เครือข่ายเพื่อให้สามารถติดต่อรับส่งเมสเซจได้

          รูปที่ 2 แสดงชุดโปรโตคอล TCP/IP ที่เป็นพื้นฐานของการสื่อสารข้อมูลโดยใช้หมายเลข IP ปัจจุบันอุปกรณ์ที่ต้องการเชื่อมต่ออินเทอร์เน็ตจำเป็นต้องใช้โปรโตคอล TCP/IP เท่านั้น โมเดลด้านล่างแสดงการใช้โปรโตคอลสแต็กของ SNMP ซึ่งแต่ละเลเยอร์จะใช้ข้อมูลจากเลเยอร์ด้านล่างมาประมวลผลและให้บริการต่อเลเยอร์ด้านบน

          เมื่อเอเยนต์ หรือ เมเนเจอร์ต้องการทำฟังก์ชันของ SNMP เช่น การร้องขอ หรือส่งแทรป ขั้นตอนการทำงานต่อไปนี้จะเกิดภายในโปรโตคอลสแต็ก

          * ระดับชั้นแอพพลิเคชั่น
          ลำดับแรกเป็นระดับของโปรแกรมประยุกต์ ทั้งในส่วนของเมเนเจอร์ และเอเยนต์ จะเป็นการตั้งค่าเพื่อกำหนดการทำงานทั้งในสภาวะปกติและไม่ปกติ โปรแกรมประยุกต์อาจส่งการร้องขอไปยังเอเยนต์ หรือส่งการตอบสนองไปยังเมเนเจอร์ หรือแทรปไปยังเมเนเจอร์โดยการสร้างเฟรม SNMP เลเยอร์ชั้นแอพพลิเคชันมักจะให้การบริการโดยตรงต่อผู้ใช้ เช่นการร้องของสถานะการทำงานของอีเทอร์เนตสวิตช์แบบแมนวล (Manual) เป็นต้น

          * ระดับชั้นทรานสปอร์ต หรือ UDP
          ชั้นถัดไปคือชั้นทรานสปอร์ตที่โปรโตคอล UDP ทำงานอยู่ ซึ่งเป็นตัวจัดการให้โฮสต์สองโฮสต์ส่งข้อมูลระหว่างกันได้ โดยสิ่งที่สำคัญของก็คือ เฮดเดอร์ของโปรโตคอล UDP ซึ่งประกอบด้วยหมายเลขพอร์ตปลายทางที่ต้องการส่งการร้องขอ หรือส่งแทรป โดยหมายเลขปลายทางจะเป็น 161 (สำหรับการร้องขอ) และ 162 (สำหรับแทรป)

          * ระดับชั้นเน็ตเวิร์ก หรือ IP
          ชั้นถัดไปคือชั้นเน็ตเวิร์กที่โปรโตคอล IP ทำงานอยู่ ซึ่งจะใช้จริง ๆ สำหรับการส่งแพ็กเกจ SNMP ข้ามเครือข่ายไปยังปลายทางโดยการใช้หมายเลข IP

          * ระดับชั้นดาต้าลิงก์ หรือ MAC (Medium Access Control)
          กระบวนการสุดท้ายที่จะเกิดขึ้นสำหรับการส่งแพ็กเกจ SNMP ไปยังปลายทาง คือการส่งสัญญาณทางกายภาพ โดยปกติแพ็กเกจถูกประมวลผลโดยโปรโตคอล MAC ซึ่งจะถูกติดตั้งบนฮาร์ดแวร์สำหรับติดต่อระบบเครือข่ายจริง ๆ เช่น การ์ดแลน เป็นต้น โดยปกติจะทำงานควบคู่กับไดรฟ์เวอร์ของระบบปฏิบัติการเพื่อสร้างสัญญาณบนสื่อสัญญาณจริง ๆ เช่น สายทองแดง ชั้น MAC ยังรับผิดชอบในการรับแพ็กเกจจากเครือข่ายโดยพิจารณาจากหมายเลข MAC และส่งข้อมูลที่ได้รับไปยังโปรโตคอลสแต็กชั้นบนให้ดำเนินการต่อไป

รูปที่ 2 SNMP กับ UDP

SNMP คอมมิวนิตี้ (SNMP Communities)
          สำหรับ SNMPv1 และ SNMPv2 ที่เป็นที่นิยม จะใช้ระบบคอมมิวนิตี้ในการสร้างความปลอดภัยในการรับส่งข้อมูลระหว่างเมเนเจอร์ และเอเยนต์ โดยทั่วไปเอเยนต์จะถูกตั้งค่าให้มีคอมมิวนิตี้ 3 ประเภทโดยวิธีการตั้งชื่อ นั้นคือ อ่านได้อย่างเดียว สามารถอ่านเขียน และแทรป ชื่อคอมมิวนิตี้ หรือคอมมิวนิตี้สตริง อันที่จริงทำงานเสมือนเป็นรหัสผ่าน โดยผู้ผลิตทั่วไปจะให้คอมมิวนิตี้สตริง ชื่อพับลิก (Public) สำหรับการอ่านได้อย่างเดียว คอมมิวนิตี้สตริง ชื่อไพรเวต (Private) สำหรับการอ่านและเขียน หรือเซตติ้งตั้งค่า เป็นสิ่งที่ดีที่จะเปลี่ยนชื่อคอมมิวนิตี้สตริงที่เป็นดีฟอลต์ให้เป็นชื่อเฉพาะเพื่อเพิ่มระดับความปลอดภัย การสร้างแทรปเพื่อแจ้งผู้ดูแลระบบเครือข่ายเมื่อมีการพยายามเข้ามาตั้งค่า หรือร้องขอข้อมูลจากตัวเอเยนต์ด้วยชื่อคอมมิวนิตี้สตริงที่ไม่ถูกต้อง หรือไม่ตรงกับที่กำหนดก็เป็นสิ่งที่ดี ก็เพราะเป็นการแจ้งเตือนว่าอาจเกิดมีผู้ไม่หวังดีพยายามเข้ามาเจาะระบบเครือข่าย

          เนื่องจากชื่อคอมมิวนิตี้สตริงเสมือนเป็นรหัสผ่านของระบบจัดการเครือข่าย ดังนั้นการตั้งชื่อคอมมิวตี้สตริงก็ควรตั้งตามกฎการตั้งรหัสผ่านของเซิร์ฟเวอร์ เช่น ไม่เป็นคำในพจนานุกรม คำควรมีทั้งตัวเล็กตัวใหญ่รวมทั้งตัวเลข เป็นต้น

รูปที่ 3 SNMP คอมมิวนิตี้

          แต่อย่างไรก็ตามระดับความปลอดภัยด้วยคอมมิวนิตี้สตริงก็ยังต่ำอยู่ เนื่องจากคอมมิวนิตี้สตริงถูกส่งแบบข้อความธรรมดาไม่มีการเข้ารหัส ทำให้ง่ายต่อผู้บุกรุกที่มีความชำนาญสูงสามารถทำการดักจับชื่อคอมมิวนิตี้สตริงได้ และใช้มันเป็นจุดเริ่มต้นในการเจาะเข้าระบบเครือข่าย ดังนั้นจึงได้มีออกข้อกำหนดเพิ่มระดับความปลอดภัยให้สูงขึ้นในมาตรฐาน SNMPv3 แต่อย่างไรก็ตามยังมีวิธีการลดระดับความเสี่ยงต่อการเจาะระบบ ก็คือการติดตั้งไฟล์วอลล์ (Firewall) ซึ่งสามารถกำหนดให้ไฟร์วอลล์อนุญาตเฉพาะโฮสต์ที่รู้จักเข้ามาจัดการระบบเครือข่ายได้เท่านั้น เป็นสิ่งสำคัญที่ต้องตระหนักว่าถ้ามีใครซักคนสามารถอ่านเขียนอุปกรณ์เครือข่ายด้วย SNMP ก็คือสามารถเข้ามาควบคุมระบบเครือข่ายได้ เช่น ปิดพอร์ตเราเตอร์ การเปลี่ยนตารางเราเตอร์ซึ่งทำให้ระบบเครือข่ายล้มเหลวได้ อีกวิธีการหนึ่งในการเพิ่มระดับความปลอดภัย คือการใช้ฟังก์ชัน VPN (Virtual Private Network) เนื่องจากทราฟิกของ VPN จะถูกเข้ารหัสไว้ทำให้ดักจับได้ยาก อีกวิธีการหนึ่งแบบง่าย ๆ คือการเปลี่ยนชื่อคอมมิวนิตี้สตริงอย่างสม่ำเสมอ แต่ก็เป็นการยากสำหรับระบบเครือข่ายขนาดใหญ่ที่จำนวนเมเนเจอร์ และเอเยนต์จำนวนมาก

          ในตอนที่ 2 จะกล่าวถึงโครงสร้าง การตั้งชื่อออบเจ็กต์ รวมทั้งรายละเอียดในแต่ละเวอร์ชันของ SNMP รวมทั้งหลักการวิเคราะห์การทำงานของเฟรม SNMP โปรดติดตามนะครับ

เอกสารอ้างอิง
          1. Subramanian, Mani. Network Management. Addison-Wesley, 2000
          2. Stallings, W. SNMP, SNMPv1, SNMPv3 and RMON 1 and 2. Addison-Wesley, 1999
          3. Douglas Mauro, Kevin Schmidt. Essential SNMP. O’Reilly, 2001
          4. IETF SNMPv3 working group (Web sites)
          5. Andrew Tanenbaum, Computer Networks (fourth edition), Prentice Hall, Upper Saddle River, NJ, 2003, ISBN 0-13-038488-7

 

สงวนลิขสิทธิ์ ตามพระราชบัญญัติลิขสิทธิ์ พ.ศ. 2539 www.thailandindustry.com
Copyright (C) 2009 www.thailandindustry.com All rights reserved.

ขอสงวนสิทธิ์ ข้อมูล เนื้อหา บทความ และรูปภาพ (ในส่วนที่ทำขึ้นเอง) ทั้งหมดที่ปรากฎอยู่ในเว็บไซต์ www.thailandindustry.com ห้ามมิให้บุคคลใด คัดลอก หรือ ทำสำเนา หรือ ดัดแปลง ข้อความหรือบทความใดๆ ของเว็บไซต์ หากผู้ใดละเมิด ไม่ว่าการลอกเลียน หรือนำส่วนหนึ่งส่วนใดของบทความนี้ไปใช้ ดัดแปลง โดยไม่ได้รับอนุญาตเป็นลายลักษณ์อักษร จะถูกดำเนินคดี ตามที่กฏหมายบัญญัติไว้สูงสุด