Network Troubleshooting: วิธีแก้ปัญหาเครือข่ายอย่างเป็นระบบ
เมื่อเครือข่ายมีปัญหา ผู้ใช้จะโทรมาบอกว่า “เน็ตช้า” หรือ “เข้าเว็บไม่ได้” แต่คำอธิบายเหล่านี้ไม่ได้บอกว่าปัญหาอยู่ที่ไหน Network Engineer ที่ดีต้องมีวิธีการ troubleshoot อย่างเป็นระบบ แยกปัญหาออกเป็นชั้นๆ จนหาต้นตอได้ ไม่ใช่เดาสุ่มไปเรื่อย
จากประสบการณ์ กว่า 70% ของปัญหาเครือข่าย สามารถแก้ได้ด้วยเครื่องมือพื้นฐานอย่าง ping, traceroute, nslookup และ show commands บน switch/router ไม่ต้องใช้เครื่องมือราคาแพง แค่ต้องรู้วิธีใช้อย่างถูกต้องและตีความผลลัพธ์ได้
บทความนี้จะสอนวิธี Network Troubleshooting อย่างเป็นระบบ ตั้งแต่ methodology ที่ใช้ เครื่องมือที่จำเป็น วิธีแก้ปัญหาที่พบบ่อย ไปจนถึง Wireshark packet analysis
Troubleshooting Methodology: OSI Model Approach
วิธีที่มีประสิทธิภาพที่สุดคือใช้ OSI Model เป็นกรอบในการ troubleshoot โดยเริ่มจาก Layer 1 (Physical) ขึ้นไปทีละชั้น
Layer 1: Physical
เริ่มจากสิ่งที่ง่ายที่สุด สายหลุดหรือเปล่า ไฟ link บน switch ติดไหม สาย LAN ชำรุดหรือไม่ SFP module ใส่แน่นหรือเปล่า PoE จ่ายไฟได้ปกติไหม ปัญหา Physical layer พบบ่อยกว่าที่คิด โดยเฉพาะหลังจากมีการย้ายอุปกรณ์ ทำความสะอาด หรือปรับปรุง server room ตรวจสอบ interface status ด้วย show interface ดู input/output errors, CRC errors ถ้ามีมากแสดงว่าสาย cable มีปัญหา
Layer 2: Data Link
ตรวจสอบ MAC address table บน switch ดูว่า MAC ของอุปกรณ์ปลายทางอยู่ใน table หรือไม่ ตรวจ VLAN assignment ถูกต้องไหม trunk port ส่ง VLAN ที่ต้องการหรือเปล่า STP (Spanning Tree Protocol) block port ไหนอยู่หรือไม่ ปัญหา Layer 2 ที่พบบ่อยคือ VLAN mismatch, native VLAN ไม่ตรง, STP topology change ที่ทำให้ link กระพริบ
Layer 3: Network
ใช้ ping ทดสอบ connectivity ไปยังปลายทาง เริ่มจาก ping gateway ของ subnet ตัวเอง ถ้า ping gateway ไม่ได้ ปัญหาอยู่ที่ local network ถ้า ping gateway ได้แต่ ping ปลายทางไม่ได้ ใช้ traceroute ดูว่า packet หายตรงจุดไหน ตรวจ routing table ว่ามี route ไปยัง destination หรือไม่ ตรวจ ACL ว่า block traffic อยู่หรือเปล่า
Layer 4-7: Transport และ Application
ถ้า ping ผ่านแต่ application ยังไม่ทำงาน ปัญหาอาจอยู่ที่ firewall rules ที่ block port ที่ต้องการ DNS resolution ผิด (ใช้ nslookup ตรวจ) certificate expired, proxy settings ผิด หรือ application server เอง ใช้ telnet หรือ Test-NetConnection ทดสอบว่า port เปิดอยู่หรือไม่
เครื่องมือ Troubleshooting ที่ต้องรู้
| เครื่องมือ | ใช้ทำอะไร | ตัวอย่างการใช้ |
|---|---|---|
| ping | ทดสอบ connectivity และ latency | ping 8.8.8.8 -t (continuous ping) |
| traceroute/tracert | หาจุดที่ packet หาย | tracert www.google.com |
| nslookup/dig | ทดสอบ DNS resolution | nslookup siamlancard.com 8.8.8.8 |
| Wireshark | Packet capture และ analysis | Capture filter: host 192.168.1.100 |
| show commands | ตรวจสถานะ switch/router | show ip route, show mac address-table |
| iperf3 | ทดสอบ bandwidth จริง | iperf3 -c server_ip -t 30 |
| mtr | Continuous traceroute + statistics | mtr –report google.com |
Wireshark: Packet Analysis สำหรับปัญหาซับซ้อน
Wireshark เป็นเครื่องมือ packet capture ที่ทรงพลังที่สุด เมื่อเครื่องมือพื้นฐานหาปัญหาไม่เจอ Wireshark จะบอกคุณได้ว่าเกิดอะไรขึ้นจริงๆ บน wire
Capture Filters vs Display Filters
Capture Filter กำหนดว่าจะเก็บ packet ไหนลง file (ใช้ BPF syntax เช่น host 10.0.0.1 and port 443) ใช้เมื่อต้องการลดขนาด capture file Display Filter กำหนดว่าจะแสดง packet ไหนบนหน้าจอ (เช่น tcp.flags.syn==1 && tcp.flags.ack==0) ใช้หลังจาก capture แล้ว เพื่อ filter ดูเฉพาะ traffic ที่สนใจ
วิเคราะห์ปัญหาด้วย Wireshark
ปัญหา TCP retransmission มากผิดปกติ บ่งชี้ว่ามี packet loss บน network (อาจเป็นสาย cable เสีย, switch overloaded, หรือ firewall drop packets) ปัญหา DNS query timeout บ่งชี้ว่า DNS server มีปัญหาหรือถูก block ปัญหา TLS handshake failure อาจเกิดจาก certificate ไม่ตรง, cipher mismatch, หรือ proxy ที่ intercept HTTPS ใช้ Wireshark Expert Information (Analyze > Expert Information) ให้ Wireshark สรุปปัญหาที่พบในการ capture ให้
ปัญหาเครือข่ายที่พบบ่อยและวิธีแก้
เน็ตช้า (Slow Network)
เมื่อผู้ใช้บอกว่า “เน็ตช้า” ต้องแยกก่อนว่าช้าเฉพาะคนนี้หรือทั้งแผนก ถ้าเฉพาะคนเดียว ตรวจ interface errors บน switch port, ทดสอบสาย cable, ดู duplex mismatch ถ้าทั้งแผนก ตรวจ uplink bandwidth utilization บน switch ดูว่า saturated หรือไม่ ตรวจ broadcast storm (ดู broadcast/multicast counters) ถ้าช้าทั้งองค์กร ตรวจ internet bandwidth, firewall throughput, DNS performance
เข้าเว็บไม่ได้ (Cannot Access Website)
ขั้นตอนแรก nslookup ดูว่า DNS resolve ได้ไหม ถ้า resolve ไม่ได้ ปัญหาอยู่ที่ DNS ลอง resolve ด้วย DNS server อื่น (เช่น 8.8.8.8) ถ้า resolve ได้ด้วย 8.8.8.8 แต่ไม่ได้ด้วย internal DNS แสดงว่า internal DNS มีปัญหา ถ้า resolve ได้แต่เข้าเว็บไม่ได้ ลอง telnet ไปยัง port 80/443 ดูว่าเปิดอยู่ไหม ถ้าไม่เปิด อาจเป็น firewall block หรือ web server ล่ม
IP Address Conflict
IP conflict เกิดเมื่อ 2 อุปกรณ์ใช้ IP เดียวกัน อาการคือ connection กระพริบ บางครั้งใช้ได้บางครั้งไม่ได้ ตรวจสอบด้วย arp -a ดูว่า IP มี MAC address กี่ตัว ถ้ามี 2 MAC แสดงว่า conflict แก้โดยใช้ DHCP แทน static IP และ enable DHCP snooping + Dynamic ARP Inspection บน switch เพื่อป้องกัน
Best Practices สำหรับ Network Troubleshooting
เก็บ Baseline
ต้องรู้ว่า “ปกติ” เป็นอย่างไร ก่อนจะบอกว่า “ผิดปกติ” เก็บ baseline ของ bandwidth utilization, latency, error counters, CPU/memory ของอุปกรณ์ในช่วงปกติ เมื่อมีปัญหาจะเปรียบเทียบกับ baseline ได้ ใช้ SNMP monitoring (Zabbix, PRTG) เก็บข้อมูลย้อนหลังอย่างน้อย 30 วัน
Document Everything
เมื่อแก้ปัญหาเสร็จ จดบันทึกทุกครั้ง อาการเป็นอย่างไร สาเหตุคืออะไร แก้อย่างไร ใช้เวลาเท่าไหร่ สร้าง knowledge base สำหรับทีม เมื่อปัญหาเดิมเกิดซ้ำ จะแก้ได้เร็วขึ้นมาก
ทิ้งท้าย: Troubleshooting เป็นทักษะที่ฝึกได้
Network Troubleshooting ไม่ใช่พรสวรรค์ แต่เป็นทักษะที่ฝึกได้ ยิ่งเจอปัญหามากยิ่งเก่งขึ้น สิ่งสำคัญคือต้องมีวิธีการที่เป็นระบบ ไม่เดาสุ่ม ใช้ OSI Model เป็นกรอบ เริ่มจาก Layer 1 ขึ้นไป ใช้เครื่องมือพื้นฐานให้คล่อง แล้วเสริมด้วย Wireshark เมื่อต้องวิเคราะห์ลึก
อ่านเพิ่มเติมเกี่ยวกับ SNMP Monitoring และ Firewall Best Practices ที่ siamlancard.com หรือจาก icafeforex.com และ siam2r.com
