Networking Tools — ถามเครือข่ายให้เป็น แล้วค่อยเลือกเครื่องมือ

1วิธีคิดก่อนพิมพ์คำสั่ง

2กติกาและการเตรียมแล็ป

1. ใช้เฉพาะเครื่องและเครือข่ายที่ได้รับอนุญาต การ scan port หรือจับ packet ของผู้อื่นอาจขัดนโยบายและกฎหมาย
2. เตรียม Windows PowerShell หรือ Linux/macOS terminal ถ้ามี VM/container ให้ใช้เป็นปลายทางทดลองของตนเอง
3. สร้างแฟ้มบันทึก มีเวลา คำถาม คำสั่ง ผลที่สำคัญ การตีความ และคำสั่งถัดไป ทุกข้อสรุปต้องชี้กลับไปหาหลักฐาน
4. ชื่อ interface และคำสั่งต่างกันตามระบบ ให้ปรับ eth0, en0, Wi-Fi และ IP ให้ตรงเครื่องจริง

3Lab A — สำรวจเครื่องของเรา

ipconfig /all
Get-NetIPConfiguration
Get-NetAdapter
Get-DnsClientServerAddress

ip addr        # macOS: ifconfig
ip link
ip route
cat /etc/resolv.conf

1. ระบุ active interface, IPv4/IPv6, prefix/netmask, default gateway และ DNS server
2. คำนวณว่า IP ของตนกับ gateway อยู่ subnet เดียวกันหรือไม่ อย่าเพียงคัดลอกค่า
3. ปิด Wi-Fi หรือถอดสายชั่วคราวแล้วรันใหม่ สังเกต state และ address ที่หายไป เปิดคืนหลังบันทึก
4. ถ้ามี VPN ให้เปรียบเทียบก่อนและหลังเชื่อม ดู interface กับ route ที่เพิ่มขึ้น โดยไม่เผยแพร่ข้อมูลภายใน

4Lab B — Ping: การตอบไม่ได้ไม่ได้แปลว่าปลายทางล่ม

# Windows
ping 127.0.0.1
ping <default-gateway>
ping -n 10 1.1.1.1
ping -l 1400 -f <authorized-target>

# Linux/macOS
ping -c 10 1.1.1.1
ping -s 1400 -M do <authorized-target>   # ตัวเลือกขึ้นกับ OS

1. ping loopback, IP ตัวเอง, gateway, public IP และ hostname ตามลำดับ แต่ละจุดตอบคำถามต่างกัน
2. เก็บ min/avg/max และ packet loss ทำซ้ำขณะเครือข่ายว่างกับขณะดาวน์โหลดไฟล์ แล้วอธิบาย jitter
3. ping IP สำเร็จแต่ ping ชื่อไม่สำเร็จ ชี้ไปที่ DNS มากกว่า link/routing
4. HTTP ใช้ได้แต่ ping ไม่ตอบ อาจเพราะ firewall ปิด ICMP ไม่ใช่หลักฐานว่า host ล่ม
5. ทดลองขนาด payload โดยได้รับอนุญาต เพื่อเชื่อมกับ MTU และ fragmentation หยุดถ้าเครือข่ายไม่ใช่ของตนเอง

Ping เปรียบเหมือนถามหน้าบ้านว่า “มีใครอยู่ไหม” บางบ้านตั้งใจไม่ตอบคนแปลกหน้า แต่ร้านด้านในอาจยังเปิดรับลูกค้าทางประตู HTTP ตามปกติ จึงต้องทดสอบบริการที่ผู้ใช้ต้องการจริงด้วย

5Lab C — ARP/Neighbor: จาก IP ไปหา MAC ในวงเดียวกัน

# Windows
arp -a
Get-NetNeighbor

# Linux
ip neigh show
ip neigh flush <gateway-ip>   # ทำเฉพาะเครื่องตนและเมื่อเข้าใจผล

1. ดูก่อน ping gateway แล้วดูอีกครั้ง หา entry ที่เพิ่มหรือ state ที่เปลี่ยน
2. จับ packet ด้วย filter arp แล้วระบุว่าใครถาม “Who has …” และใครตอบ MAC ใด
3. ping public IP แล้วสังเกตว่า ARP table มี MAC ของ public server หรือมีเพียง MAC ของ gateway เพราะ Ethernet frame ส่งถึง next hop ไม่ได้ส่งข้ามอินเทอร์เน็ตโดยตรง
4. อธิบาย INCOMPLETE/FAILED/STALE/REACHABLE ตามระบบที่ใช้ และเหตุใด cache จึงต้องหมดอายุ

