คลังเก็บผู้เขียน: panya.w

Video สาธิตการใช้งาน UnetLab เบื้องต้น

กลับมาลองทำ Video เป็นทางการอีกครั้งในรอบปีเลยทีเดียว 🙂

วันนี้ขอเสนอการใช้งาน UnetLab แบบคร่าวๆมาให้ดูครับ ต้องบอกก่อนว่า Video นี้ไม่ได้มีรายละเอียดทั้งหมดแต่เป็นการให้ Idea ในการเริ่มใช้งานเท่านั้นนะครับ สำหรับรายละเอียดเดี๋ยวจะทำออกมาให้ดูบางส่วนอีกครั้งนึง

ร่วมร่างไฟล์ให้กลับมาจากแพ็คเก็ตที่ได้จาก Wireshark ^^

กลับมาอีกครั้งหลังจากหายไปหลายอาทิตย์ ^^

รอบนี้กลับมาลองใช้ Wireshark ทำงานในส่วนของ Network forensics กันดูบ้างว่ามันจะเป็นเช่นไร……….

เข้าเรื่องกันเลยดีกว่าวันนี้เราจะขอเสนอฟังก์ชั่น “Export Objects” ซึ่งฟังก์ชั่นนี้จะทำหน้าที่ในการ “สกัด” สิ่งที่อยู่ในรูปแบบของแพ็คเก็ตที่ดูแล้ว “ไม่เข้าใจ” ให้ออกมาเป็นในรูปแบบของไฟล์ หรือ URL เนื่องจากวันนี้เราจะเน้นให้ทำการ “สกัด” เนื้อหาที่อยู่ในรูปแบบของ HTTP โปรโตคอลออกมานั่นเอง

โดยปกติแล้วเมื่อเปิด Wireshark ขึ้นมาและทำการจับข้อมูลที่วิ่งผ่านเข้ามาในเครื่องของเรา สิ่งที่เห็นจะมีรูปแบบในรูปด้านล่างนี้ คือ Source-Destination IP Address, Port, Packet information ซึ่งโดยปกติแล้วเราจะไม่มีทางรู้ได้เลยว่าข้อมูลที่อยู่ภายในนั้นคืออะไร ยกตัวอย่างเช่น URL อะไร หรือรูปที่เปิดขึ้นมาอยู่ที่ URL ไหน?

ยกตัวอย่างการใช้งานในรูปแบบของ Network forensic ในหัวข้อนี้จะลองทำการ “ประกอบร่าง” แพ็คเก็ตที่ได้มาจาก Wireshark ให้กลายเป็นข้อมูลที่สมบูรณ์และย้อนกลับไปได้ว่าไฟล์ที่เปิดขึ้นมาอยู่ที่ URL ใดและลองโหลดไฟล์ที่ได้จากการ “ประกอบร่าง” ลงมาในเครื่องของเราเพื่อทำการตรวจสอบต่อไปได้นั่นเอง

ก่อนที่จะใช้ฟังก์ชั่นนี้ได้อย่างสมบูรณ์เราจะต้องมาการเตรียมการให้เรียบร้อยก่อนตามขั้นตอนดังนี้

  • Protocol IPv4: Enable Reassemble fragmented IPv4 datagrams
  • Protocol TCP: Enable Validate the TCP checksum if possible
  • Protocol TCP: Enable Allow subdissector to reassemble TCP streams
  • Protocol SSL: Enable Reassemble SSL records spanning multiple TCP segments
  • Protocol SSL: Enable Reassemble SSL Aplication Data spanning multiple SSL records

โดยการตั้งค่าทั้งหมดนี้ให้เข้าไปทำที่เมนู Edit Preference… ตามรูปด้านล่างนี้

 

เมื่อทำการตั้งค่าทั้งหมดเสร็จเรียบร้อยแล้วให้เข้าไปที่เมนู File -> Export Objects -> HTTP ก็จะมีหน้าต่างเปิดขึ้นมาใหม่คือ “Wireshark: HTTP object list” โดยในหน้านี้จะแสดงรายละเอียดของสิ่งที่ได้จากการ “ประกอบร่าง” เช่น Hostname ซึ่งก็คือ เวบไซท์ที่เราได้เข้าไป Content Type คือชนิดของไฟล์ที่ได้จากการเข้าไปที่เวบไซท์นั้น Size คือขนาดของไฟล์ที่โหลดขึ้นมา และสุดท้าย Filename คือชื่อของไฟล์ที่โหลดมานั่นเอง

ในตัวอย่างนี้ผมจะทำการเซฟไฟล์ชื่อ “UNL%20diagram.png” ลงมาที่เครื่องโดยการเลือกที่ไฟล์ที่ต้องการและกด “Save As” จากนั้นให้ทำการเลือกตำแหน่งที่ต้องการเซฟลงในเครื่องและทำการตั้งชื่อตามที่ต้องการ หลังจากนั้นให้ทำการเปิดไฟล์ที่ได้จากการเซฟเมื่อสักครู่นี้ขึ้นมา สำหรับผมจะได้ผลจากการเปิดไฟล์ขึ้นมาตามรูปด้านล่างนี้ครับ

