คลังเก็บหมวดหมู่: Network troublshooting

การใช้ Wireshark สร้างกราฟเพื่อดูสรุปภาพรวมของเหตุการณ์

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

คำถามที่เกิดขึ้นเลยคำถามแรกคือจะเอามาดูภาพรวมทำไมในเมื่อโปรแกรม Wireshark สามารถดูข้อมูลได้ล฿กได้ถึงข้อมูลในระดับ Bit ของ Protocol อย่างเช่น DSCP หรือ Reset flag ใน TCP header!!! ทำไมไม่เอาความสามารถของโปรแกรมที่มีอยู่มาใช้ให้ถูกต้อง!!!

ลองมาดูการแสดงผลของ Wireshark ที่แสดง TCP reset bit กันก่อนว่ามีหน้าตาเป็นยังไงกันตามรูปนี้เลยครับ

 

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

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

ดังนั้นจะดีกว่าหรือไม่ที่เราสามารถที่จะเอาโปรแกรม Wireshark มาใช้ในการแสดงภาพรวมของ Packet ที่เรามีอยู่มาแสดงผลก่อนที่จะลงมือค้นหาสาเหตุที่อยู่ในระดับที่ลึกลงไปอีกทีหนึ่ง อย่าลืมว่า Packet ที่เรานำมาเปิดด้วยโปรแกรม Wireshark นั้นอาจจะไม่ใช่ Packet ที่มีปัญหาอยู่ด้วยก็ได้ ลองนึกย้อนกลับไปในส่วนของการทำงานจริงดูว่าปัญหาจะเกิดขึ้นได้ในช่วงเวลาได้ได้บ้าง ตำตอบคือไม่รู้!!! เพราะถ้าเรารู้แล้วเราก็จะสามารถหาทางแก้ไขได้อย่างแน่นอน แต่ในชีวิตจริงเราไม่สามารถรู้ได้เลยว่าปัญหาจะเกิดขึ้นได้ในช่วงไหน ดังนั้นการจับ Packet ก็อาจจะต้องทำทิ้งไว้เป็นเวลาหลายชั่วโมง หรืออาจจะเป็นวันเลยก็ตาม เพื่อให้ครอบคลุมในช่วงเวลาที่มีปัญหาเกิดขึ้น ซึ่งอาจจะเกิดขึ้นแค่เพียง 1 หรือ 2 นาทีในเวลา 24 ชั่วโมง (เราจะไม่จับ Packet ค้างไว้ทั้งวันเพราะเราจะไม่สามารถเปิดไฟล์ที่มีขนาดใหญ่เกินไปได้ ให้ลองนึกถึงการเปิด .txt ที่มีขนาด 1GB ดูครับ) ดังนั้นการไล่เปิดไฟล์และค้นหาเหตุการณ์ต่างๆจะเสียเวลามากไปถ้าใช้การพิจารณาในระดับที่ละเอียดมากเกินไปนั่นเอง (ยังไม่นับกรณีที่ปัญหาเกิดในช่วงเวลาที่คาบเกี่ยวกันในระหว่างที่เราแยกไฟล์เป็นชิ้นตามช่วงเวลาและต้องนำไฟล์มารวมกันเป็นก้อนใหม่เพื่อวิเคราะห์ปัญหาอีกต่างหาก ผมเคยต้องเอาไฟล์มารวมกันจนได้ขนาด 16GB และเอามาหาความผิดปกติ T^T)

ส่วนนี้จะเป็นตัวอย่างการใช้งานจริงในส่วนของการนำเอา Wireshark มาใช้ในการดูภาพรวมของปัญหากันครับ

ตัวอย่าง เบื้องต้นเราต้องการทราบว่าโมเด็มที่เราใช้งานอยู่มีอาการ Disconnect ในทุกวันเราก็นำโมเด็มนั้นมาทดสอบใน Lab และกำหนดค่า Timeout ให้เป็น 15 นาทีเพื่อดูปัญหาที่เกิดขึ้นในระยะเวลาที่จำกัด หลังจากการทดสอบและเก็บข้อมูลใน Lab ออกมาได้จะพบว่าปัญหาที่เกิดขึ้นเกิดจากการที่ Session ไม่ Reestablish ใหม่หลังจากหมดช่วงเวลา Timeout จาก Protocol LCP เมื่อได้ผลารุปมาแล้วก็นำไปหาวิธีการแก้ปัญหา โดยแบ่งวิธีการแก้ปัญหาเป็น 2 ส่วน ดังนี้

  1. แก้ไขโดยใช้ Command บนอุปกรณ์ที่เชื่อมต่ออยู่ด้วยช่วยแก้ไขการทำงาน
  2. แก้ไขโดยการแก้ Firmware ของโมเด็มใหม่

