sshuttle เทียบกับ VPN เต็มรูปแบบ: วิธีการของมันครอบคลุมอะไรจริง ๆ
sshuttle พาไปได้เฉพาะสิ่งที่วิธีการส่งต่อของมันรองรับ: ตรวจสอบความครอบคลุมของ TCP, DNS และ UDP สิทธิ์ในเครื่องที่ต้องใช้ และตัวช่วยฝั่งไกลก่อน
sshuttle ถูกเลือกเพราะ SSH ทำงานอยู่แล้วและวิทยาการเข้ารหัสดูคุ้นเคย และเหตุผลนั้นข้ามคำถามเดียวที่ตัดสินว่ามันเหมาะหรือไม่ คำถามนั้นคือแพ็กเก็ตใดออกจากเครื่อง บัญชีใดพาพวกมันไปยังอีกฝั่ง และเครื่องมือต้องใช้สิทธิ์ในเครื่องมากเพียงใด คำตอบทั้งสามข้อแตกต่างกันตามวิธีการส่งต่อ การตั้งค่าที่ใช้ได้กับแอปพลิเคชันหนึ่งจึงอาจล้มเหลวอย่างเงียบ ๆ กับอีกตัวหนึ่ง คำอธิบายด้านล่างเริ่มจากโพรโทคอลที่แอปพลิเคชันต้องการจริง ๆ
เริ่มจากโพรโทคอลที่แอปพลิเคชันต้องการ
การรองรับโพรโทคอลใน sshuttle 2.0 ขึ้นอยู่กับวิธีที่คุณเลือก วิธี NAT และ nft ของ Linux จัดการ TCP และ DNS ส่วน TPROXY เพิ่ม UDP ทั่วไป แต่ละแพลตฟอร์มและแต่ละวิธีมีขีดจำกัดของตัวเอง และ macOS ดักจับด้วยกลไกที่ต่างออกไปทั้งหมด บันทึกเวอร์ชันที่ติดตั้ง วิธีที่เลือก และโพรโทคอลที่แอปพลิเคชันต้องการก่อนเลือกสิ่งใด
ดังนั้นคำขอ TCP ที่ทำงานได้จึงพิสูจน์ได้น้อยมากเกี่ยวกับแอปพลิเคชัน UDP หรือการค้นหา DNS ทุกครั้ง sshuttle ยังถือว่า TCP เป็นสตรีมแทนการทำอุโมงค์แพ็กเก็ต IP ทั้งก้อน ข้อสรุปเรื่องทรูพุตที่ยืมมาจาก VPN ทั่วไปจึงใช้ที่นี่ไม่ได้ เปรียบเทียบกลไกที่คุณรันจริงกับภาระงานที่คุณมีจริง
| Approach | What it carries | What it needs locally |
|---|---|---|
| SSH local forward | One explicitly named TCP destination | Nothing beyond the SSH client |
| sshuttle, nft or nat method | TCP and DNS to the routed prefixes | Root or sudo for firewall rules |
| sshuttle, tproxy method | TCP, DNS and general UDP | Root or sudo, and kernel support |
| IP VPN | Routed IP traffic in a tunnel | A client with the required privileges |
สิ่งที่ไคลเอนต์ต้องมีในเครื่อง
การจัดวางไคลเอนต์ตามเอกสารต้องใช้ root หรือ sudo เพราะมันติดตั้งกฎดักจับในเครื่องแทนการสร้างอินเทอร์เฟซอุโมงค์ ข้อเท็จจริงเดียวนี้เปลี่ยนเรื่องราวความปลอดภัย โปรเซสที่มีสิทธิ์นั้นสามารถเปลี่ยนเส้นทางทราฟฟิกของทั้งเครื่อง ไม่ใช่แค่แอปพลิเคชันเดียว มองสิทธิ์ว่าเป็นส่วนหนึ่งของการออกแบบ ไม่ใช่รายละเอียดการติดตั้ง
ยืนยันว่าเครื่องมือติดตั้งกฎใดและกฎเหล่านั้นหายไปเมื่อมันออก สเซสที่พังกลางทางและทิ้งกฎดักจับไว้อาจทำให้ทราฟฟิกตกหลุมดำได้นานหลังจากผู้ดูแลเชื่อว่าการเชื่อมต่อหายไปแล้ว และอาการดูเหมือนเครือข่ายขัดข้องไม่ใช่กฎที่ค้างอยู่
sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip routeคำสั่งแรกคือรูปแบบของการเรียกใช้ทั่วไป พร้อมคำนำหน้าที่คุณต้องการจริง คำสั่งที่สองแสดงสิ่งที่เครื่องมือติดตั้ง และคำสั่งที่สามยืนยันว่าไม่มีอินเทอร์เฟซอุโมงค์เกิดขึ้น ซึ่งเป็นผลลัพธ์ที่คาดไว้สำหรับการออกแบบนี้
ฝั่งไกลรันอะไร
ฝั่งไกลคือบัญชี SSH ที่ได้รับอนุญาตพร้อมสภาพแวดล้อมตัวช่วย Python ที่เข้ากันได้ การเข้าสู่ระบบที่สำเร็จภายใต้เชลล์จำกัดไม่ได้ให้สิทธิ์รันตัวช่วยนั้นโดยอัตโนมัติ และบัญชีที่รันตัวช่วยได้ก็ไม่ได้เข้าถึงทุกบริการเป้าหมายโดยอัตโนมัติ ข้อเท็จจริงทั้งสองข้อควรอยู่ในคำขอเข้าถึง ไม่ใช่ในบันทึกการแก้ปัญหา
ปกป้องการยืนยันตัวตนของโฮสต์และการพิสูจน์ตัวตนของบัญชี การยอมรับคีย์โฮสต์ที่ไม่รู้จักเพื่อให้การเชื่อมต่อแรกทำงานได้เป็นการถอดการตรวจสอบว่าฝั่งไกลคือเครื่องที่คุณตั้งใจ และเรื่องนี้สำคัญกว่าการส่งต่อเพื่อจุดประสงค์เดียว
จำกัดบัญชีฝั่งไกลให้อยู่เฉพาะบริการที่เวิร์กโฟลว์ต้องการ และเจรจาขอบเขตนั้นกับผู้ดูแลโฮสต์ พวกเขาเป็นส่วนหนึ่งของความสัมพันธ์เชิงความไว้วางใจ และไม่มีการตั้งค่าฝั่งไคลเอนต์ใดเปลี่ยนสิ่งนั้น
ขอบเขตความไว้วางใจอยู่ตรงไหน
การส่งต่อการเชื่อมต่อ API ส่วนตัวผ่าน SSH ไม่ได้อนุญาตทุกการดำเนินการของ API TLS ของแอปพลิเคชันและการเข้าสู่ระบบของแอปพลิเคชันยังคงมีผล และเครื่องมือไม่สามารถทำให้บริการที่ไม่มีการพิสูจน์ตัวตนปลอดภัยได้ การกระโดดต่อไปจากโฮสต์ฝั่งไกลก็ไม่ใช่ส่วนที่ได้รับการป้องกันเดียวกันกับช่องทาง SSH โดยอัตโนมัติ เพราะการเชื่อมต่อที่สองนั้นเป็นไปตามนโยบายที่โฮสต์ฝั่งไกลมี
เขียนขอบเขตเป็นประโยคเดียว ทราฟฟิกไปยังคำนำหน้าเหล่านี้ออกผ่านบัญชีนี้บนโฮสต์นั้น ถ้าประโยคนั้นต้องใช้ย่อหน้าข้อยกเว้น การออกแบบก็ทำมากกว่าที่เอกสารอ้าง และสมควรได้รับการพิจารณาอีกครั้งก่อนถึงการผลิต
พิสูจน์ทีละโพรโทคอลแล้วจึงเลือกเครื่องมือ
ทดสอบทุกโพรโทคอลที่ต้องการด้วยคำขอที่ไม่เป็นอันตราย รวมถึงเส้นทางของตัวแปลงชื่อและกลุ่มที่อยู่ที่แอปพลิเคชันใช้ รวมการตัดการเชื่อมต่อไว้ในการทดสอบด้วย เพื่อให้พฤติกรรมล้มเหลวที่อนุญาตของแอปพลิเคชันเป็นผลลัพธ์ที่รู้ล่วงหน้า ไม่ใช่ความประหลาดใจระหว่างเหตุการณ์ เซสชันที่ส่งต่อถูกต้องขณะทำงานไม่ได้บอกอะไรเกี่ยวกับสิ่งที่เกิดขึ้นเมื่อมันหลุด
สำหรับบริการไม่กี่รายการที่ระบุชื่อไว้ชัดเจน การส่งต่อในเครื่องแบบธรรมดาเป็นเจ้าของและตรวจสอบได้ง่ายกว่า สำหรับทราฟฟิกแอปพลิเคชันที่เข้ากับวิธีการของมัน sshuttle เสนอทางสายกลางที่ชอบธรรม เมื่อข้อกำหนดคือการเชื่อมต่อ IP แบบกว้าง การออกแบบ VPN คือคำตอบที่ซื่อสัตย์ และการเลือกเป็นไปตามความครอบคลุมและความรับผิดชอบในการปฏิบัติงาน ไม่ใช่การจัดอันดับอัลกอริทึมการเข้ารหัส