สำหรับตัวอย่างการประยุกต์ใช้งานในส่วนของ Network forensics คือการนำไปใช้หาข้อมูลการดาวน์โหลดไฟล์ที่ไม่ได้รับอนุญาตจากทั้งในส่วนของภายในและภายนอกบริษัท หรือในส่วนของตัวอย่างจะเป็นการดาวน์โหลดไฟล์จาก Internet มาซึ่งสามารถระบุได้ถึง Hostname และชื่อไฟล์ซึ่งเป็นหลักฐานที่ดีในระดับนึงเลยทีเดียว

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

หวังว่าคงจะได้แนวคิดในการนำไปประยุกต์ใช้งานกันต่อแล้วนะครับ ขอบคุณทุกท่านที่ติดตามนะคร้าบบบบบ _/|\_

ถ้าอ่านแล้วถูกใจอยากมาลองเรียนเพิ่มเติมกับเราตั้งแต่พื้นฐานจนทำให้ได้ผลลัพธ์ออกมาเป็นรูปร่างได้เหมือนในบทความและยังสามารถนำความรู้ไปต่อยอดได้ ลองมาเรียนกับเราได้โดยดูรายละเอียดได้ ที่นี่ นะครับ ^^

TCP zerowindow กับปัญหาที่เกิดขึ้นใน network

อาทิตย์นี้กลับมาในเรื่องของ WireShark อีกรอบครับ

วันนี้เสนอเรื่อง TCP zerowindow กับปัญหาที่เกิดขึ้นใน network ปัญหาที่เกี่ยวกับเรื่องของ TCP window size ที่เคยเห็นมาจะเป็นเรื่องที่ต้องเกี่ยวกับการรับส่งข้อมูลในปริมาณที่มากในระดับหนึ่งและข้อมูลที่ต้องการจะนำมาใช้มีความต่อเนื่องสม่ำเสมอไม่ขาดตอน ยกตัวอย่าง เช่น Video streaming หรือ Youtube ก็ได้

TCP window size คืออะไร

จากรูปด้านบนจะเห็นได้ว่าก่อนที่มะมีการส่ง Packet หากันระหว่า Client และ Server จะต้องมีการกำหนดขนาดของ Window size กันก่อน โดยจะเป็นการตกลงกันว่าจ Client จะรอรับข้อมูลเป็นปริมาณเท่าไรจึงจะทำการส่ง Packet ACK ให้กับ Server หนึ่งครั้ง การทำงานแบบนี้จะช่วยเพิ่มประสิทธิภาพของ Protocol TCP ได้เนื่องจากไม่ต้องทำการส่ง Packet ACK กลับไปทุกครั้งเมื่อได้รับ Packet เข้ามานั่นเอง

สำหรับอาการเมื่อเกิดขึ้นเมื่อมีปัญหาเกี่ยวกี่ยวกับ TCP zerowindow คือโปรแกรมจะค้าง เนื่องจากจะมีมีการส่ง Packet request ออกไปขอข้อมูลใหม่เข้ามา เมื่อไม่รับข้อมูลเข้ามา Client จะเกิดอาการค้างอยู่ในช่วงระยะเวลาหนึ่ง จนกระทั่ง Windos size จะกลับมาเป็นปรกติ จึงทำให้เกิดอาการ Video สะดุดนั่งเอง 🙂

คราวนี้เราจะมาลองสร้างกราฟเพื่อแสดงค่า TCP zerowindow เพื่อให้เข้าใจการเกิดปัญหาได้ดียิ่งขึ้น ก่อนอื่นก็เปิดโปรแกรมขึ้นมาก่อนตามรูปนี้

ขั้นตอนต่อไปเราจะมาทำการสร้างกราฟโดยใช้เมนู TCP stream graph กันก่อน โดยให้ไปที่เมนู Statistics > TCP StreamGraph > Window Scaling Graph โดยเมื่อ WireShark ทำการสร้างกราฟขึ้นมาจะได้หน้าตามแบบในรูปด้านล่างนี้

จากรูปในส่วนที่มีลูกศรสีแดงชี้ไว้อยู่คือตำแหน่งที่มีขนาดของ TCP windows เป็น 0 ดังนั้นจากรูปก็จะพอสรุปได้ว่า ในช่วงเวลาที่ทำการ Capture packet อยู่นั้นจะเกิดอาการ Video กระตุกอยู่ที่ 4 ครั้ง และการแสดงผลจะเป็นไปในลักษณะทิศทางเดียว คือ จาก Source IP ไปที่ Destination IP โดยสังเกตุได้จากกรอบสีแดงในรูปครับ แต่จะเห็นได้ว่าการใช้ TCP Stream Graph นั้นจะแสดงค่าได้ไม่สวยงามและไม่สามารถทำการขยายหรือปรับแต่งกราฟให้เข้าใจได้ง่ายขึ้นเลย ดังนั้นเราจะใช้เครื่องมือในอีกเมนูนึงคือ IO graph มาเพื่อช่วยให้การแสดงผลมีความยืดหยุ่นมากขึ้น

การใช้ IO graph ให้ไปที่เมนู Statistics > IO Graph ตามรูป

