วิธีการตั้งค่าพร็อกซี TCP-changer แบบถาวร

ฉันมีผู้ให้บริการ (A) ที่ต้องการส่งข้อมูลถึงเราผ่านการเชื่อมต่อ TCP ขาเข้า น่าเสียดายที่เปลืองบริการ (B) ไม่สามารถรับการเชื่อมต่อ TCP ขาเข้า นอกจากนี้ยังไม่มี IP แบบคงที่ข้อกำหนดอื่น

วิธีหนึ่งในการแก้ไขปัญหานี้จะเป็นบริการที่เชื่อมต่อพอร์ต TCP A ขาเข้ากับพอร์ต TCP อื่น B ​​เพื่อให้ผู้บริโภคสามารถทำการเชื่อมต่อขาออกไปยัง B

นี่ไม่ใช่ปัญหาที่เป็นเอกลักษณ์[1] [2]และด้วย socat ฉันสามารถทำบางสิ่งบางอย่างใกล้เคียงกับสิ่งที่ฉันต้องการ:

socat -d -d -d -u TCP4-LISTEN:PORT-A,reuseaddr TCP4-LISTEN:PORT-B,reuseaddr

อย่างไรก็ตามนี่เป็นปัญหาต่อไปนี้:

• หาก B ตัดการเชื่อมต่อจะไม่สามารถเชื่อมต่อใหม่ได้ ด้วยTCP4-LISTEN:PORT-B,reuseaddr,forkมันสามารถเชื่อมต่อ แต่ไม่ได้รับข้อมูล
• B ไม่สามารถเชื่อมต่อก่อนที่ A ได้สร้างการเชื่อมต่อ (ผ่านได้)
• สามารถสร้างการเชื่อมต่อได้เพียงครั้งเดียวเพื่อPORT-B(เกินได้)

มีวิธีการปรับคำสั่งเพื่อที่จะกลายเป็น "permament" และทนต่อความล้มเหลว?

คำถามสำคัญคือ A จะตอบสนองต่อการสูญเสียการเชื่อมต่อหรือการเชื่อมต่อถูกปฏิเสธอย่างไร? อะไรก็ตามที่เพิ่งสันนิษฐานว่าการเชื่อมต่อ TCP เดียวจะคงอยู่ตลอดไปจะเปราะบาง นั่นเป็นเพียงลักษณะของอินเทอร์เน็ต

วิธีการเกี่ยวกับการตั้งค่าsocatเป็น[x]inetdบริการหรือไม่

คุณจะตั้งค่าxinetdให้ฟังใน PORT-B และเริ่มต้นsocat -u TCP4-LISTEN:PORT-A,reuseaddr STDIOทันทีที่เชื่อมต่อ B-side

xinetdจะผ่านทราฟฟิกขาเข้าจาก B-side ไปยังอินพุตมาตรฐานของsocatและจับเอาท์พุทมาตรฐานของsocatและผ่านไปยัง B-side

หาก B ยกเลิกการเชื่อมต่อจะทำให้socatกระบวนการสามารถสิ้นสุดได้ xinetdจะเริ่มใหม่ทันทีที่ B เชื่อมต่ออีกครั้ง ในขณะที่ B ถูกตัดการเชื่อมต่อ A จะได้รับข้อผิดพลาด "การเชื่อมต่อถูกปฏิเสธ"

ฉันเคยทำสิ่งที่คล้ายกันมากกับระบบ HP-UX เก่า

โลกแห่งความจริงยุ่งเหยิง

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

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

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

นอกจากนี้การเชื่อมต่อ TCP เป็นสตรีมของไบต์ไม่ใช่สตรีมของข้อความดังนั้นเมื่อการเชื่อมต่อของคุณตายคุณอาจได้รับข้อความบางส่วน

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

1. วิธีการแยกลำธารเมื่อมีการเชื่อมต่อใหม่เข้ามา
2. ควรเก็บข้อความหรือไม่เมื่อแหล่งข้อมูลเชื่อมต่อโดยผู้รับข้อมูลไม่ใช่
3. กลไกการตอบรับจากต้นทางถึงปลายทางเหมาะสมหรือไม่เพื่อป้องกันการสูญเสียข้อความ
4. ต้องใช้กลไก "ping" ระดับแอปพลิเคชันบางอย่างเพื่อเร่งความเร็วการตรวจจับการเชื่อมต่อที่ไม่ทำงานหรือไม่