อุโมงค์ VPN คืออะไร และการป้องกันสิ้นสุดตรงไหน
อุโมงค์ห่อแพ็กเก็ตที่คัดเลือกไว้ในซองที่สองบนลิงก์ที่คุณมีอยู่แล้ว ติดตามคำขอหนึ่งรายการและดูว่าเว็บไซต์บันทึกที่อยู่ใดจริง ๆ
ไคลเอนต์บอกว่าเชื่อมต่อแล้ว แม่กุญแจล็อกอยู่ และเว็บไซต์ก็ยังบันทึกที่อยู่ห้องของคุณอยู่ดี ไม่มีอะไรล้มเหลว อุโมงค์ไม่ได้แทนที่ Wi-Fi หรือลิงก์มือถือของคุณ แต่ห่อหุ้มแพ็กเก็ตบางส่วนด้วยซองที่สองแล้วส่งซองนั้นผ่านเครือข่ายที่คุณมีอยู่แล้ว การเข้าใจกลอุบายนี้คือการติดตามคำขอหนึ่งรายการและสังเกตว่าซองถูกเปิดที่ไหน เพราะเกือบทุกอาการที่ชวนสับสน ตั้งแต่ที่อยู่บ้านรั่วไหลไปจนถึงการดาวน์โหลดขนาดใหญ่ค้าง ต่างมาจากเส้นแบ่งนั้น
สองซอง หนึ่งลิงก์กายภาพ
แล็ปท็อปของคุณยังคงเชื่อมต่อกับเราเตอร์ตามปกติ และเราเตอร์ก็เชื่อมต่อกับผู้ให้บริการตามปกติ ไม่มีอะไรเปลี่ยนบนเส้นทางนั้นเมื่ออุโมงค์ถูกยกขึ้น สิ่งที่เปลี่ยนคือแพ็กเก็ตที่เลือกจะถูกส่งให้อินเทอร์เฟซเสมือน ถูกห่อในแพ็กเก็ตใหม่ที่กำหนดที่อยู่ไปยังคู่ VPN และถูกส่งเป็นทราฟฟิกธรรมดาผ่านลิงก์กายภาพ
ฝั่งรับคืออุปกรณ์ที่เปิดซองและส่งต่อแพ็กเก็ตต้นทางไปยังปลายทาง ระหว่างสองปลาย ผู้สังเกตเห็นหัวข้อด้านนอกและไม่เห็นอะไรเกี่ยวกับด้านใน เว้นแต่โปรโตคอลจะเข้ารหัส ซึ่งโปรโตคอลผู้บริโภคส่วนใหญ่ทำ และเทคนิคทั่วไปไม่ได้บังคับ
นี่คือเหตุผลที่อินเทอร์เฟซเสมือนเป็นทั้งของจริงและหลอกลวง มันมีอยู่เป็นออบเจ็กต์เคอร์เนลที่มีที่อยู่และหน่วยส่งข้อมูลสูงสุด และระบบปฏิบัติการกำหนดเส้นทางทราฟฟิกเข้าไปเหมือนอินเทอร์เฟซอื่น ๆ มันไม่ใช่สายเคเบิล และการมีอยู่ของมันพิสูจน์เพียงว่ามีส่วนประกอบติดตั้งอยู่ เบราว์เซอร์ของคุณใช้มันหรือไม่นั้นขึ้นอยู่กับเส้นทาง ไม่ใช่การที่อินเทอร์เฟซเปิดอยู่
ติดตามคำขอหนึ่งรายการในการเดินทาง
เลือกปลายทางและถามเคอร์เนลว่าจะใช้อินเทอร์เฟซใด คำสั่งเดียวนี้ตัดสินข้อโต้แย้งส่วนใหญ่ว่าอุโมงค์ทำอะไรหรือไม่:
ip route get 203.0.113.7
ip -brief addr show
ip -4 addr show dev wg0หากเอาต์พุตของเส้นทางระบุอินเทอร์เฟซของอุโมงค์ แพ็กเก็ตจะถูกห่อ หากระบุอินเทอร์เฟซกายภาพ ก็จะไม่ถูกห่อ และการรีสตาร์ตไคลเอนต์ไม่ว่ากี่ครั้งก็ไม่เปลี่ยนสิ่งนั้น คำสั่งที่สองแสดงอินเทอร์เฟซทั้งสองเคียงกัน และนั่นคือวิธีที่คุณสังเกตเห็นอุโมงค์ที่ขึ้นมาโดยไม่มีที่อยู่หรือมีที่อยู่จากตระกูลที่ผิด
จากนั้นดูฮอปแรกจากภายในซอง และเปรียบเทียบกับฮอปแรกจากภายนอก:
traceroute -n -m 3 203.0.113.7
sudo tcpdump -ni wg0 -c 5ภายในอุโมงค์ ฮอปแรกคือที่อยู่ภายในของคู่ ไม่ใช่เราเตอร์ของคุณ การดักจับบนอินเทอร์เฟซของอุโมงค์แสดงแพ็กเก็ตภายใน ซึ่งเป็นทราฟฟิกที่แอปพลิเคชันคิดว่ากำลังส่ง การดักจับบนอินเทอร์เฟซกายภาพพร้อมกันแสดงแพ็กเก็ตภายนอก และทั้งสองอย่างรวมกันคือการสาธิตที่ชัดเจนที่สุดว่าอุโมงค์ทำอะไรจริง ๆ
สามที่อยู่ และเว็บไซต์เห็นเพียงหนึ่งเดียว
ผู้คนสับสนสิ่งเหล่านี้ตลอดเวลา และความสับสนนั้นสร้างรายงานการรั่วไหลที่เป็นเท็จ สิ่งเหล่านี้เป็นฟิลด์ที่แตกต่างกันในหัวข้อที่แตกต่างกันซึ่งมีอายุการใช้งานต่างกัน
| Address | Where it appears | Who can see it |
|---|---|---|
| Endpoint address | Outer header, the peer you connect to | Your access network and the path to it |
| Inner tunnel address | Inside the envelope, on the virtual interface | The peer, and anything the peer routes to |
| Exit address | Source of the packet that reaches the website | The website and its upstream |
ตัวเลขข้างอะแดปเตอร์เสมือนคือแถวที่สอง มันไม่ใช่ที่อยู่ที่เว็บไซต์บันทึก และการอ้างว่าเป็น IP สาธารณะของคุณก็เป็นความผิดพลาดอย่างชัดเจน ที่อยู่ที่เว็บไซต์เห็นถูกกำหนดโดยทางออก และในอุโมงค์เครือข่ายส่วนตัวอาจไม่มีทางออกสาธารณะเลย เพราะปลายทางอยู่ภายในองค์กรไม่ใช่อินเทอร์เน็ต
อุโมงค์ระหว่างไซต์เป็นกลไกเดียวกันกับปลายทางอื่น เราเตอร์สองตัวห่อทราฟฟิกระหว่างเครือข่าย และไม่มีอุปกรณ์ใดติดตั้งไคลเอนต์ไว้ อุโมงค์เหมือนกันในหลักการ แต่ขอบเขตการบริหารไม่เหมือน
ซองถูกเปิดที่ไหน และอะไรอยู่รอดจากมัน
อุโมงค์สิ้นสุดที่คู่ของมัน หากการเข้ารหัสของแอปพลิเคชันเองไปได้ไกลกว่านั้น มันก็อยู่รอดจากขอบเขตนั้น ซึ่งเป็นกรณีปกติของ HTTPS: เซสชันของเบราว์เซอร์สิ้นสุดที่เว็บไซต์ ดังนั้นทางออกจึงส่งต่อข้อความเข้ารหัสที่อ่านไม่ได้
ไม่มีอะไรอื่นอยู่รอดโดยค่าเริ่มต้น คำขอที่ไม่เข้ารหัสนั้นอ่านได้ที่ทางออกเหมือนกับที่อ่านได้ใน Wi-Fi ของร้านกาแฟ และอุโมงค์ไม่ได้เพิ่มการป้องกันที่แอปพลิเคชันไม่เคยมี เช่นเดียวกัน กฎไฟร์วอลล์และนโยบายการส่งต่อของทางออกเป็นตัวกำหนดว่าจะเกิดอะไรต่อไป การจับมือที่สำเร็จเป็นข้อเท็จจริงเกี่ยวกับการเชื่อมต่อกับคู่ ไม่ใช่เกี่ยวกับส่วนที่เหลือของการเดินทาง
โอเวอร์เฮดเป็นผลที่มองเห็นได้อีกอย่าง แต่ละแพ็กเก็ตมีหัวข้อเพิ่มเติม และการขนส่งชั้นนอกอาจเพิ่มของตัวเอง ดังนั้นเพย์โหลดที่ใช้ได้ต่อแพ็กเก็ตจึงลดลง บนเส้นทางที่มีหน่วยส่งข้อมูลสูงสุดคงที่ นี่คือเหตุผลที่อุโมงค์ส่ง ping ผ่านได้แต่ทำให้การอัปโหลดขนาดใหญ่หยุดชะงัก
ตรวจสอบเส้นทางที่แอปพลิเคชันใช้จริง
ขั้นตอนสุดท้ายคือยืนยันแอปพลิเคชันที่เฉพาะเจาะจง ไม่ใช่เครื่องโดยทั่วไป แก้ไขปลายทาง ดูเส้นทางสำหรับที่อยู่นั้น แล้วสังเกตการเชื่อมต่อขณะที่มันเปิดอยู่:
getent hosts example.com
ip route get "$(getent hosts example.com | awk '{print $1; exit}')"
ss -tnp state established '( dport = :443 )'หากเส้นทางระบุอุโมงค์ แต่รายการซ็อกเก็ตแสดงการเชื่อมต่อที่มีที่อยู่ต้นทางจากอินเทอร์เฟซกายภาพ แอปพลิเคชันผูกกับบางสิ่งเฉพาะ หรืออุโมงค์ที่สองกำลังแย่งเส้นทางเริ่มต้น นี่เป็นคำถามเรื่องการกำหนดเส้นทาง และตอบได้จากเอาต์พุตทั้งสามนี้ ไม่ใช่จากหน้าจอสถานะของไคลเอนต์
สถาปัตยกรรมความปลอดภัย RFC 4301 อธิบายเวอร์ชันชั้น IP ของการห่อนี้สำหรับ IPsec และตรรกะชั้นเดียวกันใช้กับ WireGuard และ OpenVPN เมื่อคุณชี้ไปที่แพ็กเก็ตภายในและแพ็กเก็ตภายนอกเป็นวัตถุแยกกันได้ พฤติกรรมส่วนใหญ่ของอุโมงค์ก็ไม่เป็นปริศนาอีกต่อไป และกลายเป็นตารางเส้นทางที่คุณอ่านได้