จากนั้นให้ทำการใส่ Filter “tcp.window_size” ลงในช่องที่ 2 และก่อนหน้าที่จะกดปุ่มกราฟให้ทำการปรับค่าเพิ่มอีก 2 ตัวเพื่อให้การแสดงผลมีรายละเอียดมากยิ่งขึ้น คือ ให้แสดงช่วงเวลาที่เราได้ทำการ Capture packet มาแสดงผลในกราฟ โดยให้ทำการเลือก “View as time of day” ตรงที่ลูกศรสีฟ้าชี้อยู่ ส่วนต่อมาให้ทำการปรับ Scale ของกราฟให้เป็นแบบ “Logarithm” โดยประโยชน์ของการใช้ Scale แบบ Logarithm นี้คือ ในกรณีที่ค่าที่ต้องการแสดงผลมีค่าที่ต่างกันมากอาจจะทำให้การแสดงผลขาดรายละเอียดได้ ในกรณีนี้ให้ทำการเลือกการแสดงผลในแกน Y โดยให้ทำการเปลี่ยนค่าตามในกรอบสี่เหลี่ยมสีแดง จากจั้นให้ทำการกดปุ่ม Graph 1 เพื่อเอาค่าข้อมูลของ Graph 1 ออกไปก่อน หลังจากนั้นทำการกดปุ่ม Graph 2 เพื่อทำการแสดงผลของ TCP window scale ที่เกิดขึ้นในในช่วงเวลาที่เราได้ทำการ Capture packet มาวิเคราะห์ โดยจะได้ผลตามรูปด้านล่างนี้

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

หวังว่าจะได้ Idea เพื่อนะไปลองวิเคราะห์ปัญหาที่อาจจะเกิดขึ้นได้บ้างนะครับ 🙂

ถ้าอ่านแล้วถูกใจอยากมาลองเรียนเพิ่มเติมกับเราตั้งแต่พื้นฐานจนทำให้ได้ผลลัพธ์ออกมาเป็นรูปร่างได้เหมือนในบทความและยังสามารถนำความรู้ไปต่อยอดได้ ลองมาเรียนกับเราได้โดยดูรายละเอียดได้ ที่นี่ นะครับ ^^

การหาค่า TCP Delay และนำมาแสดงบน Column ใน WireShark

กลับมาเขียน Blog อีกครั้งในรอบหลายอาทิตย์แล้วครับ วันนี้ขอนำเสนอการใช้งาน WireShark เพื่อแสดงค่า TCP Delay ก็แล้วกันครับ

ปัญหาโลกแตกของคนที่ทำงานสาย Network อย่างหนึ่งที่ทุกคนต้องเจอก็คือคำถามนี้ครับ “ทำไม Network ช้า???” คำถามนี้จะมาจากทั้งฝั่งที่ดูแล Application หรือผู้ใช้งานทั่วไปใน Office ของเรานั่นเอง และคำถามนี้ก็เป็นปัญหาที่น่าหนักใจสำหรับคนที่ทำงาน Network อย่างเราๆเสมอมา เพราะการที่จะยืนยันได้ว่า Network หรืออะไรก็แล้วแต่ที่เกี่ยวข้องทั้งปัจจัยภายในและภายนอกในการหาต้นตอของปัญหาทาง Network หรือทุกปัญหาก็คือการหาหลักฐานว่าปัญหาเกิดจากอะไรนั่นก็คือ “หลักฐาน” นั่นเอง เมื่อไม่มีหลักฐานไปแสดงก็จะไม่มีทางรู้ได้เลยว่าปัญหาที่เกิดขึ้นนั้นมาจากอะไร และเมื่อขาดหลักฐานก็จะนำไปสู่การแก้ปัญหาที่ไม่ถูกจุดต่อไปนั่นเอง

เมื่อปัญหาเกี่ยวกับ Network ช้าและคนทำ Network ตกเป็นจำเลยของ Office ดังนั้นเราจะมาหาหลักฐานกันว่าสิ่งที่เขาบอกว่านั้นมันช้าจริงหรือเปล่า เมื่อพูดถึงการสื่อการบน Network แล้ว Protocol หนึ่งที่เรามีการใช้งานเป็นส่วนใหญ่จะเกี่ยวข้องกับโปรโตคอล TCP ดังนั้นในบทความนี้เราจะเสนอแนะวิธีการให้ WireShark แสดงผลของค่า TCP delay ออกมาเป็น Column หนึ่งการการแสดงผลเพื่อที่เราจะได้ทำการ Sort หาค่า Delay ที่เกิดจากโปรโตคอล TCP และนำมาหาความสัมพันธ์และอาจจะนำมาใช้วิเคราะห์และเป็นหลักฐานในการแก้ปัญหาต่อไปได้สะดวกขึ้น

