Network Fundamental › เครื่องมือวินิจฉัย

จับแพ็กเก็ต — เครื่องมือที่เห็นน้อยกว่าที่ทุกคนคิด

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

2026-09-19 · หมวด 5 · เครื่องมือวินิจฉัย · 7 นาที

ห้าบทบนเว็บนี้ลงท้ายด้วยคำแนะนำทำนองว่า "ถ้าอยากรู้จริง ๆ ให้ไปจับแพ็กเก็ตดู"

บทนี้อธิบายว่าเครื่องมือนั้นทำงานอย่างไร และที่สำคัญกว่าคือมันเห็นอะไรบ้าง เพราะคำตอบข้อหลังทำให้คนผิดหวังบ่อยกว่าที่ควร

บอกไว้ก่อน บทนี้ไม่มีผลจับจริง

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

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

ถ้ายังไม่เคยดู เริ่มตรงนี้

คำสั่งนี้ไม่ต้องใช้สิทธิ์พิเศษ

$ tcpdump -D

มันแสดงรายชื่ออินเทอร์เฟซที่จับได้ การได้รายชื่อไม่ได้แปลว่าจับได้ ซึ่งเป็น เส้นแบ่งที่บทนี้จะอธิบาย

กลไกอยู่ในเคอร์เนล ไม่ได้อยู่ในโปรแกรม

tcpdump และ Wireshark ไม่ได้ดักจับอะไรด้วยตัวเอง ทั้งคู่คุยกับกลไกในระบบ ปฏิบัติการ ซึ่งบนเครื่องนี้มีคู่มือของตัวเอง

$ man bpf

คู่มือนิยามไว้ในประโยคเดียวที่อธิบายทุกอย่าง

"The Berkeley Packet Filter provides a raw interface to data link layers in a protocol independent fashion. All packets on the network, even those destined for other hosts, are accessible through this mechanism."

ประโยคที่ว่า "even those destined for other hosts" คือเหตุผลทั้งหมดที่มันต้อง ใช้สิทธิ์พิเศษ

สิทธิ์นั้นอยู่ในระบบไฟล์

คู่มือบอกว่ากลไกนี้ปรากฏเป็นอุปกรณ์

"The packet filter appears as a character special device, /dev/bpf0, /dev/bpf1, etc."

บนเครื่องที่ใช้เขียนบทนี้

$ ls -l /dev/bpf0
  crw-------  root  wheel

สิทธิ์เป็น 600 และเจ้าของคือ root ไม่มีกลุ่ม ไม่มีคนอื่น ซึ่งแปลว่าใครที่ เปิดอุปกรณ์นี้ได้ อ่านทราฟฟิกของทุกคนบนเครื่องนั้นได้

เมื่อลองจับโดยไม่มีสิทธิ์ ข้อความที่ได้จึงตรงไปตรงมา

  tcpdump: lo0: You don't have permission to capture on that device
  (cannot open BPF device) /dev/bpf0: Permission denied

คู่มือของ tcpdump เองก็แยกสองกรณีไว้ชัด

"Reading packets from a network interface may require that you have special privileges"

"Reading a saved packet file doesn't require special privileges."

อ่านไฟล์ที่คนอื่นจับมาแล้วไม่ต้องใช้สิทธิ์ ซึ่งเป็นทางที่ใช้ได้จริงในหลาย สถานการณ์

ตัวกรองทำงานในเคอร์เนล ไม่ใช่ในโปรแกรม

จุดที่คนเข้าใจผิดบ่อยคือคิดว่าโปรแกรมรับทุกอย่างมาแล้วค่อยคัด

คู่มืออธิบายไว้ว่าไม่ใช่

"Sets the filter program used by the kernel to discard uninteresting packets."

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

และเครื่องมือรายงานการตกหล่นนั้นด้วย คู่มือระบุโครงสร้างสถิติไว้ว่ามีสองค่า

  bs_recv   จำนวนแพ็กเก็ตที่รับมา
  bs_drop   จำนวนแพ็กเก็ตที่ตกหล่น

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

promiscuous mode — และเหตุผลที่มันช่วยน้อยกว่าที่คิด

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

"BIOCPROMISC Forces the interface into promiscuous mode."

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

  device   what reaches your port
  hub      ทุกเฟรมในวง
  switch   เฉพาะของคุณ บวกกระจายข่าว multicast และปลายทางที่ยังไม่รู้

บนสวิตช์ promiscuous mode แทบไม่เพิ่มอะไรเลย เพราะสวิตช์ไม่ได้ส่งของคนอื่น มาให้ตั้งแต่แรก การเปิดโหมดนี้แล้วคาดว่าจะเห็นทราฟฟิกของทั้งวง คือความคาดหวังที่ มาจากยุคฮับ

นั่นคือเหตุผลที่การจับแพ็กเก็ตในเครือข่ายสมัยใหม่ต้องทำที่จุดที่ถูกต้อง คือบน เครื่องปลายทางเอง หรือบนพอร์ตที่ถูกตั้งให้ทำสำเนามาให้

รายละเอียดเล็ก ๆ ที่คู่มือเตือนไว้

