เชื่อมต่ออุโมงค์ TCP อีกครั้งโดยอัตโนมัติ

9

ฉันมีการเชื่อมต่อเครือข่ายที่ไม่น่าเชื่อถือระหว่างเครื่องสองเครื่อง: บางครั้งการเชื่อมต่อ TCP ที่ทำงานอยู่จะตกเนื่องจากเหตุผลที่อยู่นอกเหนือการควบคุม ฉันต้องการสร้างการเชื่อมต่อ TCP ที่เชื่อถือได้ระหว่างเครื่องสองเครื่อง

หากเครือข่ายเป็นที่เชื่อถือได้ผมทำงานเพียงssh -L 1234:localhost:1234 remotehostกับการฟังเซิร์ฟเวอร์บนพอร์ต 1234 บนและชี้ให้ลูกค้าที่remotehost localhost:1234แต่ถ้าการเชื่อมต่อ ssh ตายดังนั้นการเชื่อมต่อที่ส่งต่อจะ ฉันจะจัดการคืนค่าการเชื่อมต่อระหว่างไคลเอนต์และเซิร์ฟเวอร์โดยอัตโนมัติได้อย่างไร?

ที่ไม่ใช่การแก้ปัญหา:

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

ฉันมีหน่วยความจำสลัวของโปรแกรมที่เรียกrocksว่าทำอย่างนั้น แต่ดูเหมือนว่าจะหลุดจากหน้าเว็บ ฉันสนใจ Linux เป็นส่วนใหญ่ทั้งสองด้าน (แต่ฉันคาดหวังว่าโปรแกรมในระดับนี้จะพกพาไปยัง unices อื่น ๆ ) แต่ถ้าคุณรู้ว่าโปรแกรมที่ทำงานระหว่าง QNX และ VMS นั้นดีกว่าทั้งหมด

— Gilles 'หยุดความชั่วร้าย'
แหล่งที่มา

Gilles คุณใช้ tcp keepalives กับการเชื่อมต่อ ssh ของคุณหรือไม่? ถ้าไม่ลองสิ่งนี้ก่อน ... การติดตั้ง NAT บางครั้งใช้เวลาในการเชื่อมต่ออย่างรวดเร็ว

— Mike Pennington

@ ไมค์: ขอบคุณสำหรับเคล็ดลับ ฉันไม่ต้องการทันที แต่ฉันต้องเผชิญกับทั้งสองสถานการณ์ที่มีเส้นทางกลางมาและไป (ดังนั้น TCP keepalives ทำอันตรายมากกว่าดี) และสถานการณ์ที่ NAT โอเวอร์โหลดและทำให้ฉันตก (ดังนั้น TCP keepalives อาจช่วยได้) TCP keepalives ไม่สำคัญสำหรับการสตรีมต่อเนื่อง (เช่น scp) ใช่ไหม ไม่ว่าในกรณีใดฉันจะต้องการรักษาความเป็นนายพลนี้: ครั้งต่อไปที่ฉันต้องเผชิญกับเครือข่ายที่ไม่สม่ำเสมอของรสชาติใด ๆ ฉันควรทำอย่างไร

— Gilles 'หยุดชั่วร้าย'

Gilles scpการแก้ปัญหาที่แตกต่างกันสำหรับกระแสอย่างต่อเนื่องเช่น ฉันกำลังตอบสนอง w / ssh keepalives ตามตัวอย่างการส่งต่อพอร์ตของคุณ Re: การสตรีมดาวน์สตรีมที่ไม่สม่ำเสมอคุณไม่สามารถทำได้นอกจากสร้างเซสชั่น ssh ที่มี keepalives ที่อดทนมากกว่า (เช่นอนุญาตให้ keepalives ที่ถูกทิ้งServerAliveInterval > 0และServerAliveCountMax > 3อื่น ๆ ) NAT ต้องการช่วงเวลารักษาความปลอดภัยที่ต่ำกว่า ปัญหาสำคัญคือการระบุว่าปัญหาคืออะไรและปรับแต่งตามความเหมาะสม ใส่ตัวเลือก.ssh/configเพื่อให้พวกเขาอยู่ที่นั่นเสมอสำหรับคุณ

— Mike Pennington

@ ไมค์: กรณีการใช้งานอย่างหนึ่งของฉันรวมถึงไคลเอนต์ที่ได้รับ IP จาก NAT ที่โอเวอร์โหลดมากกว่าการสุ่มการเชื่อมต่อที่ใช้งานแบบสุ่ม (คิดว่ามี P2P มากกว่าที่ควรจะเป็น) หลังจากนั้นสองสามวินาทีไคลเอ็นต์จะจัดการเชื่อมต่อใหม่ แต่อาจได้รับที่อยู่ IP อื่น ไม่มีทางที่การเชื่อมต่อ TCP จะอยู่รอดในกรณีนั้น ร็อค copes แต่ฉันต้องการสิ่งที่รวบรวมออกจากระบบในวันนี้

— Gilles 'หยุดความชั่วร้าย' ใน