จากรูปตัวอย่างที่ผมเอามาทำบทความนี้เอามาจากการแก้ไขโดยใช้ Command บนอุปกรณ์ที่เชื่อมต่ออยู่ด้วยช่วยแก้ไขการทำงานในส่วนที่ 1 เมื่อลองใส่ Command ใหม่ลงไปแล้วก็ทดสอบใน Lab เหมือนเดิมและก็ไม่ลืมที่จะเก็บ Packet มาวิเคราะห์ปัญหาด้วยเหมือนเดิม จากรูปด้านล่างที่เห็นคือหลังจาก Session timeout แล้วอุปกรณ์สามารถกลับมาเชื่อมต่อได้อย่างปกติ

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

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

หวังว่าบทความนี้จะเป็นตัวอย่างการเอา Wireshark ไปใช้งานได้ดีขึ้นในส่วนนึงนะครับ

 

แล้วเจอกันในบทความหน้า (ถ้าพอมีเวลาและขยันเขียน) ขอบคุณที่เสียสละเวลาอันมีค่าเข้ามาอ่านด้วยครับ _/|\_

แสดงค่า Round Trip Time ของ Network ในรูปแบบของกราฟเพื่อแสดงเวลาที่ Packet ใช้เวลาใน Network

วันนี้เป็นเรื่องการแสดงค่า Round Trip Time (RTT) หรือค่าเวลาที่ Packet ใช้เวลาในการเดินทางใน Network จากต้นทางไปยังปลายทางและกลับมาที่เครื่องต้นทางอีกครั้งหนึ่ง “ซึ่งค่าที่ได้นี้จะเป็นค่าอ้างอิงของเวลาที่ Packet ใช้เวลาในการเดินทางระหว่างอุปกรณ์ต้นทางและอุปกรณ์ปลายทาง คู่หนึ่งเท่านั้น” ไม่ใช่ค่าเวลาที่สามารถใช้อ้างอิงเวลาที่ใช้ในระบบ Network ของอุปกรณ์ทุกตัวได้

ตัวอย่างการหาค่า RTT อาจจะเป็นการใช้งานคำสั่ง Ping ไปที่ปลายทางต่างๆ ดังนี้

จากรูปด้านบนทั้งสองรูปเราก็จะเห็นว่าค่า “time” ที่อยู่ในกรอบสีแดงทั้งสองค่ามีค่าไม่เท่ากันซึ่งค่าที่เปลี่ยนไปนี้จะมีค่าไม่ท่ากันในทุกๆปลายทาง ซึ่งค่านี้จะเปลี่ยนไปตามอุปกรณ์ต้นทางและอุปกรณ์ปลายทางคู่หนึ่งเท่านั้น ดังที่อธิบายไปแล้วก่อนหน้านี้

สำหรับ Diagram ที่ใช้อธิบายการทำงานของ RTT จะมีรูปแบบดังรูปด้านล่างนี้

หรือถ้าจะมองในรูปแบบของคู่การสื่อสารในรูปแบบการ Request data แบบ peer-to-peer ก็จะได้รูปแบบเป็นตาม Diagram ตามรูปด้านล่างนี้

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

ก่อนอื่นก็ให้เราเปิด Packet ที่เรามีอยู่ขึ้นมาด้วยโปรแกรม Wireshark ก่อนจากนั้นก็ให้ทำการเลือกเพ็คเก็ตที่เราต้องการหาค่า RTT จากในรูปตัวอย่างผมจะเลือก Packet ที่มี Source IP address = 172.16.4.115 และมี Destination IP address = 192.168.1.2 ซึ่งการทำแบบนี้ก็คือการที่เราเลือกอุปกรณ์ต้นทางและปลายทางนั่นเอง

ต่อมาให้ไปที่เมนู Statistics -> TCP StreamGraph -> Round Trip Time Graph ตามรูปด้านล่างนี้

จากนั้นก็รอสักพักนึงเพื่อให้โปรแกรม Wireshark ทำการคำนวนค่า RTT ของอุปกรณ์ที่มีค่า IP address = 172.16.4.115 ไปที่อุปกรณ์ปลายทางที่มีค่า IP address = 192.168.1.2 ตามกราฟด้านล่างนี้

กรณีที่เราต้องการแสดงค่า RTT ของคู่การสื่อสารอื่นๆก็สามารถทำได้โดยการเลือก Packet ใหม่โดยอาจจะเปลี่ยน Source IP address หรือ Destination IP address ไปตามที่เราต้องการ จากรูปตัวอย่างด้านล่างผมจะเปลี่ยน Destination IP address = 192.168.1.3

