Client SOCKS サポート

IBM i オペレーティングシステムは、SOCKS バージョン 4 をサポートしています。このため、ソケット・タイプが SOCK_STREAM である AF_INET アドレス・ファミリーを使用するプログラムは、ファイアウォールの外側にあるシステムで稼働しているサーバー・プログラムと通信することができます。

ファイアウォールとは、ネットワーク管理者がセキュア内部ネットワークと非セキュア外部ネットワークとの間に置く高度なセキュア・ホストのことです。一般に、そのようなネットワーク構成では、セキュア・ホストから非セキュア・ネットワークへと、またはその逆へと経路指定される通信は許可されません。ファイアウォール上に置かれる proxy サーバーは、セキュア・ホストと非セキュア・ネットワークとの間で必要となる管理を援助します。

セキュア内部ネットワーク内のホストで実行されるアプリケーションは、自らの要求をファイアウォールの proxy サーバーに送信することによって、ファイアウォールまでナビゲートしなければなりません。それを受けて、proxy サーバーはそれらの要求を非セキュア・ネットワーク上の実サーバーに転送します。また、送信元ホストのアプリケーションに応答を戻すこともできます。 proxy サーバーの一般的な例は、HTTP proxy サーバーです。 proxy サーバーは、HTTP クライアントのために、以下のような数多くのタスクを実行します。

proxy サーバーは、外部システムから内部ネットワークを隠します。
proxy サーバーは、外部システムによる直接アクセスからホストを保護します。
proxy サーバーは、適切に設計および構成されていれば、外部からのデータをフィルターに掛けることができます。

HTTP proxy サーバーは、HTTP クライアントのみを扱います。

1 つのファイアウォールで複数の proxy サーバーを実行する別の一般的な方法は、SOCKS サーバーとして知られる、より堅固な proxy サーバーを実行することです。 SOCKS サーバーは、ソケット API を介して確立された TCP クライアント接続に対して、proxy としての役割を果たすことができます。 IBM i クライアント SOCKS サポートの主な利点は、クライアント・コードを変更することなく、クライアント・アプリケーションが SOCKS サーバーに透過的にアクセスできることです。

以下の図は、一般的なファイアウォールの配置を示しています。ファイアウォールには、HTTP proxy、 Telnet proxy、SOCKS proxy が置かれています。インターネット上のサーバーにアクセスするセキュア・クライアントのために、2 つの TCP 接続が別々に使用されていることに注意してください。 1 つはセキュア・ホストから SOCKS サーバーへと、もう 1 つは非セキュア・ネットワークから SOCKS サーバーへと接続されています。

SOCKS サーバーを使用するためには、セキュア・クライアント・ホストで以下の 2 つのアクションを実行しなければなりません。

SOCKS サーバーを構成します。
セキュア・クライアント・システムにおいて、クライアント・システム上の SOCKS サーバーに送信されるすべてのアウトバウンド・クライアント TCP 接続を定義します。
クライアント SOCKS サポートを構成するには、以下のステップを実行します。
1. IBM Navigator for iから、［Network ］>［ TCP/IP Configuration］を展開し、［ TCP/IP Configuration Properties ］をクリックします。
2. 「SOCKS」タブをクリックします。
3. 「SOCKS」ページに関する接続情報を入力します。
注: セキュア・クライアント SOCKS 構成データは、セキュア・クライアント・ホスト・システム上のライブラリー QUSRSYS 内の QASOSCFG ファイルに保存されます。

構成が完了すると、システムは SOCKS ページで指定した SOCKS サーバーへ、特定のアウトバウンド接続を自動的に送信します。システムが自動的に行うので、クライアント・アプリケーションに変更を加える必要はありません。これが要求を受信すると、SOCKS サーバーは非セキュア・ネットワーク内のサーバーに対して別の外部の TCP/IP 接続を確立します。それから SOCKS サーバーは、内部 TCP/IP 接続と外部 TCP/IP 接続の間でデータを中継します。

注: 安全性の低いネットワーク上のリモート・ホストは、SOCKS サーバーに直接接続します。セキュア・クライアントに直接アクセスすることはできません。

ここまでは、セキュア・クライアントから送信されるアウトバウンド TCP 接続について説明しました。クライアント SOCKS サポートは、SOCKS サーバーにファイアウォールを経由するインバウンド接続要求を許可させることもできます。セキュア・クライアントから Rbind() 呼び出しを出せば、この通信が可能になります。 Rbind() が操作を行えるようにするため、セキュア・クライアントはすでに connect() 呼び出しを発行済みで、その呼び出しの結果、SOCKS サーバーを介したアウトバウンド接続が行われている必要があります。 Rbind() インバウンド接続は、connect() が確立したアウトバウンド接続が宛先にしていたのと同じ IP アドレスからのものでなければなりません。

以下は、アプリケーションに対して透過的な SOCKS サーバーと、ソケット API がどのように対話するかを分かりやすく示したものです。例では、FTP クライアントは Rbind() API を bind() API の代わりに呼び出します。これは、FTP クライアントからファイルまたはデータの送信が要求されたときに、FTP プロトコルによって FTP サーバーがデータ接続を確立できるようになるからです。この呼び出しを行うためには、 __Rbind プリプロセッサー #define (bind() を Rbind() として定義する) を使用して FTP クライアント・コードを再コンパイルします。別の方法として、アプリケーションが関連するソース・コードで Rbind() を明示的にコーディングすることもできます。アプリケーションが SOCKS サーバーからのインバウンド接続を必要としない場合は、Rbind() を使用しないでください。

注:

FTP クライアントは、非セキュア・ネットワークへのアウトバウンド TCP 接続を SOCK サーバー経由で開始します。 FTP クライアントが connect() で指定する宛先アドレスは、非セキュア・ネットワークに置かれている FTP サーバーの IP アドレスおよびポートです。セキュア・ホスト・システムは SOCKS ページから構成されています。これにより、この接続を SOCKS サーバーから送信できます。構成が完了すると、システムは SOCKS ページで指定された SOCKS サーバーへ接続を自動的に送信します。
ソケットがオープンされ、インバウンド TCP 接続を確立するための Rbind() が呼び出されます。確立が完了すると、このインバウンド接続は上記で指定したのと同じ宛先アウトバウンド IP アドレスから接続します。特定のスレッドについては、SOCKS サーバーを介するアウトバウンド接続とインバウンド接続は対にする必要があります。言い換えれば、すべての Rbind() インバウンド接続は、SOCKS サーバーを使用したアウトバウンド接続の直後に実行されなければなりません。 Rbind() を実行する前に、このスレッドと関連する非 SOCKS 接続への介入を試行することはできません。
getsockname() は SOCKS サーバーのアドレスを戻します。ソケットは、SOCKS サーバーから選択したポートと対になっている SOCKS サーバー IP アドレスに論理的にバインドされます。この例では、アドレスは制御接続ソケット CTLed によって、非セキュア・ネットワークに置かれている FTP サーバーへ送信されます。これは FTP サーバーが接続されているアドレスです。 FTP サーバーは SOCKS サーバーに接続されますが、直接セキュア・ホストに接続されることはありません。
SOCKS サーバーは FTP クライアントとのデータ接続を確立し、FTP クライアントと FTP サーバーの間でデータを中継します。ほとんどの SOCKS サーバーは、サーバーが一定の時間だけセキュア・クライアントに接続するのを許可します。サーバーがその時間内に接続しない場合は、accept() でエラー ECONNABORTED が戻されます。