มีข้อเสียใน SSH tunneling หรือไม่?

เมื่อเร็ว ๆ นี้ฉัน "ซื้อ" VPS ที่ฉันต้องการใช้เป็นพร็อกซีเพื่อให้สามารถใช้บางไซต์และบางสิ่งที่ฉันไม่สามารถเข้าถึงได้จากประเทศเยอรมนี

เนื่องจากฉันยังขี้เกียจเกินไปที่จะตั้งค่า Squid และ OpenVPN (ซึ่งฉันคิดว่าเป็นสิ่งจำเป็นในปัจจุบัน) ฉันใช้ ssh-tunneling

หลังจากสองสามสัปดาห์ที่ผ่านมาฉันถามตัวเองว่า ssh-tunneling ไม่ได้ดีหรือ - และนั่นคือคำถามของฉัน - หากมีข้อแม้ / ข้อขัดแย้ง / ข้อบกพร่องใด ๆ ที่ฉันจำเป็นต้องมีในใจ?

ssh proxy ssh-tunneling

— Nils Riedemann
แหล่งที่มา

สำหรับสิ่งที่คุ้มค่า OpenVPN นั้นติดตั้งง่ายมากโดยใช้คีย์คงที่หากคุณเปลี่ยนจาก Linux เป็น Linux มันค่อนข้างยุ่งยากหากหนึ่งในเครื่องของคุณเป็น Windows แต่ทำได้ bit.ly/ujkD2

— transistor1

คำตอบ:

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

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

หน้านี้อธิบายปรากฏการณ์โดยละเอียด

แก้ไข:

แทนที่จะยึดติดกับ TCP ผ่านปัญหา TCP ดูที่sshuttleซึ่งป้องกันไม่ให้
ดูหัวข้อ " ทฤษฎีการดำเนินงาน " เพื่อดูรายละเอียดเพิ่มเติมเกี่ยวกับสถานการณ์นี้

— Shadok
แหล่งที่มา

เลเยอร์ชั้นในไม่ทราบว่ากำลังคุยกับส่วนต่อประสานย้อนกลับหรือไม่

— Random832

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

— Shadok

ฉันคิดเกี่ยวกับกรณีที่มันเชื่อมต่อ TCP เจาะปกติไม่ได้ "TCP over IP กว่า PPP ผ่าน TCP" - ในกรณีที่มีไม่จริงกองโปรโตคอล TCP สอง - SSH เป็นเพียงการส่งกระแสไบต์ และฉันไม่ได้หมายถึง "รู้ตัวว่ามันอยู่ในลำธารด้านใน" ฉันหมายถึงว่าในสถานการณ์เช่นนี้มันจะมีลูปแบ็คอินเทอร์เฟซ (โลคอลพอร์ต ssh กำลังฟังอยู่) เป็นปลายทาง

— Random832

OP พูดคุยเกี่ยวกับ "บางไซต์" ฉันคิดว่าเขากำลังทำ HTTP ผ่าน SocksV5 ถึง SSH ซึ่งหมายความว่าเขากำลังทำ TCP ผ่าน TCP (SSH เองก็คือ TCP และ HTTP ภายในอุโมงค์นั้นไหลผ่านลำธาร TCP อื่นซึ่งถูกห่อหุ้มใน SSH)

— Shadok

@ Shadok ฉันค่อนข้างมั่นใจว่าข้อสรุปของคุณไม่เป็นความจริง apenwarr หมายถึงการtun/tapขุดซึ่งเป็นผลลัพธ์ใน tcp-over-tcp SOCKSv5 ไม่ประสบปัญหาเดียวกัน แต่ไม่สามารถทำงานร่วมกับแอพพลิเคชั่นทั้งหมดได้อย่างโปร่งใส (ในขณะที่ tun / tap เป็นเพียงส่วนต่อประสานเครือข่ายอื่นเพื่อให้สามารถจัดการได้อย่างโปร่งใส)

— jpc

สิ่งหนึ่งที่ฉันนึกได้คือการแสดง แต่นั่นขึ้นอยู่กับประเภทของอุโมงค์ที่คุณใช้

— มาร์คัส
แหล่งที่มา

ประสิทธิภาพแบบไหน Bandwidth? ปัจจุบันฉันใช้เพื่อเข้าถึง hulu และวิดีโอ youtube บางรายการที่ถูกบล็อก

— Nils Riedemann

CPU โอเวอร์เฮด (เข้ารหัส) และอาจเกิดความหน่วงแฝง

— XTL

โดยทั่วไปฉันพบว่าเวลาในการตอบสนองเพิ่มขึ้น แต่ปริมาณงานปกติดี (90%) เมื่อใช้ SSH tunneling ตรวจสอบให้แน่ใจว่าได้ตั้งค่าServerAliveIntervalเพื่อป้องกันการตัดการเชื่อมต่อและรวมไว้ในสคริปต์เพื่อเริ่มอุโมงค์ในความล้มเหลว

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

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

ข้อสังเกตประสิทธิภาพหลัก (ตามที่คนอื่น ๆ ทราบ) คือการเชื่อมต่อที่ไม่น่าเชื่อถือมีแนวโน้มที่จะไม่ดีกับวิธีนี้เนื่องจากอัลกอริทึมของ TCP ไม่ตอบสนองได้ดีภายใต้การห่อหุ้ม

ที่กล่าวว่า SSH ดูเหมือนจะ "ทำสิ่งที่ถูกต้อง" เกือบตลอดเวลา

— สตูชาร์ลตัน
แหล่งที่มา

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

— jpc