หลังจากที่ได้กราฟที่มีค่า RTT แล้วต่อมาเราจะสามารถสรุปอะไรได้บ้าง ผมขอยกตัวอย่างการสรุปข้อมูลที่ได้จากกราฟดังนี้ครับ

  • ค่า RTT ของ Source IP address = 172.16.4.115 ไปยัง Destination IP address = 192.168.1.2 มีค่าเฉลี่ยประมาณ >0.001 วินาที โดยพิจารณาจากความหนาแน่นของ Packet ที่มีค่าเกือบเป็นเส้นตรงที่ค่านี้เกือบตลอดเวลา
  • ค่า RTT ของ Source IP address = 172.16.4.115 ไปยัง Destination IP address = 192.168.1.3 มีค่าเฉลี่ยประมาณ 0.0003 – 0.004 วินาที โดยพิจารณาจากความหนาแน่นของ Packet
  • จากกราฟทั้งสองจะเห็นว่า Source IP address = 172.16.4.115 มีการสื่อสารไปที่ Destination IP address = 192.168.1.2 มากกว่าเครื่องอื่นและมีค่า RTT ที่ค่อนข้างคงที่ซึ่งหมายความว่าการสื่อสารนั้นมีประสิทธิภาพที่ดีจากกราฟที่เห็นคือ Packet มีความต่อเนื่องกันมากจนกลายเป็นเส้นต่อเนื่อง
  • จากกราฟที่สองถึงแม้ว่าค่า RTT จะมีค่าไม่คงที่เมื่อเทียบกับค่า RTT ของกราฟที่หนึ่งแต่ค่า RTT โดยเฉลี่ยยังมีค่าที่ใกล้เคียงกับค่าที่ได้จากกราฟที่หนึ่ง
  • ในมุมมองของการสื่อสารระหว่าง Network 172.16.4.0/24 ไปที่ Network 192.168.1.0/24 จะสามารถสรุปได้ว่าค่า RTT ที่ได้จากการสื่อสารระหว่าง Network มีประสิทธิภาพไม่มีปัญหาในเรื่องการ Delay เกิดขึ้นจน User รู้สึกได้

IP SLA graph บอกอะไรได้บ้าง

หนึ่งภาพสามารถแทนความหมายมากมาย ภาพที่เกิดจากการ monitor อุปกรณ์ network ก็ทำได้ในแนวเดียวกัน ^^

ภาพที่อยู่ด้านล่างเป็น graph ที่เกิดจากการ “ping” ไปที่ปลายทาง “แค่นั้น” แต่ความหมายที่แสดงอยู่มีค่ามากกว่านั้น ยกตัวอย่างที่เห็นจากภาพไม่ต้องคิดเลยก็มีประมาณนี้
1. ค่าเฉลี่ยของการตอบสนอง ping ไปที่ปลายทางคือ 30 ms.
2. มีบางช่วงที่ ping ไปที่ปลายทางไม่ได้
3. link ที่ใช้ไม่ค่อยจะเสถียรเท่าไร แต่ยอมรับได้
4. ต้องไปมีใครสักคนเปลี่ยนอะไรสักอย่างในช่วง week 20 – week 30

แล้วกราฟนี้มาจากไหน??
ตามหัวข้อ IP SLA เลยกราฟนี้มากจากการใช้ IP SLA command บน Catalyst 3750X ทำการส่งคำสั่ง ping ไปที่ปลายทางที่ต่างประเทศผ่าน internet ส่วน command ก็ประมาณนี้

ip sla X
 icmp-echo Y.Y.Y.Y
 threshold 1000
 timeout 1000
 frequency 10
ip sla schedule X life forever start-time now

เท่านี้ L3 ของเราก็จะ ping ไปที่ IP Y.Y.Y.Y แล้วก็เอามาพล็อตกราฟก็จบ แต่ประโยชน์ของมันไม่ได้มีแค่นั้นถ้าเรารู้เบื้องหลังและที่มาก็จะได้ข้อมูลเพื่อเอามาใช้ประโยชน์ได้อีกประมาณนี้

