การสูญเสีย Ping บน VPN: จัดกลุ่มคำขอ Echo ก่อนคิดเป็นเปอร์เซ็นต์

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

ขั้นตอนที่ 1: แยกสตรีมตามแหล่งที่มาและปลายทาง

คำขอ Echo มีแหล่งที่มาและปลายทาง และสองฟิลด์นี้กำหนดว่าอยู่ในบทสนทนาใด โพรบที่เกตเวย์สร้างขึ้นใช้ที่อยู่อุโมงค์ของเกตเวย์ ขณะที่โพรบที่ส่งต่อในนามของโฮสต์ LAN ยังคงใช้ที่อยู่ของโฮสต์นั้น อีกฝั่งอาจมีเส้นทางกลับสำหรับตัวหนึ่งแต่ไม่มีสำหรับอีกตัว ซึ่งทำให้สองกลุ่มทำงานต่างกันด้วยเหตุผลที่ไม่เกี่ยวกับอุโมงค์เลย

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

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

ขั้นตอนที่ 2: จับคู่ด้วยตัวระบุและลำดับ

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

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

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

tshark -r capture.pcap -Y 'icmp.type == 8' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq
tshark -r capture.pcap -Y 'icmp.type == 0' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq

ขั้นตอนที่ 3: เปรียบเทียบทูเพิลที่ขอบเขตเดียวกัน

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

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

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

tcpdump -ni any icmp and host 10.90.0.1 -c 20
tshark -r capture.pcap -Y 'icmp' -T fields -e ip.src -e ip.dst -e ip.ttl | head -20

ขั้นตอนที่ 4: บอกว่าแคปเจอร์พิสูจน์อะไรได้และไม่ได้

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

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

จากนั้นแยกสิ่งที่การสังเกตยืนยันออกจากสิ่งที่มันบอกเป็นนัย ในสองประโยคแทนที่จะเป็นประโยคเดียว ประโยคแรกบอกจำนวนนับและขอบเขต ประโยคที่สองบอกสมมติฐานและสิ่งที่ จะยืนยันได้

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

รายงานกลุ่มและขอบเขตถัดไป

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

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

ping -c 5 -I 10.80.0.6 10.90.0.1
ping -c 5 -I 10.30.0.25 10.90.0.1
tshark -r capture.pcap -Y 'icmp.type == 8 || icmp.type == 0' -T fields -e ip.src -e ip.dst -e icmp.ident -e icmp.seq | sort | uniq -c | head

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