SSH ฟอร์เวิร์ดส่งผ่านทราฟฟิกแอปใดจริง ๆ?

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

ระบุอินเทอร์เฟซก่อนเปรียบเทียบสิ่งใด

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

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

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

การส่งต่อภายใน ระยะไกล และไดนามิกต่างกันที่ใครเป็นผู้รอฟัง

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

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

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

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

โหมดอุปกรณ์อุโมงค์คือข้อยกเว้นเครือข่ายที่แท้จริงเพียงอย่างเดียว

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

sudo ssh -w 0:0 [email protected]
ip addr show tun0

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

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

ทดสอบว่าแอปของคุณใช้อินเทอร์เฟซที่คุณสร้าง

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

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

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

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