1. เนื่องจากการต่อใช้งาน internet แบบ BGP multihome ทำให้รู้ว่า Best path ไปที่ปลายทาง Y.Y.Y.Y ของ ISP1 แย่กว่า ISP2 จากกราฟในช่วงที่ใช้ ISP1 ทำงานเป็น default route ในหมายเลข 1 และ 4 มี respond time ที่เกิดจากการ ping สูงกว่าเมื่อช่วงที่ ISP2 ทำงานแทนในหมายเลข 3
2. ในช่วงหมายเลข 2 อาจจะมีการ cutoff ระบบแล้วเกิดปัญหากับ ISP1 ทำให้ ISP1 ไม่สามารถทำงานได้แต่ BGP ยังคงทำงานเมื่อ on ระบบขึ้นมาหลังจากทำงานเสร็จแล้ว ISP2 สามารถใช้งานได้ทำให้อุปกรณ์ใน site สามารถใช้งานได้เป็นปกติ
3. ในช่วงที่ ISP2 ทำงานพบว่า respond time ไปที่ IP Y.Y.Y.Y ต่ำกว่าตอนที่ ISP1 ทำงานแสดงว่า ISP2 มี Best path ไปที่ IP Y.Y.Y.Y ดีกว่า ISP1 จุดนี้สามารถนำไปทำ Optimize route ต่อได้อีก
4. เมื่ออุปกรณ์ของ ISP1 กลัมาทำงานได้เป็นปกติ Respond time ของ IP Y.Y.Y.Y กลับมาอยู่ที่ค่าเฉลี่ยประมาณ 70 ms เท่าเดิมแสดงว่าสำหรับ IP ปลายทางนี้ ISP2 มี best path ดีกว่า ISP1 แน่นอน
5. ถ้าลองตรวจสอบย้อนกลับไปที่ช่วงเวลา week ที่ 20 จะพบว่ามีการเปลี่ยนแปลงระบบทำให้สามารถ focus ความผิดพลาดที่เกิดขึ้นได้ว่าพอจะมาจากสาเหตุอะไรกันแน่ได้แม่นยำขึ้น
6. อันนี้ไม่ได้ใส่รูป graph ของ IP ปลายทางตัวอื่นแต่จะพบว่าถึงแม้ ISP2 จะทำงานแต่ Respond time ของ IP ปลายทางอื่นๆยังเท่าเดิมแสดงว่าไปทำการ optimize route แค่ชุดเดียวก็พอ

จะเห็นได้ว่าแค่การ ping ก็สามารถบอกข้อมูลได้เยอะแล้วดังนั้นใครที่ยังไม่ได้ทำระบบ monitor ก็ไปทำเพิ่มซะหน่อยดีกว่าปล่อยให้ระบบ network เป็น black box เวลามีปัญหาก็แก้ไขอะไรไม่ได้ จะเริ่มตรงไหนก็ไม่ถูก เมื่อตอบปัญหาไม่ได้ก็ต้องตกเป็นจำเลยของชาวบ้านเขาเรื่อยไป 😛

ปล. คัดลอกมาเป็นบทความบน Blog จาก Facebook note ของผมเองที่เขียนไว้เมื่อปี 2014 จาก ที่นี่ ครับ

Pro-active monitor เพื่อการตรวจสอบระบบ Network แบบ realtime

ผมคิดว่าเพื่อนๆที่ทำงานตำแหน่ง Network admin หรือ System admin ในบริษัทหลายท่านอาจจะมีความรู้สึกว่า “User ของท่านหลายๆคนจะรู้ว่าจะรบบที่ทำงานอยู่นั้นมีปัญหาได้เร็วกว่าคนที่ทำงานด้าน Network หรือ System ที่ดูแลระบบด้านนั้นๆอยู่เสมอ” ไม่ว่าจะเป็นเรื่องการใช้งานระบบ Database หรือการใช้งาน Internet จนทำให้เวลาที่ระบบมีปัญหาเรามาักจะใช้ “User เป็น Alert system ได้ดีกว่า” การเปิดหน้าจอโปรแกรม System monitor เพื่อดูสถานะของระบบไว้ซะอีก 🙂

ทำไม User จึงสามารถรับรู้ว่าระบบนั้นๆมีปัญหาได้เร็วกว่าเรา? ผู้ดูแลระบบหลายคนก็อาจจะคิดเช่นนั้น รวมทั้งผมเองในช่วงแรกๆ 🙂 แต่เมื่อมองถึงการใช้งานของ User ในด้านที่แตกต่างๆจากผู้ดูแลระบบก็จะพบว่าการที่ User นั้นรับรู้ปัญหาที่เกิดขึ้นได้เร็วกว่าเราก็คือ “พฤติกรรมการใช้งาน” ที่มีมากกว่าเรานั่นเอง เช่น ฝ่ายบัญชีมักจะมีการเรียกข้อมูลหรือเพิ่มข้อมูลลงไปที่ Database บ่อยๆ หรือกำลังดู Youtube อยู่แล้วภาพกระตุก 😛 ในขณที่เราอาจจะพิมพ์ Word อยู่ก็เป็นด้ายยยยย!!! จากพฤติกรรมการใช้งานที่เกี่ยวข้องกับระบบ Network นี้เองทำให้ User รับรู้ได้ถึงการเปลี่ยนแปลงบางอย่างที่เปลี่ยนแปลงไปจากเดิม ความแตกต่างที่ User สามารถรับรู้ได้นั้นจึงเป็นที่มาของการแจ้งความผิดปกติเข้ามาที่ผู้ดูแลระบบอย่างเราๆนั่นเอง

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

  • Cisco – IP SLA
  • Juniper – RPM
  • HP – NQA
  • Huawei – NQA
  • Nokia (Alcatel-Lucent) – SAA

