共通の表記
TCPrelay
例) 同様の役割をする、TCP 上の2つのプロキシー
UDPrelay
例) 同様の役割をする、UDP 上の 2つのプロキシー
例) UDP/TCP 間のゲートウェイ
上記のような一対のゲートウェイは、TCP 接続上で UDP パケットを伝送できますが、 このような中継（トンネリング）は、単一の TCP 接続で SockMux を使用することで、さらに能率的に実現できます。
DGAuth サーバー
例) DGAuth-DeleGate サーバーとそのクライアント
例) DGAuth-DeleGate サーバーと同じホスト上のクライアント
DGAuth サーバーは、各プロトコル用のダイジェスト計算に使用する構成要素一式を受信し、 以下のようにダイジェストを返します。
PAM server
例) PAM-DeleGate サーバーとそのクライアント
例) PAM-DeleGate サーバーとそのクライアントの SSL 上での通信
注記：ほとんどの PAM 認証は Unix 上のスーパーユーザー特権 (OWNER="root" オプションを伴う) で実行することが必要です。 しかし、DGROOT/subin/ に、 外部プログラム "dgpam" をインストールすることで、 スーパーユーザー特権をともなう DeleGate を走らせることを回避できます。
実験 PAM/HTTP サーバー の初期ポート番号は、8686 です。 他のポートは、 AUTHRIZER=-pam//host..port で指定できます。例) AUTHORIZER="-pam//hostX..8765/passwd"
PAM/HTTP プロトコルは、以下のような HTTP 互換の 要求/応答メッセージ書式を使用します。
要求 URL の基点 "/-/pam/" は、PAMCONF="baseurl:/basePath/" で、 任意のパスに置き換えることができます。 要求 URL 全体は、PAMCONF="url:/path" で置き換えられます。 現仕様では、応答メッセージ中の内容は注意されませんが、 将来、いくつかの認証関連情報または、 能力情報は伝達できるようになります。
- 要求：
- GET /-/pam/service/auth HTTP/1.0
Authorization: Basic BASE64of(User:Pass)
- 応答 (以下のいずれか):
- HTTP/1.0 200 OK, authorized
HTTP/1.0 401 Not authorized
HTTP/1.0 403 Forbidden to use the PAM server
次の書式により、あなたは、PAM-DeleGate に代えて、CGI 等を伴う HTTPサーバー などを使用し、PAM サーバーを開発できます。
FTPxHTTP server
YYsh server
YYMUX サーバー
SOCKMUX parameter* == SOCKMUX=host:port:option[,option]* option == acc | con | ssl -- default: none -- status: tentative
host:port は SockMux の持続的接続を確立する 対象のポートを指定します。 接続は、"con" オプションを持つ DeleGate から、 "acc" オプションを持つ DeleGate へ確立されます。
オプション:
例) SockMux 越えで SOCKS プロキシーを連鎖する
例) SockMux 越えで SOCKS プロキシーを連鎖する(サーバー側から接続する)
例) SockMux 越えで HTTP プロキシーを連鎖する
SOXCONF parameter* == SOXCONF=confSpec[,confSpec]* -- default: none
SockMux サーバー
常駐接続は、レセプター側では、"-Phost:port" パラメーター、コネクター側では、 "SERVER=sockmux://host:port" によって生成されます。 外部のリモートへの転送を行うため、接続を受理するポートは、 PORT="listOfPorts パラメーターで指定します。 リモートから内部サーバーへの接続は、接尾文字列 ",-in" を、SERVER="telnet://host:23,-in" のようにつけて指定します。
1つの内部への接続は、指定したプロトコルのプロキシーである DeleGate で処理できます。 プロトコル名が、SERVER="telnet,-in" または "-in" が 接尾された "-in(option list)" のような 指定をした場合のみ、DeleGate は接続処理を呼び出します。 オプションリスト は、起動された DeleGate に コマンドラインオプションリストとして渡されます。 例）SERVER="telnet://host,-in(+=config.cnf)" は、 ``delegated SERVER=telnet://host +=config.cnf'' のような コマンドラインオプションで、DeleGate を起動します。
例) 双方向 SockMux-DeleGate
例) 単方向 SockMux-DeleGate
例）単方向 を proxy-Telent-DeleGate へ
SockMux をソケット間のデータ中継に使用する場合、 アプリケーションプロトコルを解釈せずに SockMux 上を中継します。 このような中継は、SERVER パラメーターの代わりに、 DEST パラメーターを使用することで、以下のように、簡単な表記で表現できます：
例) SockMux 経由の tcprelay
Example: SockMux/TCP 経由で UDP を中継する
これらは、他の方法として、名前付パイプのような単一の FIFO デバイスを使用し 2つの SockMux-DeleGate 間の常駐接続を作ります。 それは、SERVER=sockmux:commtype@fifoName のように指定し、 この、commtype は、"commin", "commout", "comm" の内一つで、 それぞれ、単方向入力，単方向出力，双方向入出力を表します。
例）ホスト上の FIFO デバイスを使用する。
例）2ホスト間の通信ポートを使用する (未テスト)
常駐接続は DeleGate により起動された外部プログラムにより生成できます。 プログラムの処理は、 ファイルディスクリプター番号 0 および、1 で DeleGate とのソケット でやり取りされます;
例) 外部コマンドを使用して接続を開始する。
リモートから内部への接続するための対象サーバーは、 受け付けたリモートポートによって選択できます。 SERVER パラメーターに、 ":-:-Pxxxx" を後置することで、PORT=xxxx によりリモートホスト上で 受け付けられた接続にのみ有効になります。
例）複数のポートを転送する
注記）FTP データ接続の転送は、(まだ)サポートされません。
HTMUX parameter == HTMUX=sv[:[hostList][:portList]] | HTMUX=cl:host:port | HTMUX=px:host:port -- 制限: CAPSKEY が必要 -- default: none
標準で、入ってくる接続だけでなく、HTMUX クライアントから出てゆく接続も HTMUX サーバー経由で達成されます。 これは、内部サーバーへ入ってくる要求を転送する DeleGate には不要でしょう。 例えば、このようなケースでは、CONNECT="direct:*:192.168.1.*" のように CONNECT パラメーターを使って、そのような接続を直接的に確立するように指定します。
例)
この例では、hostX は、プライベートアドレス 192.168.1.1 とグローバルアドレス xx.xx.xx.xx を持つマルチホームホストであることを表しています。 hostX 上の DeleGate は、HTMUX サーバーとして機能しています。 hostI 上の HTTP DeleGate と、hostJ 上の FTP DeleGate は、 HTMUX クライアントとして機能していて、hostX 上の HTMUX サーバー経由で、 (xx.xx.xx.xx に来た) 要求を遠隔で受け付けています。
一対の HTMUX サーバー/クライアントは、SockMux プロトコルによって多重化された 複数の並列接続をリレーする単一の持続的接続を使います。 この機能は、入ってくる接続がファイアーウォール上の制限をすり抜けでくるような 悪意を持った使われかたをされてはいけません。 ですので、この機能を有効にするには、CAPSKEY を導入する必要があります。 HTMUX で他に標準で無効になっているのは、 クライアントサーバー間の間接接続(NAT やプロキシー経由の接続)、 クライアントサーバー間の大きすぎる時間のずれ(初期値は300秒)、 クライアントサーバー間に挿入された SSL 暗号化です。
HTMUX のための間接接続を有効にするには2通りの方法があります。
ひとつは、CAPSKEY を導入して、間接 HTMUX 接続を有効にする。
もうひとつは、下記例のように HTMUX プロキシーを挟む事です。
例) HTMUX を HTMUX プロキシーとともにカスケードする
HTMUX クライアントサーバー間の持続的な接続は、双方向接続を搬送できますので、 それ上に一対のプロキシーを形成できます。 各プロキシーは、以下の例のようにローカルポートで要求を受け付けて遠隔のプロキシーに転送します。
例) HTMUX を対称性を持つプロキシーにして使う(もっとも簡単な汎用的な設定)
この例で、-P8080 はワイルドカードアドレス表現 "-P*:8080" と同じで、
ホスト上の全インターフェースのポート番号 8080 から受け付けます。
ですので、hostX 上の任意のインターフェース上のポート 8080 への要求は、
HTMUX クライアント(および HTTP プロキシー)としての hostX 上の DeleGate 経由
でサーバーに転送されます。
対称的に hostY 上の任意のインターフェース上のポート 8080 への要求は、
HTTP プロキシー(および hostX:9876 での HTMUX サーバ)としての hostX 上の
DeleGate 経由でサーバーに転送されます。
(今一度、標準でこの機能は無効になっており、有効にするには CAPSKEY
が必要です。)
サーバー側とクライアント側で使うポートは、-P または -Q オプションに "/local" と "/remote" 修飾子を使う事で別々に指定できます。 "/local" は、ポートをローカルホスト上で使う(HTMUX クライアントで)事を明示し、 "/remote" は、ポートをリモートホスト上で使う(HTMUX サーバー)事を明示します。 上記例の "-P8080" の指定は、"-P*:8080/remote,*:8080/local" と同じです。
例) HTMUX を双方向に使う
この例で、hostX と hostI 間で、 それぞれのホスト上の localhost:8081 への要求は、 対向に転送されます ("-Plocalhost:8081/remote,localhost:8081/local" と同じ)。 hostX と hostJ 間で、 hostX:8082 and hostJ:8083 は、対向に転送されます ("-PhostX:8082/remote,hostJ:8083/local" と同じ)。
例) HTMUX を外向けの要求にのみ使う。
これは、HTMUX を外向けの要求にのみ使う例です。 HTMUX パラメータがなくても動きますが、HTMUX により、サーバークライアント間では、 単一の持続的接続が使われます。 この HTMUX の使いかたは DeleGate がフォアグラウンド動作しているとき (-fv オプションを伴い、サービスやデーモンとしてではなく) に上記制限や CAPSKEY 無しで、標準で使えます。
CAPSKEY parameter* == CAPSKEY=opaque -- default: none
Socks サーバー
例) Socks-DeleGate
Socks-DeleGate サーバー経由で内向けの TCP 接続を許可する場合、 そのために使用されるネットワークインターフェースは、DeleGate が自動的に選択します (DST.ADDR または、SOCKS クライアントから BIND コマンドのパラメーターとして送られた、DSTIP を基準として)。 SRCIF を指定した場合、擬似プロトコル名 "tcpbind" と共に、 ネットワークインターフェース（およびポート番号）を指定できます。 パラメーターの完全な書式は、 SRCIF= "[host]:[port]:tcpbind[:dstHostList[:srcHostList]]" となります。 通常、host フィールドには、選択するネットワークインターフェースのみを、 SRCIF="150.29.202.120::tcpbind" のように指定します。
注記: DeleGate を、他の SOCKS サーバーと連結する時、UDP リレーで、 DeleGate によって、内部的に仮に拡張された SOCKS プロトコルに起因する、問題が発生するかもしれません。 そのような問題を回避するために以下の SRCIF パラメーターが使えます。