ส่งต่อภายในด้วย SSH ไปยังพร็อกซี HTTP ที่มีอยู่: ที่อยู่ loopback สองที่

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

ตัดสินใจว่ามีพร็อกซีแบบตายตัวอยู่แล้วหรือไม่

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

การยืนยันสิ่งนี้ก่อนจะช่วยให้คุณไม่ต้องดีบักอุโมงค์ที่ไม่เคยเชื่อมต่อกับสิ่งใดเลย

สร้างการส่งต่อและอ่านคำสั่ง

รูปแบบที่คุณต้องการผูกพอร์ต loopback บนแล็ปท็อปของคุณและเชื่อมต่อจากฝั่งเซิร์ฟเวอร์ไปยังที่อยู่ของพร็อกซีตามที่เซิร์ฟเวอร์มองเห็น

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

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

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

ชี้แอปพลิเคชันหนึ่งไปที่การส่งต่อ

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

การตรวจสอบอย่างรวดเร็วก่อนตั้งค่าถาวรใด ๆ: curl -x http://127.0.0.1:13128 -I https://example.com ซึ่งฝึกวิธี HTTP CONNECT ที่พร็อกซีต้องรองรับ

เก็บอำนาจไว้ที่เดิม

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

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

ตรวจสอบทั้งสองด้านแล้วทำความสะอาด

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

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