ซึ่ง Feature ที่ได้กล่าวถึงไว้ที่ด้านบนจะทำหน้าที่เป็นตัว “สร้าง Traffic” การใช้งานระบบ Network แทน User นั่งเอง โดยเรามาสามารถกำหนดให้อุปกรณ์ทำการตรวจสอบ(หรือใช้งานระบบ) Network เป็นช่างเวลา หรือตรวจสอบการใช้งานตลอดเวลาก็ได้ในกรณีที่เราต้องการนำมาใช้งานเป็นระบบ Real-time monitor

ประโยชน์ของการนำ Feature เช่น IP SLA มาใช้งานเป็นระบบ Real-time monitor คือ Network หรือ System admin จะได้ทราบถึงพฤติกรรมบนระบบที่เกิดขึ้นและเปลี่ยนแปลงไปในช่วงเวลาต่างๆ ซึ่งการใช้งานระบบ Network monitor ทั่วไปที่ให้แต่ผลการใช้งานแค่เรื่อง Traffic (Bandwidth) ที่เกิดขึ้นในระบบทั่วๆไปไม่สามารถให้คำตอบได้ เช่น

1.การตอบสนองการ Query ของ DNS server ว่ามีการตอบสนองการ Query ได้เร็วหรือช้าเป็นเวลาเท่าใด

2.การตอบสนองของ WAN ที่เชื่อมต่อระหว่างสาขานั้นมีค่า Round Trip Time(RTT) ใน WAN เส้นนั้นๆเป็นเวลาเท่าใด

3. การตอบสนองของ Service port บน Server ที่เปิดใช้งานบน Server เครื่องหนึ่งนั้นมีค่าเป็นเท่าใด

4. ค่าเวลาตอบสนองในการทดสอบการ Download ไฟล์จาก FTP server มีค่าเป็นเท่าใด

5. การใช้งาน Web site หนึ่งมีค่าตอบสนองของ TCP/DNS/HTTP เพื่อทำให้โหลดข้อมูลหน้านั้นๆขึ้นมาได้มีค่าเป็นเท่าไร

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

ผมขอยกตัวอย่างสำหรับการนำใช้งานข้อมูลไปใช้งานในบางกรณีดังนี้

ระบบ Internet มีปัญหาในช่วงเวลา 9.30น. ทำให้ User ใช้งาน Internet ไม่ได้ ต่อมา Internet กลับมาใช้งานได้ในช่วงเวลา 9.35น. ในช่วงเวลาที่เหลื่อมกันนั้นเวลา 9.34น. Network admin ได้โทรไปที่ ISP ให้ทำการตรวจสอบ Internet ต้องรอสายจนเวลา 9.36น.จึงจะได้คุยกับ Engineer ของ ISP และ Engineer ได้ขอผล Ping และ Traceroute ไปเพื่อนำไปตรวจสอบ Network admin จึงได้ส่งผลไปให้แต่เป็นผลการ Ping และ Traceroute ที่เวลา 9.37น.

กรณีที่ 1 ไม่มี Proactive monitor: จากช่วงเวลาด้านบน เมื่อส่งผล Ping/Traceroute ไปให้ Engineer ของ ISP ตรวจสอบก็จะพบว่าไม่มีความผิดปกติเกิดขึ้นในการเชื่อมต่อ Internet และเมื่อใช้โปรแกรม Monitor ทั่วไปดูจะพบว่ามี Bandwidth ที่ Interface จากมี Traffic เกิดขึ้นที่ Interface ที่เชื่อมต่อกับ Router ของ ISP ซึ่งอาจจะมีข้อมูลหากันตามปกติ เช่น Routing protocol หรือ L2 protocol อื่นๆ

