SSH บนเส้นทางส่วนตัวที่สองขณะที่ VPN ยังทำงานอยู่

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

ทำไมเส้นทางใหม่จึงไม่ได้สร้างตัวรับฟังใหม่

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

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

แสดงรายการที่อยู่และตัวรับฟัง

ก่อนแก้ไขสิ่งใด ให้บันทึกที่อยู่บนโฮสต์และซ็อกเก็ตที่มีอยู่ในขณะนี้

ip -br addr
ss -ltnp | grep ':22'

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

เพิ่มการผูกและเก็บของเดิมไว้

OpenSSH ยอมรับรายการ ListenAddress หลายรายการ เส้นทาง VPN จึงคงอยู่ได้ขณะเพิ่มเส้นทางส่วนตัว ทดสอบไฟล์ก่อนโหลดใหม่

sshd -t
systemctl reload sshd

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

ตรวจสอบเซสชันใหม่ก่อนปิดเซสชันเก่า

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

ssh -v [email protected]

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

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