マニュアルページには次の内容がsocat
記載されています。socatは、2つの双方向バイトストリームを設定し、それらの間でデータを転送するコマンドラインベースのユーティリティです。これに基づいて、主張の順序は重要ではありません。私はしばしば他のソースから同じ内容を読みます。
しかし、時には順序が重要だと感じる時もあります。例:顧客のネットワークにSSH経由でアクセスできる組み込みシステムがあります。埋め込みは、MS SQLデータベースへの直接アクセスを提供します。データベースの内容をデバッグするには、ホストコンピュータ(IP 192.168.100.1)のVirtualBox VMで実行されているAzure Data Studioを使用したいと思います。あまりにも簡単なことはssh -L1433:dbserver:1433
役に立ちません。これが私がsocatを使用しているところです。
まず、ローカル転送を使用し、宛先ポート1433をローカルポート11433に接続します。
ssh my-remote-embedded -N -L11433:dbserver:1433
socat
その後、仮想マシンがポートにアクセスできるように、0.0.0.0にバインドされているポート11433と1433の間に直接接続を作成しました。
私がこうすれば:
socat -v tcp:localhost:11433 tcp-listen:1433,bind=0.0.0.0,fork,reuseaddr
その後、Azure Data Studioは192.168.100.1:1433に接続しようとし、接続は機能しますが機能しません. Azure Data Studioが接続され(socat出力でバイトが双方向に流れることを確認できるオプションのおかげで
-v
)、接続アイコンが緑色に変わりますが、データベースのリストを取得できず、通常のクエリも機能しません。
しかし、socat呼び出しの順序を次のように置き換えると:
socat -v tcp-listen:1433,bind=0.0.0.0,fork,reuseaddr tcp:localhost:11433
Azure Data Studio は再起動後すぐに接続し、問題なくデータベースの一覧を取得し、クエリが正常に動作します。
Azure Data Studioを閉じて交換されたパラメータを使用してsocatを再起動すると、この問題が再発生します。接続はほとんど機能しません。
したがって、socatのパラメータの順序は次のとおりです。する本当に重要です。私は狂った?私がここで何を見逃しているのでしょうか?
私は知っているhttps://learn.microsoft.com/en-us/azure-data-studio/download-azure-data-studio?tabs=win-install%2Cwin-user-install%2Credhat-install%2Cwindows-uninstall%2Credhat-アンインストール#install-azure-data-studioLinux用のインストールガイドがあります。私の質問はこれに関するものではなく、socatに関するものです。毎回動作を再現できる例に過ぎません。
ベストアンサー1
それに気づきましたか?
主張の順序は重要ではありません。私はしばしば他のソースから同じ内容を読みます。
socat
興味深いことに、()のドキュメントは次のようにman socat
一致しない可能性があります。
オープンフェーズでは、socatは最初のアドレスを開き、2番目のアドレスを開きます。これらのステップは通常ブロックされます。したがって、特にソックスなどの複雑なアドレスタイプの場合は、次の手順を開始する前に接続要求または認証会話を完了する必要があります。
これは、現在見ている動作の少なくとも一部を説明できます。理想的には、リモートサービスに接続しようとする前にリスニングソケットに接続する必要があります。そうではなく、ローカルソケットで接続要求を実行する前にリモートサービスに接続すると、リモート側でアイドルタイムアウトが発生する可能性があります。
まずローカル、その後リモート:
socat -v tcp-listen:1433,bind=0.0.0.0,fork,reuseaddr tcp:localhost:11433 # Yes
まずリモートで、次にローカルで:
socat -v tcp:localhost:11433 tcp-listen:1433,bind=0.0.0.0,fork,reuseaddr # No