กรณีที่ 2 มี Proactive monitor: เราจะมีผลการเชื่อต่อของ WAN-to-WAN, การตอบสนองของ Web site ปลายทาง หรือเวลาในการตอบสนองของ DNS server แล้วส่งเป็นกราฟไปให้ ISP ดูซึ่งจำทำให้เกิดความชัดเจนมากกว่าเพราะการทำ Real-time monitor จะต้องมีการเก็บข้อมูลไว้เป็น History ในระดับชั่วโมง วัน เดือน และปี ดังนั้นการที่เราเห็นความผิดปกติที่เกิดขึ้นจะทำให้เรามองเห็นปัญหาได้ชัดเจนและรวดเร็วขึ้นได้เป็นอย่างมาก

จากการแนะนำ Feature pro-active monitor และตัวอย่างการนำไปใช้งานในบทความนี้หวังว่าจะทำให้เพื่อนๆหลานคนได้ Idea ในการทำ Pro-active monitor ไว้ใช้งานในบริษัทของตัวเองกันมากขึ้น เพื่อใช้ในการตรวจสอบและใช้ในการประกอบการวิเคราะห์ปัญหาที่เกิดขึ้นกันได้นะครับ 🙂

ลองหาข้อมูลเพิ่มเติมเกี่ยวกับ Cisco IP SLA เพื่อใช้งานต่อได้ที่

http://www.bloggang.com/mainblog.php?id=likecisco&month=09-07-2015&group=3&gblog=50

http://www.cisco.com/c/en/us/td/docs/ios/12_4/ip_sla/configuration/guide/hsla_c/hsoverv.html

ปล. รูปตัวอย่างในบทความมากจาก Cacti โดยใช้ Template ที่ Modify ใหม่เองครับ เพื่อนๆที่สนใจสามารถหา Software อื่นๆมาใช้งานได้เองเช่นเดียวกันนะครับ 🙂

หมายเหตู: การทำ Pro-active monitor ไม่สามารถตอบคำถามทุกอย่างที่เกิดขึ้นได้ จะต้องมีการทำงานที่เกี่ยวข้องกับ Resource monitor อื่นๆด้วยเพื่อทำให้การวิเคราห์ปัญหาทำได้สะดวกและชัดเจนมากขึ้นด้วย การใช้เครื่องที่ดีตัวหนึ่ง อาจจะไม่ได้เหมาะสมกับทุกปัญหาที่เกิดขึ้นครับ

 

[Training] Wireshark for network troubleshooting

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

แต่จะดีกว่าไหมที่เราสามารถหาสาเหตุที่แท้จริงและนำไปปรับปรุงหรือแก้ไขระบบ Network หรือพฤติกรรมการใช้งานที่มีผลกระทบต่อภาพรวมของการใช้งานระบบ Network ได้อย่างชัดเจน ตรงจุด และ “สามารถสื่อสารให้คนที่ไม่เข้าใจระบบ Network ให้เข้าใจได้ง่ายขึ้นด้วยการใช้กราฟ” เช่น หัวหน้า, ผู้บริหาร หรืออธิบายปัญหาที่เกิดขึ้นกับโปรแกรมที่มีการเขียนใช้งานเองในบริษัทให้โปรแกรมเมอร์เข้าใจได้ หรือจะเป็นการปรับปรุงค่า Configuration ในระบบ Infrastructure ภายในบริษัทเองให้มีความเหมาะสมกับการใช้งาน เพื่อทำให้การใช้งานระบบ Network มีประสิทธิภาพที่ดีที่สุด โดยไม่มีการทิ้งคำถามมาที่คนทำระบบ Network เพียงคนเดียว

Wireshark for network troubleshooting เป็นหัวข้อ Workshop ที่คิดขึ้นเพื่อให้ผู้เรียนที่เป็นผู้ดูและระบบ Network ให้มีความเข้าใจในการทำงานของพื้นฐานการทำงานของระบบ Network โดยใช้รูปแบบการทำงานของ Protocol TCP มาอธิบายให้เห็นว่าในระหว่างการทำงานในระบบ Network ถ้ามีปัญหาเกิดขึ้นกับส่วนใดในการสื่อสารแบบ TCP จะมีปัญหาอย่างไรเกิดขึ้น และจะนำไปสู่การวิเคราะห์ปัญหาที่เกิดขึ้นในลักษณะต่างๆต่อไปได้อย่างเป็นรูปธรรม

Workshop จะเน้นให้ลงมือทำโดยเนื้อหาจะถูกแบ่งออกเป็น 3 ส่วนที่สำคัญคือ

ส่วนที่ 1

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

  • เริ่มต้นด้วยการพิจารณา OSI, TCP model และเปรียบเทียบกับการแสดงผลของ Wireshark
  • ตัวอย่างการทำงานของ Protocol TCP เพื่อใช้ในการอ้างอิงเมื่อเกิดปัญหาค่างๆ
  • การทำงานของ Protocol ARP
  • การเก็บข้อมูลในลักษณะต่างๆเพื่อนำมาเป็นข้อมูล Input ให้กับ Wireshark เช่น TCPdump, Remote capture

