แพ็กเก็ต VPN มีเช็กซัมกี่ตัว? ขึ้นอยู่กับสถานการณ์

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

ตรวจสอบว่าเวอร์ชัน IP ใดอยู่บนสายจริง

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

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

outer IPv6 | ESP | inner IPv6 | UDP | application data
outer IPv4 | ESP | inner IPv4 | TCP | application data

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

ตรวจสอบว่าแต่ละเช็กซัมครอบคลุมอะไร

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

RFC 791 กำหนดการตรวจสอบส่วนหัว IPv4 และการคำนวณใหม่ในทุกฮอป และ RFC 8200 กำหนดการจัดการชั้นบนบน IPv6 รวมถึงส่วนหัวเทียม ไม่มีเอกสารใดกล่าวว่าแพ็กเก็ต VPN มีจำนวนเช็กซัมคงที่ เพราะไม่มีเอกสารใดอธิบายอุโมงค์

tshark -r capture.pcap -Y "ip.proto == 50" -V | grep -i checksum

ตรวจสอบการป้องกันความสมบูรณ์แยกต่างหาก

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

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

tshark -r capture.pcap -Y esp -V | grep -iE "integrity|icv"

ตรวจสอบจุดสังเกตก่อนนับ

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

sudo tcpdump -ni eth0 -vv -c 5 esp
sudo tcpdump -ni tun0 -vv -c 5

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

เทียบจำนวนกับแคปเจอร์จริง

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

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

tshark -r capture.pcap -T fields -e ip.checksum -e udp.checksum -e tcp.checksum