ก่อนอื่นก็มาดูการทำงานของโปรโตคอล TCP แบบง่ายๆกันก่อน เริ่มจากช่วงแรกก่อนที่จะมีการเริ่มส่งข้อมมูลระหว่าง Client-Server นั้นจะต้องการเปิด Connection เพื่อทำการตกลงในการส่งข้อมูลกันก่อนนั่นคือ 3 ways handshaking กันก่อน คือ ช่วงสาม Packet แรกในรูปคือส่ง Packet Sync, Sync Ack, Ack ก่อนที่จะทำการ Established connection เพื่อทำการส่งข้อมูลกัน และเมื่อทำการ Established connection กันเรียบร้อยแล้วระหว่าง Client-Server จะเริ่มมีการส่งข้อมูลระหว่างกัน เมื่อมีการส่งข้อมูลกันจะเกิดเวลาช่วงหนึ่งระหว่างข้อมูล Packet แรกที่ส่งออกไปและมีการส่ง Packet ที่สองตามออกไป เวลาที่เกิดขึ้นในช่วงนี้คือ Delta “T” หรือระยะเวลาที่ Packet ที่สองห่างจาก Packet เป็นระยะเวลาเท่าไรนั่นก็คือค่า TCP delay ที่เกิดขึ้นนั่นเอง

 

ก่อนอื่นเลยให้ทำการ Capture packet และเปิดขึ้นมาโดยโปรแกรม WireShark แล้วไปที่ Column protocol จากนั้นหา TCP และทำการเลือกขึ้นมาหนึ่ง Packet จากนั้นเข้าไปที่ Packet detail pane และทำการเลือก “Transmission Control Protocol” ตามตัวเลข “1” จากนั้นเลือก “Protocol preferences” ตามหมายเลขที่ “2” และสุดท้ายเลือก “Calculate conversation timestamps” ตามหมายเลข “3”

เมื่อทำตามขั้นตอนชุดแรกนี้แล้วในช่องของ Packet detail pane จะมีค่า “Timestamps” ขึ้นมาตามตัวเลขที่ “4” จากนั้นให้ทำการขยายช่องของ “Timestamps” ออกมาจะเจอ “Time since previous frame in this TCP stream” ตามหมายเลขที่ “5” ให้ทำการคลิกขวาและเลือก “Apply as column” ตามหมายเลข “6”

จากนั้นเราจะได้ Column ใหม่ขึ้นมาให้ทำการ Rename เป็น Delta Time หรือชื่ออื่นที่ต้องการ เมื่อทำการสังเกตค่าที่แสดงผลใน Column นี้เราก็จะพบค่าเวลาที่แตกต่างกันไปตามรูปดังนี้

 

และจากข้อมูลตัวเลขที่แสดงออกมาจะทำให้เราเห็นว่าค่า Delay ที่เกิดจาก Packet ก่อนหน้านี้แสดงออกมามีค่าสูงบ้างต่ำบ้าง เช่น 0.000xxxxxx และ 15.00xxxxxxx ซึ่งแสดงว่าโดยปกติแล้วค่าการ Delay ที่เกิดขึ้นระหว่าง Client-Server อยู่ในระดับที่ปกติคือมีค่า Delay 0.000000000 เป็นส่วนใหญ่แต่จะมีค่า 15.00xxxxxxx อยู่เป็นระยะ ซึ่งเราก็จะสามารถนำค่า Delay ที่มีค่าสูงนี้ไปหาความสัมพันธ์เพื่อวิเคราะห์ปัญหาต่อไปได้นั่นเองครับ และนี่ก็คือตัวอย่างหนึ่งในการหาหลักฐานว่า Network ที่เราดูแลอยู่นั้น “ช้า” จริงหรือไม่อย่างหนึ่งนั่นเอง

ถ้าอ่านแล้วถูกใจอยากมาลองเรียนเพิ่มเติมกับเราตั้งแต่พื้นฐานจนทำให้ได้ผลลัพธ์ออกมาเป็นรูปร่างได้เหมือนในบทความและยังสามารถนำความรู้ไปต่อยอดได้ ลองมาเรียนกับเราได้โดยดูรายละเอียดได้ ที่นี่ นะครับ ^^

ทำความรู้จักกับ Mininet

กลับมาเข้าเรื่อง SDN กันอีกครั้ง ^^

คราวนี้เราจะมาทำความรุ้จักกับ Mininet กัน คำถามที่เกิดขึ้นแน่ๆในใจของหลายๆคนน่าจะมีดังต่อไปนี้

  • Mininet คืออะไร?
  • Mininet เอาไว้ทำอะไร?
  • Mininet เกี่ยวกับ SDN ยังไง?

