日本語 man コマンド類 (ja-man-1.1j_5) と日本語 man ドキュメント (ja-man-doc-5.4 (5.4-RELEASE 用) など) をインストールすると、以下のような man コマンド閲覧、キーワード検索が コンソールからできるようになります。
4.11-RELEASE-K, 5.4-RELEASE-K, 5.5-RELEASE-K, 6.0-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K, 12.1-RELEASE-K は、 プライベート版 (小金丸が編集してまとめたもの) ですが、 より多くの翻訳したファイルが含まれています。 (5.4-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K から 12.4-RELEASE-K, 13.0-RELEASE-K から 13.3-RELEASE-K, 14.0-RELEASE-K から 14.1-RELEASE-K は、全翻訳済み)
13.3-STABLE-K, 15.0-CURRENT-K は現在、作成中で日々更新されています。
Table of Contents
LIBALIAS(3) FreeBSD ライブラリ関数マニュアル LIBALIAS(3)
名称
libalias -- マスカレードとネットワークアドレス変換のためのパケットエイリ
アスライブラリ
書式
#include <sys/types.h>
#include <netinet/in.h>
#include <alias.h>
関数のプロトタイプは、テキストの本文で与えられます。
解説
libalias ライブラリは、マスカレードとネットワークアドレス変換 (NAT) を対
象とした、IP パケットのエイリアスとデエイリアス (エイリアスの解除) のため
の関数を集めたものです。
紹介
このライブラリは、IP マスカレードとネットワークアドレス変換の処理過程を支
援するように設計された適度に移植性のある関数の集合です。未登録の IP アド
レスのローカルネットワークからの発信するパケットは、あたかもそれらがアク
セス可能な IP アドレスから来たかのように見えるエイリアスできます。それら
がローカルネットワークの正確なマシンに送信されるように、着信パケットは、
デエイリアスされます。
ある程度の柔軟性は、パケットエイリアスエンジンのなかに組み込まれていま
す。最も簡単な操作モードにおいて、多対 1 のアドレスマッピングは、ローカル
ネットワークとパケットエイリアスホストの間で行なわれます。これは、IP マス
カレードとして知られています。さらに、ローカルアドレスとパブリックアドレ
スの間の 1 対 1 のマッピングも実装することができ、それは、静的 NAT として
知られています。これらの極端の間では、プライベートアドレスの異なるグルー
プは、いくつかのはっきりと識別できる多対 1 のマッピングを構成する、異なる
パブリックアドレスにリンクできます。さらに、与えられたパブリックアドレス
とポートは、静的にプライベートアドレス/ポートに転送先を変更できます。
初期化と制御
特別な 1 つの関数、LibAliasInit() は、すべてのパケット操作が実行される前
に、常に呼び出されなければなりません、そして、他のすべての関数へ渡されな
ければならないポインタのインスタンスを返します。通常 LibAliasSetAddress()
関数は、デフォルトのエイリアスアドレスを設定するために後で呼び出されま
す。さらに、パケットエイリアスエンジンの操作のモードは、LibAliasSetMode()
を呼び出すことによりカスタマイズできます。
struct libalias * LibAliasInit(struct libalias *)
この関数は、内部データ構造体を初期化するために使用されます。最初に
呼び出されたとき、引数として NULL ポインタが渡されるべきです。次の
モードビットは、LibAliasInit() を呼び出した後に常に設定されます。こ
れらのモードビットの意味に関しては、下記の LibAliasSetMode() の記述
を参照してください。
PKT_ALIAS_SAME_PORTS
PKT_ALIAS_USE_SOCKETS
PKT_ALIAS_RESET_ON_ADDR_CHANGE
この関数は、同じ初期状態のパケットエイリアスエンジンを常に返しま
す。LibAliasSetAddress() 関数は、通常後で呼び出され、また、上記のリ
ストされたデフォルトモードビットからのどんな要望された変更は、
LibAliasSetMode() への呼び出しを要求します。
この関数は、必ず任意のパケット操作の前にプログラムの最初で呼び出し
てください。
void LibAliasUninit(struct libalias *)
この関数は、返り値がなく、内部データ構造体にアタッチされた任意のリ
ソースをクリアするために使用されます。
この関数は、プログラムがエイリアスエンジンの使用を停止されるときに
呼び出されるべきです。とりわけ、それは、どんなファイアウォールの穴
もきれいに一掃します。後方互換性と特別なセキュリティを提供するため
に、それは、LibAliasInit() によって atexit(3) チェーンに追加されま
す。
void LibAliasSetAddress(struct libalias *, struct in_addr addr)
この関数は、ローカルエリアネットワークから発信するパケットがエイリ
アスされるソースアドレスを設定します。すべての発信パケットは、
LibAliasRedirectAddr() によって確立された静的アドレスのマッピングに
よって上書きされなければ、このアドレスへ再マッピングされます。この
関数が呼び出されず、静的規則が一致しないなら、発信パケットは、その
ソースアドレスを保持します。
PKT_ALIAS_RESET_ON_ADDR_CHANGE モードビット (デフォルトの操作モー
ド) が設定されるなら、内部エイリアスリンクテーブルは、エイリアスア
ドレスの変更のときは、いつでもリセットされます。これは、IP アドレス
が連続するダイヤルアップの試みで変更されるかどうか分からないところ
で、ppp(8) のようなインタフェースに便利です。
PKT_ALIAS_RESET_ON_ADDR_CHANGE モードビットが 0 に設定されるなら、
(オーバヘッドの少ない呼び出しで) また、パケットからパケット基盤でエ
イリアスアドレスを動的に変更するために、この関数も使用することがで
きます。
この関数は、必ず任意のパケット操作の前で呼び出してください。
unsigned int LibAliasSetMode(struct libalias *, unsigned int flags,
unsigned int mask)
この関数は、flags の値に従ってモードビットを設定するか、またはクリ
アします。mask でマークされたビットだけが影響されます。次のモード
ビットが <alias.h> に定義されています。
PKT_ALIAS_LOG
/var/log/alias.log へのロギングを可能にします。エイリアスリ
ンクが作成されるか、または削除されるたびに、ログファイル
は、ICMP、TCP と UDP リンクの現在の数が追加されます。ログ
ファイルが tail(1) で連続的に見られるとき、主としてデバッグ
するために役立ちます。
PKT_ALIAS_DENY_INCOMING
このモードビットが設定されるなら、新しい TCP 接続または新し
い UDP トランザクションに関連したすべての着信パケットは、呼
び出しプログラムによって無視される (LibAliasIn() は、
PKT_ALIAS_IGNORED コードを返します) ようにマークされます。
パケットエイリアスホストまたはローカルネットワークから始め
られた接続かトランザクションへのレスポンスパケットは、影響
されません。このモードビットは、一方向のファイアウォールを
実装するために役立ちます。
PKT_ALIAS_SAME_PORTS
このモードビットが設定されるなら、パケットエイリアスエンジ
ンは、実際のローカルポート番号からエイリアスポート番号をそ
のまま変更しないようにします。これは、5 つ (プロト
(proto)、エイリアスアドレス、エイリアスポート、リモートアド
レス、リモートポート) がユニークな限り行うことができます。
競合が存在するなら、例えば、このモードビットが設定されてい
ても、新しいエイリアスポート番号が選択されます。
PKT_ALIAS_USE_SOCKETS
パケットエイリアスホストがネットワークトラフィックを転送す
るのと同様にそれを発生するとき、このビットは、設定されるべ
きです。パケットエイリアスホストが、未知のホストアドレスあ
るいは未知のポート番号からの接続 (例えば FTP データ接続) を
待っているとき、このモードビットは、ポート競合を防ぐために
プレースホルダとしてソケットが割り付けられることを特定しま
す。いったん接続が確立されれば、通常 1 分程度以内でソケット
は、クローズされます。
PKT_ALIAS_UNREGISTERED_ONLY
このモードビットが設定されるなら、未登録のアドレス空間から
発生しないローカルネットワーク上のトラフィックは、無視され
ます。標準クラス A、B と C の未登録のアドレスは、次の通りで
す:
10.0.0.0 -> 10.255.255.255 (クラス A サブネット)
172.16.0.0 -> 172.31.255.255 (クラス B サブネット)
192.168.0.0 -> 192.168.255.255 (クラス C サブネット)
このオプションは、パケットエイリアスホストが異なるインタ
フェース上のサブネットを登録したか未登録の両方の場合に有用
です。登録されたサブネットは、完全に外部の世界へアクセス可
能です。したがって、それからのトラフィックは、パケットエイ
リアスエンジンを通して渡される必要はありません。
PKT_ALIAS_UNREGISTERED_CGN
PKT_ALIAS_UNREGISTERED_ONLY に似ていますが、次のように RFC
6598 (Carrier Grade NAT) サブネットを含みます:
100.64.0.0 -> 100.127.255.255 (RFC 6598 subnet)
PKT_ALIAS_RESET_ON_ADDR_CHANGE
このモードビットが設定され、LibAliasSetAddress() がエイリア
スアドレスを変更するために呼び出されるとき、パケットエイリ
アスエンジンの内部リンクテーブルは、クリアされます。インタ
フェースアドレスが時々変更できるか、ダイヤルアップの試みの
間で同じのままでありうるところで、この操作モードは、ppp(8)
リンクに役立ちます。このモードビットが設定されないなら、リ
ンクテーブルは、アドレス変更のイベントでリセットされませ
ん。
PKT_ALIAS_PUNCH_FW
このオプションは、FTP/IRC DCC 接続のためのファイアウォール
をベースとする ipfirewall(4) の libalias ``パンチホール''
を作ります。パンチホールは、IP アドレスとポートから/によっ
て結びつけられます。別の接続のためにホール使用することでき
ません。それを使用する接続が止まるとき、ホールは、取り除け
られます。libalias (例えば、kill -9) を使用してプログラムの
予期しない終りを応じることは、フラグの状態の変更によりホー
ルのために割り付けられたすべてのファイアウォール範囲をクリ
アします。また、このクリアは、このフラグを設定する前に起こ
らなければならない、LibAliasSetFWBase() への初期の呼び出し
で起こります。
PKT_ALIAS_REVERSE
このオプションは、libalias が、外部インタフェースではなく内
部インタフェースを通して渡されるデータを送り込むことを可能
にして、着信パケットと発信パケットを操作する方法を反転させ
ます。
PKT_ALIAS_PROXY_ONLY
このオプションは、libalias に透過なプロキシ規則だけに従うよ
うに命じます。通常のパケットエイリアスは、実行されません。
詳細については、下記の LibAliasProxyRule() を参照してくださ
い。
PKT_ALIAS_SKIP_GLOBAL
このオプションは、ipfw_nat によってのみ使用されます。
LibAliasSetMode() へのフラグとして、それを指定することは、
効果がありません。その他の詳細については、ipfw(8) のセク
ション「ネットワークアドレス変換 (NETWORK ADDRESS
TRANSLATION)」を参照してください。
void LibAliasSetFWBase(struct libalias *, unsigned int base, unsigned int
num)
パンチファイアウォールの穴のために (PKT_ALIAS_PUNCH_FW フラグで) 割
り付けられたファイアウォール範囲を設定します。範囲は、初期化ですべ
ての規則のためにクリアされます。
void LibAliasSkinnyPort(struct libalias *, unsigned int port)
Skinny Station プロトコルによって使用される TCP ポートを設定しま
す。Skinny は、ボイス IP 呼び出しを設定するために Cisco Call Man
agers (マネージャ) と通信するために、Cisco IP 電話によって使用され
ます。これが設定されないなら、Skinny エイリアスは、行われません。
Skinny によって使用される典型的なポートは、2000 です。
パケット操作
パケット操作関数は、(リモートからローカルへの) 着信パケット、(ローカルか
らリモートへの) 発信パケットを修正するために使用されます。呼び出しプログ
ラムは、ネットワークインタフェースを介する受信パケットと送信パケットに対
して責任があります。
LibAliasInit() と LibAliasSetAddress() とともに、2 つのパケット操作関数
LibAliasIn() と LibAliasOut() は、基本的な IP マスカレードの実装のために
必要とされる最低限の一式の関数で構成されています。
int LibAliasIn(struct libalias *, char *buffer, int maxpacketsize)
リモートマシンからローカルネットワークに到達する着信パケットは、こ
の関数によってデエイリアス (de-aliase) されます。IP パケットは、
buffer によって指されます。また、maxpacketsize は、パケットを含んで
いるデータ構造体のサイズを示し、実際のパケットサイズより少なくとも
同じ大きさであるべきです。
返りコードは、次の通りです:
PKT_ALIAS_OK
パケットエイリアス処理は、成功しました。
PKT_ALIAS_IGNORED
パケットは、無視され、デエイリアスされませんでした。プロト
コルが認識されないなら、ICMP メッセージタイプが操作されない
か、または新しい接続のための着信パケットが無視されるなら、
(PKT_ALIAS_DENY_INCOMING モードビットが LibAliasSetMode()
を使用して設定されたなら)、これは、起こるかもしれません。
PKT_ALIAS_UNRESOLVED_FRAGMENT
ヘッダフラグメントがまだ送られていないので、フラグメントを
解決することができないとき、これは、返されます。この状況
で、ヘッダフラグメントが見つかるまで、フラグメントは、
LibAliasSaveFragment() で保存されなければなりません。
PKT_ALIAS_FOUND_HEADER_FRAGMENT
パケットエイリアスプロセスは、成功し、ヘッダフラグメント
は、見つかりました。これは、LibAliasGetFragment() で任意の
未解決のフラグメントを検索するシグナルで、
LibAliasFragmentIn() でそれらをデエイリアスします。
PKT_ALIAS_ERROR
パケットエイリアスエンジン内で内部エラーが生じました。
int LibAliasOut(struct libalias *, char *buffer, int maxpacketsize)
ローカルネットワークからリモートマシンへ到達する発信パケットは、こ
の関数によってエイリアスされます。IP パケットは、buffer によって指
されます。また、maxpacketsize は、最大のパケットサイズを示し、変更
されるパケット長を許容できるべきです。IP エンコードプロトコルは、修
正されなければならず、パケットの長さの変更を明らかにすることができ
るカプセル化されたデータストリームにアドレスとポート情報を置きま
す。そのようなプロトコルのよく知られた例は、FTP と IRC DCC です。
返りコードは、次の通りです:
PKT_ALIAS_OK
パケットエイリアス処理は、成功しました。
PKT_ALIAS_IGNORED
パケットは、無視され、エイリアスされませんでした。プロトコ
ルが認識できないか、あるいは ICMP メッセージタイプが操作さ
れないなら、これは、起こるかもしれません。
PKT_ALIAS_ERROR
パケットエイリアスエンジン内で内部エラーが生じました。
ポートとアドレスリダイレクション (出力先変更)
このセクションに記述された関数は、ローカルネットワーク上のマシンが、外部
ネットワークからの新しく着信する通信をある程度アクセス可能にすることを許
可します。個々のポートは、再マップすることができるか、または静的なネット
ワークアドレス変換を指定できます。
struct alias_link * LibAliasRedirectPort(struct libalias *,
struct in_addr local_addr, u_short local_port,
struct in_addr remote_addr, u_short remote_port,
struct in_addr alias_addr, u_short alias_port, u_char proto)
この機能は、与えられたリモートアドレス/ポートから指定されたローカル
アドレス/ポートへリダイレクトされるエイリアスアドレス/ポートへのト
ラフィックを明記します。<netinet/in.h> で定義されるように、パラメー
タ proto は、IPPROTO_TCP または IPPROTO_UDP のいずれかを指定できま
す。
local_addr または alias_addr が 0 であるなら、これは、
LibAliasSetAddress() によって確立されるパケットエイリアスアドレスが
使用されることを示します。LibAliasSetAddress() が
LibAliasRedirectPort() が呼ばれた後、アドレスを変更するために呼ばれ
ても、0 参照は、この変更を追跡記録するでしょう。
リンクがロード共有で操作をさらに設定するなら、local_addr と
local_port は、無視され、下記の LibAliasAddServer() に記述されるよ
うに、サーバプールから動的に選択されます。
remote_addr が 0 であるなら、任意のリモートアドレスからのパケットを
リダイレクトすることを示します、同様に、remote_port が 0 であるな
ら、任意のリモートポート番号から由来するパケットをリダイレクトする
ことを示します。リモートポート仕様は、ほとんどの場合、0 になります
が、0 でないリモートアドレスは、ファイアウォールに時々役立つことが
できます。LibAliasRedirectPort() への 2 つの呼び出しがそれらのアド
レス/ポート仕様で重複するなら、最新の呼び出しが優先されます。
この関数は、LibAliasRedirectDelete() によって続いて使用することがで
きるポインタを返します。NULL が返されるなら、関数呼び出しは、成功し
て終了しませんでした。
すべてのポート番号は、ネットワークアドレスバイト順であるべきです。
したがって、これらのパラメータを内部的に判読可能な数値からネット
ワークバイト順に変換するために htons(3) を使用する必要があります。
アドレスもまた struct in_addr データタイプを暗黙で使用するネット
ワークバイト順です。
struct alias_link * LibAliasRedirectAddr(struct libalias *,
struct in_addr local_addr, struct in_addr alias_addr)
この関数は、alias_addr へのすべての着信トラフィックを local_addr に
リダイレクトするように指定します。同様に、local_addr からのすべての
発信トラフィックは、alias_addr にエイリアスされます。
local_addr または alias_addr が 0 であるなら、これは、
LibAliasSetAddress() によって確立されるパケットエイリアスアドレスが
使用されることを示します。LibAliasSetAddress() が
LibAliasRedirectAddr() が呼び出された後にアドレスを変更するために呼
び出されても、0 参照は、この変更を追跡記録します。
リンクがロード共有で操作をさらに設定するなら、local_addr 引数は、無
視され、下記の LibAliasAddServer() に記述されるように、サーバプール
から動的に選択されます。
LibAliasRedirectAddr() へのその後の呼び出しが同じエイリアスアドレス
を使用するなら、エイリアスアドレスへのすべての新しい着信トラフィッ
クは、最後の関数呼び出しで作られたローカルアドレスへリダイレクトし
ます。いくつかの関数呼び出しで指定された、ローカルマシンのいずれか
によって生成された新しいトラフィックは、同じアドレスへエイリアスさ
れます。次の例を考慮してください。
LibAliasRedirectAddr(la, inet_aton("192.168.0.2"),
inet_aton("141.221.254.101"));
LibAliasRedirectAddr(la, inet_aton("192.168.0.3"),
inet_aton("141.221.254.101"));
LibAliasRedirectAddr(la, inet_aton("192.168.0.4"),
inet_aton("141.221.254.101"));
192.168.0.2、192.168.0.3 と 192.168.0.4 からの telnet(1) または
ftp(1) のようなどんな発信の接続も、141.221.254.101 から来るように見
えます。141.221.254.101 までどんな着信接続も 192.168.0.4 にリダイレ
クトされます。
LibAliasRedirectPort() へのどんな呼び出しも、LibAliasRedirectAddr()
によって指定されたアドレスマッピングより優位になります。
この関数は、LibAliasRedirectDelete() によってそれ以降使用することが
できるポインタを返します。NULL が返されるなら、関数呼び出しは、成功
して終了しませんでした。
int LibAliasAddServer(struct libalias *, struct alias_link *link,
struct in_addr addr, u_short port)
この関数は、IP Network Address Translation (RFC 2391, LSNAT) を使用
して、ロード共有のために link (リンク) を設定します。LSNAT は、次の
ように動作します。クライアントは、サーバ仮想アドレスの使用により
サーバをアクセスすることを試みます。LSNAT ルータは、実時間 (リアル
タイム) のロード共有アルゴリズムを使用して、サーバプール中のホスト
の 1 つに対して要求を透過的にリダイレクトします。複数のセッション
は、同じクライアントから開始され、セッションが開始されるとき、サー
バプールホストを越えてロードバランスに基づく異なるホストに各セッ
ションを向けることができます。ロード共有がわずかの特定のサービスに
対して要求されるなら、LSNAT の設定は、単に要求されたサービスへの
ロード共有を制限するために定義できます。
現在、ホストがホストのロードに配慮をせずにラウンドロビン原理のみで
選択されている場合に、最も単純な選択アルゴリズムだけが実装されてい
ます。
最初に、link は、LibAliasRedirectPort() または
LibAliasRedirectAddr() のいずれかによって作成されます。次に、
LibAliasAddServer() は、link のサーバプールへのエントリを加えるため
に複数回呼び出されます。
LibAliasRedirectAddr() で作成されたリンクについては、port 引数は、
無視され、どんな値、例えば htons(~0) もありえます。
この関数は、成功すれば 0 を返し、そうでなければ -1 を返します。
int LibAliasRedirectDynamic(struct libalias *, struct alias_link *link)
この関数は、動的に LibAliasRedirectPort() によって入力された、指定
された静的なリダイレクト規則をマークします。規則が削除された後、動
的に単一の TCP 接続をリダイレクトするような例でこれは、使用できま
す。完全に指定されたリンクだけが動的になることができます。(静的対動
的、および部分的対完全に指定されたリンクの定義については、下記の
「静的と動的リンク」と「部分的に指定されたエイリアスリンク」を参照
してください。)
この関数は、成功すれば 0 を返し、そうでなければ -1 を返します。
void LibAliasRedirectDelete(struct libalias *, struct alias_link *link)
この関数は、LibAliasRedirectPort() か LibAliasRedirectAddr() によっ
て入力された指定された静的リダイレクト規則を削除します。パラメータ
link は、リダイレクション関数のどちらかによって返されたポインタで
す。無効のポインタが LibAliasRedirectDelete(), に渡されるなら、プロ
グラムクラッシュか、または予測できない結果となるので、この関数を使
用するとき、注意が必要です。
int LibAliasProxyRule(struct libalias *, const char *cmd)
渡された cmd 文字列は、1 つ以上の語のペアからなります。各組の最初の
語は、トークンで、2 番目は、そのトークンのために適用されるべき値で
す。トークンとそれらの引数タイプは、次の通りです:
type encode_ip_hdr | encode_tcp_stream | no_encode
透過なプロキシをサポートするために、新しい宛先サーバへ元の
アドレスとポート情報を何らかの形で渡すことは必要です。
encode_ip_hdr が指定されるなら、元の宛先アドレスとポート
は、特別の IP オプションとして渡されます。encode_tcp_stream
が指定されるなら、元の宛先アドレスとポートは、フォーマット
``DEST IP port'' での TCP ストリームのデータの最初の断片と
して渡されます。
port portnum
宛先ポート portnum のパケットだけがプロキシ処理されます。
server host[:portnum]
これは、データがリダイレクトされる host と portnum を指定し
ます。host は、DNS ホスト名ではなく IP アドレスでなければな
りません。portnum が指定されないなら、宛先ポート番号は、変
更されません。
delete コマンドが使用されない限り、server 指定は、強制的で
す。
rule index
通常は、LibAliasProxyRule() への各呼び出しは、規則の線形の
リストの最初に次の規則を挿入します。index が指定されるな
ら、新しい規則は、より低いインデックスですべての規則の後に
チェックされます。規則が指定されない LibAliasProxyRule() へ
の呼び出しは、ルール 0 が割り当てられます。
delete index
このトークンとその引数は、他のトークンと共に使用されてはな
りません。使用されたとき、与えられた index のすべての既存の
規則が削除されます。
proto tcp | udp
指定されれば、与えられたプロトコルタイプのパケットだけが一
致します。
src IP[/bits]
指定されれば、与えられた IP と一致するソースアドレスのパ
ケットだけが一致します。bits も指定されるなら、IP の最初の
bits ビットは、ネットワーク指定として得られ、そのネットワー
クからのすべての IP アドレスは、一致します。
dst IP[/bits]
指定されれば、与えられた IP と一致する宛先アドレスのパケッ
トだけが一致します。bits も指定されるなら、IP の最初の bits
ビットは、ネットワーク指定として得られ、そのネットワークか
らのすべの IP アドレスは、一致します。
この関数は、ある種のインターネットアクセスを許されない、内部マシン
のための発信の接続をリダイレクトするか、または特定の外部マシンへの
アクセスを制限するために通常使用されます。
struct alias_link * LibAliasRedirectProto(struct libalias *,
struct in_addr local_addr, struct in_addr remote_addr,
struct in_addr alias_addr, u_char proto)
この関数は、与えられたリモートアドレスからエイリアスアドレスへの
proto プロトコル番号でどんな IP パケットも指定されたローカルアドレ
スへリダイレクトされることを指示します。
local_addr または alias_addr が 0 であるなら、これは、
LibAliasSetAddress() によって確立されるパケットエイリアスアドレスが
使用されることを示します。LibAliasSetAddress() が
LibAliasRedirectProto() が呼び出された後に、アドレスを変更するため
に呼び出されても、0 参照は、この変更を追跡記録します。
remote_addr が 0 であるなら、これは、任意のリモートアドレスからのパ
ケットをリダイレクトすることを示します。0 でないリモートアドレス
は、ファイアウォールに時々役立ちます。
LibAliasRedirectProto() への 2 つの呼び出しがそれらのアドレス指定で
オーバラップするなら、最新の呼び出しが優先します。
この関数は、LibAliasRedirectDelete() によって続いて使用することがで
きるポインタを返します。NULL が返されるなら、関数呼び出しは、成功し
て終了しませんでした。
フラグメント操作
このセクションの関数は、着信フラグメントを処理するために使用されます。
発信フラブメントは、LibAliasRedirectAddr() によって設定された任意の適用可
能なマッピングによってアドレスを変更することにより、または
LibAliasSetAddress() によって設定されたデフォルトエイリアスアドレスによ
り、LibAliasOut() で操作されます。
着信フラグメントは、2 つの方法のうちの 1 つで処理されます。フラグメント
IP パケットのヘッダが既に見られたなら、後のフラグメントは、すべてヘッダフ
ラグメントと同じ方法で再マッピングされます。ヘッダの前に到着するフラグメ
ントは、保存され、いったんヘッダフラグメントが解決されたならば取り出され
ます。
int LibAliasSaveFragment(struct libalias *, char *ptr)
LibAliasIn() が PKT_ALIAS_UNRESOLVED_FRAGMENT を返すなら、この関数
は、未決着のフラグメントへのポインタを保存するために使用できます。
ptr は、malloc(3) によって割り付けられたメモリのブロックを指すこと
が暗黙に仮定されています。フラグメントが解決されないなら、パケット
エイリアスエンジンは、タイムアウト時間経過後に自動的にメモリを解放
します。[いつかは、メモリを解放するためのコールバック関数が引数とし
て渡されるように、この関数は、修正されるべきです。]
この関数は、それが成功したなら、PKT_ALIAS_OK を返し、エラーがあった
場合は、PKT_ALIAS_ERROR を返します。
char * LibAliasGetFragment(struct libalias *, char *buffer)
この関数は、LibAliasSaveFragment() によって保存されたフラグメントポ
インタを取り出すために使用できます。buffer によって指される IP ヘッ
ダフラグメントは、LibAliasIn() が PKT_ALIAS_FOUND_HEADER_FRAGMENT
を返すときに示されたヘッダフラグメントです。いったんフラグメントポ
インタが取り出されると、それは、フラグメントに対するダイナミックに
割り付けられたメモリを解放することは呼び出しプログラムの責任になり
ます。
これ以上利用可能なフラグメントがなくなるまで、LibAliasGetFragment()
関数は、連続して呼び出すことができます。フラグメントがなくなったと
きに、それは、NULL を返します。
void LibAliasFragmentIn(struct libalias *, char *header, char *fragment)
フラグメントが LibAliasGetFragment() で取り出されるとき、それは、
LibAliasFragmentIn() への呼び出しでデエイリアスできます。header 引
数は、テンプレートとして使用されるヘッダフラグメントへのポインタで
す。そして、fragment は、デエイリアスされるパケットへのポインタで
す。
雑多な関数
struct alias_link * AddLink(struct libalias *, struct in_addr src_addr,
struct in_addr dst_addr, struct in_addr alias_addr, u_short src_port,
u_short dst_port, int alias_param, int link_type)
この関数は、新しい状態をインスタンスのハッシュテーブルに追加しま
す。dst_address そして/または dst_port は、LibAliasSetAddress が使
用されたアドレスを変更することができるので、いくつかの動的な文字を
リンクに取り入れる、0 として与えられます。しかしながら、現在の実装
では、着信 (ext -> int) トラフィックのためにそのようなリンクのみを
使用することができます。
void LibAliasSetTarget(struct libalias *, struct in_addr addr)
着信パケットが、ホストマシンに到着する任意の既存のエイリアスリンク
に関連しなかったとき、それは、LibAliasSetTarget() への呼び出しに
よって示されたアドレスへ送られます。
この関数が INADDR_NONE アドレス引数で呼び出されるなら、すべての新し
い着信パケットは、LibAliasSetAddress() によって設定されたアドレスへ
行きます。
この関数が呼び出されないか、INADDR_ANY アドレス引数で呼び出されるな
ら、すべての新しい着信パケットは、パケットで指定されたアドレスへ行
きます。それらが問題のマシンへのパケットを送ることができるなら、外
部マシンが内部マシンに直接話すことを可能にします。
int LibAliasCheckNewLink(struct libalias *)
新しいエイリアスリンクが作成されたとき、この関数は、0 でない値を返
します。着信トラフィックが異なるローカルサーバへ連続して送られてい
る状況で、この関数は、LibAliasSetTarget() がデフォルトターゲットア
ドレスを変更するために呼び出される場合に、トリガのために使用できま
す。
u_short LibAliasInternetChecksum(struct libalias *, u_short *buffer, int
nbytes)
これは、他のところで利用可能に思われず、便利なものとして含まれてい
るユーティリティ関数です。IP とプロトコル (TCP、UDP、ICMP) に特有の
ヘッダの両方で使用されるインターネットチェックサムを計算します。
buffer 引数は、チェックサムを計算したデータブロックを指します。ま
た、nbytes は、バイト数です。16 ビットのチェックサムフィールドは、
チェックサムを計算する前に 0 にされるべきです。
また、チェックサムは、そのチェックサムを含むデータブロックで操作す
ることにより検証できます。チェックサムが有効な場合、
LibAliasInternetChecksum() は、0 を返します。
int LibAliasUnaliasOut(struct libalias *, char *buffer, int
maxpacketsize)
既にエイリアスされた発信パケットは、この関数によってそのプライベー
トアドレス/ポート情報を復元します。IP パケットは、buffer によって指
されます。また、maxpacketsize は、エラーチェックのために提供されま
す。既にエイリアスされたパケットがさらなる処理 (例えば、ロギング)
のためにそのオリジナルの IP ヘッダを復元する必要があるなら、この関
数を使用できます。
概念の背景
このセクションは、ソースコードを修正するかパケットエイリアス関数を使用し
て、多少難解なアプリケーションを作成したいことを計画している人々を対象に
しています。
パケットエイリアスエンジン操作の概念のフレームワークは、ここに記述されま
す。議論の中心となるのは、ローカルマシン、エイリアスされた識別子とリモー
トマシン間の与えられたパケットトランザクションのための関係について記述す
る、"エイリアスリンク" についての考えです。そのようなリンクがどのように発
生するか、破棄されるかが検討されます。
エイリアスリンク
特定の変換を記述する 7 つの要素からなる "エイリアスリンク" についての概念
があります。
(ローカルアドレス、ローカルポート、エイリアスアドレス、
エイリアスポート、リモートアドレス、リモートポート、プロトコル)
発信パケットは、ローカルアドレスとポート番号がエイリアスアドレスとポート
番号で置き換えられます。着信パケットは、逆のプロセスを受けます。パケット
エイリアスエンジンは、与えられた IP パケットを修正する方法を決定するため
にエイリアスリンクの内部テーブルとパケットを適合させることを試みます。必
要なときに、IP ヘッダとプロトコルに依存するヘッダの両方が修正されます。エ
イリアスリンクは、ネットワークトラフィックによって必要なときに作成され削
除されます。
プロトコルは、ある状況で TCP、UDP か ICMP などでありえます。(一種の ICMP
パケットは、どのように個々のパケットを操作すべきかを識別するための等価な
ポート番号の役割をするシーケンスか ID 番号によってエイリアスできます。)
それぞれのエイリアスリンクは、次の 5 つの数値の組合せを持っていなければな
りません。各エイリアスリンクは、次の 5 つの数量のユニークな組み合わせを
持っていなければなりません。エイリアスアドレス/ポート、リモートアドレス/
ポートとプロトコル。これは、ローカルネットワーク上のいくつかのマシンが同
じエイリアス IP アドレスを共有できることを保証します。競合が発生するかも
しれない場合には、独自性が維持されるように、エイリアスポートは、選択され
ます。
静的と動的リンク
エイリアスリンクは、静的であるか動的であるかもしれません。静的リンクは、
無期限に持続し、IP パケットの変換のために固定規則を表わします。動的リンク
は、特定の TCP 接続や UDP トランザクションか ICMP ECHO シーケンスのために
出現します。TCP の場合については、接続は、関連するエイリアスリンクをいつ
削除すべきか知るためにモニタできます。UDP トランザクション (と ICMP ECHO
と TIMESTAMP 要求) のためのエイリアスリンクは、単純なタイムアウト規則で動
作します。一定の時間で動的リンク上でアクティビティが観察されないとき、そ
れは、自動的に削除されます。さらに、タイムアウト規則は、適切にオープンか
クローズしない TCP 接続に適用されます。
部分的に指定されたエイリアスリンク
エイリアスリンクは、リモートアドレスおよび (または) リモートポートが未知
であることを意味する部分的な指定ができます。この場合、不完全な指定と一致
するパケットが見つかるとき、完全に指定された動的リンクが作成されます。元
の部分的に指定されたリンクが動的であるなら、完全に指定されたリンクが作成
された後に削除され、そうでなければそれは、持続されます。
例えば、部分的に指定されたリンクは、次のようになります。
(192.168.0.4, 23, 204.228.203.215, 8066, 0, 0, tcp)
0 は、リモートアドレスとポートのための無指定の構成要素を表します。このリ
ンクが静的な場合、204.228.203.215 のポート 8066 からローカルネットワーク
上のマシン 192.168.0.4 のポート 23 (telnet) へすべての着信トラフィックを
リダイレクトする効果があります。各個々の telnet (テルネット) 接続は、別個
の動的リンクの作成を開始します。
動的リンクの作成
エイリアスリンクすることに加えて、さらにパケットエイリアスメカニズムの内
部データテーブルに格納することができるアドレスマッピングがあります。
(ローカルアドレス、エイリアスアドレス)
アドレスマッピングは、新しい動的リンクを作成するときに検索されます。
ローカルネットワークからのすべての発信パケットが既に存在する完全に指定さ
れたリンクと一致しないなら、それらは、自動的に動的リンクを作成します。発
信パケットのためのアドレスマッピングが存在するなら、これは、使用されるエ
イリアスアドレスを決定します。マッピングが存在しないなら、通常デフォルト
アドレスとしてパケットエイリアスホストのアドレスが使用されます。必要な場
合、このデフォルトアドレスは、各個々のパケットが到着するたびごとに変更で
きます。
エイリアスポート番号は、新しい動的リンクが任意の存在のリンクと競合しない
ように決定します。デフォルト操作モードでは、パケットエイリアスエンジン
は、ローカルポート番号と等しいエイリアスパケットを設定することを試みま
す。この結果が競合するなら、ユニークなエイリアスリンクを確立することがで
きるまで、ポート番号は、ランダムに選択されます。代替の操作モードでは、エ
イリアスポートの最初選択は、ランダムでローカルポート番号と無関係です。
モジュールのアーキテクチャ (と ipfw(4) サポート)
libalias の最新の改良の 1 つは、実行時に新しいプロトコルのサポートをロー
ド/アンロードする能力を与える、新しいプロトコルのサポートをライブラリの残
りから独立することです。この機能を達成するために、プロトコル取り扱いのた
めのすべてのコードは、メインライブラリの外の一連のモジュールに移動されま
した。これらのモジュールは、同じソースからコンパイルされますが、それら
は、カーネルの中、またはユーザランドライブラリの一部として動作するように
コンパイルされるかどうかによって、異なった方法で動作します。
カーネルランドの LIBALIAS モジュール
カーネルのためにコンパイルされるとき、libalias モジュールは、alias_ 接頭
辞で認識可能な単純な KLD です。
新しいプロトコルのサポートを追加するためには、対応するモジュールをロード
します。例えば:
kldload alias_ftp
プロトコルのサポートがもはや必要でないときに、モジュールをアンロードする
ことができます:
kldunload alias_ftp
ユーザランドの LIBALIAS モジュール
カーネルとユーザランド (KLD メカニズムがない、多くの異なったアドレス空間
など) の違いのため、我々は、ユーザランドに、ロードする/追跡する/アンロー
ドするモジュールを扱う方法を少し変更しなければなりませんでした。
ユーザランドの libalias のコンパイルでは、すべてのモジュールは、単純なラ
イブラリで、/usr/lib に存在し、libalias_ 接頭辞をつけて認識可能です。
(デフォルトで) 次の内容である設定ファイル /etc/libalias.conf があります:
/usr/lib/libalias_cuseeme.so
/usr/lib/libalias_ftp.so
/usr/lib/libalias_irc.so
/usr/lib/libalias_nbt.so
/usr/lib/libalias_pptp.so
/usr/lib/libalias_skinny.so
/usr/lib/libalias_smedia.so
このファイルは、libalias がロードするモジュールのパスを含んでいます。新し
いモジュールをロード/アンロードするためには、単にパスを libalias.conf に
追加し、プログラムから LibAliasRefreshModules() を呼び出します。万一、ア
プリケーションが SIGHUP シグナルハンドラを提供する場合には、ハンドラの内
側で LibAliasRefreshModules() への呼び出しを追加し、ロードされたモジュー
ルをリフレッシュするたびに、SIGHUP シグナルをそれに送ります:
kill -HUP <process_pid>
モジュールのアーキテクチャ: どのように動作するか
libalias のモジュールアーキテクチャは、実行がカーネルの内側であろうとユー
ザランドの内側であろうと同様に動作します。alias_mod.c では、次の通りです:
/* プロトコルとユーザランドモジュールハンドラのチェーン. */
LIST_HEAD(handler_chain, proto_handler) handler_chain ...
...
SLIST_HEAD(dll_chain, dll) dll_chain ...
handler_chain は、ロードされたすべてのプロトコルハンドラの経過を追い、一
方 ddl_chain は、どのユーザランドモジュールがロードされているかを追跡しま
す。
handler_chain は、struct proto_handler エントリから成ります:
struct proto_handler {
u_int pri;
int16_t dir;
uint8_t proto;
int (*fingerprint)(struct libalias *la,
struct ip *pip, struct alias_data *ah);
int (*protohandler)(struct libalias *la,
struct ip *pip, struct alias_data *ah);
TAILQ_ENTRY(proto_handler) link;
};
ここで:
pri は、プロトコルハンドラに割り当てられた優先順位であり、低い優先順位
が、より良いです。
dirは、パケットの方向です: 入って来るもの、または出て行くものです。
protoは、このパケットがどのプロトコルに属するかを示します: IP、TCP または
UDP です。
fingerprintは、指紋関数を指し、一方、protohandler は、プロトコルハンドラ
関数を指します。
fingerprint 関数には、着信パケットが見つけられるか、このモジュールが扱う
ことができる任意のカテゴリに属すかどうかチェックする二重の役割がありま
す。
protohandler 関数は、libalias が正しくそれを NAT するように、実際にパケッ
トを操作します。
パケットが libalias に入るとき、モジュールフックに出会うなら、
handler_chain は、パケットのこのタイプにマッチするハンドラがあるかどうか
調べるために (それは、パケットのプロトコルと方向をチェックします) 検索さ
れます。次に 1 つ以上のハンドラが見つけられるなら、最も低い優先順位番号で
モジュールから始めます。それは、fingerprint 関数を呼び出して、結果を解釈
します。
結果の値が 0 と等しいなら、このハンドラのプロトコルハンドラを呼び出して返
ります。そうでなければ、handler_chain が使い尽くされるまで、次の適任のモ
ジュールへ続きます。
libalias の中では、モジュールフックは、次に似ています:
struct alias_data ad = {
lnk,
&original_address,
&alias_address,
&alias_port,
&ud->uh_sport, /* 元の発信元ポート */
&ud->uh_dport, /* 元の宛先ポート */
256 /* 最大パケットサイズ */
};
...
/* チェーンを出る */
err = find_handler(IN, UDP, la, pip, &ad);
ジュールの役に立つすべてのデータは、alias_data 構造に集められて、次に、
find_handler() が呼び出されます。find_handler() 関数は、ハンドラのチェー
ンを出て行くことに責任があります: それは、入力パラメータとして受信します:
IN 方向
UDP 動作するプロトコル
la libalias のこのインスタンスへのポインタ
pip struct ip へのポインタ
ad struct alias_data (上記参照) へのポインタ
この場合、find_handler() は、INcoming UDP パケットをサポートのために登録
されたモジュールだけを検索します。
前述のように、ユーザランドの libalias は、少し異なっていて、(モジュールの
重複するロード避けて、同じ名前のモジュールを避けて、等) 同様に、モジュー
ルの操作で注意が払われなければならないので、dll_chain が導入されました。
dll_chain は、ロードされたすべてのユーザランドの libalias モジュールのリ
ストを含んでいます。
アプリケーションが LibAliasRefreshModules() を呼び出すとき、libalias は、
最初にロードされたすべてのモジュールをアンロードし、/etc/libalias.conf に
リストされたすべてのモジュールを再ロードします: ロードされたあらゆるモ
ジュールに関して、新しいエントリは、dll_chain に追加されます。
dll_chain は、struct dll エントリから成ります:
struct dll {
/* モジュールの名前 */
char name[DLL_LEN];
/*
* dlopen() を通して取得された共有オブジェクトへの
* ポインタ - dlsym() を通してロードされたモジュール
* から任意のシンボルにアクセスするためにこの
* ポインタを使用します
*/
void *handle;
struct dll *next;
};
name は、モジュールの名前です。
handleは、dlopen(3) を通して得られたモジュールへのポインタです。
モジュールがユーザランドでロードされるときはいつでも、エントリは、
dll_chain に追加され、すべてのプロトコルハンドラは、モジュールが、
handler_chain で解決され、登録される点において、存在します。
LIBALIAS のためにどのようにモジュールを書くか
今後の作業の骸骨として使用することができる、libalias に (alias_dummy.[ch]
と呼ばれる) モジュールがあります。ここで、私たちは、そのモジュールのいく
つかの部分を解析します。alias_dummy.c から:
struct proto_handler handlers[] = {
{
.pri = 666,
.dir = IN|OUT,
.proto = UDP|TCP,
.fingerprint = fingerprint,
.protohandler= protohandler,
},
{ EOH }
};
変数 handlers は、存在するハンドラを説明して、不透明な方法で外の世界でそ
れを使用させるので、モジュールの中で ``最も重要なもの'' です。
それは、あらゆるモジュールで「常に」存在していなければならなくて、名前
handlers 保有していなければ「なりません」、そうでなければ、ユーザランドの
モジュールをロードすることを試みると、不足しているシンボルに関して失敗し
てエラーを出します: モジュールのロード/アンロードに関する詳しい情報につい
て、alias.c の LibAliasRefreshModules(), LibAliasLoadModule() と
LibAliasUnloadModule() を参照してください。
handlers は、モジュールに存在するすべての proto_handler 構造体を含みま
す。
static int
mod_handler(module_t mod, int type, void *data)
{
int error;
switch (type) {
case MOD_LOAD:
error = LibAliasAttachHandlers(handlers);
break;
case MOD_UNLOAD:
error = LibAliasDetachHandlers(handlers);
break;
default:
error = EINVAL;
}
return (error);
}
KLD として実行するとき、mod_handler() は、それぞれ
LibAliasAttachHandlers() と LibAliasDetachHandlers() を使用してモジュール
を登録/登録取り消しをします。
あらゆるモジュールは、少なくとも次の 2 つの関数を含まなければなりません:
1 つは、指紋関数とプロトコルハンドラ関数です。
#ifdef _KERNEL
static
#endif
int
fingerprint(struct libalias *la, struct ip *pip, struct alias_data *ah)
{
...
}
#ifdef _KERNEL
static
#endif
int
protohandler(struct libalias *la, struct ip *pip,
struct alias_data *ah)
{
...
}
そして、それらは、正確にこれらの入力パラメータを受け付けなければなりませ
ん。
ユーザランド LIBALIAS モジュールためのアプリケーションにパッチする
libalias を使用するアプリケーションにモジュールのサポートを追加するため
に、次の簡単な処置に従うことができます。
1. アプリケーションのメインファイルを見つけます (それを main.c と呼びま
す)。
2. まだ存在しないなら、main.c のヘッダ部分にこれを追加します:
#include <signal.h>
そして、これは、ヘッダ部分の直後です:
static void signal_handler(int);
3. アプリケーションの初期化関数に次の行を追加するか、または初期化関数が
ないなら、main() にそれを置きます:
signal(SIGHUP, signal_handler);
そして、signal_handler() 関数を main.c のどこかに置きます:
static void
signal_handler(int sig)
{
LibAliasRefreshModules();
}
そうでなければ、アプリケーションが、既に SIGHUP シグナルを捕らえてい
るなら、シグナルハンドラ関数で LibAliasRefreshModules() への呼び出し
を単に追加します。
例えば、libalias モジュールを使用するために natd(8) をパッチするために
は、単に RefreshAddr(int sig __unused) に次の行を追加します:
LibAliasRefreshModules()
再コンパイルすれば、終りです。
カーネルランドでログ記録のサポート
KLD として動作しているとき、libalias には、現在 (alias_local.h から)
struct libalias の中の割り付けられたバッファで起こるログ記録サポートがあ
ります:
struct libalias {
...
/* log 記述子 */
#ifdef KERNEL_LOG
char *logDesc; /*
* libalias が kld として動作する
* とき、自動的的に malloc された
* メモリバッファへのポインタ
*/
#else
FILE *logDesc; /*
* libalias がユーザランドの lib
* として実行するとき、
* /var/log/alias.log へのポインタ
*/
#endif
...
}
したがって、libalias を使用するすべてのアプリケーションは、それらが、
logDesc にアクセスすることを望んでいるなら、それら自体のログを取り扱うこ
とができます。さらに、ログバッファへのあらゆる変更は、LOG_SECURITY 機能と
LOG_INFO レベルで自動的に syslog(3) に追加されます。
作者
Charles Mott <cm@linktel.net>, versions 1.0 - 1.8, 2.0 - 2.4。
Eivind Eklund <eivind@FreeBSD.org>, versions 1.8b, 1.9 と 2.5。多くのアー
キテクチャの改良に貢献すると同様に IRC DCC サポートを追加しました。
FTP/IRC DCC のためのファイアウォールバイパスを追加しました。
Erik Salander <erik@whistle.com> は、PPTP と RTSP のサポートを追加しまし
た。
Junichi Satoh <junichi@junichi.org> は、RTSP/PNA のサポートを追加しまし
た。
Ruslan Ermilov <ru@FreeBSD.org> は、一般的なハッキングと同様に PPTP と
LSNAT のサポートを追加しました。
Gleb Smirnoff <glebius@FreeBSD.org> は、カーネル空間へライブラリを移植し
ました。
Paolo Pisati <piso@FreeBSD.org> は、すべてのプロトコル (IP、TCP と UDP を
除いた) のサポートを外部のモジュールに移動して、ライブラリモジュールを作
成しました。
謝辞
次は、おおよその年代順に、価値のあるコメントや/またはデバッグ援助を提供し
た個人のリストです。
Gary Roberts
Tom Torrance
Reto Burkhalter
Martin Renters
Brian Somers
Paul Traina
Ari Suutari
Dave Remien
J. Fortes
Andrzej Bialecki
Gordon Burditt
FreeBSD 11.4 December 25, 2013 FreeBSD 11.4