名称

gre — ネットワークデバイスのカプセル化

書式

このドライバをカーネルにコンパイルするためには、次の行をカーネル設定ファイルに置きます:

device gre

もう一つの方法として、ブート時にモジュールとしてドライバをロードするためには、次の行を loader.conf(5) に置きます:

if_gre_load="YES"

解説

gre ネットワークインタフェース疑似デバイスはデータグラムを IP にカプセル化します。それらのカプセル化されたデータグラムは宛先ホストに発送され、そこではカプセル化が解除されてそれらの最終的な宛先に発送されます。“トンネル”は 1 つのホップとして内側のデータグラムに現れます。

gre インタフェースは、 ifconfig(8) の create と destroy サブコマンドで動的に作成されて破壊されます。

このドライバは現在次の操作モードをサポートします:

gre インタフェースはつぎのような多くの ioctl(2) をサポートします:

トンネルの終点の IP アドレスは例えば、AppleTalk がカプセル化される時のように必要がないものを除いて、 (まるで IP がカプセル化されたかのような) インタフェースのための ifconfig(8) で定義されるものと同じであるかもしれないことに注意してください。

使用例

設定例:

ホスト X-- ホスト A  --------------トンネル-------- Cisco D------ホスト E 
            \                                          | 
             \                                        / 
              +------ホスト B--------ホスト C--------+

ホスト A ( FreeBSD):

route add default B 
ifconfig greN create 
ifconfig greN A D netmask 0xffffffff linkX up 
ifconfig greN tunnel A D 
route add E D

ホスト D (Cisco):

Interface TunnelX 
 ip unnumbered D   ! e.g. address from Ethernet interface 
 tunnel source D   ! e.g. address from Ethernet interface 
 tunnel destination A 
ip route C <some interface and mask> 
ip route A mask C 
ip route X mask tunnelX

または

ホスト D ( FreeBSD):

route add default C 
ifconfig greN create 
ifconfig greN D A 
ifconfig greN tunnel D A

すべてがうまく行くなら、利用者は、パケットが流れを調べるべきです ;-)

(ホスト D (Cisco) から) トンネルを越えてホスト A に到達したいなら、利用者は次のように例えば、イーサネットインタフェースのためのホスト A に別名を持たなければなりません:

ifconfig <etherif> alias Y

そして cisco では

ip route Y mask tunnelX

同様な設定はインターネットの上に 2 つのプライベートネットワーク (例えば、 192.168 サブネット) の間のリンクを作成するの使用できます:

192.168.1.* --- ルータ A  ------トンネル------- ルータ B --- 192.168.2.* 
                   \                              / 
                    \                            / 
                     +----- インターネット -----+

ルータ A が (外部の) IP アドレス A と内部のアドレス 192.168.1.1 があることを仮定すれば、一方、ルータ B は外部のアドレス B と内部のアドレス 192.168.2.1 があります。次のコマンドはトンネルを設定します:

ルータ A:

ifconfig greN create 
ifconfig greN 192.168.1.1 192.168.2.1 link1 
ifconfig greN tunnel A B 
route add -net 192.168.2 -netmask 255.255.255.0 192.168.2.1

ルータ B:

ifconfig greN create 
ifconfig greN 192.168.2.1 192.168.1.1 link1 
ifconfig greN tunnel B A 
route add -net 192.168.1 -netmask 255.255.255.0 192.168.1.1

これは link1 フラグ (下記のバグセクションで議論するように) が設定できる (たぶん設定すべき) ところで安全な状況であることに注意してください、

注

gre インタフェースの MTU は、Cisco ルータによって使用される値を合わせるためにデフォルトで 1476 に設定されます。 grekey が設定されているなら、これは 1472 に下げられます。 2 つのトンネルの終点の間のリンクに依存して、これは最適値でないかもしれません。 ifconfig(8) によって調整することができます。

正しい操作のために、 gre デバイスはトンネル上のものに比べると特定されない宛先へのルートを必要とします。 (基本的に、これがループとなるであろう、トンネル上で実行されないカプセル化を解除するホストへのルートがあることが必要です。) アドレスがあいまいであるなら、 gre IP アドレスを設定するための ifconfig(8) 呼び出しの前に ifconfig tunnel ステップをすることは、トンネルの外側でルートを見つける助けとなります。

実際にインタフェースを“up”とマークするように ifconfig(8) に伝えるためには、コマンドラインの最後にキーワード up を与えなければなりません。

net.inet.ip.forwarding sysctl(8) 変数を 0 以外に設定することによってカーネルはデータグラムを転送するように設定しなければなりません。

作者

Heiko W.Rupp <hwr@pilhuhn.de>

バグ

if_gre.c 中の compute_route() コードはループを防ぐための直接トンネルを越えるものに比べて特定のルートでない検索を引き起こす IP アドレスの最後のビットを切り替えます。これはたぶん最も良い解決策ではありません。

上記に説明されたアドレスの改変を避けるためには、 ifconfig(8) コマンドラインで link1 フラグをオンにします。これは、GRE パケットの宛先と ifconfig のリモートホストが同じ IP アドレスでなく、また GRE 宛先が gre インタフェース自体を越えてルートを決めないことを意味します。

現在の実装は、発信パケットにだけキーを使用します。異なったキーがある、またはキーがない着信パケットは、まるで、このインタフェースに属しているかのように扱われます。

RFC1701 は、完全にサポートされていませんが、すべてのサポートされない機能は、RFC2784 で非推奨となりました。

YOS OPENSONAR

名称

書式

解説

使用例

注

関連項目

作者

バグ