ขอสรุปกันแบบบ้านๆประมาณนี้ก็แล้วกันครับ

  • Mininet คือ Network emulator ซึ่งจะทำการจำลองการสร้าง Switch, Host, Controller และ Link ที่ทำการเชื่อมโยงระหว่างอุปกรณ์ที่เราสร้างขึ้นมา โดย Host ที่ Mininet สร้างขึ้นมาจะเป็น Linux host ส่วน Switch ที่ Mininet สร้างขึ้นมาจะรองรับการใช้งาน OpenFlow ดังนั้นมันจึงสามารถรองรับการทำ Customize routing และ SDN ได้นั่นเอง
  • Mininet มีจุดประสงค์ในการนำมาใช้งานในลักษณะต่างๆดังนี้ งานวิจัย การพัฒนา การใช้ประกอบการเรียนการสอน การทดสอบ นำมาใช้ในการ Debugging เพื่อทดสอบระบบ Network บน PC หรือ Laptop ที่เราใช้งาน โดย Mininet สามารถยกตัวอย่างการนำไปใช้งานในหัวข้อต่างๆได้ดังนี้
    • ใช้ในการสร้าง Network ตัวอย่างเพื่อพัฒนาโปรแกรมกับ OpenFlow
    • ทำ System-level regression test
    • ทำการสร้าง Topology ที่มีความซับซ้อนสูงโดยไม่ต้องทำการ Wire สายเนื่องจาก Mininet ทำงานในลักษณะ Virtualizes
    • Code ที่ทำการทดสอบบน Mininet เพื่อใชงานกับ OpenFlow สามารถนำไปใช้งานจริงได้โดยอาจจะมีการแก้ไขเพียงเล็กน้อยเท่านั้น นั่นหมายความว่าเมื่อใดก็ตามที่การทดสอบบน Mininet สามารถใช้งานได้ก็สามารถนำไปใช้งานกับ Hardware จริงได้เช่นเดียวกัน เพื่อทำการทดสอบในลักษณะของ Line-rate forwarding ต่อไปได้ทันที
  • Mininet เกี่ยวกับ SDN โดย Mininet จะเป็นตัวสร้าง Network จำลองขึ้นมาเพื่อใช้ในการทดสอบ SDN application โดยข้อดีของ Mininet คือสามารถจำลองระบบ Network ขนาดใหญ่ขึ้นมาได้จาก Linux host หรือ VM guest เพียงเครื่องเดียว โดยสามารถทำการ Boot อุปกรณ์ขึ้นมาจำลองการทำงานได้ถึง 4096 อุปกรณ์ โดยมีทั้ง Host และ Switch ตั้งแต่ Version 2.2.26

Mininet สามารถทำงานร่วมกับ Controller ที่มีการใช้งาน OpenFlow ได้เป็นอย่างดี โดย Topology ที่สร้างขึ้นมาจาก Mininet สามารถทำการ Discovery ได้จาก SDN controller ทั้งในส่วนของ Host และ Switch สำหรับการใช้งาน Mininet ร่วมกับ Controller จะมีการนำเสนอในบทความส่วนต่อไปครับ

สำหรับรูป Topology ด้านล่างนี้เป็นตัวอย่าง Topology ที่สร้างจาก Mininet และทำการ Discovery บน OpenDayLight ครับ

 

สำหรับท่านที่ต้องการ Download Mininet มาเพื่อลองใช้งานสามารถไปที่ http://mininet.org/download/ เพื่อนำมาลองใช้งานได้ โดยมีให้เลือกใช้งานทั้งแบบ VM หรือจะทำการติดตั้งเองลงบน Linux host ก็ได้เช่นเดียวกันครับ

เข้าใจการทำงาน bridge network บน UnetLab

กลับมาอีกครั้งกับการขุด UnetLab แบบที่ชาวบ้านไม่สนใจ แต่เราชอบเพราะเราอินดี้ 😛

ก่อนหน้านี้เคยเขียนเรื่อง pnet ไปแล้วดังนั้นรอบนี้ก็เลยถึงคิวของ Bridge network ซึ่งเป็น Network type พื้นฐานที่ทุกคนจะสร้างขึ้นมาเพื่อใช้เชื่อมต่อระหว่างอุปกรณ์ ต่างๆใน Lab

แต่หลายคนอาจจะไม่รู้ว่าอุปกรณ์มันเชื่อมต่อหากันได้ยังไง ให้ลองคิดง่ายๆว่า Bridge เป็น Switch ที่มีแค่ 2 Interface (เพื่อให้เข้าใจง่ายๆ) ดังนั้นเมื่อเราต้องการเชื่อมต่ออุปกรณ์ 2 ตัวเข้าหากันเราก็จะทำการเชื่อมต่อมันเข้าหากันด้วย Bridge นั่นเอง ถ้านึกไม่ออกลองดูรูปข้างล่างนี้เป็นตัวอย่างประกอบไปก่อนครับ

 

 

ต่อมาเราก็มโนต่อว่าอุปกรณ์พวกนี้เมื่อไปอยู่ใน UnetLab มันจะมีหน้าตาหรือชื่อยังไงกัน? ให้ลองดูรูปด้านล่างก่อนนะครับ

จะเห็นว่าเมื่อเข้าไปอยู่ใน UnetLab แล้ว Bridge จะมีชื่อเป็น vnet0_1 และต่อมา E0/0 ของ R1 จะเปลี่ยนเป็น vunl0_1_0 และ E0/0 ของ R2 จะเปลี่ยนเป็น vunl0_2_0 ทั้งหมดนี้จะเป็นชื่อเพื่ออ้างอิงการเชื่อมต่อในระดับ OS เท่านั้น ส่วนในระดับ Application ของ UnetLab จะยังมีชื่อในการอ้างอิงเป็น E0/0 เหมือนเดิม