6Lab D — Route: ป้ายบอกทางก่อน packet ออกจากเครื่อง

# Windows
route print
Get-NetRoute | Sort-Object DestinationPrefix

# Linux/macOS
ip route
ip route get 8.8.8.8
netstat -rn

1. หา connected route, loopback route และ default route 0.0.0.0/0
2. เลือกปลายทางสามตัว: subnet เดียวกัน, private subnet อื่น, อินเทอร์เน็ต ระบุ route ที่ชนะด้วย longest-prefix match ก่อนดูคำตอบจากระบบ
3. ถ้ามีสอง route prefix เท่ากันจึงพิจารณา metric อย่าสับสนว่าค่า metric ชนะ prefix ที่เฉพาะกว่าเสมอ
4. ทดลองดู route ก่อน/หลัง VPN แล้วอธิบาย split tunnel กับ full tunnel จากตารางจริง

7Lab E — Tracert, Traceroute, Pathping และ MTR

# Windows
tracert example.com
tracert -d example.com
pathping example.com

# Linux/macOS
traceroute example.com
traceroute -n example.com
mtr -rwzc 50 example.com

Traceroute ส่ง probe ด้วย TTL เพิ่มจาก 1, 2, 3 … เมื่อ TTL หมด router มักส่ง ICMP Time Exceeded กลับมา จึงค่อย ๆ เห็นเส้นทาง เหมือนส่งนักวิ่งพร้อมตั๋วเดินทางได้หนึ่งสถานี แล้วเพิ่มเป็นสองสถานีเพื่อถามว่าเขาหยุดที่ไหน

1. เปรียบเทียบแบบ resolve hostname กับ -d/-n ว่า DNS lookup ทำให้การแสดงผลช้าหรือเปลี่ยนอย่างไร
2. ทำซ้ำสามครั้ง เส้นทางอาจเปลี่ยนจาก load balancing อย่าถือผลครั้งเดียวเป็นแผนที่ถาวร
3. เครื่องหมาย * ที่ hop กลางแต่ปลายทางถึง ไม่ได้แปลว่า router นั้นล่ม อาจไม่ตอบหรือ rate-limit ICMP
4. ถ้า hop หนึ่งแสดง loss แต่ hop ถัดไปไม่ loss อย่าสรุปว่า hop แรกทำ packet หาย มันอาจลดความสำคัญของการตอบ probe แต่ยัง forward traffic ปกติ
5. ใช้ MTR/pathping แยก latency ต่อเนื่องจากตัวอย่างระยะสั้น และเขียนข้อจำกัดของการวัดเส้นทางขาไปซึ่งไม่รับประกันว่าเหมือนขากลับ

8Lab F — DNS ด้วย nslookup, dig และ Resolve-DnsName

# ใช้ได้ทั่วไป
nslookup example.com
nslookup -type=mx example.com

# Linux/macOS
dig example.com A
dig example.com AAAA
dig example.com MX
dig example.com NS
dig +trace example.com

# PowerShell
Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Type MX

1. ค้น A, AAAA, CNAME, MX, NS และ TXT แล้วเขียนว่าระเบียนแต่ละชนิดตอบคำถามใด
2. ถาม resolver ปกติและ resolver อื่นที่ได้รับอนุญาต เปรียบเทียบ answer, TTL และเวลา คำตอบต่างกันอาจเกิดจาก cache, CDN หรือ split DNS
3. สังเกต TTL สองครั้งห่างกัน ถ้าตอบจาก cache ค่ามักลดลง TTL เป็นอายุป้ายบอกทาง ไม่ใช่เวลาที่รับประกันว่า record จะหายจากทุกที่พร้อมกัน
4. ใช้ชื่อที่ไม่มีจริง แยก NXDOMAIN จาก timeout และ SERVFAIL ทั้งสามอย่างมีการแก้ต่างกัน
5. อธิบายว่า DNS สำเร็จแปลเพียงได้ address ยังไม่ได้พิสูจน์ว่า TCP port หรือ application ใช้งานได้

