ทำไมเซ็นเซอร์ VPN ของคุณจึงไม่เคยเห็นแท็ก VLAN ของสาขา
อุโมงค์แบบกำหนดเส้นทางกู้คืนแพ็กเก็ต ไม่ใช่เฟรมที่บรรทุกมันมา การตรวจสอบสี่ข้อเกี่ยวกับชนิดอินเทอร์เฟซ ตำแหน่งเซ็นเซอร์ บริบทต้นทาง และเส้นทางตอบกลับ
เซ็นเซอร์ฝั่ง VPN เห็น VLAN ของสาขาสองตัวเป็นเพียงทราฟฟิก IP ธรรมดา และแท็กที่ระบุสาขาแต่ละแห่งบนสายของตัวเองนั้นหายไปแล้ว นั่นคือสิ่งที่อุโมงค์แบบกำหนดเส้นทางทำ: มันกู้คืนแพ็กเก็ต ไม่ใช่เฟรม Ethernet ที่ส่งมันมา แท็กที่หายไปสำคัญหรือไม่นั้นขึ้นอยู่กับคำถามที่คุณถามเซ็นเซอร์อย่างสิ้นเชิง ทำการตรวจสอบสี่ข้อด้านล่างตามลำดับ แล้วคุณจะรู้ว่าจุดสังเกตใดสามารถตอบคำถามนั้นได้
ข้อแรก: ระบุให้ชัดว่าอุโมงค์ของคุณกู้คืนอะไร
อินเทอร์เฟซ TUN บรรทุกแพ็กเก็ต IP ดังนั้นหัว VLAN ของเฟรมสาขาจะหยุดที่เราเตอร์ที่ดันทราฟฟิกเข้าไปในอุโมงค์ อินเทอร์เฟซ TAP บรรทุกเฟรม Ethernet ซึ่งหมายความว่าแท็กอาจอยู่รอดได้เมื่อบริดจ์และกฎการรับ VLAN ยอมให้ผ่าน อ่านชนิดอินเทอร์เฟซก่อนจะให้เหตุผลว่าการดักจับควรมีอะไร
ไม่มีตัวเลือกใดเป็นข้อบกพร่อง การออกแบบทั้งสองตอบคำถามต่างกันและทิ้งแท็กไว้คนละที่
ยืนยันชนิดอินเทอร์เฟซด้วยตัวเองแทนการอนุมานจากชื่อผลิตภัณฑ์ รายละเอียดของลิงก์ระบุชนิดอุปกรณ์และแสดงแฟล็กที่บังคับใช้ และการดักจับที่ทำบนอุปกรณ์ TUN จะไม่ได้หัว Ethernet เพียงเพราะคุณขอ หากแท็กยังปรากฏในการดักจับ TUN คุณเกือบแน่นอนว่ากำลังอ่านอินเทอร์เฟซอื่นหรืออุโมงค์ที่บรรทุกเฟรมไว้ในเพย์โหลด บันทึกว่าคุณอยู่ในกรณีใดก่อนดำเนินการต่อ
ข้อสอง: วางเซ็นเซอร์ไว้ที่ที่วัตถุยังมีอยู่
สามตำแหน่งครอบคลุมการออกแบบแบบกำหนดเส้นทางส่วนใหญ่: ส่วน Ethernet ของสาขา เครือข่ายภายนอกระหว่างปลายอุโมงค์ และเส้นทางหลังการประมวลผลอุโมงค์ แต่ละตำแหน่งเห็นวัตถุต่างกัน และแท็กมีอยู่เฉพาะตำแหน่งแรก การเลือกตำแหน่งเซ็นเซอร์เป็นการตัดสินใจว่าองค์ประกอบใดที่นโยบายต้องการ ไม่ใช่เรื่องของความสะดวก
| Observation point | What is actually there | Question it can answer |
|---|---|---|
| Branch Ethernet segment | Tagged frames on the local wire | Which VLAN carried this frame here |
| Outer tunnel network | The protected carrier between endpoints | Which endpoints are exchanging traffic |
| After tunnel processing | Recovered IP packets | Which branch prefix the packet claims |
ตั้งคำถามเชิงนโยบายด้วยถ้อยคำที่ตารางตอบได้ และมักจะคลี่คลายเอง หากกฎต้องรู้ว่าแพ็กเก็ตมาจากสาขาใด การแมปคำนำหน้าปลายทางอาจเพียงพอ แต่เฉพาะตราบใดที่การแมปนั้นแม่นยำและไม่กำกวม หากกฎต้องรู้ว่าเฟรมมาถึงพอร์ตใด คุณต้องใช้ตำแหน่งแรก เพราะไม่มีสิ่งใดปลายทางสามารถสร้างมันขึ้นใหม่ได้ เซ็นเซอร์ที่วางตามความเคยชินแทนที่จะวางตามคำถามคือเหตุผลที่ทีมต่างๆ ลงเอยด้วยการเรียกร้องฟิลด์ที่การออกแบบไม่เคยบรรทุก
อุโมงค์ที่บรรทุก Ethernet เป็นการออกแบบอีกแบบและต้องตรวจสอบของตัวเองว่าปลายทั้งสองรักษาหรือเขียนใหม่สิ่งใด การเลือก TAP เพียงอย่างเดียวยังไม่นิยามบริดจ์ กฎการรับ VLAN หรือนโยบายการตรวจสอบ
ข้อสาม: ได้มาซึ่งบริบทต้นทางแทนการเชื่อถือมัน
ช่วงที่อยู่หนึ่งช่วงต่อสาขาเป็นสิ่งทดแทนตัวตน VLAN ตามปกติ และใช้ได้เฉพาะตราบใดที่การแมปยังเป็นหนึ่งต่อหนึ่ง คำนำหน้าที่ทับซ้อน การแปล และเกตเวย์ที่ใช้ร่วมกันแต่ละอย่างล้วนทำลายสมมติฐานนั้นในแบบที่ดูเหมือนปัญหาคุณภาพข้อมูลมากกว่าปัญหาการออกแบบ เขียนการแมปพร้อมขอบเขตของมัน และบอกว่าเกิดอะไรขึ้นกับแพ็กเก็ตที่ตรงกับสองแถว คำนำหน้าที่ปรากฏในสองสาขาควรเป็นข้อผิดพลาดที่คุณตรวจพบ ไม่ใช่การโยนเหรียญที่คุณยอมรับ
บริบทที่ไคลเอนต์ให้มาไม่ใช่หลักฐานของการเป็นสมาชิก มันเป็นข้อกล่าวอ้าง และที่ของมันอยู่ในคอลัมน์อื่น
ในที่ที่ความต่างนี้สำคัญ ให้ใช้ข้อมูลความเชื่อมโยงที่คุณควบคุมได้: อินสแตนซ์อุโมงค์ใดรับการเชื่อมต่อ แพ็กเก็ตมาถึงอินเทอร์เฟซใด ตารางเส้นทางท้องถิ่นกล่าวถึงเพื่อนนั้นว่าอย่างไร ป้ายที่ไคลเอนต์ให้มาเป็นเบาะแสที่มีประโยชน์และเป็นอินพุตการอนุญาตที่ไร้ประโยชน์ หากเซ็นเซอร์ไม่สามารถสร้างความเชื่อมโยงจากฝั่งของตัวเองได้ นโยบายต้องการกฎที่กว้างขึ้น ไม่ใช่การคาดเดาอย่างมั่นใจ
ข้อสี่: ยืนยันเส้นทางตอบกลับและสิ่งที่การถอดรหัสพลาดไป
เซ็นเซอร์ที่เห็นเพียงทิศทางเดียวยังดูปกติได้ เพราะคำขอยังมาถึงตามกำหนด ตรวจสอบเส้นทางตอบกลับอย่างชัดเจน และตรวจสอบสำหรับโฟลว์เดียวกัน ไม่ใช่สำหรับการเข้าถึงโดยทั่วไป การมองเห็นแบบครึ่งสองทิศทางกลายเป็นช่องว่างเงียบในข้อสรุปเชิงสถานะใดก็ตามที่คุณดึงออกมา
การกู้คืนทราฟฟิก IP ภายในก็ไม่เหมือนกับการเห็นแอปพลิเคชันที่อยู่ข้างใน เพราะ TLS ที่บรรทุกผ่านอุโมงค์ยังคงเป็น TLS
ip -d link show tun0
tcpdump -i tun0 -n -e -c 5สองคำสั่งนั้นตอบคำถามเรื่องอินเทอร์เฟซและแสดงว่าการดักจับมีอะไรจริงๆ ซึ่งเร็วกว่าการถกเถียงเรื่องสถาปัตยกรรม แทนที่ด้วยชื่ออินเทอร์เฟซที่การออกแบบของคุณใช้ แล้วรันการดักจับขณะที่โฟลว์ที่คุณสนใจทำงานอยู่ เมื่อไม่มีแท็กปรากฏบนอุปกรณ์ TUN ข้อค้นพบคือการออกแบบเลือกกำหนดเส้นทางแทนการบริดจ์ ไม่ใช่เซ็นเซอร์ทำข้อมูลตกหล่น จากนั้นย้ายเซ็นเซอร์ไปยังตำแหน่งที่มองเห็นแท็ก หรือเขียนกฎใหม่ด้วยถ้อยคำที่ตำแหน่งปัจจุบันรองรับได้