เข้าถึงเว็บไซต์ HTTPS ที่เข้าถึงได้ผ่าน VPN เท่านั้นด้วยการส่งต่อ SSH

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

ขั้นแรก: ยืนยันเงื่อนไขเบื้องต้นสามข้อ

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

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

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

ขั้นที่สอง: ผูกพอร์ต loopback และรักษาเซสชันให้ยังมีชีวิต

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

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

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

ขั้นที่สาม: รักษาชื่อ HTTPS เมื่อซ็อกเก็ตเป็นภายในเครื่อง

การเรียกดู https://127.0.0.1:9443/ เปลี่ยนชื่อเซิร์ฟเวอร์ TLS และอำนาจของแอปพลิเคชัน ใบรับรองที่ออกให้ portal.lab.example จะไม่ผ่านการตรวจสอบกับที่อยู่ loopback และข้อผิดพลาดที่เกิดขึ้นดูเหมือนใบรับรองที่เสียหายมากกว่าทางลัดของการส่งต่อ สำหรับการทดสอบจากบรรทัดคำสั่ง ให้เก็บ URL จริงไว้และเปลี่ยนเฉพาะปลายทางของซ็อกเก็ต นั่นคือสิ่งที่ --connect-to ทำ และคู่มือ curl อธิบายรูปแบบสี่ฟิลด์ที่ใช้ด้านล่าง

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

ชื่อยังคงอยู่ใน URL ในการจับมือ TLS และในส่วนหัว Host ขณะที่การเชื่อมต่อ TCP ไปยังตัวรับฟังภายใน ตัวเลือกไม่ใช้พร็อกซีรักษาการทดสอบไว้บนการส่งต่อนี้แทนที่จะให้พร็อกซี HTTP ที่กำหนดค่าไว้ดักจับ และการเปิดการตรวจสอบใบรับรองไว้คือสิ่งที่ทำให้ผลลัพธ์มีความหมาย

ขั้นที่สี่: รู้ว่าการส่งต่อเดียวครอบคลุมอะไรไม่ได้

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

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

ขั้นที่ห้า: ทำความสะอาดและบันทึก

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

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