ในกรณีของ NAT ที่ให้ IP ใหม่แก่คุณไม่มีอะไรที่คุณสามารถทำได้มากกว่าได้รับการแก้ไข NAT หรือความหวังสำหรับrocksการดำเนินการอื่น... แม้ว่าจะเห็นได้ชัดว่าเป็นกระบองจริง

— Mike Pennington

5

เป็นเก่า Sockets เชื่อถือ unmaintained ( Rocks ) สิ่งที่คุณกำลังมองหา?

— Hangin เปิดในที่สิ้นหวังเงียบ
แหล่งที่มา

1

ขอบคุณ Rocks เป็นสิ่งที่ฉันจำได้ แน่นอนฉันต้องการอะไรที่เก็บรักษาไว้

— Gilles 'หยุดความชั่วร้าย' ใน

@ Gilles'SO-stopbeingevil 'ไม่เพียง แต่จะไม่ทำความสะอาด แต่มันดูเหมือนจะหลุดจากใบหน้าของอินเทอร์เน็ตอย่างสมบูรณ์!

— ไมเคิล

1

เพียงโปรโตคอลมาตรฐานที่ฉันรู้ที่มีความสามารถนี้อยู่MPTCP มีความโปร่งใสในเลเยอร์แอปพลิเคชันดังนั้น SSH ที่อยู่ด้านบนของ MPTCP ควรทำงานได้ มันสามารถเรียกใช้การเชื่อมต่อ TCP พื้นฐานผ่านเส้นทางที่แตกต่างกับ IP ที่แตกต่างกันดังนั้นโดยหลักการแล้วมันสามารถใช้ในการโยกย้ายการเชื่อมต่อ SSH ของคุณเข้าและออกจากการเชื่อมต่อ VPN ขึ้นอยู่กับว่าการเชื่อมต่อ VPN นั้นขึ้นอยู่หรือไม่

ฉันไม่ค่อยรู้เกี่ยวกับวุฒิภาวะของการใช้งาน MPTCP แต่การออกแบบโปรโตคอลนั้นดูค่อนข้างแข็งแกร่ง

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

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

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

0

คุณสามารถใช้daemontoolsเพื่อรักษาพอร์ต ssh ไปข้างหน้า; มันไม่จำเป็นต้องให้โปรแกรมต่าง ๆ ขึ้นอยู่กับการเชื่อมต่อขณะที่มันหยุดทำงาน (อย่างที่คาดไว้เมื่อ ssh ยกเลิกการเชื่อมต่อพอร์ตท้องถิ่นจะเริ่มปฏิเสธการเชื่อมต่อของพวกเขา) แต่มันเป็นการเริ่มต้น

ฉันสงสัยว่ามีiptablesเทคนิคบางอย่างเช่นทำให้พอร์ตนั้นไปที่แพ็กเก็ต DROP ทันทีที่ ssh ไปข้างหน้าหายไปดังนั้นโปรแกรมที่เชื่อมต่อก็รู้ว่าแพ็กเก็ตหายไปไม่ใช่ถูกปฏิเสธ ฉันเพิ่งเรียนdaemontoolsรู้ตัวเอง (อีกครั้ง) ดังนั้นฉันไม่แน่ใจว่าคุณสามารถเรียกใช้สคริปต์ที่กำหนดเองเมื่อบริการตาย แต่ฉันสงสัยว่าคุณสามารถ

— กอร์ดอนมอร์เฮาส์
แหล่งที่มา

-2

TCP ทำสิ่งนี้โดยอัตโนมัติ คุณต้องปิดการใช้งานหรือลดขนาดแฮ็คการล้างข้อมูลที่ใช้งานได้จริงที่ใช้เพื่อฆ่าการเชื่อมต่อ TCP ที่มีปัญหา ปิดใช้งาน TCP keepalive สำหรับการเชื่อมต่อของคุณและเพิ่มขีด จำกัด อย่างมากสำหรับการส่งสัญญาณซ้ำมากเกินไป ตัวอย่างเช่นบน Linux เขียนจำนวนมาก/proc/sys/net/ipv4/tcp_retries2ๆ

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

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

1

เป็นความจริงที่ TCP สามารถจัดการกับสถานการณ์ได้ตราบใดที่แต่ละจุดปลายมีที่อยู่ IP แบบคงที่และไม่มีกล่องจดหมายสถานะกลาง คำถามที่กล่าวถึงreasons beyond my controlซึ่งฉันอ่านเป็น IP แบบไดนามิกหรือมิดเดิ้ล stateful ในสถานการณ์เช่นนี้ TCP keepalive สามารถช่วยได้เล็กน้อย แต่ไม่ว่าคุณจะกำหนดค่า TCP keepalive อย่างไรก็จะไม่เพียงพอที่จะทำให้การเชื่อมต่อยังคงอยู่เมื่อมิดบ็อกซ์สูญเสียสถานะเนื่องจากการเริ่มต้นใหม่

— kasperd

@kasperd ฉันเห็นด้วย อย่างไรก็ตามมันไร้ประโยชน์ที่จะพยายามเปิดการเชื่อมต่อ TCP ในกรณีเหล่านั้น ดังนั้นฉันคิดว่าผู้ถามไม่ได้เผชิญกับความท้าทายเหล่านั้น

— aecolley

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

— kasperd