9Lab G — Port และ Socket ด้วย netstat/ss

# Windows
netstat -ano
Get-NetTCPConnection -State Listen
tasklist /fi "PID eq <pid>"

# Linux
ss -lntup
ss -tan state established
lsof -iTCP -sTCP:LISTEN

1. เปิด Python HTTP server python -m http.server 8000 แล้วหา LISTEN socket กับ PID
2. เปิด browser/curl แล้วหา ESTABLISHED connection ระบุ local/remote address และ port
3. ปิด server สังเกต TIME_WAIT ที่ฝั่งซึ่ง active close และเชื่อมกลับไปยัง TCP lifecycle
4. เปรียบเทียบ bind ที่ 127.0.0.1 กับ 0.0.0.0 โดยทดสอบจากเครื่องอื่นที่ได้รับอนุญาต

10Lab H — ทดสอบ Port, HTTP และ TLS

# TCP port
Test-NetConnection example.com -Port 443
nc -vz example.com 443

# HTTP
curl -I https://example.com
curl -v https://example.com
curl -sS -o /dev/null -w "code=%{http_code} connect=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n" https://example.com

# TLS certificate/handshake
openssl s_client -connect example.com:443 -servername example.com

1. ทดสอบ port ที่เปิดและปิดบนเครื่องทดลอง แยก refused จาก timeout
2. ใช้ curl -v ระบุ DNS, connect, TLS, request และ response ตามลำดับ แล้วบอกว่าช้าช่วงใดจาก timing
3. ทดลองเรียก HTTPS ด้วย hostname และ IP ตรง เปรียบเทียบ certificate validation และ SNI ชื่อไม่ได้มีไว้แค่ DNS แต่ยังช่วยเลือก certificate/virtual host
4. ดู issuer, subject/SAN และวันหมดอายุของ certificate ห้ามใช้ -k เป็นวิธีแก้ถาวร เพราะเพียงปิดการตรวจตัวตน
5. ใช้ curl --resolve ในระบบทดลองเพื่อบังคับชื่อไป IP โดยยังรักษา Host/SNI เหมาะกับทดสอบ server ใหม่ก่อนแก้ DNS

11Lab I — Packet Capture ด้วย tcpdump และ Wireshark

# เริ่มแคบก่อน ลดข้อมูลส่วนเกิน
tcpdump -i any -nn host <lab-ip>
tcpdump -i any -nn 'tcp port 8000'
tcpdump -i any -nn -w lab.pcap 'host <lab-ip> and (icmp or tcp port 8000)'

# ตัวอย่าง Wireshark display filters
arp
icmp
dns
tcp.port == 8000
tcp.flags.syn == 1 && tcp.flags.ack == 0
tcp.analysis.retransmission

1. จับ ARP → DNS → TCP handshake → HTTP → TCP close ในงานเดียว แล้วเรียงเป็น timeline
2. เลือก SYN, SYN-ACK, ACK ระบุ sequence/acknowledgment แบบสัมพัทธ์และเวลาระหว่าง packet
3. แยก capture filter ซึ่งกำหนดสิ่งที่จะเก็บตั้งแต่ต้น ออกจาก display filter ซึ่งเลือกแสดงจากข้อมูลที่เก็บแล้ว
4. ถ้า HTTPS จะเห็น TLS record และ metadata บางส่วน แต่ไม่เห็น HTTP body ตามปกติ นี่คือหลักฐานว่าการเข้ารหัสปกป้องเนื้อหา ไม่ได้ทำให้ traffic หายจากสาย
5. ห้ามจับ traffic เกินขอบเขตแล็ป และลบ/เก็บ pcap ตามนโยบาย เพราะ pcap อาจมีข้อมูลละเอียดกว่าภาพหน้าจอมาก

12Lab J — วัด Throughput ด้วย iperf3

# เครื่องปลายทางที่เราได้รับอนุญาต
iperf3 -s

# เครื่อง client
iperf3 -c <server-ip>
iperf3 -c <server-ip> -R
iperf3 -c <server-ip> -P 4
iperf3 -c <server-ip> -u -b 10M

