VM ของคุณใช้ VPN ของโฮสต์หรือไม่? ทดสอบจากภายในเกสต์

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

การทดสอบต้องรันภายในเกสต์ และต้องระบุว่าวัดอะไร

เริ่มจากภายในเกสต์ ไม่ใช่จากเบราว์เซอร์ของโฮสต์

บันทึกโหมดเครือข่ายของไฮเปอร์ไวเซอร์ก่อน: NAT, bridged, host-only หรือ macvtap ในโหมด NAT โฮสต์กำหนดเส้นทางทราฟฟิกของเกสต์ ดังนั้นอุโมงค์ของโฮสต์อาจใช้ได้หรือไม่ได้ ขึ้นอยู่กับวิธีที่ไคลเอนต์ติดตั้งเส้นทาง ในโหมด bridged เกสต์เป็นสมาชิกที่เท่าเทียมบน LAN จริง และอุโมงค์ของโฮสต์ไม่เกี่ยวข้อง สองโหมดนี้ให้คำตอบที่ตรงกันข้ามจากการตั้งค่าโฮสต์เดียวกัน

เขียนโหมดลงไปก่อนที่คุณจะเปลี่ยนแปลงอะไร เพราะมันเป็นตัวกำหนดว่าผลลัพธ์จะหมายถึงอะไรได้

ส่งคำขอหนึ่งรายการที่คุณรู้จุดหมาย

ใช้คำขอที่ไม่เป็นอันตรายไปยังบริการที่รายงานที่อยู่ต้นทางที่มันเห็น จากนั้นตรวจสอบการตัดสินใจกำหนดเส้นทางของเกสต์เองสำหรับจุดหมายนั้น: ip route get 203.0.113.5 พิมพ์อินเทอร์เฟซและเกตเวย์ที่เกสต์จะใช้

หากอินเทอร์เฟซเป็น NIC ปกติของเกสต์ ทราฟฟิกนั้นไม่ได้ผ่านอุโมงค์ภายในเกสต์

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

ตรวจสอบตัวแก้ไขชื่อแยกต่างหาก

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

สองสิ่งนี้อาจแตกต่างกันได้ทั้งสองทิศทาง และความแตกต่างนั้นมักเป็นบั๊กจริง

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

ทดสอบนโยบายเมื่อล้มเหลว ไม่ใช่แค่ความสำเร็จ

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

เกสต์ที่ถอยกลับไปใช้ NIC จริงเมื่ออุโมงค์ล่มกำลังทำสิ่งที่โหมด NAT อนุญาตพอดี

บันทึกโหมดและขอบเขต

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

หาก IPv4 ตามอุโมงค์ไป ให้บอกเช่นนั้น อย่าขยายข้อกล่าวอ้างไปยัง IPv6 เนมสเปซอื่น หรือ VM อื่นบนเครือข่ายอื่น