ไฮเปอร์ไวเซอร์ในแล็บที่บ้านเข้าถึงไม่ได้ผ่าน VPN: ควรดูตรงไหน

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

เริ่มจากเซกเมนต์การจัดการ

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

จากนั้นสองเส้นทาง ไคลเอนต์ VPN ต้องการเส้นทางไปยังเครือข่ายการจัดการ ซึ่งปกติหมายความว่า AllowedIPs ของไคลเอนต์หรือเส้นทางที่พุชไปนั้นรวมซับเน็ตนั้นด้วย ไฮเปอร์ไวเซอร์หรือเกตเวย์เริ่มต้นของมัน ต้องการเส้นทางกลับไปยังพูลที่อยู่ของไคลเอนต์ เว้นแต่การออกแบบจะแปลต้นทางที่ทางเข้าอย่างตั้งใจ สองข้อนี้เป็นข้อเท็จจริงแยกกัน และการขาดอย่างใดอย่างหนึ่งให้เวลาหมดเหมือนกัน ตรวจแยกกัน: ip route get 192.168.10.20 บนไคลเอนต์ และการดักจับบนโฮสต์ไฮเปอร์ไวเซอร์ที่แสดงว่าแพ็กเก็ตมาถึงหรือไม่

อนุญาตผู้ดูแลระยะไกลจริง

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

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

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

ตรวจสอบการเชื่อมต่อทุติยภูมิ

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

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

เก็บทางกลับไว้ก่อนแตะเครือข่าย

ก่อนเปลี่ยนเครือข่ายเสมือนที่บรรทุก VPN ของคุณเอง ยืนยันว่าคุณมีทางกลับภายในหรือที่เป็นอิสระ

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

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

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

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