ต่อมาในเมื่อเราทำการเชื่อมต่ออุปกรณ์เข้าหากันด้วย Bridge network เพียงแค่ Object เดียวดังนั้นในกรณีนี้ผมจะสมมุติให้ Bridge network มีค่าเท่ากับสาย LAN หนึ่งเส้นก็ได้ใช่หรือไม่?? ดังนั้นในเมื่อผมมองว่า Bridge network คือสาย LAN หนึ่งเส้นดังนั้นผมก็จะได้ Diagram ใหม่ตามรูปด้านล่างนี้ครับ

ต่อมาหลายๆคน (อาจจะทุกคน) ก็อาจจะสตั้นนนนน!!! ว่าไอ้ชื่อ vnet0_1 หรือ vnul0_1_0 นี่มันคืออะไรกันแน่ ก็เลยจะขออธิบายดังนี้ครับ

สำหรับ vnet0_1 คือ

  • vnet คือ Bridge network
  • 0      คือ Reference Object ID  ของ User admin หรือ POD 0 ในกรณีที่ Login และ Start Lab ด้วย User admin กรณีที่ Start Lab ด้วย User อื่นตัวเลขก็จะเปลี่ยนไปตาม User
  • 1       คือ Reference Object ID ของ Bridge network ในกรณีนี้คือ Object ที่ 1

ต่อมา vunl0_1_0 อธิบายจากซ้ายไปขวา

  • vunl คือ อุปกรณ์เสมือนที่อยู่ใน UnetLab
  • 0      คือ Reference Object ID  ของ User admin หรือ POD 0 ในกรณีที่ Login และ Start Lab ด้วย User admin กรณีที่ Start Lab ด้วย User อื่นตัวเลขก็จะเปลี่ยนไปตาม User
  • 1       คือ Reference Device ID ของอุปกรณ์เสมือนที่อยู่ใน UnetLab ในกรณีนี้คือ Device ID ที่ 1
  • 0      คือ Interface Index ของอุปกรณ์เสมือนที่อยู่ใน UnetLab ซึ่ง UnetLab จะสร้างขึ้นมาให้เอง

ต่อมาผมจะมีตัวอย่าง Lab ที่สร้างขึ้นใน UnetLab ตามรูปนี้ขึ้นมา

ต่อมาก็ลองเข้าไปเช็ค Device ID ตามในรูปด้านล่างนี้

จากรูปก็จะเห็นว่ามี ID: 1, 2 แน่นอนแล้ว ทีนี้เราจะรู้ได้ยังไงว่าอุปกรณ์ในรูปมีการเชื่อมต่อด้วย Bridge network ที่ระดับ OS ได้ถูกต้องแล้วหรือยัง? กรณีนี้เราก็มี Command มาช่วยตรวยสอบเนื่องจากเป็นการเชื่อมต่อใน OS level จึงต้องใช้ Command ที่เกี่ยวกับ Network ของ Ubuntu มาช่วยนั่นคือ “brctl show” และเมื่อใช้ Command นี้ไปแล้วก็จะได้ผลออกมาตามรูปครับ

จากรูปเราก็จะเห็นว่า UnetLab มีการสร้าง Bridge network ขึ้นมา 2 ตัวคือ vnet0_1 และ vnet0_2 โดยที่ vnet0_1 มี vunl0_1_0 และ vunl0_2_0 เชื่อมต่อยู่ (ให้ย้อนกลับไปดูรูปด้านบนด้วยนะครับจะได้เข้าใจมากขึ้น) ส่วนนี้ก็คือเส้นสีดำที่เชื่อต่อ Interface E0/0 ของ R1 และ R2 เข้าด้วยกันนั่นเอง ส่วนที่เหลือก็ตามรูปเลยไม่น่าจะยากแล้ว

ต่อมาอาจจะสงสัยทำไม UnetLab ต้องสร้าง Bridge network ลงมาที่ OS level ด้วย คำตอบง่ายๆเลย Interface ที่สร้างขึ้นมาที่ OS level จะสามารถนำมาใช้งานกับ TCPdump ได้นั่นเอง ดังนั้นการสร้าง Virtual interface ขึ้นมาที่ OS level นั้นก็เพื่อให่สามารถใช้งาน Packet capture ร่วมกับ WireShark ได้นั่นเองงงงงง

สำหรับวันนี้ก็ขอจบหัวข้อ Bridge network ใน UnetLab เอาไว้เท่านี้ ขอบคุณที่ติดตามคร้าบบบบบ _/|\_

 

[GNS3Vault] SNMPv2 Server

SNMPv2 Server

Scenario:
The Agency has created a new security policy and since you are part of the security team you need to help them implement them. Some changes on the network have to be implemented through SNMPv2 and it’s up to you to configure your router as a SNMPv2 agent.

สถานะการณ์จำลอง:

ทีม Security ได้สร้าง Rule ขึ้นมาใหม่โดยที่คุณก็เป็นส่วนหนึ่งของทีม Security คุณต้องการช่วยทีมในการ Implement rule มีการเปลี่ยนแปลงบางอย่างบน Network คือการนำ SNMPv2 มาใช้งานและเป็นหน้าที่ของคุณที่จะต้องทำการ Configure SNMPv2 บน Router

