Kalıcı bir TCP cinsiyet değiştirici proxy nasıl kurulur?

Gelen bir TCP bağlantısı üzerinden bize veri göndermek isteyen bir sağlayıcı (A) var. Maalesef tüketen hizmet (B) gelen TCP bağlantılarını alamıyor. Ayrıca statik bir IP, başka bir gereksinimi yoktur.

Bunu çözmenin bir yolu, gelen TCP A bağlantı noktasını başka bir TCP bağlantı noktasına B bağlayan bir hizmettir, böylece tüketici B'ye giden bağlantı kurabilir.

Bu benzersiz bir sorun değil [1] [2] ve socat ile istediğim şeye çok yakın bir şey yapabilirim:

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

Ancak, bunun aşağıdaki sorunları vardır:

• B bağlantısı kesilirse, yeniden bağlanamaz. İle TCP4-LISTEN:PORT-B,reuseaddr,forkbağlanabilir, ancak veri almaz.
• A bir bağlantı kurmadan önce B bağlanamaz (aşılır)
• İle sadece bir bağlantı kurulabilir PORT-B(aşılabilir)

Komutu "permament" olacak ve hatalara karşı dirençli olacak şekilde ayarlamanın bir yolu var mı?

Önemli soru, A'nın bağlantı kaybına veya reddedilen bağlantıya nasıl tepki vereceği? Sadece tek bir TCP bağlantısının sonsuza kadar ayakta kalacağını varsayan her şey kırılgan olacaktır; bu sadece internetin doğası.

Hizmet socatolarak kurulmaya ne dersiniz [x]inetd?

Sen kuracak xinetdPORT-B'de dinlemeye ve başlangıç socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIOB tarafı bağladığı en kısa sürede.

xinetdgelen trafiği B tarafından standart girdiye geçirecek ve socatstandart çıktısını yakalayıp socatB tarafına geçirecektir.

B'nin bağlantısı kesilirse, socatişlemin bitmesine izin verilebilir; xinetdB tekrar bağlanır bağlanmaz yeni bir tane başlatacaktır. B bağlantısı kesildiğinde, A "bağlantı reddedildi" hataları alır.

Bir zamanlar eski bir HP-UX sisteminde oldukça benzer bir şey yapmak zorunda kaldım.

Gerçek dünya dağınık.

Gerçek dünyada bazen TCP bağlantıları ölür, bu durum duruma bağlı bir güvenlik duvarı veya NAT yeniden başlatılırsa, bağlantı trafik olmadan çok uzun sürerse, alttaki bağlantı çok uzun süre kesilirse oluşabilir.

Ayrıca bazen bağlantılar öldüğünde simetrik olarak ölmezler. Çok fazla veri taşıyan bir bağlantı koparsa, gönderenin karşılık verenin çok önce öldüğünü fark etmesi muhtemeldir. Bunun birkaç yan etkisi vardır.

• Eğer gönderenden alıcıya bağlantı başlatılırsa, eski bağlantı hala canlıyken yeni bir bağlantı gelebilir.
• Bağlantı karşılıktan göndericiye başlatılırsa, bağlantının koptuğunu algılayan gönderen ile bu gerçeği algılayan ve yeniden bağlantıyı tetikleyen alıcı arasında önemli bir gecikme olabilir.

Ayrıca TCP bağlantıları bir bayt akışıdır, bir mesaj akışı DEĞİLDİR, bu nedenle bağlantınız öldüğünde kısmi bir mesaj alabilirsiniz.

Bunun net sonucu beni, güçlü bir çözümün, çözümünüzün anlayabilmesi için uygulama protokolünün anlaşılmasını gerektirdiği sonucuna götürmektedir.

1. Yeni bir bağlantı geldiğinde akışların nasıl birleştirileceği.
2. Veri kaynağı veri alıcısı tarafından bağlandığında mesajların saklanıp saklanmayacağı.
3. Mesaj kaybını önlemek için uçtan uca bir onay mekanizmasının uygun olup olmadığı.
4. Ölü bağlantıların algılanmasını hızlandırmak için bir tür uygulama seviyesi "ping" mekanizmasının gerekli olup olmadığı.