"Since more than one file can be listening on a given interface, a listener that opened its interface non-promiscuously may receive packets promiscuously."

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

เมื่อมันโกหก

"เปิด promiscuous แล้วเห็นทั้งวง" จริงกับฮับ ไม่จริงกับสวิตช์ ซึ่งคือทุกที่ ในปัจจุบัน

"จับแพ็กเก็ตแล้วเห็นทุกอย่าง" เห็นเท่าที่มาถึงการ์ด และเห็นเท่าที่ไม่ตกหล่น ค่า bs_drop บอกส่วนที่หายไป

"tcpdump ต้องใช้ root เพราะเป็นเครื่องมือของผู้ดูแลระบบ" ต้องใช้เพราะอุปกรณ์ ที่ให้ข้อมูลนั้นเห็นทราฟฟิกของทุกคน ตามที่คู่มือ bpf ระบุ

"ตัวกรองทำให้ประมวลผลช้าลง" ตรงกันข้าม มันทำงานในเคอร์เนลเพื่อลดของที่ต้อง คัดลอกขึ้นมา ยิ่งกรองแคบยิ่งตกหล่นน้อย

"เห็นแพ็กเก็ตแล้วรู้ทุกอย่าง" สิ่งที่เข้ารหัสยังคงอ่านไม่ออก ตามที่บทความ TLS อธิบาย จับได้แต่เนื้อหาไม่ได้

ตัวอย่างจริงจากงานจริง

กรณีที่ 1 — จับแล้วไม่เห็นอะไรเลย

สถานการณ์ ตั้งเครื่องจับไว้บนสวิตช์ แล้วเห็นแต่ทราฟฟิกของเครื่องตัวเอง

อ่านอย่างไร นี่คือพฤติกรรมปกติของสวิตช์ ตามที่บทความ โดเมนการชน อธิบาย ไม่ใช่ความผิดพลาด ของเครื่องมือ ต้องย้ายจุดจับไปที่เครื่องปลายทาง หรือขอให้สวิตช์ทำสำเนาให้

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

กรณีที่ 2 — ข้อมูลที่จับได้ไม่ครบ

สถานการณ์ วิเคราะห์แล้วพบว่าลำดับแพ็กเก็ตขาดหาย

อ่านอย่างไร ดูตัวเลขที่เครื่องมือรายงานตอนจบ ถ้ามีค่าที่บอกว่า dropped ไม่เป็นศูนย์ แปลว่าเคอร์เนลตกหล่น ไม่ใช่เครือข่ายทำหาย ทางแก้คือกรองให้แคบลง ตั้งแต่ต้น

สิ่งที่ยังไม่ได้พิสูจน์ การตกหล่นที่ตัวจับ กับการสูญหายในเครือข่าย ให้อาการ คล้ายกันในไฟล์ผลลัพธ์ ต้องแยกด้วยตัวเลขสถิตินี้ก่อน

กรณีที่ 3 — ไม่มีสิทธิ์บนเครื่องที่ต้องการดู

สถานการณ์ ต้องการข้อมูลจากเครื่องที่ยกสิทธิ์ให้ไม่ได้

อ่านอย่างไร คู่มือ tcpdump ระบุว่าการอ่านไฟล์ที่บันทึกไว้แล้วไม่ต้องใช้ สิทธิ์พิเศษ ให้คนที่มีสิทธิ์บันทึกไฟล์มาให้ แล้ววิเคราะห์ต่อได้ตามปกติ

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

สิ่งที่เครื่องมือนี้สอน

การจับแพ็กเก็ตให้ความรู้สึกว่า เห็นความจริงทั้งหมด ซึ่งเป็นความรู้สึกที่ อันตราย

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

เครื่องมือที่ดีที่สุดในการดูเครือข่าย ก็ยังบอกได้แค่สิ่งที่มาถึงจุดที่มันยืนอยู่

อ้างอิง

จากเครื่องที่ใช้เขียน

• man bpf — นิยามของกลไก ประโยคเรื่องแพ็กเก็ตที่ส่งถึงเครื่องอื่น การตั้งตัวกรอง ในเคอร์เนล โหมด promiscuous และโครงสร้างสถิติที่มี bs_recv กับ bs_drop ประโยคที่ยกมาอ้างทั้งหมดในบทนี้มาจากหน้านี้
• man tcpdump — สองประโยคเรื่องสิทธิ์ในการจับ เทียบกับการอ่านไฟล์ที่บันทึกไว้
• ls -l /dev/bpf0 — สิทธิ์ 600 เจ้าของ root
• tcpdump -D — ทำงานได้โดยไม่ต้องใช้สิทธิ์พิเศษ

สิ่งที่บทนี้ทำไม่ได้

• ไม่มีผลการจับแพ็กเก็ตจริง เพราะต้องใช้สิทธิ์ระดับ root ซึ่งไม่ได้ยกให้ สิ่งที่แสดงคือกลไกและขอบเขต ไม่ใช่ตัวอย่างผลลัพธ์

วัดจากเครื่องจริง

อ่านหน้านี้เป็นภาษาอังกฤษ