ให้ SOCKS พร็อกซีแก่ Pi ระยะไกลผ่าน SSH ไคลเอนต์ของคุณ

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

ตัวรับฟังกับฝั่งที่การเชื่อมต่อเริ่มต้นอาจแตกต่างกัน

ssh -D 1080 ทั่วไปจะรันตัวรับฟังบนเครื่องของคุณเองและส่งการเชื่อมต่อไปจากที่นั่น การส่งต่อแบบไดนามิกจากระยะไกลกลับด้าน: ตัวรับฟังจะปรากฏบนโฮสต์ระยะไกล และทุกการเชื่อมต่อที่รับไว้จะถูกเปิดจากฝั่งภายในเครื่อง คู่มือไคลเอนต์ OpenSSH ระบุว่า -R ที่ไม่มีปลายทางตายตัวคือรูปแบบ SOCKS4/5 นี้เอง

คำสั่งที่รองรับจากแล็ปท็อปมีหน้าตาเช่นนี้ โดยถือว่าบัญชี โฮสต์ และพอร์ตเป็นตัวแทนชั่วคราว:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

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

ตัวรับฟังระยะไกลเปิดเผยอะไรจริง ๆ

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

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

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

ส่งแอปพลิเคชันหนึ่งตัวผ่านพร็อกซี

ไคลเอนต์บน Pi ที่เข้าใจพร็อกซีจะส่งคำขอได้ คำนำหน้า socks5h ส่งชื่อปลายทางให้พร็อกซี ดังนั้นการค้นหาและการเชื่อมต่อจึงเกิดทั้งคู่ฝั่งแล็ปท็อป และตรงกับปลายทางที่ระบุชื่อใน PermitRemoteOpen:

curl --proxy socks5h://127.0.0.1:1080 \
  --noproxy '' https://app.corp.example/

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

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

พิสูจน์เส้นทางแล้วปิดมัน

ยืนยันว่าตัวรับฟังอยู่ที่ที่คุณคาดหวัง และมีเพียงปลายทางที่ตั้งใจไว้เท่านั้นที่ตอบกลับ:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

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

รูปแบบนี้พา TCP เท่านั้น UDP, ICMP และโปรแกรมที่เพิกเฉยต่อการตั้งค่าพร็อกซีจะอยู่นอกเหนือจากนี้ และการส่งต่อจะสิ้นสุดในทันทีที่เซสชัน SSH สิ้นสุด หยุดเซสชันนั้นเมื่อทำเสร็จและเอาค่าพร็อกซีที่คุณเพิ่มในแอปพลิเคชันออก

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