ส่วนที่ 2

เริ่มลงมือใช้งาน Wireshark เพื่อให้เห็นการทำงานของ Protocol ต่างๆแบบชัดเจน เช่น การเปิดการสื่อสารด้วย Packet SYN และวิเคราะห์การทำงานของระบบ Network โดยรวมได้แบบง่ายๆและรวดเร็ว ในส่วนนี้ทุกคนจะบอกได้อย่างเต็มปากว่า “ระบบ Network ไม่มีปัญหา” ระบบทำงานได้เร็วปกติ” โดยมีหลักฐานที่สามารถแสดงให้เห็นได้อย่างชัดเจน

  • เมนูใช้งานของโปรแกรม Wireshark, Coloring rules
  • รูปแบบ Input แบบต่างๆเพื่อใช้เป็น Filter string ของ Wireshark เพื่อใช้ในการกรองข้อมูลที่ต้องการนำมาวิเคราะห์ด้วย Wireshark ต่อไป
  • การใช้งาน Follow TCP stream
  • การใช้งาน TCP stream graph เพื่อพิจารณาและวิเคราะห์เหตุการณ์ต่างๆที่เกิดขึ้นใน Network

ส่วนที่ 3

ส่วนสุดท้ายของ Workshop เน้นการใช้งานเพื่อนำไปวิเคราะห์ปัญหาที่เกิดขึ้นได้อย่างรวดเร็วโดยสามารถหา Packet ที่คาดว่าจะเป็นต้นเหตุของปัญหาได้อย่างรวดเร็วและแม่นยำ “การหาจุดเริ่มต้นในการวิเคราะห์ปัญหาอย่าง Network ช้า” โดยการพิจารณา Packet ที่สนใจได้อย่างรวดเร็ว และปิดท้ายด้วยการวิเคราะห์การทำงาน Application ที่มีปัญหาด้วยคนเอง เพื่อสร้างความมั่นใจในการทำงานต่อไป

  • การสร้าง Profile และการเพิ่ม Column เพื่อให้เหมาะสมกับการวิเคราะห์ปัญหาในแบบต่างๆ
  • การ Export HTTP object
  • การใช้งาน IO graph
  • การใช้งาน Expert info
  • วิเคราะห์การทำงานที่ผิดปกติของ Application

Workshop ทั้ง 3 ส่วนจะใช้เวลาทั้งหมด 2 วันเพื่อให้ผู้เรียนได้ทำความเข้าใจการนำโปรแกรม Wireshark ไปใช้งานได้อย่างมีประสิทธิภาพ เนื้อหาทั้งหมดได้ผ่านกระบวนการคิดทดสอบและลงมือทำผ่านโปรแกรมอย่าง GNS3 และ VirtualBox หรือ EVE-NG จากผู้สอนก่อนที่จะลงมือทำเอกสารทุกขั้นตอน เพื่อให้แน่ใจว่าผู้เรียนจะสามารถกลับไปทำการทดลองซ้ำต่อที่บ้านหรือบริษัทต่อไปได้ ทำให้มีความสะดวกในการทบทวนเนื้อหาที่ได้เรียนผ่านไป โดยสามารถทำการทดลองซ้ำตามเอกสารเพื่อให้เกิดความชำนาญจนสามารถนำไปประยุกต์ใช้งานได้อย่างสะดวกตามความต้องการต่อไป

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

  1. ใช้ Wireshark เพื่อวิเคราะห์ความผิดปกติในการทำงานของ Application
  2. การนำค่า Delay ที่เกิดขึ้นในระบบ Network มาแสดงผลเป็นกราฟ
  3. ร่วมร่างไฟล์ให้กลับมาจากแพ็คเก็ตที่ได้จาก Wireshark ^^
  4. TCP zerowindow กับปัญหาที่เกิดขึ้นใน network
  5. การหาค่า TCP Delay และนำมาแสดงบน Column ใน WireShark

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

ค่าใช้จ่ายในการเรียน 5,000 บาท

สิ่งที่จะได้รับในการเรียน

  1. เอกสารประกอบการเรียนที่มีเนื้อหาและขั้นตอนเป็นภาษาไทยในรูปแบบ PDF
  2. ตัวอย่าง Packet file ประกอบการทดลองต่างๆ
  3. เอกสารอ้างอิงประกอบการสอน
  4. โปรแกรมที่เกี่ยวข้องในการทำ Workshop
  5. VM Image file สำหรับประกอบการทำ Lab เพื่อให้สามารถทำการทดลองและนำไปใช้ทบทวนที่บ้านได้