Goal:

  • All IP addresses have been preconfigured for you.
  • Optional: You can use the cloud interface to connect your router to a free syslog server like Kiwi Syslog Server (also works for SNMPv2).
  • Configure router Agent so it uses community string “VAULT”.
  • Configure router Agent so the SNMP contact is “007”.
  • Configure router Agent so the SNMP location is “Agency”.
  • Configure router Agent so the largest SNMP packet is 1500.
  • Configure router Agent so the router can be reloaded through SNMP.
  • Configure router Agent so only network 192.168.12.0 /24 is allowed to contact the router. Dropped packets should be logged.
  • Configure router Agent so it has a community string called “README”. This should only be used for read-only access.
  • Configure router Agent to traps are sent to SNMPv2 server IP address 192.168.12.2. Use community string “VAULT”.
  • Configure router Agent so it informs a device with IP address 192.168.12.3. Use community string “VAULT”.
  • Create a loopback0 interface on router Agent with IP address 1.1.1.1 /24.
  • Configure router Agent so it doesn’t send any traps or informs when something happens with the loopback0 interface.
  • Configure router Agent so it generates a trap when a new OSPF LSA is originated.

เป้าหมาย:

  • IP address ทั้งหมดได้ทำการตั้งค่าไว้ให้หมดแล้ว
  • ออปชั่น: คุณสามารถใช้ Cloud interface เชื่อต่อกับ Router ของคุณเข้ากับฟรี Syslog server เช่น Wiwi syslog server (มันรองรับ SNMPv2 เช่นเดียวกัน)
  • ตั้งค่าให้ Router agent ใช้ Community string เป็น “VAULT”
  • ตั้งค่าให้ Router agent ใช้ Community location เป็น “007”
  • ตั้งค่าให้ Router agent ใช้ขนาดของ SNMP packet ที่มีขนาดใหญ่ที่สุดคือ 1500
  • ตั้งค่าให้ Router agent อนุญาตให้เฉพาะ Network  192.168.12.0 /24 เชื่อมต่อเข้ามาที่ Server โดย Drop packet จะต้องถูก Log
  • ตั้งค่าให้ Router agent ใช้ Community string เป็น “REAQDME” เป็นการใช้งานแบบอ่านค่าอย่างเดียว
  • ตั้งค่าให้ Router agent ส่งค่า Trap ไปที่ SNMPv3 server IP address 192.168.12.3 โดยใช้ Community string “VAULT”
  • ตั้งค่าให้ Router agent แจ้งไปที่อุปกรณ์ IP address 192.168.12.3 โดยใช้ Community string “VAULT”
  • สร้าง Interface loopback0 บน Router โดยใช้ IP address 1.1.1.1/24
  • ตั้งค่าให้ Router agent ตั้งค่าไม่ให้มีการส่ง Trap ใดๆก็ตามออกไปในกรณีที่มีบางอย่างเกิดขึ้นกับ Interface loopback0
  • ตั้งค่าให้ Router agent ส่งค่า Trap ออกไปเมื่อมี OSPF LSA ใหม่เกิดขึ้น

IOS:
c3640-jk9s-mz.124-16.bin

Topology:

 

 

ปล. เรื่องนี้ Rene ยังไม่ได้ทำ Video แต่การ Configure แนวๆนี้เคยเห็นในข้อสอบ CCIE R&S ด้วยนะ 🙂

รู้จักกับ OpenFlow

OpenFlow

OpenFlow คืออะไร?

OpenFow คือ มาตรฐานเปิดที่อนุญาตให้ผู้ใช้งานสามารถนำโปรโตคอลที่สร้างขึ้นเองนำมาใช้งานได้ในระบบเน็ทเวิร์คที่มีการใช้งานในปัจจุบันได้ โดยที่ OpenFlow จะทำงานคล้ายๆกับการเพิ่ม Feature เข้าไปที่อุปกรณ์ switch, router หรือ wireless access point โดยที่ไม่ต้องการให้เจ้าของผลิตภัณฑ์ทำการเปิดเผยขั้นตอนการทำงานภายในของอุปกรณ์ ในปัจจุบัน OpenFlow ได้มีการนำไปใช้งานกับอุปกรณ์เจ้าหลักๆ โดยจำหน่ายอยู่ในรูปแบบของ switch ที่มีการรองรับการทำงานของ OpenFlow

OpenFlow ทำงานอย่างไร

