หลังจากเขียนเรื่องเกี่ยวกับ Wireshark มาระยะหนึ่งแล้วหลายๆท่านก็น่าจะได้แนวคิดในการใช้งานโปรแกรมนี้กันมากขึ้นกันแล้ว วันนี้ผมขอเสนอการเอาโปรแกรม Wireshark มาใช้วิเคราะห์ความผิดปกติของ Application ที่เกิดขึ้นโดยใช้งาน Feature IO graph เพื่อแสดงให้เห็นการทำงานที่ผิดปกติได้ชัดเจนและเป็นรูปธรมมมากขึ้น
วันนี้จะขอสมมติเหตการณ์ที่เกิดขึ้นใน Office แห่งหนึ่งซึ่งมีปัญหาการใช้งาน Application server ดังนี้
จากการตรวจสอบปัญหาของโปรแกรมเมอร์ที่เขียนโปรแกรม App 1 ที่ติดตั้งลงใน Application server 1 และ 2 รายงานว่าโปรแกรมไม่มีความผิดปกติใดๆ คาดว่าการที่ App 1 บน Application server 2 ใช้งานไม่ได้นั้นน่าจะเกิดจากการที่ ผู้ดูแลระบบ Network มีการทำ QoS ทำให้เมื่อมีการใช้เข้าใช้งาน Network ในช่วงเช้าที่มีปริมาณข้อมูลจำนวนมากทำให้ App 1 บน Application server 2 มีปัญหา
จากรายงานของโปรแกรมเมอร์ที่ได้ส่งไปให้หัวหน้าทีม Network ทำให้ Network engineer ทำการหาสาเหตุของปัญหาที่เกิดขึ้นโดยใช้โปรแกรม Wireshark เพื่อหาสาเหตุที่แท้จริงมารายงานต่อไป
ตอนนี้เราจะใช้ข้อมูลจากบทความตอนที่แล้วนำมาแยกเป็นชุดการสื่อสารแบบ Client-server มาแยกเป็นชุดไว้จะทำให้ได้ชุด Filter string ดังต่อไปนี้
แต่ก่อนที่จะทำการแยกแยะการใช้งานเป็นแบบ Client-server ให้ลองทำการพิจารณาภาพรวมการใช้งานระบบ Network ก่อนโดยใช้ Feature IO graph จะได้ผลดังนี้
ต่อมาลองดูภาพรวมของการเชื่อมต่อไปที่ Application server 2 จากเครื่อง Front end จะได้ดังนี้ (Filter string: ip.addr==172.16.4.115 && ip.addr==192.168.1.2)
จากกราฟภาพรวมของระบบ Network ในรูปแรกและการเชื่อมต่อไปที่ Application server 2 ไม่พบการทำงานของการทำงานของ QoS ซึ่ง Throughput จะต้องมีลักษณะราบเรียบลงในส่วนที่ QoS ทำงานอยู่
ต่อมาลองพิจารณาการทำงานของ App 1 และ App 2 ที่อยู่ที่เครื่อง Application server 2 โดยใช้ Filter string ดังนี้
จากกราฟที่ได้จะพบว่าที่เครื่อง Application server 2 จะมีความผิดปกติที่ App 1 เท่านั้นซึ่งตรงกับที่ User A, C รายงาน
ต่อมาให้ทำการเปรียบเทียบการทำงานของ App 1 และ App 2 ที่ติดตั้งลงบนเครื่อง Application server 2 จะได้ผลดังนี้
จะเห็นได้อย่างชัดเจนว่า App 1 บน Application server 2 มีปัญหาเกิดขึ้นเพียง App เดียวจริง
เพื่อความแน่ใจลองตรวจสอบการทำงานของ App 1 ที่เครื่อง Application server 1 เพื่อลองหาความผิดปกติที่อาจจะเกิดขึ้้นด้วย Filter string: ip.addr==172.16.4.115 && ip.addr==192.168.1.9 && tcp.port==2074 จะได้ผลดังนี้
จากผลที่ได้จะตรงกับที่ User B รายงานว่าสามารถใช้งาน App 1 บนเครื่อง Application server 1 ได้อย่างปกติ
ต่อมาลองทำการเปรียบเทียบค่า Throughput ของ App 1 บน Application server 1 และ Application server 2 เพื่อหาความแตกต่างว่าถ้า QoS เป็นต้นเหตุของปัญหาค่า Throughput ของทั้ง 2 server ควรจะมีค่าที่ต่างกันมากจนทำให้ QoS ทำงานจนตัด Connection ของ Application server 2
จากกกราฟที่ได้แสดงให้เห็นว่า Throughput ของ App 1 บน Application server 1 และ Application server 2 มีค่าใกล้เคียงกันมากในช่วงเข้าจนกระทั่งช่วงเวลาประมาณ 9.30น. App 1 บน Application server 2 จึงเกิดปัญหาไม่สามารถใช้งานได้ และหลังจากที่ App 1 กลับมาใช้งานได้ค่า Throughput ของ App 1 ก็ยังมีค่าใกล้เคียงกันทั้ง 2 server (มีค่าต่างกันบ้างอาจจะเกี่ยวกับการดึงข้อมูล) ดังนั้นการที่กล่าวว่า QoS เป็นสาเหตุของปัญหาที่เกิดขึ้นจึงเป็นเรื่องที่ไม่เป็นความจริงและไม่มีหลักฐานใดที่ระบุได้ว่าระบบ Network มีปัญหาในช่วงเวลาดังกล่าว
และเมื่ออพิจารณาจากภาพรวมที่ได้จากระบบ Network ทั้งหมดจะเห็นได้อย่างชัดเจนว่าปัญหาที่เกิดขึ้นนั้นน่าจะเกิดจาก App 1 ที่มีการใช้งานระหว่างเครื่อง Frontend (172.16.4.115) และ Backend (192.168.1.2) มากกว่าจะมาจากระบบ Network
ผมหวังว่าบทความนี้น่าจะเป็นตัวอย่างการนำโปรแกรม Wireshark ไปประยุกต์ใช้งานให้กับหลายๆท่านได้ต่อไปนะครับ
ถ้าอ่านแล้วถูกใจอยากมาลองเรียนเพิ่มเติมกับเราตั้งแต่พื้นฐานจนทำให้ได้ผลลัพธ์ออกมาเป็นรูปร่างได้เหมือนในบทความและยังสามารถนำความรู้ไปต่อยอดได้ ลองมาเรียนกับเราได้โดยดูรายละเอียดได้ ที่นี่ นะครับ ^^
กลับมาเขียนบทความลง Blog อีกครั้งหลังจากมีกิจกรรมใหม่ๆอีกครั้งครับ
รอบนี้เป็นบทความที่ค้างไว้จากที่ได้แจ้งไว้ที่หน้า FaceBook page และเป็นเรื่องที่หลายๆคนที่มีเรียน UnetLab แล้วยังมึนๆอยู่ นั่นคือเรื่องของการทำ Initial configure (Exported CFG) ของอุปกรณ์นั่นเอง
ก่อนอื่นก็ต้องขอเกริ่นกันก่อนว่า Initial configure ที่ว่านี้คืออะไรกันก่อน ลองนึกดูว่าในการทำ Lab ของแต่ละคนจะต้องทำอะไรก่อนเป็นขั้นตอนแรกหลังจากเปิดอุปกรณ์อย่าง Router ขึ้นมา? สิ่งที่หลายๆคนจะทำก็คือการตั้งค่า Hostname และการกำหนด IP address ให้กับ Interface ต่างๆของอุปกรณ์ที่ได้ออกแบบมาไว้แล้วจาก Diagram ที่เราวาดไว้ในกระดาษหรือโปรแกรมก่อนหน้านี้ (ไม่รวมการต่อสายต่างๆนะ) ซึ่งเมื่อทำขั้นตอนนี้เสร็จแล้วส่วนมากเราจะทำการ Save configuration ชุดนี้ไว้ก่อนที่จะเริ่มลงมือทำการทดลอง Lab กันต่อไป ซึ่งขั้นตอนนี้นี้ผมจะขอเรียกว่าการทำ Initial configure ของ UnetLab นั้นเอง
คำถามต่อมาทำไมเราจะต้องมาทำ Initial configure ด้วยล่ะ? ในเมื่อเวลาที่เราทำ Lab ไปแล้วเราก็ลงมือทำต่อไปเรื่อยๆได้อยู่แล้ว ไม่เห็นว่าจะมีความจำเป็นอะไรเลย? ลองย้อนกลับไปที่การทำ Lab ด้วยการใช้อุปกรณ์จริงกันก่อนละกัน ผมจะมีคำถามว่าถ้าเรา Configure อุปกรณ์ผิดไปแล้วหาจุดที่เราทำผิดไม่ได้และทำให้ต้องเริ่ม Configure อุปกรณ์ใหม่ตั้งแต่ต้นอีกครั้งหรือไม่? น่าจะเคยกันมาบ้างสำหรับคนที่ต้องการทำ Lab บ่อยๆ กรณีนี้หลายๆคนก็จะบอกว่าทำผิดก็อย่าเพิ่งไป Save configure ที่ไว้ไว้สิ พอเปิดปิดอุปกรณ์ใหม่มันก็มาเริ่มจุดที่ทำ Save ไว้ วิธีการแบบนี้ก็เป็นที่มาของการใช้งาน Initial configure แบบ Classic แบบนึงครับ แต่ที่มันเหนือกว่านั้นคือใน UnetLab สามารถทำการดึงเอา Initial configure ที่เก็บไว้นำมา Apply กลับเป็น Initial configure ที่ต้องการหลังจากที่เราได้ Save configuration ด้วย Command เช่น Write men หรือ Commit ทับ Initial configure ที่ใช้อยู่ไปแล้วไม่ว่าจะมีการ Save ทับไปแล้วกี่รอบด้วยการกดเมนูเท่านั้น ไม่ต้องทำการ Dump configuration ใหม่อีกรอบ
ประโยชน์ที่ผู้ใช้งานจะได้รับอย่างเต็มที่อีกส่วนหนึ่งก็คือการสร้าง Lab เพื่อฝึกแก้ปัญหาที่เกิดขึ้น เช่น ฝึกทำ Lab สำหรับการสอบ TSHOOT หรือการเตรียมสอบ CCIE ที่มีหัวข้อ Troubleshooting นั้นเอง การแก้ปัญหาหรือ Ticket ในลักษณะนี้มักจะมีการทดลองแก้ Configuration ของอุปกรณ์อยู่เสมอๆ และบ่อยครั้งที่จะทำให้ค่าที่โจทย์ให้มีมีปัญหาหนักมากกว่าเดิม!!! เนื่องจากเราแก้ปัญหาผิดจุดนั้นเอง การนำ Initial configuration มาใช้งานในลักษณะนี้จึงมีประโยชน์อย่างมากนั้นเอง แต่ UnetLab ยังมีการทำงานทีเกี่ยวกับการจัดการ Configuration รูปแบบอื่นอีกซึ่งจะมีตัวอย่างการใช้งานด้านท้ายบทความครับ
เท่านี้ก็คงจะพอเห็นความสำคัญของการนำ Initial configure มาใช้งานกันบ้างแล้วนะครับ ในส่วนนี้เราจะมาเริ่มลงมือสร้าง Initial configure ใน UnetLab กันครับ
ก่อนที่จะลงมือสร้าง Initial configure นั้นเราจะต้องสร้าง Lab ใน UnetLab ขึ้นมาให้เรียบร้อยก่อน โดยในตัวอย่างผมจะใช้ Lab ที่ได้สร้างไว้แล้วในหัวข้อของ Service Provider (ยังไม่ได้เขียนต่อเลย ^^”)
จากรูปตัวอย่างถ้าใครสังเกตุจะเห็นว่ามีการเปลี่ยนแปลงเล็กน้อยที่ CE ทั้งสองฝั่งเมื่อเทียบกับตัวอย่างใน Blog เนื่องจากมีแผนที่จะเพิ่มรูปแบบ Lab นั่นเองครับ ^^
ขั้นตอนต่อมาให้ทำการเปิดอุปกรณ์ขึ้นมาทั้งหมดและ Configure อุปกรณ์โดยใช้ Command ที่อยู่ในหัวข้อ “Service Provider Lab Series Part 1” มาสร้างเป็น Initial configure ครับ เมื่อใส่ Command ให้กับอุปกรณ์ที่ต้องการหมดแล้วต้อง Save configuration ให้อุปกรณ์ทุกตัวด้วย Command “wr” หรือ “commit” เพื่อ Save configuration ที่เราทำไว้
ขั้นตอนนี้จะเป็นขั้นตอนพิเศษสำหรับการสร้าง Initial configure แล้ว ให้เลือกที่เมนู More actions -> Export all CFGs เพื่อให้ UnetLab ทำ Export configuration ที่เรา Save ไว้บนอุปกรณ์ออกมาเก็บไว้
จากนั้นให้ลองตรวจสอบการทำงานของ UnetLab ว่าถูกต้องหรือไม่โดยไปที่เมนู Startup-configures ถ้าเราทำถูกต้องจะต้องมี
รูป Drive A ที่มีเครื่องหมายถูกบนมุมขวาล่างขึ้นมาที่หลังรายชื่ออุปกรณ์ทุกตัวที่ได้ Save configuration ไว้ เพียงเท่านี้เราก็จะมี Initial configure ของอุปกรณ์เก็บไว้ใช้งานแล้ว
มาถึงตอนนี้หลายๆคนจะมีคำถามขึ้นมาคือ แล้วอะเอาไปใช้งานยังไง? สำหรับการใช้งานอะแบ่งออกเป็นลักษณะต่างๆดังนี้
ลองมาสรุปการทำงานของการสร้าง Initial configuration ใน UnetLab กันด้วยรูปก็น่าจะได้ประมาณนี้ครับ
สำหรับบทความนี้สามารถโหลดบทความในรูปแบบ PDF ได้จาก ที่นี่ ครับ
สำหรับ Video เสริมความเข้าใจดูได้จากด้านล่างนี้เลยครับ
ทำตามสัญญาครับวันนี้ทำ Video เรื่องการ Convert disk image บน UnetLab มาให้ดูครับ ตามตัวอย่างมี 3 ตัวคือ Arista, F5 และ HP โดยทั้ง 3 ตัวสามารถไปขอใช้งานได้ฟรีแต่ต้องมีการ Register ก่อนครับ
ลองทำตามกันดูครับติดขัดยังไงก็ลอง Post ถามกันได้ครับ
กลับมาลองทำ Video เป็นทางการอีกครั้งในรอบปีเลยทีเดียว 🙂
วันนี้ขอเสนอการใช้งาน UnetLab แบบคร่าวๆมาให้ดูครับ ต้องบอกก่อนว่า Video นี้ไม่ได้มีรายละเอียดทั้งหมดแต่เป็นการให้ Idea ในการเริ่มใช้งานเท่านั้นนะครับ สำหรับรายละเอียดเดี๋ยวจะทำออกมาให้ดูบางส่วนอีกครั้งนึง
กลับมาอีกครั้งหลังจากหายไปหลายอาทิตย์ ^^
รอบนี้กลับมาลองใช้ Wireshark ทำงานในส่วนของ Network forensics กันดูบ้างว่ามันจะเป็นเช่นไร……….
เข้าเรื่องกันเลยดีกว่าวันนี้เราจะขอเสนอฟังก์ชั่น “Export Objects” ซึ่งฟังก์ชั่นนี้จะทำหน้าที่ในการ “สกัด” สิ่งที่อยู่ในรูปแบบของแพ็คเก็ตที่ดูแล้ว “ไม่เข้าใจ” ให้ออกมาเป็นในรูปแบบของไฟล์ หรือ URL เนื่องจากวันนี้เราจะเน้นให้ทำการ “สกัด” เนื้อหาที่อยู่ในรูปแบบของ HTTP โปรโตคอลออกมานั่นเอง
โดยปกติแล้วเมื่อเปิด Wireshark ขึ้นมาและทำการจับข้อมูลที่วิ่งผ่านเข้ามาในเครื่องของเรา สิ่งที่เห็นจะมีรูปแบบในรูปด้านล่างนี้ คือ Source-Destination IP Address, Port, Packet information ซึ่งโดยปกติแล้วเราจะไม่มีทางรู้ได้เลยว่าข้อมูลที่อยู่ภายในนั้นคืออะไร ยกตัวอย่างเช่น URL อะไร หรือรูปที่เปิดขึ้นมาอยู่ที่ URL ไหน?
ยกตัวอย่างการใช้งานในรูปแบบของ Network forensic ในหัวข้อนี้จะลองทำการ “ประกอบร่าง” แพ็คเก็ตที่ได้มาจาก Wireshark ให้กลายเป็นข้อมูลที่สมบูรณ์และย้อนกลับไปได้ว่าไฟล์ที่เปิดขึ้นมาอยู่ที่ URL ใดและลองโหลดไฟล์ที่ได้จากการ “ประกอบร่าง” ลงมาในเครื่องของเราเพื่อทำการตรวจสอบต่อไปได้นั่นเอง
ก่อนที่จะใช้ฟังก์ชั่นนี้ได้อย่างสมบูรณ์เราจะต้องมาการเตรียมการให้เรียบร้อยก่อนตามขั้นตอนดังนี้
โดยการตั้งค่าทั้งหมดนี้ให้เข้าไปทำที่เมนู Edit Preference… ตามรูปด้านล่างนี้
เมื่อทำการตั้งค่าทั้งหมดเสร็จเรียบร้อยแล้วให้เข้าไปที่เมนู File -> Export Objects -> HTTP ก็จะมีหน้าต่างเปิดขึ้นมาใหม่คือ “Wireshark: HTTP object list” โดยในหน้านี้จะแสดงรายละเอียดของสิ่งที่ได้จากการ “ประกอบร่าง” เช่น Hostname ซึ่งก็คือ เวบไซท์ที่เราได้เข้าไป Content Type คือชนิดของไฟล์ที่ได้จากการเข้าไปที่เวบไซท์นั้น Size คือขนาดของไฟล์ที่โหลดขึ้นมา และสุดท้าย Filename คือชื่อของไฟล์ที่โหลดมานั่นเอง
ในตัวอย่างนี้ผมจะทำการเซฟไฟล์ชื่อ “UNL%20diagram.png” ลงมาที่เครื่องโดยการเลือกที่ไฟล์ที่ต้องการและกด “Save As” จากนั้นให้ทำการเลือกตำแหน่งที่ต้องการเซฟลงในเครื่องและทำการตั้งชื่อตามที่ต้องการ หลังจากนั้นให้ทำการเปิดไฟล์ที่ได้จากการเซฟเมื่อสักครู่นี้ขึ้นมา สำหรับผมจะได้ผลจากการเปิดไฟล์ขึ้นมาตามรูปด้านล่างนี้ครับ
สำหรับตัวอย่างการประยุกต์ใช้งานในส่วนของ Network forensics คือการนำไปใช้หาข้อมูลการดาวน์โหลดไฟล์ที่ไม่ได้รับอนุญาตจากทั้งในส่วนของภายในและภายนอกบริษัท หรือในส่วนของตัวอย่างจะเป็นการดาวน์โหลดไฟล์จาก Internet มาซึ่งสามารถระบุได้ถึง Hostname และชื่อไฟล์ซึ่งเป็นหลักฐานที่ดีในระดับนึงเลยทีเดียว
หมายเหตุ: การ “สกัด” เนื้อของไฟล์ที่ต้องการจำเป็นที่จะต้องมีปริมาณของแพ็คเก็ตในปริมาณที่มากพอและครบถ้วนเพื่อที่จะได้ไฟล์หรือเนื้อหาตามที่ต้องการได้อย่างถูกต้องสมบูรณ์ด้วยเช่นกัน
หวังว่าคงจะได้แนวคิดในการนำไปประยุกต์ใช้งานกันต่อแล้วนะครับ ขอบคุณทุกท่านที่ติดตามนะคร้าบบบบบ _/|\_
ถ้าอ่านแล้วถูกใจอยากมาลองเรียนเพิ่มเติมกับเราตั้งแต่พื้นฐานจนทำให้ได้ผลลัพธ์ออกมาเป็นรูปร่างได้เหมือนในบทความและยังสามารถนำความรู้ไปต่อยอดได้ ลองมาเรียนกับเราได้โดยดูรายละเอียดได้ ที่นี่ นะครับ ^^
อาทิตย์นี้กลับมาในเรื่องของ 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 เพื่อนะไปลองวิเคราะห์ปัญหาที่อาจจะเกิดขึ้นได้บ้างนะครับ 🙂
ถ้าอ่านแล้วถูกใจอยากมาลองเรียนเพิ่มเติมกับเราตั้งแต่พื้นฐานจนทำให้ได้ผลลัพธ์ออกมาเป็นรูปร่างได้เหมือนในบทความและยังสามารถนำความรู้ไปต่อยอดได้ ลองมาเรียนกับเราได้โดยดูรายละเอียดได้ ที่นี่ นะครับ ^^
กลับมาเขียน 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 ที่เราดูแลอยู่นั้น “ช้า” จริงหรือไม่อย่างหนึ่งนั่นเอง
ถ้าอ่านแล้วถูกใจอยากมาลองเรียนเพิ่มเติมกับเราตั้งแต่พื้นฐานจนทำให้ได้ผลลัพธ์ออกมาเป็นรูปร่างได้เหมือนในบทความและยังสามารถนำความรู้ไปต่อยอดได้ ลองมาเรียนกับเราได้โดยดูรายละเอียดได้ ที่นี่ นะครับ ^^
กลับมาเข้าเรื่อง SDN กันอีกครั้ง ^^
คราวนี้เราจะมาทำความรุ้จักกับ Mininet กัน คำถามที่เกิดขึ้นแน่ๆในใจของหลายๆคนน่าจะมีดังต่อไปนี้
ขอสรุปกันแบบบ้านๆประมาณนี้ก็แล้วกันครับ
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 ก็ได้เช่นเดียวกันครับ
กลับมาอีกครั้งกับการขุด 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 คือ
ต่อมา vunl0_1_0 อธิบายจากซ้ายไปขวา
ต่อมาผมจะมีตัวอย่าง 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 เอาไว้เท่านี้ ขอบคุณที่ติดตามคร้าบบบบบ _/|\_
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:
เป้าหมาย:
IOS:
c3640-jk9s-mz.124-16.bin
Topology:
ปล. เรื่องนี้ Rene ยังไม่ได้ทำ Video แต่การ Configure แนวๆนี้เคยเห็นในข้อสอบ CCIE R&S ด้วยนะ 🙂
ความเห็นล่าสุด