หมายเหตุุ: เนื่องจากมีการใช้งาน EVE-NG ในการทดลอง ดังนั้นผู้เรียนจึงควรมี Notebook ที่มี Spec ขั้นต่ำดังนี้ เพื่อให้การทดลองได้ประโยชน์สูงสุด

1. CPU Intel core i3

2. Free space on HDD 80G (SSD for best performance)

3. RAM 8G

ระยะเวลาในการอบรม : ระหว่างวันที่ 28-29 ตุลาคม 2560 เวลา 9:00น. – 17:00น.
จำนวนผู้เข้าอบรม : สูงสุด 12 ท่าน
ค่าอบรม : ท่านละ 5,000 บาท -> โอนเงินมัดจำ 2,500 บาทล่วงหน้า ส่วนที่เหลือ จ่ายในวันที่เริ่มเรียน Workshop เพื่อยืนยันในการพิมพ์เอกสารประกอบการเรียน
สถานที่อบรม : Comscicafe ติดสถานีรถไฟฟ้า BTS แบริ่ง (มีที่จอดรถให้ผู้เข้าอบรมทุกท่าน)

แผนที่ของ ComSci cafe ใน Google maps คลิกดู ที่นี่

กรณีที่มีความสนใจ Workshop นี้สามารถติดต่อสอบถามได้ที่ Email: info@virtualnetsystems.com หรือ Dowload รายละเอียดเพื่อนำเสนอหน่วยงานได้ ที่นี่

ใช้ Wireshark เพื่อวิเคราะห์ความผิดปกติในการทำงานของ Application

หลังจากเขียนเรื่องเกี่ยวกับ Wireshark มาระยะหนึ่งแล้วหลายๆท่านก็น่าจะได้แนวคิดในการใช้งานโปรแกรมนี้กันมากขึ้นกันแล้ว วันนี้ผมขอเสนอการเอาโปรแกรม Wireshark มาใช้วิเคราะห์ความผิดปกติของ Application ที่เกิดขึ้นโดยใช้งาน Feature IO graph เพื่อแสดงให้เห็นการทำงานที่ผิดปกติได้ชัดเจนและเป็นรูปธรมมมากขึ้น

วันนี้จะขอสมมติเหตการณ์ที่เกิดขึ้นใน Office แห่งหนึ่งซึ่งมีปัญหาการใช้งาน Application server ดังนี้

  • User A รายงานว่าเมื่อใช้งาน App 1 บน Application server 2 ในช่วงเช้าจะสามารถใช้งานได้สักครู่แล้วโปรแกรมจะหลุดเองไม่สามารถใช้งานได้ ต้องรอระยะนึงจึงจะสามารถใช้งานโปรแกรมได้อีกครั้ง
  • User B ซึ่งใช้งาน App 1 เช่นเดียวกันใช้งานบน Application server 1 ในช่วงเวลาเดียวกันกลับไม่มีปัญหา
  • User C ใช้งาน App 2 บน Application server 2 ได้ตั้งแต่เริ่มงานในช่วงเช้ากลับไม่พบปัญหาใดๆเลย

จากการตรวจสอบปัญหาของโปรแกรมเมอร์ที่เขียนโปรแกรม 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 ดังต่อไปนี้

  • ip.addr==172.16.4.115 && ip.addr==192.168.1.9 && tcp.port==2074 -> Application server 1 – App 1
  • ip.addr==172.16.4.115 && ip.addr==192.168.1.2 && tcp.port==2077 -> Application server 2 – App 2
  • ip.addr==172.16.4.115 && ip.addr==192.168.1.2 && tcp.port==2074  -> Application server 2 – App 1

แต่ก่อนที่จะทำการแยกแยะการใช้งานเป็นแบบ 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 ดังนี้

  • ip.addr==172.16.4.115 && ip.addr==192.168.1.2 && tcp.port==2077 -> Application server 2 – App 2
  • ip.addr==172.16.4.115 && ip.addr==192.168.1.2 && tcp.port==2074  -> Application server 2 – App 1

จากกราฟที่ได้จะพบว่าที่เครื่อง 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 ไปประยุกต์ใช้งานให้กับหลายๆท่านได้ต่อไปนะครับ

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

ร่วมร่างไฟล์ให้กลับมาจากแพ็คเก็ตที่ได้จาก 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 ที่เราดูแลอยู่นั้น “ช้า” จริงหรือไม่อย่างหนึ่งนั่นเอง

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