ในอุปกรณ์ router หรือ switch แบบเก่า fast packet forwarding (data plane) และส่วนที่ทำหน้าในการจัดการ routing protocol (control plane) จะอยู่บนอุปกรณ์เดียวกัน การทำงานของ OpenFlow จะทำการแยกทั้งสองส่วนนี้ออกจากกัน โดย data plane จะยังคงทำงานอยู่บนอุปกรณ์เดิมส่วนที่เป็น control plane (software) ที่ทำหน้าที่ในการตัดสินใจเลือกเส้นทางหรือ routing protocol จะถูกแยกไปอยู่บน controller โดยที่อาจจะเป็นเครื่อง server ทั่วๆไปก็ได้ โดยที่ OpenFlow switch และ OpenFlow controller จะทำการติดต่อกันด้วย OpenFlow protocol ด้วย message ที่กำหนดไว้ เช่น การรับและส่ง packet การเปลี่ยนแปลง forwarding table หรือการอ่านค่าสถานะของอุปกรณ์
Data plane ของ OpenFlow switch จะอยู่ในรูปแบบของ clean flow table abstraction โดยที่ในแต่ละตำแหน่งของ Flow table จะประกอบไปด้วยกลุ่มของ packet ที่มีการระบุการทำงานเอาไว้ด้วย เช่น ให้ส่งออกไปที่ interface ไหน มีการ modify field ใดบ้าง หรือให้ทำการ drop packet ทิ้ง กรณีเมื่อ OpenFlow switch ได้รับ packet เข้ามาและยังไม่เคยอยู่ใน Flow table มันจะถูกส่งไปที่ controller เพื่อให้ controller ทำการตัดสินใจว่าจะจัดการกับ packet ที่ได้รับมานี้อย่างไร โดยมันจะสามารถทำการ drop หรือนำไปใส่ไว้ที่ Flow table และกำหนดการทำงานให้กับ OpenFlow switch ว่าจะต้องส่ง packet นี้ออกไปในทิศทางใดในกรณีที่มีการพบ packet แบบนี้อีกในอนาคต

เราจะทำไรกับ OpenFlow ได้บ้าง

OpenFlow อนุญาตให้ผู้ใช้งานสามารถสร้าง routing และ switching protocol ขึ้นมาใหม่และนำไปใช้งานได้ง่าย โดยมันจะถูกนำไปใช้งานในรูปแบบของ application ในรูปแบบต่างๆ เช่น virtual machine mobility หรือระบบ network ที่มีความปลอดภัยสูง และ mobile network ในยุคถัดไป

 

แปลและเรียบเรียงเนื้อหาจาก

Ref: http://archive.openflow.org/wp/learnmore/

[GNS3Vault] Access-List Logging

Original post from GNS3Vault: http://gns3vault.com/network-management/access-list-logging/

Scenario:
The local boyscout needs your help as a network engineer. They want to make sure everytime their router receives an OSPF packet this will be logged on their local router. Think you can help them out?

สถานะการณ์จำลอง:

เจ้าหน้าที่ NOC ต้องการความช่วยเหลือจาก Network engineer อย่างคุณ พวกเข้ต้องการแน่ใจว่าทุกๆครั้งที่ Router ของเขารับ OSPF packet เข้ามามันจะถูก Log อยู่บน Router ของเขา คุณคิดว่าจะช่วยพวกเขาได้ไหม?

Goal:

  • All IP addresses have been preconfigured for you.
  • OSPF has been configured for you.
  • Configure router Scout so every OSPF packet that is received on the interface will be logged. Use an access-list for this.
  • Your log file should be updated every 4 packets.
  • Make sure you log the MAC address of the device sending the OSPF packet.

เป้าหมาย:

  • IP address ทั้งหมดถูกตั้งค่าไว้ให้แล้ว
  • OSPF ถูกตั้งค่าไว้ให้แล้ว
  • ทำการตั้งค่า Router Scout เพื่อให้ทุกๆ OSPF packet ที่รับเข้ามาบน Interface ถูก Log ลงบน Router โดยอนุญาตให้ใช้ access-list เท่านั้น
  • ไฟล์ Log จะต้องทำการ Update ทุกๆ 4 packet
  • คุณต้องแน่ใจว่าทำการ Log MAC address ของอุปกรณ์ที่ส่ง OSPF packet มาให้ด้วย

IOS:
c3640-jk9o3s-mz.124-16.bin

Topology:

Video Solution:

หมายเหตุ:

สำหรับ Configuration file ต้องทำการสมัครสมาชิกของเวบ GNS3Vault ก่อนจึงจะสามารถทำการโหลดมาใช้งานได้ครับ

[GNS3Vault] Conditional Debug

Original post from GNS3Vault: http://gns3vault.com/network-management/conditional-debug/

Conditional Debug

Scenario:

Frank has heard about a feature called “conditional debug” that sounds interesting to him. It seems that you can use this command to only show the output of certain protocols instead of having your screen flooded with debug information. Think you can teach a fellow network engineer this feature?

สถานะการณ์จำลอง:

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

Goal:

  • All IP addresses have been preconfigured for you.
  • OSPF and RIP have been preconfigured to generate some traffic.
  • Enable a debug on router Frank which only shows RIP information on the FastEthernet0/0 interface. You are not allowed to use any access-lists.

เป้าหมาย:

  • ไอพีแอดเดรสทั้งหมดได้ตั้งค่าไว้ให้คุณเรียบร้อยแล้ว
  • OSPF และ RIP ได้ตั้งค่าไว้ให้แล้วเพื่อสร้างทราฟฟิกจำนวนหนึ่ง
  • เปิด debug บนเราท์เตอร์ Frank เพื่อแสดงข้อมูลเฉพาะในส่วนของ RIP บนอินเตอร์เฟส FastEthernet0/0 โดยคุณไม่ได้รับอนุญาตให้ใช้ access-list ในหัวข้อนี้

IOS:

c3640-jk9o3s-mz.124-16.bin

Topology:

Video Solution: