ส่งต่อ SSH ภายในเครื่อง หรือ VPN เต็มรูปแบบ สำหรับหน้าจอ Mac หนึ่งจอ?

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

มีสามเงื่อนไขที่ชี้ขาด และเงื่อนไขใดเงื่อนไขหนึ่งอาจผลักคุณไปสู่ VPN แบบจัดการแทน

สามเงื่อนไขที่ชี้ขาด

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

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

ส่งต่อหนึ่งพอร์ต ไม่ใช่ทั้งเครือข่าย

การส่งต่อภายในเปิดตัวรับฟังบนเครื่องของคุณและส่งต่อทุกการเชื่อมต่อผ่านเซิร์ฟเวอร์ SSH ไปยังปลายทางที่เซิร์ฟเวอร์นั้นเข้าถึงได้ สำหรับ Mac ที่บริการแชร์หน้าจอฟังอยู่บน TCP 5900 และโฮสต์กลางที่แก้ไข mac.corp.example ได้ คำสั่งนั้นสั้นและแคบโดยเจตนา ทุกตัวเลือกในคำสั่งมีอยู่เพื่อให้การจัดวางเล็ก: ไม่มีเชลล์ ไม่มีตัวรับฟังบนทุกอินเทอร์เฟซ ไม่มีเดมอน อ่านมันเป็นถ้อยแถลงขอบเขต ไม่ใช่สูตรอาหาร

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:15900:mac.corp.example:5900 [email protected]

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

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

SSH เข้ารหัสอะไร และหยุดที่ใด

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

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

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

เมื่อใดที่ VPN เต็มรูปแบบคือการตัดสินใจที่ถูก

เลือก VPN เมื่องานต้องใช้มากกว่าหนึ่งพอร์ต: ฟังก์ชันการจัดการและรายงานของ Apple Remote Desktop ใช้ทราฟฟิก TCP และ UDP เพิ่มเติมที่การส่งต่อ TCP ครั้งเดียวพาไม่ได้ การส่งต่อไม่ใช่การนำผลิตภัณฑ์ทั้งชิ้นมาทำบางส่วน มันคือเครื่องมืออื่นที่เล็กกว่า

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

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

ทำให้การส่งต่อล้มเหลวอย่างเสียงดัง

ใช้ ExitOnForwardFailure=yes เพื่อให้การผูกที่ล้มเหลวหยุดเซสชัน แทนที่จะทิ้งเชลล์ที่ดูเหมือนเชื่อมต่อแต่ไม่ส่งต่ออะไรเลย เปิดการตรวจสอบคีย์โฮสต์ไว้ และเลือกคีย์หรือเอเจนต์แทนรหัสผ่าน จากนั้นทดสอบ URL ที่แน่นอนซึ่งตัวดูจะใช้ เพราะเซสชัน SSH ที่ใช้งานได้และการเชื่อมต่อหน้าจอที่ใช้งานได้เป็นสองผลลัพธ์ที่ต่างกัน

สำหรับไคลเอนต์ดั้งเดิมบน macOS เข้าถึงตัวดูผ่าน URL ภายใน: open "vnc://127.0.0.1:15900" ถ้าหน้าต่างเปิดและโฮสต์ระยะไกลปฏิเสธการพิสูจน์ตัวตน อุโมงค์ก็ปกติดีและปัญหาอยู่ที่เป้าหมาย ถ้าหน้าต่างไม่เปิดเลย ปัญหาอยู่ที่ตัวรับฟังหรือพอร์ต

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