การส่งต่อภายในของ SSH พาเซสชัน TCP OpenVPN อย่างไร

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

การส่งต่อภายในเคลื่อนย้ายอะไรจริง ๆ

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

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

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

ชี้ไคลเอนต์ไปที่ตัวรับฟังภายใน

ตัวอย่างที่ประกาศไว้: รีเลย์เข้าถึงตัวรับฟัง TCP ที่ gw.internal.example:443 ได้ และพอร์ตภายในที่สูงจะเปิดเส้นทางนั้นให้เฉพาะเครื่องนี้เท่านั้น

ssh -N -L 127.0.0.1:24011:gw.internal.example:443 [email protected]

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

จากนั้นตั้งไคลเอนต์ VPN เป็นโหมด TCP และชี้ไปที่ 127.0.0.1:24011 หากโปรไฟล์ใช้ UDP การออกแบบนี้ช่วยไม่ได้ เพราะการส่งต่อบรรทุกกระแสไบต์และไม่มีเส้นทางเดตาแกรมผ่านมัน

แยกการพิสูจน์ตัวตนสองอย่างออกจากกัน

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

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

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

อย่าสร้างลูปใต้อุโมงค์

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

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

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

ปิดตัวรับฟังเมื่อเสร็จ

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

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