1. วัด TCP ไปและกลับ เปรียบเทียบเพราะ Wi-Fi, shaping หรือเส้นทางอาจไม่สมมาตร
2. เปรียบเทียบ stream เดียวกับหลาย stream อธิบายว่าได้เร็วขึ้นไม่ได้แปลว่า application จริงจะเปิดหลาย connection ได้เสมอ
3. ทดลอง UDP ด้วยอัตราที่ควบคุม ดู loss และ jitter ห้ามยิงเกินขนาดเครือข่ายที่ได้รับอนุญาต
4. เก็บ CPU, signal strength และตำแหน่งร่วมด้วย Throughput ต่ำไม่ได้ชี้สาเหตุเอง อาจมาจาก radio, congestion, disk หรือข้อจำกัดปลายทาง

13สถานการณ์วินิจฉัยแบบปลายเปิด

สถานการณ์ 1 — “เข้าเว็บไม่ได้ แต่เพื่อนเข้าได้”

1. ตรวจ interface/IP/gateway และ scope ว่าปัญหาอยู่เครื่องเดียวหรือทั้งวง
2. ping gateway แล้ว public IP ถ้า IP ได้แต่ชื่อไม่ได้ ตรวจ DNS
3. ใช้ nslookup/dig ดูคำตอบ จากนั้น curl -v แยก connect, TLS และ HTTP
4. ตรวจ proxy/VPN/hosts file และ route เฉพาะเมื่อหลักฐานพาไป ไม่สุ่มปิดระบบความปลอดภัย

สถานการณ์ 2 — “Service รันแล้ว แต่เครื่องอื่นเรียกไม่ได้”

1. ใช้ ss/netstat ตรวจว่าฟัง port จริงและ bind ที่ loopback หรือทุก interface
2. ทดสอบ loopback, IP ตัวเอง และจากเครื่องอื่นตามลำดับ
3. ตรวจ route/ARP ระหว่างเครื่อง แล้วจึงตรวจ host firewall และ container port mapping
4. จับ packet ที่ server: ไม่เห็น SYN แปลว่าปัญหาก่อนถึงเครื่อง เห็น SYN แต่ไม่มี SYN-ACK ชี้ไปที่ firewall/listener เห็น handshake แล้ว HTTP error ชี้ขึ้น application

สถานการณ์ 3 — “ประชุมออนไลน์กระตุก แต่ speed test ดูเร็ว”

1. วัด packet loss, latency และ jitter ต่อเนื่อง ไม่ดู throughput อย่างเดียว
2. เปรียบเทียบ Wi-Fi กับสาย และช่วงว่างกับช่วงมี upload เพราะ queue เต็มอาจทำ latency สูง
3. ดู route/MTR อย่างระวัง ไม่กล่าวโทษ hop จาก ICMP loss เพียงจุดเดียว
4. อธิบายว่า realtime สนใจ packet มาถึงทันเวลามากกว่าความเร็วเฉลี่ย ไฟล์ดาวน์โหลดรอ retransmission ได้ แต่เสียงที่มาช้าไม่ช่วยการสนทนา

สถานการณ์ 4 — “บางครั้งเร็ว บางครั้งช้า”

1. เก็บข้อมูลหลายเวลา พร้อม DNS answer, destination IP, connect/TLS/TTFB/total
2. แยกว่า CDN ส่งไปคนละ IP, connection reuse, cache, server load หรือ network path เปลี่ยน
3. ใช้ correlation ID เชื่อม client timing กับ server log และ trace ถ้ามี
4. รายงานเป็น distribution/percentile ไม่สรุปจากค่าเฉลี่ยหรือการทดสอบครั้งเดียว

14แม่แบบรายงานแล็ป

15สรุปและขั้นตอนถัดไป

เครื่องมือเครือข่ายแต่ละตัวเหมือนไฟฉายที่ส่องได้บางมุม ipconfig/ip บอกตัวตนของเครื่อง arp บอกเพื่อนบ้าน route บอกทางออก ping ตรวจ ICMP traceroute เผยเส้นทางบางส่วน dig ตรวจสมุดรายชื่อ ss/netstat ดู socket curl คุยกับบริการ และ packet capture ใช้ตรวจเหตุการณ์จริง ขั้นถัดไปคือหยิบสถานการณ์หนึ่งจากระบบที่สร้างในแล็ป 1–4 แล้วใช้เครื่องมือเหล่านี้เขียนเรื่องราวจากอาการไปถึงสาเหตุโดยไม่กระโดดข้ามหลักฐาน