1. No category

ネットワーク管理2 - www2.matsue

ネットワーク管理 2
金山 典世
2011 年 4 月 1 日
iii
目次
1.1
演習課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
第 2 章 フィルタリング I
2.1
2.2
3
4
2.1.2
2.1.3
TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
6
2.1.4 ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
何をフィルタリングするか？ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
8
IPFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1
3.1.2
3.2
3
プロトコル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 コネクション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
第 3 章 フィルタリング II
3.1
1
インストール方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
カーネルの再構築 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
9
9
9
3.1.3
カーネルの設定ファイル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.4
3.1.5
フィルタリングの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
フィルタリングコマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
フィルタリングルール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1
基本の書き方 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.2
3.2.3
ログの取り方 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.4
3.2.5
private address と spoofing 対策 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
内部に通してはいけないパケット . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
不正な IP オプションを持ったパケット . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.6
3.2.7
ルールセットの整理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.8
3.2.9
Mail と Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
DNS query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
ICMP 対策 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.10 内部から外への自由なアクセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.11 外から内への自由なアクセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.12 禁止すべきアクセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.13 ここまでのまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.14 テスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3
3.4
演習課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
演習課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
iv
第 4 章 動的ルーティングと RIP
33
4.1
動的ルーティングプロトコルの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2
4.1.2 ルーティングプロトコルのアルゴリズム . . . . . . . . . . . . . . . . . . . . . . . . 34
距離ベクトル型と RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.1
4.3
内部、外部ルーティングプロトコル . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Quagga の構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.1 Quagga の管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.2
4.3.3
zebra の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
ripd の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.4
Quagga の起動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4
4.3.5 VTY での操作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
RIP の実際 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.5
演習課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
第 5 章 OSPF
51
5.1
OSPF の概略 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.1.1 リンク状態広告 (LSA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2
5.3
マルチキャスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.4
OSPF のネットワーク構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3.1 バックボーンとエリア . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
ospfd の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.4.1
5.4.2
ospf router のその他の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
ospf と rip の同時利用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.5
5.4.3 interface の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
OSPF の動作の確認 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.6
演習課題 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
第 6 章 BGP
6.1
67
BGP 概略 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.2
6.3
BGP セッションとメッセージ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
パス属性情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.4
6.5
その他の機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.6
6.7
bgpd の設定 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
BGP の動作の確認 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.8
演習課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
bgpd の設定 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
1.1. 演習課題
1.1
1
演習課題
演習 1.1 マスターは NAT の設定を変更し、172.16.N.0/24 を自分の IP アドレスに変換するようにして、
NAT を動かしなさい。マスターは、DNS は一旦止めて下さい (/etc/rc.conf で named_enab="NO" に) 。
マスター以外の全員、実際に、Ethernet の PCMCIA カードを挿入してみて、以下のように新しいイン
ターフェースが認識されているか確認せよ。
# ifconfig ue0
ue0: flags=108843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=8<VLAN_MTU>
ether 00:09:5b:bc:01:8f
media: Ethernet autoselect (none)
status: no carrer
確認出来たら、上記の ifconfig ue0 の結果を提出しなさい。
演習 1.2 マスター以外の人は、le0 の IP アドレスを 172.16.N.M/24 に設定しなさい。但し、N はグルー
プ番号で、M はグループの中でユニークになるように設定しなさい。マスターの人は、ue0 の IP アドレ
スを 172.16.N.1 に設定しなさい。 kterm をグループの全員分の数だけ開け、それぞれの kterm の中で、
グループの異なるメンバーに ping を打ったままで (全員へ ping が打たれている状態) 、導通を確認し、そ
の状態で arp -a の結果を提出しなさい。
演習 1.3 グループ 1∼5 までの間で、マスター以外の全員が異なるグループの異なるメンバーに対してケー
ブルを張りなさい。但し、作成するのは、リバースケーブルです。マスターはケーブル作成を手伝いなさ
い。グループ 5∼10 までの間でも同じようにしなさい。
演習 1.4 マスター以外の人は、ue0 のインターフェースに 振る IP アドレスを以下のようにして相手と相
談の上決めて下さい。
172.17.N.0/24 がグループ毎に与えられ、自由に利用して構いません。このアドレスの中から、172.17.N.1/30
を自分の IP に振ったら、相手には 172.17.N.2/30 を与えます。但し、N は接続するグループの内、番号
の小さい方を利用します。つまり、グループ 1 と 4 の接続では、N として 1 を利用します。IP アドレスは
衝突しないように、グループの中で相談して行いなさい。
ping を相手と打って、接続出来たならば、ifconfig ue0 の結果と、接続先のグループ番号、PC 番号、IP
アドレスを提出しなさい。
一方、マスターはこの間に、グループ内部の人がどこに接続されているかを聞き、その表を作成しなさ
い。表は、接続先のグループ番号、名前、使用 IP アドレスからなります。
演習 1.5 マスターは、NAT を利用せずに、静的ルーティングで、相手に到達できるように、/etc/rc.conf
に設定をしなさい。(172.16.N.0/24 へのルーティング表を作成)。
3
第 2 章 フィルタリング I
ファイアーウォール (防火壁) は、不正な侵入を水際で防御するという役割を持っています。一般にファ
イアーウォールはルータの役割も持っていますが (単なるマルチホームなマシン)、ルーティングをしない
場合もあり、後者の特別な場合としてファイアーウォールがブリッジであるようなときもあります。基本
的に、ファイアーウォールの種類には、パケットフィルタリングのタイプとアプリケーションゲートウェ
イ (プロクシ−) のタイプの２種類があります。パケットフィルタリングはネットワーク層でのファイアー
ウォールの実現方法であり、パケットの送受信 IP, ポート番号, プロトコル (TCP,UDP,ICMP) などを元に
して通すか否かを決定します。これに対して、アプリケーションゲートウェイはアプリケーション層での
ファイアーウォールの実現方法です。アプリケーション層ですので、個々のアプリケーションのプロトコ
ルに依存しますが、プロトコル内部の解釈を行い、許可不許可、書き換え、転送などを行います。従って、
よりきめの細かい制御とロギングが行えるという利点がありますが、同時に個別対応になるので対応して
いないプロトコルはファイアーウォールを通過出来ないという問題があります。
このように一口にファイアーウォールと言っても、それぞれの適不適があるのでサイトの管理方針、運営
方針に応じて選択しなければなりません。基本的な方針としては、最低でもパケットフィルタリングは必ず
行い、必要に応じてアプリケーションゲートウェイを設ける。ネットワーク的には、外部に公開するサー
バなどと、内部用のネットワークは分離することなどが望まれます。更に、ルータなどにもアクセスコン
トロールを施し、重要な部門には専用のファイアーウォールをもう一段入れるようにすれば良いでしょう。
この章では、パケットフィルタリングによるファイアーウォール構築の基本について説明を行うことにし
ます。フィルタリングツールは、IPFilter, IPFW(FreeBSD), PF, screend, IPCHAIN(Linux) などが有名で
すが、この中では IPFilter が最も多くの OS に対応しています (Solaris にも対応) ので、ここでは IPFilter
を使う事にしますが、基本的な理解が出来たならば他のフィルタリングツールでも原理は同じなので対応
は容易でしょう。
特に、FreeBSD では、IPFW(IPFirewall),IPFilter,PF が用意されており、どれを使うかは迷う所です。
いずれも標準で準備されているので、好みと言って差し支えありませんが、あえて違いを上げるとするな
らば、IPFW はルールがルータなどで使われているものと似ているので親しみやすい、 IPFW と共に用い
る事が出来る帯域制御などがある、ブリッジでも使える等の点が上げられます。一方、IPFilter は、ルー
ルの構文は複雑なものが書け、機能も IPFW よりも高い、多くの OS で利用出来る、などの特徴がありま
す。更に、PF は OpenBSD で開発されたものが移植されたもので、OpenBSD では元々IPFilter を利用し
ていましたが、OpenBSD のポリシーが IPFilter と合わなかったために独自に開発がされたものです。従っ
て、構文は IPFilter とほとんど共通になっており、その上 IPFilter より優れた NAT や帯域制御がサポー
トされているために、徐々に人気が出つつありますが、利用出来る OS に制限があるのが惜しまれるとこ
ろです。
2.1
プロトコル
パケットフィルタリングについて学ぶ前に、まず最初に TCP/IP のプロトコルについて理解しなければ
なりません。この部分が理解されていないと、フィルタリングをしているつもりでも穴だらけという事に
第2章
4
フィルタリング I
なりかねないからです。一般に、パケットフィルタリングが難しいと言われるのも、このプロトコルに対
する理解を要するのが原因なのですが、逆にきちんと基本的な理解をすればフィルタリングルールの理解
はそれほど困難なものではなくなるでしょう。
2.1.1
コネクション
それぞれのプロトコルについて述べる前に、TCP/IP における 2 点間通信について理解していなければな
らないでしょう。トランスポート層における TCP の 2 点間の通信の識別は、発信元 IP,Port, 送信先 IP,Port
でなされます。ここで注意しなければならないのは、異なる 2 点間通信であっても、送信先 IP,Port が同
じであるような場合があることです。例えば、mail の MTA へのアクセスは常に mail-server,25 という形
で行われますが、そうした送信先アドレスが同じ通信であっても発信元が違えば全て違う通信を意味して
います。このように、それぞれの 2 点間通信は、発信元 IP,Port, 送信先 IP,Port の４つの情報によって区
別される訳です。逆にこうした性質を使って、TCP コネクションの横取りというクラック手法も考えられ
ます。勿論、コネクションの継続性を保証するためのメカニズムもありますが、こうしたものも完全では
ないために、発信元の偽造とこれらのメカニズムを突破することによるクラッキングの可能性があり得る
ことを知っていることは重要です。(厳密には、UDP にはコネクション概念はありません。上に述べたよ
うな区別は TCP と同様に出来ますが、コネクションという時には接続を保持するためのメカニズムも含
めて指しますので、その部分が UDP にはないからです。)
ポート番号については、1023 番よりも下のポート番号は特権ポートと呼ばれ、Unix では root 以外のユー
ザが生成する権限はありません (勿論、このポートに対してネットワークからアクセスする権限はあります
が)。従って、Unix でサーバを管理している限りではこの特権ポートからのアクセスは内部的には信頼で
きますが、Unix 以外での OS ではそうした事は期待出来ません。従って、結論としてはこのポートからの
アクセスであるから信頼できる訳ではないということです。信頼できるのは、その当該マシンが自分たち
によって適切に管理されているという場合のみです。この場合は、例えば FreeBSD や Linux の NIS のセ
キュリティ確保に利用されているように、そのコネクションは信頼出来る事になります。一方、外部から
のアクセスについてはこうした信頼は全く何の意味もなしません。同時に、外部からのこれらの特権ポー
トへのアクセスも注意深くフィルタリングする必要があります。一方、特権ポートのみがそうした注意の
対象かと言えばそうとは限らず、現在では様々なサービスが特権ポート以外で提供されていますので、そ
うしたサービスの内セキュリティ上問題のあるポートへのアクセスは制限する必要があります。
2.1.2
TCP
TCP はデータストリーム型のコネクション志向で、データパケットの中身や順序についての保証がプロ
トコル上されています。そのために常にデータは受けとられたかどうかのハンドシェークを行いながら通
信を行っています。こうした性質から TCP コネクションはフィルタリングで良く制御出来るようになっ
ています。ここでは、TCP ヘッダのフラグの種類と TCP コネクションの状態遷移について見ることで、
TCP をフィルタリングするために必要な知識を簡単に解説します。
TCP ヘッダにはシーケンスやチェックサムなど多くのヘッダ情報がありますが、中でもフィルタリング
に関係するのはヘッダフラグ情報でしょう。ヘッダフラグ情報には 2byte のフィールドがあり、第 10 ビッ
トから第 15 ビットまでにコネクション状態に関する情報が格納されています。
2.1. プロトコル
5
bit
フラグ
意味
10
URG
緊急転送データ
11
12
ACK
PSH
受信確認
13
14
RST
SYN
接続のリセット
15
FIN
送出の終了
プッシュ。アプリケーションに直に引き渡す。
同期
TCP では接続状態は以下のように遷移します (RFC793)。
1. クライアントの状態遷移
(a) SYN SENT 接続のオープン (3 ハンドシェーク)
(b) ESTABLISHED 接続の確立
(c) FIN WAIT 1, FIN WAIT 2 接続終了の通知 (half-closed)
(d) TIME WAIT 終了確認の待ち状態
(e) CLOSED 接続の終了
2. サーバの状態遷移
(a) LISTEN 接続待ち状態
(b) SYN RECVD クライアントからの接続要求受信
(c) ESTABLISHED 接続の確立
(d) CLOSE WAIT 接続終了の通知
(e) LAST ACK 接続終了の通知確認
(f) CLOSED 接続の終了
これらの状態遷移がどのようなパケット交換で成立しているかを次に示します。
状態
クライアント
方向
コネクションの開設
SYN
→
確立
ACK
ACK(,PSH,URG) データ
←
FIN,ACK
サーバからの終了通知
ACK
SYN,ACK
→
→
←
クライアントからの終了通知
サーバ
ACK(,PSH,URG) データ
→
←
ACK
←
FIN,ACK
→
このようにコネクションが確立するまでに３つのパケットが往復するので、この過程を 3 ウェイハンド
シェークと呼びます。通常、この状態はフィルタリングでは setup などとも呼んでいます。一方、接続の確
立から終了状態まではフィルタリングでは established と呼びます (特に終了状態は区別しなくても構いま
せん)。しかし、これらのパケット交換を注意深く見れば分かるとおり、最初の SYN 以外は全て ACK ビッ
第2章
6
フィルタリング I
トが立っています。つまり、フィルタリングでは最初の SYN ビットのみが立ったコネクション要求が重要
で、それ以外は特に重要ではないことに気がつくでしょう (ですから、そこしか見ないようなフィルタリン
グアルゴリズムもありました)。特に、どちらからどちらに向かって SYN パケットが飛んでいるかがフィ
ルタリングをする際には重要になります。一方、ここで出てきた以外のビットが立ったパケットは不正なも
のであり、要注意が必要です。また、こうした遷移過程についての知識は重要ですが、フィルタリングにお
いては一つ一つのパケットのみを見ているために、単純な、あるいは古いフィルタリングツールでは状態
遷移は分からない場合があります。ですから、単に ACK のみが立ったパケットはフィルタリングでは原
理的にすり抜ける可能性があります。こうした問題についても対処するには状態の遷移過程まで見るよう
なフィルタリングツールが必要ですが、幸い IPFilter にはその機能がついています (しかも、UDP,ICMP
にまで及んでいます。勿論、IPFW にもこうしたステートフルの機能がサポートされています)。
このような状態遷移を追いかけるものをステートフル (stateful) と呼び、状態遷移のないものをステー
トレス (stateless) と呼んで区別します。また、ステートフルで本当に状態遷移を完全に追いかけようとす
ると、順序番号 (Sequence Number) や応答番号 (ACK Number) なども見なければなりませんが、ここで
はこれ以上取り上げません。 (Sequence Number や ACK Number は、パケットの順序性や、次に期待さ
れるパケットの正当性をある程度保証するものです。初期の実装においては、Sequence Number が非常に
類推しやすいものであったりしましたが、現在では乱数などのアルゴリズムも改善されています。)
2.1.3
UDP
UDP はデータグラム通信であり、TCP のような信頼性のある通信手段は提供していません。従って、
そのヘッダも単純であり、ハンドシェークなどもないためにフィルタリングには最も不得意な分野である
と言ってもよいでしょう。実際、UDP はしばしばセキュリティホールを提供しています。従って、UDP
でのサービスは極力塞いでしまった方が良いでしょう。但し、DNS は例外です。DNS の問い合わせ (クエ
リー) は主に UDP で行われます。TCP での問い合わせもプロトコル上正当なものですが、無視しても構
わないでしょう。というのは、プライマリー DNS とセカンダリー DNS 間のゾーン転送は TCP で行われ
るからであり、そのために DNS に関しては TCP を塞いだ方が良いからです (例えば、DoS 攻撃によって
セカンダリー DNS を潰し、セキュリティホールのあるセカンダリ DNS に偽のゾーン転送を行う事で、攻
撃対象のサイトの DNS を書き換えてしまうような事が可能になります)。
UDP も発信元 IP,Port, 送信先 IP,Port をヘッダ情報として持っていますが、受け側の実装としては発信
元 IP,Port に関係なく、同一の送信先に対応するプロセスに送られます。従って、外部からの UDP を受け
入れる場合には、接続先を限定し、その接続先のプロセスのセキュリティ管理を厳重にする、可能ならば
プロクシ−などの手段を講じるなどの対策が必要です。
2.1.4
ICMP
ICMP (Internet Control Message Protocol) は、TCP,UDP がトランスポート層のプロトコルであるの
に対し、ネットワーク層のプロトコルです (従ってポート概念はない事に注意してください)。その役割は、
ネットワーク層での IP 通信を保証するためにあり、経路の変更や経路のトラブル、相手ホストの状態、障
害発生時の接続終了などに用いられます。また、管理者が利用する最も基本的なツールである ping など
による診断にも利用されます。低レベルのプロトコルであるために、ネットワーク自体やホストのネット
ワークに関する動作自体に作用します。従って、ICMP には十分な注意を払う必要があります。
ICMP には上記のような様々な目的のためにメッセージタイプという 1byte のフィールドで表される、
言わば種別があります。以下にそのタイプを掲げます。
2.1. プロトコル
7
type
message
ipf での表記
0
Echo Reply
echorep
3
4
Host Unreacheable
Source Quench
unreach
squench
5
8
Redirect
Echo
redir
echo
9
10
Router Advertisement
Router Solicitation
routerad
routersol
11
12
Time Exceeded
Parameter Problem
timex
paramprob
13
14
Time Stamp
Time Stamp Reply
timest
timestrep
15
16
Information Request
Information Reply
inforeq
inforep
17
18
Address Mask Request
Address Mask Reply
maskreq
maskrep
それぞれのメッセージの意味を簡単に下に述べます。
Echo, Echo Reply
Echo は相手ホストの状態を調べるために用いられます。その応答が Echo Reply です。
Host Unreacheable
ホストに到達できない、あるいはホストのサービスにコネクト出来ないなどの場合に送られます。
Source Quench
フロー制御のために送られる。受けとった側は送信スピードを落として相手の対応を待つ。
Redirect
ゲートウェイがクライアントに対してルートを変更し、別のゲートウェイを使うように指示する場合
に出される。非常に危険なメッセージである。
Router Solicitation, Router Advertisement
ルータを発見するためや、ルータが自身の場所を通知するために用いられる。内部ネットのみで使用
するべきもの。
Time Exceeded
TTL(Time To Live) が 0 になってしまった場合や、Fragmentation パケットの再構成が出来なかっ
た場合に送られる。前者に関しては、ネットワーク上でループになっている事などが考えられる。後
者については、あまりにも送信が遅く、あるいはネットワークトラブルのために分割されたパケット
が届かないなどの理由が考えられる。
Parameter Problem
データ中のパラメータに誤りがあった場合などに送られる。
Time Stamp, Time Stamp Reply
標準時を用いた遅延計測や、時刻合わせに用いる。
第2章
8
フィルタリング I
Information Request, Information Reply
相手の IP アドレスなどを得る時に使い、Information Reply はそれに対する応答である。従って、セ
グメント内部で用いられるもの。
Address Mask Request, Address Mask Reply
相手のネットマスクを得るためのもの。
2.2
何をフィルタリングするか？
フィルタリングを行う際には、方針を決定する必要があります。通常、絶対通すべきでないものを列挙
し、次に通すべきものを考えます、最後に全てを落とすようにすれば良いでしょう。
まず、通すべきでないものを掲げます。
1. ICMP の一部 (後述)
2. 内部 IP を持った外部からのパケット、送信先が内部 IP の外部へのパケット
3. 不正な IP オプションを伴ったパケット
4. プライベートアドレスを持ったパケット (NAT との関係に注意)
5. ファイアーウォールの内部 IP への外部からのアクセス
次に通すべきもののリストです。
1. 外から内側 Mail Server への SMTP コネクション
2. 内から外への SMTP コネクション
3. 外から内側 DNS(公式, プライベート両方) への UDP コネクション
4. 内から外への DNS クエリー
5. 外から内側の WWW サーバへのアクセス
6. 内側から外の WWW サーバへのアクセス
7. 内側から外への NTP クエリー
ここで、NTP は Network Time Protocol で、時刻合わせに用います。NTP はなるべく設定しておいた
方がログの信頼性や、ログ同士の比較参照に役立ちます。
次に、一般に拒否すべき危険なポートへのアクセスを禁止し、その後に必要であれば中から外への一般
アクセスを許可し、最後に全てを禁止します。但し、これはフィルタリングのためのリストを作るために必
要な作業でありますが、実際にフィルタリングルールを書く際には別の問題があります。それは、フィルタ
リングツールによってルールの記述方法が違い、アルゴリズムが違うからです。例えば、Cisco や FreeBSD
などで使われているものは、条件がマッチすればその瞬間にフィルタリングを終了しますが、 IPFilter な
どでは指定しない限り、全ての条件を検査し、最後にマッチしたルールを適用します。ですから、フィル
タリングツールによって考え方が違うので、ルールを作成する時には注意が必要です。
この他にも、内側からの FTP を通したい場合には注意が必要です。
9
第 3 章 フィルタリング II
この章では、より具体的なフィルタリングについて学習をする。
3.1
IPFilter
3.1.1
インストール方法
IPFilter はほとんど make のみでコンパイル出来ます (Solaris の場合は、make solaris)。インストール
も、make install で全て終ります。幸い、FreeBSD では最初から用意されていますが、他の OS では自分
で make が必要になるでしょう。(ちなみに Solaris では SunOS5/ のディレクトリで make package を実
行すれば pkg を作成した上で、pkgadd まで実行してくれます。 ) とは言え、本格的に使用する場合には
FreeBSD であっても、カーネルの再構築を行ったほうが良いでしょう。このテキストでは既に NAT の部
分でカーネルの再構築の方法を解説していますが、もう一度解説をした上で、IPFilter の組み込み方法を
解説します。
3.1.2
カーネルの再構築
IPFilter は非常に多くの OS に対応したソフトです。多くのソフトに対応出来ている理由は、現代的な
カーネルの持つモジュールに対応しているからで、カーネルを再構築せずにモジュールをダイナミックに
カーネルに組み込む事が出来る仕組みによっています。しかし、きちんとしたファイアーウォールを作る
場合には、カーネルを再構築出来る場合には再構築した方が良いでしょう。FreeBSD では、カーネルの再
構築は非常に容易に行えるようになっているので、ここではカーネルを再構築した上で設定することにし
ます。
カーネルを再構築する場合には基本的には以下の流れになります。
1. 編集
/usr/src/sys/i386/conf ディレクトリに移動し、適当なファイルを参考に (GENERIC 及び LINT)
カーネル設定ファイルを作成します (詳細は後述)。
2. コンフィグ
カーネル設定ファイルに従って必要なディレクトリやファイルを用意します。これは config コマン
ドが自動的に行ってくれます。カーネル設定ファイルの名前が MYKERNEL だったならば、
#
config
MYKERNEL
で必要なファイルを用意してくれます。
3. make
config の最後に指示が出ますが、../compile/MYKERNEL に移動し、
第3章
10
#
#
フィルタリング II
make depend
make
を実行します。カーネル設定ファイルに誤りがなければ、新しいカーネルが出来ます。
4. カーネルのインストール
カーネルがうまく出来れば、それをインストールして再起動します。
#
make install
#
shutdown
-r
now
この時に、新しいカーネルが /boot/kernel/ としてインストされ、古いカーネルは /boot/kernel.old/
ディレクトリに自動的にリネームされますが、カーネルのインストを何度も行うと、/boot/kernel.old/
は上書きされてしまうので、まず最初に以下のように現在動作しているカーネルを保存します。
mv /boot/kernel.old /boot/kernel.org
こうしておくと、/kernel.org として保存されるので、万一新しいカーネルでブートできなかった
時にも、このカーネルを使って再起動する事が出来ます。特に、make を失敗した時には、必ずこれ
を行っておかないと二度と起動しなくなるので注意して下さい。
5. 再起動と立ち上がらない場合
カーネルインストールが成功すれば、後は再起動して動くかどうか見てやればよいでしょう。もし、
起動しなければ、リセットして再起動し、9 秒間システムが待っているときに、リターンキーの代わ
りにスペースキーなどを押すと、ok が表示されます。ここで、以下のように入力すると、先に保存
した/boot/kernel.org/ から立ち上げることが出来ます (あるいは、/boot/kernel.old/から)。
ok unload
ok load /boot/kernel.old/kernel
ok boot
勿論、このようにして /boot/kernel.old/からリブートした場合には、カーネル再構築が失敗してい
る事になるので、もう一度最初の手順からやり直さなければならない (この時に必ず先に注意したよ
うに、kernel.org ディレクトリにまともなカーネルを退避しておかないと、二度とブートしなくな
るので注意が必要である。)
再起動する際の注意点としては、loader prompt に行くには、6 を選択すれば良いのだが、待機時間
を超すと起動してしまうので、先にスペースを押すとタイムカウントが停止するので、しかる後に
ゆっくり入力すれば良い。
3.1. IPFilter
3.1.3
11
カーネルの設定ファイル
既に、NAT の部分で簡単な設定は解説をしましたが、ここはもう一度説明をしておきましょう。
カーネル設定ファイルは様々なカーネル組み込みデバイスやカーネル機能を変更するための基本の設
定ファイルです。このファイルは必ず/sys/i386/conf/ ディレクトリになければなりません (通常、/sys
は/usr/src/sys にリンクされています。従って、実ディレクトリは/usr/src/sys/i386/conf/ になります)。
標準配布のカーネルは /sys/i386/conf/GENERIC ファイルを用いて作成されたものです。また、様々な
カーネル設定のオプションは LINT に詳しく掲載されていますが、LINT 自体はカーネル構築用のファイ
ルではありませんので、LINT からカーネルは構築できません (LINT 自体は make LINT で生成されま
す)。ファイアーウォールを作成する際には、GENERIC をコピーして (例えば MYKERNEL)、以下の内
容を付け足せば良いでしょう。慣れてくれば、必要のないデバイスなどを削除することなどもしますが、当
面はこれだけで十分です。
options
IPFILTER
#ipfilter support
options
options
IPFILTER_LOG
#ipfilter logging
IPFILTER_DEFAULT_BLOCK #block all packets by default
options
IPSTEALTH
#support for stealth forwarding
最後に、これらの変更を施した MYKERNEL の識別名を GENERIC から変更します。(これは例えば
/var/log/messages やブート時のメッセージとして残りますので、 GENERIC カーネルではないカーネル
から立ち上がっている事が分かるようにという配慮です。)
ident
3.1.4
MYFIREWALL
フィルタリングの設定
カーネル再構築した後再起動する前に、設定ファイル (/etc/rc.conf ) を編集しておくのを忘れないよ
うにして下さい。これを忘れると、全く通信が出来なくなります。 何故ならば、カーネルの設定はデフォ
ルトでは立ち上がった際に、安全のため全てのパケットの受け入れを拒否するようになっているからです。
第3章
12
フィルタリング II
今の場合には、最初はフィルタリングは素通しの設定にします。ここでは素通しの設定は /etc/ipf.rules
に次のように書いておきます。
pass in
all
pass out all
次に、これらの設定に従って、フィルタリング を起動時に動くように/etc/rc.conf に設定をします。
ipfilter_enable="YES"
ipnat_enable="NO"
# Set to YES to enable ipfilter functionality
# Set to YES for ipnat; needs ipfilter, too!
ipmon_enable="YES"
tcp_drop_synfin="YES"
# Set to YES for ipmon; needs ipfilter, too!
# Set to YES to drop TCP packets with SYN+FIN
icmp_drop_redirect="YES" # Set to YES to ignore ICMP REDIRECT packets
icmp_log_redirect="YES" # Set to YES to log ICMP REDIRECT packets
なお、タイプミスが心配な方は、/etc/default/rc.conf から該当行をコピーしてきて、必要な箇所のみを
編集すれば良いでしょう。
オプションや、設定ファイルはデフォルトが /etc/defaults/rc.conf で決められており、
# 参考 /etc/defaults/rc.conf におけるデフォルト設定
ipfilter_program="/sbin/ipf" # where the ipfilter program lives
ipfilter_rules="/etc/ipf.rules" # rules definition file for ipfilter, see
# /usr/src/contrib/ipfilter/rules for examples
ipfilter_flags=""
# additional flags for ipfilter
のように決められています。勿論、/etc/rc.conf でこれらの設定をオーバーライドすれば変更する事が出
来ます。
手動で動かす際には、FreeBSD では /etc/rc.conf に設定があれば、
# /etc/rc.d/ipfilter start
で動作します。ルールセットを書き換えて、それを既に動作している ipfilter に反映させたい場合には、
# /etc/rc.d/ipfilter reload
とします。
もし、他の OS などで、こうしたスクリプトが用意されていない場合には、以下のように行えば手動で
起動できます。
# ipf -Fa -f /etc/ipf.rules
設定が終ったら、再起動して、テストして見てください。基本的には、グローバル側に出て行き、コネ
クションが成立すれば大丈夫でしょう (例えば telnet で試す)。詳しくは、tcpdump や wireshark などで、
パケットを監視して見てください。
3.1. IPFilter
3.1.5
13
フィルタリングコマンド
IPFilter は複数のコマンドを使って操作します。
ipf フィルタルールの変更
ipfstat ルールの表示、統計情報の表示
ipftest 作成したルールのテストコマンド
ipnat NAT の設定と表示
ipmon ログの書き出し
ipresend テストのための IP パケット送出コマンド
FreeBSD では標準で、ipf,ipnat,ipfstat,ipmon,ipresend は /sbin に置かれています。また、マニュアル
はデフォルトで導入されています。
ここでは ipf, ipfstat, ipftest の利用方法について紹介します。
ipf
ipf はフィルタリングルールの設定、変更用のツールで、通常は以下のように使用することで、新しい
フィルタリング設定ファイルを設定出来ます。
# ipf -Fa -Z -f /etc/ipf.rules
この場合、既に何らかのフィルタリングルールが設定されていても、それらを全て破棄し (-Fa)、新たに
ファイル /etc/opt/ipf/ipf.conf からルールを読み込みます。同時に、それまでのフィルタリング結果につ
いての統計情報もクリアされます (-Z)。通常は、新たなルールファイルを作成し、それらを設定しなおす
には、上記のようにすれば良いでしょう。
ipfstat
現在設定されている情報を表示するコマンドですが、オプションによって異なる内容を表示します。ま
ず、何もオプションを指定しないと現在の統計情報を表示します。
第3章
14
bad packets:
IPv6 packets:
input packets:
output packets:
フィルタリング II
in 0
out 0
in 0 out 0
blocked 0 passed 113 nomatch 0 counted 0 short 0
blocked 0 passed 78 nomatch 0 counted 0 short 0
input packets logged: blocked 0 passed 0
output packets logged: blocked 0 passed 0
packets logged:
log failures:
input 0 output 0
input 0 output 0
fragment state(in):
fragment state(out):
kept 0
kept 0
lost 0
lost 0
not fragmented 0
not fragmented 0
packet state(in):
kept 0
lost 0
packet state(out):
ICMP replies:
0
kept 0 lost 0
TCP RSTs sent:
0
Invalid source(in):
Result cache hits(in):
0
19
(out):
45
IN Pullups succeeded:
OUT Pullups succeeded:
0
0
failed: 0
failed: 0
Fastroute successes:
TCP cksum fails(in):
0
0
failures:
(out): 0
0
IPF Ticks:
2216
Packet log flags set: (0)
none
これに対して、-s を指定すると簡単な統計情報を表示しますが、-s と同時に-i や -o を指定すると ( -i は
input を、-o は output のパケットを意味します) 、どの IP からどこに入って来たか、あるいは出て行っ
たかの情報を表示します。一方、-s を伴わずに、-i や -o のオプションを指定した場合には現在設定されて
いるルールを表示します。
# /sbin/ipfstat -io
pass out quick on OUTIF proto tcp/udp from 192.168.254.0/24 to any keep state
pass out quick on OUTIF proto icmp from 192.168.254.0/24 to any keep state
block in on OUTIF from any to any
block in quick on OUTIF from 172.16.0.0/12 to any
block in quick on OUTIF from 127.0.0.0/8 to any
block in quick on OUTIF from 0.0.0.0/8 to any
block in quick on OUTIF from 224.0.0.0/3 to any
pass in quick on OUTIF proto tcp/udp from 192.168.254.0/24 to any keep state
上の例では、-io を指定していますので、入出力両方のルールについて表示しています。このように、
IPFilter では、ルールセットは必ず入力用と出力用に分かれています。詳細については次の節で扱います。
これに対して、-i のみを指定した場合には、入力用のルールのみが表示されます。-i, -o のオプションに対
して、-n を同時に利用するとルールの番号が表示されます。
3.2. フィルタリングルール
15
ipftest
フィルタリングルールを書く際に、テストをせずにいきなり運用するのは危険です。幸い、IPFilter に
は設定したルールのテストを IPFilter を動かす事無く行う事が出来るようになっています。ipftest コマン
ドがそのためのコマンドで、設定したルールセットに対して、どういうパケットが入って来たらどういう
動作をするのかを見る事が出来ます。
# ipftest
-r ipf.rules
-i data
上の例では、作成したルールセットのファイルが ipf.rules で、テストしたいパケットの特徴を記述した
ファイルが data です。例えば、data ファイルは以下のように記述します。
in
on
OUTIF
tcp
192.168.1.1,20000 172.16.0.1,80
ここでは、TCP プロトコルを用いて、インターフェース OUTIF に IP 192.168.1.1 の Port 20000 から、
172.16.0.1 の Port 80 へのパケットが飛んで来たというテスト用データを意味しています。
これを実際にテストを行うと例えば以下のようになり、許可されている (pass) ことが分かります。
-------------
# ipftest -r ipf.rules -i data
pass ip #0 40(20) 6 192.168.1.1,20000 > 172.16.0.1,80
このように、想定されるパケット一つ一つに対して、ルールセットが正しいか否かを検査する事が出来
る訳です。
3.2
3.2.1
フィルタリングルール
基本の書き方
IPFilter におけるルールの記述方法は最も簡単な場合には以下のようなものです。
[block|pass] [in|out] [quick,log,on IF] [proto {tcp/udp|tcp|udp|icmp}] [IP-set]
まず、パケットは全てのルールを検査し、最後にマッチしたルールが適用されるようになっています。パ
ケットを落したい場合であっても即座に落される訳ではなく、最後まで検査して、他にマッチしたルールが
ない場合に落されることになるのです但し、ルールにマッチした時に、それ以降のルールを検査せずに即
座に落としたい場合には quick を指定 すると、即座に実行されます。パケットを拒否する際には、block
を用いますが、あくまでもすぐに落される訳ではない点に注意して下さい。逆に、パケットを通したい場
合には、pass を用いますが、この場合も同様です。(block,pass 以外には、count,skip,auth,call などが使
えます。)
次に、入ってくるパケットに対して適用するのか、出て行くパケットに対して適用するのかを区別する
ために、in と out を用います。
特別に、あるインターフェース上で検査したい場合には on IF を付けます。ここで、IF は、ifconfig で
表示されるインターフェース名で、例えばインターフェース名が lnc0 の場合は、on lnc0 のように使い
ます。一方、このルールにマッチした場合についてログを取りたい場合には、 log を付けます (但し、ログ
をどこに書き出すかの設定は別に必要です)。また、このルールを即座に適用し、以降のルールを検査した
くない場合には quick を使います (実は例外が一つだけあり、後述する head を用いるとこの場合に当て
第3章
16
フィルタリング II
はまりません)。一般に、IPFilter のルールは全てを検査するために冗長になりがちです。これを回避する
ために、何も考えずにこれは通したいような場合には quick を使う訳です。
それぞれのパケットのプロトコルを指定したい場合には、proto 識別子の後にプロトコルを指定します。
主に利用されるのは以下の 4 つがあります。
tcp/udp
TCP 及び UDP プロトコル
tcp
udp
TCP プロトコルのみ
UDP プロトコルのみ
icmp
ICMP プロトコルのみ
あるいは、proto 識別子の後ろにはプロトコル番号でも構いません。あるいは、/etc/services に記載さ
れているプロトコル名も利用出来ます。
OSPF のパケットを識別し、それを通したい場合には以下のようにも使えます。
pass out quick proto 89 all
(OSPF のプロトコル番号は 89 です)
pass in
quick proto 89 all
当然、全てのプロトコルについて指定したい場合には、proto 識別は必要ありません。
最後に、IP-set は基本的には、どこからどこに向かうのかという事を指定します。例えば、172.16.1.1 か
ら発信されている全ての送信先へのパケットを指定したい場合には、
from 172.16.1.1 to any
と指定します。ここで、any は全ての行先を意味します。一方、10/8 から 192.168.0.0/16 へのパケットを
指定する場合には、
from 10.0.0.0/8 to 192.168.0.0/16
のように書きます。もちろん、mask を使って書く事も出来ます。
from 10.0.0.0 mask 255.0.0.0 to 192.168.0.0 mask 255.255.0.0
とは言え、こうした書き方を選択する必要はないでしょう。あらゆる発信先からあらゆる送信先を指定す
る場合には、当然
from any to any
と書けば良いのですが、これらの代わりに all を使うことも出来ます。
一方、ある WWW サーバへのアクセスを指定したいような場合には、ポートまで含めて書く事もでき
ます。
from any to 172.16.1.1 port = 80
また、ある範囲のポート番号を指定したい場合には、>< を使う事が出来ます。例えば、次の例は、Port
6000 から 6063 までの範囲を指定しています。
from any to 172.16.1.2 port 5999 >< 6064
3.2. フィルタリングルール
17
ここで注意しなければならないのは、5999 より大きくて、6064 より小さい範囲を指定しなければならな
い点です。他にも、あるポートよりも大きい場合の指定に > や、逆に小さい場合の指定に <、あるポート
に等しくない場合には != 、以上や以下を表すための >= や <= なども用意されています。
ルールには他にも更に様々なオプションがあり、中には重要なものもありますが、とりあえずは以上の
ような書き方をすることを知っていれば、以下の具体例を理解できるでしょうし、必要なものについては
その時に学習することにします。
より詳しく学ぶには、
http://www.obfuscation.org/ipf/ipf-howto.txt
を参照して下さい。
ログの取り方
3.2.2
先に、ルールで log を指定することでログが取れるとしましたが、実際にはログのためのデータがある
所に送るようになるだけで、それを実際にファイルなどに書き出すためには別の設定が必要です。送られた
ログを処理するプログラムが ipmon ですが、これを利用するためにはカーネル再構築時に IPFILTER_LOG
を指定して構築する必要があります (既に本書では行っています)。
デフォルトでは、ipmon は動いていないので、/etc/rc.conf で
ipmon_enable="YES"
を設定する必要があります (既に指定しています)。
次に、ログをどのファイルに書き出すかの指定が必要です。デフォルト設定は以下のようになっています。
ipmon_flags="-Ds"
# typically "-Ds" or "-D /var/log/ipflog"
つまり、syslog に書き出す設定になっているのですが、ログレベルが local0.* になっているので、
/etc/syslog.conf に、これを書き出す設定が必要になります。より簡単にログを取るには、以下のよう
に設定します。
ipmon_flags="-D /var/log/iplog"
但し、/var/log/iplog は作成しておく必要があります。(一度だけ touch
/var/log/iplog を行えば
良い)
これらの設定が終わったら、
#
/etc/rc.d/ipmon
restart
で、ログを開始します。
参考 syslog でログを取るには、/etc/syslog.conf の*.emerg の行の下などに、以下の local0.* の行
を追加し、syslogd をリロードする必要があります。
*.emerg
local0.*
*
/var/log/iplog
第3章
18
3.2.3
フィルタリング II
private address と spoofing 対策
Internet 上では、private address は発信しても、受信してもいけません。従って、ファイアーウォール
の外から private address を持って入ってくることはあり得ない筈ですので、これらは全て落す必要があり
ます。ここでは、ファイアーウォールの外側インターフェースを OUTIF とし、内側インターフェースを
INIF とします。
# Deny reserved addresses from outside
block in log quick on OUTIF from 10.0.0.0/8 to any
block in log quick on OUTIF from 192.168.0.0/16 to any
block in log quick on OUTIF from 172.16.0.0/12 to any
次に、自サイトが所有しているグローバルアドレスが 200.1.1.0/29 であったとして、これが外からやっ
て来たり、外に出て行くことはありません。特に、外から来るパケットの発信元が自サイトのアドレスに
なっているものはアドレス偽造である訳ですから要注意です。これらは即座に落します。
block in
log quick on OUTIF from 200.1.1.0/29 to any
block out log quick on OUTIF from any to 200.1.1.0/29
同様に、ループバックアドレスについても落しますが、ループバックインターフェースにおける入出力
は許可します。
block in log quick on OUTIF from 127.0.0.0/8 to any
block in log quick on OUTIF from any to 127.0.0.0/8
pass in quick on lo0 all
pass
out quick on lo0 all
3.2.4
内部に通してはいけないパケット
その他の内側に通してはいけないパケットがあります。リザーブド、DHCP の自動設定用、テスト用、
クラス D,E など宛は落します。
block in quick on OUTIF from any to 0.0.0.0/8
block in quick on OUTIF from any to 169.254.0.0/16
block in quick on OUTIF from any to 192.0.2.0/24
block in quick on OUTIF from any to 224.0.0.0/4
block in quick on OUTIF from any to 240.0.0.0/4
詳しくは draft-manning-dsua-03.txt を見て下さい。
但し、最後から２つめの 224.0.0.0/4 はマルチキャストですので、マルチキャストを使う場合には落さ
ないで下さい。
3.2. フィルタリングルール
3.2.5
19
不正な IP オプションを持ったパケット
通常、現在は使われていない IP のオプションを持ったパケットは落しておきます。こうしたオプション
は、DoS アタックにも使われるからです。IP オプションはそれぞれ以下の通りです。
rr
レコードルート
ts
ssrr
lsrr
タイムスタンプ
ストリクトソースルーティング
ルーズソースルーティング
block in log quick on OUTIF from any to any with opt rr
block in log quick on OUTIF from any to any with opt ts
block in log quick on OUTIF from any to any with opt ssrr
block in log quick on OUTIF from any to any with opt lsrr
3.2.6
ルールセットの整理
ここまでは全てのパケットについて外側インターフェースでの出入りについてのみ考えて来ましたが、
ファイアーウォールがルータである場合、実際には外側インターフェースにおける in, out 、及び内側イ
ンターフェースにおける in, out の全てについて考える必要があります。
Outside
FireWall
In
Out
Inside
Out
In
out0
in0
このように 4 つのパターン全てについて考えて行くと、多くのルールを記述する必要があり、その全て
のルールについてパケットは検査されることになってしまいます。これを緩和するために、IPFilter には
グループという考えがあります。ルールセットをグループに分けて、パケットに適用するグループを設定
する事が出来るようになっているのです。グループは番号によって区別されます。それぞれのルールがど
のグループに所属するかもこの番号を用いて行います。まず、パケットにどのグループを適用するかは、
head オプションを使って決めます。次の例は、OUTIF に入って来たパケット全てにグループ番号 100 を
適用出来るように、番号 100 をマークしています。
pass in on OUTIF all head 100
但し、この場合はデフォルトで pass を指定しているので、このパケットを block するようなルールが他
になければ通ってしまいます。通常、外側から入って来るパケットについては、デフォルトで block にし
ておいた方が良いでしょう。
第3章
20
フィルタリング II
block in on OUTIF all head 100
これによって、OUTIF に入って来るパケットは 100 の番号がマークされているので、OUTIF の入って
来るパケットには 100 のグループのルールが適用されます。(先に quick と共にに head を用いると、とい
う話がありましたが、結論としては quick と共に head を指定すると、head で指定された番号のルールセッ
トは必ずチェックされます。従って、quick を使っても、すぐにその場ではルールの適用が終りません。)
これらを用いて、これまでの内容を書き直したものが次のルールセットです。
block in
on OUTIF all head 100
block out on OUTIF all head 200
pass in on INIF all head 300
pass out on INIF all head 400
# pass loop back on lo0
pass
in
quick on lo0 all head 500
pass out quick on lo0 all head 600
# Deny reserved addresses
block in
block in
log quick from 10.0.0.0/8 to any group 100
log quick from 192.168.0.0/16 to any group 100
#block in log quick from 172.16.0.0/12 to any group 100
# Deny ip spoofing
block in log quick on OUTIF from 200.1.1.0/29 to any group 100
block out log quick on OUTIF from any to 200.1.1.0/29 group 200
# loop back
block in log quick from 127.0.0.0/8 to any group 100
block in
block in
log quick from any to 127.0.0.0/8 group 100
log quick from 127.0.0.0/8 to any group 300
block in log quick from any to 127.0.0.0/8 group 300
# other reserved address
block in quick on OUTIF from any to 0.0.0.0/8 group 100
block in quick on OUTIF from any to 169.254.0.0/16 group 100
block in quick on OUTIF from any to 192.0.2.0/24 group 100
# block in quick on OUTIF from any to 224.0.0.0/4 group 100 # multicast
block in quick on OUTIF from any to 240.0.0.0/4 group 100
# IP options
block in log quick on OUTIF from any to any with opt rr group 100
block in log quick on OUTIF from any to any with opt ts group 100
block in log quick on OUTIF from any to any with opt ssrr group 100
block in log quick on OUTIF from any to any with opt lsrr group 100
以上のように、各々のルールがどのグループに所属するルールかは、ルールの末尾に付けた group [number]
で区別する訳です。
ちなみに、上の例では効率のために lo0 でのパケットのやり取りを即座に許可するようにし、同時に他
のインターフェースのパケットがこのルールにマッチしないようにしています。
3.2. フィルタリングルール
21
また、マルチキャスト及び 172.16.0.0/12 が外部から入ってくるのを拒否するルールをコメントアウ
トしています。
なお、自サイトでプライベートアドレスを使用しており、このファイヤーウォール上で NAT を利用し
ている場合には特別な注意が必要です。 何故ならば、多くの NAT の実装はファイヤーウォールにパケッ
トが入る前に処理を行うからです (外からパケットが入ってくる場合で、外側のインターフェースに NAT
を設定したような場合)。この場合、外からのパケットはグローバルアドレス向けに入ってくるのですが、
そのパケットは NAT で処理されて、行き先アドレスがプライベートに変換されてしまいます。従って、上
の例では、入ってくるパケットに対して、プライベートアドレス宛をわざと落としていません。その理由
はプライベートアドレスに対応することをメインに考えているからです。同様に、出て行くパケットは内
側インターフェースから入って、ファイヤーウォールに入り、カーネルの IP 転送を受け、再度出て行く際
にファイヤーウォールを通りますが、この際には発信アドレスはプライベートのままです。最後に、イン
ターフェースから出て行く時に NAT によってアドレスがグローバルアドレスに書き換えられるようになっ
ているので、この流れを考えた上でルールセットは書く必要があります。
同様に、どのアドレス宛、あるいはどのアドレスから出て行くものを禁止する、許可するということに
留意してください。もし、ウェブサーバのアドレスをグローバルアドレスからプライベートに 1 対 1 対応
の NAT で変換しているような場合には、そのウェブサーバのアドレスはファイヤーウォール上ではプラ
イベートアドレスでチェックする必要がある訳です。
3.2.7
ICMP 対策
ICMP で解説をしたように、全ての ICMP を通す必要はありません。むしろ、ICMP は様々なアタック
に利用されるので、これを全て通すのは非常に危険です。しかし、だからと言って全ての ICMP を落とし
てしまうと、今度は逆に通信の保証が無くなってしまうので、最低限通しても良いものだけを通すことに
します。勿論、これはアタックを受けない事を保証するものではありませんので ICMP は要注意事項では
あります。
例をあげます。
type
message
in
out
pass
pass
block
pass
0
3
Echo Reply
Host Unreachable
4
Source Quench
pass
pass
5
8
Redirect
Echo
block
block
block
pass
9
10
Router Advertisement
Router Solicitation
block
block
block
block
11
12
TTL Exceeded
Parameter Problem
pass
pass
pass
pass
13
14
Time Stamp
Time Stamp Reply
block
block
block
block
15
16
Information Request
Information Request Reply
block
block
block
block
17
18
Address Mask Request
Address Mask Request Reply
block
block
block
block
第3章
22
フィルタリング II
但し、ここに掲げたものでも、3 の out を許すか否かや、4 の source quench を許すかどうかは問題が
あるかも知れません。また、こうした制限をかけても安全性を絶対に確保出来る訳ではありません。例え
ば、ある程度内部のサーバやマシンに種を蒔かれた後で、ファイアーウォールを突破してそれらのマシン
にメッセージや指示を届けるために、Echo Reply でデータをラップするなどの手口も有名です (実は後で
紹介をしますが、IPFilter はこうした手口に対する対策があります)。
以上をルールに書くと以下のようになります。
pass in
quick proto icmp all icmp-type 0
group 100
pass in
pass in
quick proto icmp all icmp-type 3
quick proto icmp all icmp-type 4
group 100
group 100
#pass in quick proto icmp all icmp-type 8 group 100 # for test
pass in quick proto icmp all icmp-type 11 group 100
pass in quick proto icmp all icmp-type 12 group 100
#pass out quick proto icmp all icmp-type 0 group 200
pass out quick proto icmp all icmp-type 3
pass out quick proto icmp all icmp-type 4
# for test
group 200
group 200
pass out quick proto icmp all icmp-type 8 group 200
pass out quick proto icmp all icmp-type 11 group 200
pass out quick proto icmp all icmp-type 12 group 200
但し、ファイアーウォールを作成してテストしている最中は、外からの Echo に対しては応えるように
しておいた方がやりやすいでしょう (当然、そのテスト時にはテスト用の仮想環境で実験するものとして)。
3.2.8
Mail と Web
メイルや Web に関するルールは比較的に簡単です。特に、特定のホストで集中的に送受信する場合には
そのホストだけに限定することが可能になります。もっとも、全てのホストが外部へ直接メイルを送信で
きるとしても、それほど問題にならないでしょうが、少しだけセキュリティレベルが下がります。いずれ
にせよ、外からのアクセスを許すメイルホストや Web サーバのセキュリティには気を配らなければなりま
せん。
最初に解説したように TCP にはコネクション開設のために、3 ウェイハンドシェークを行います。この
過程を setup と呼びます。具体的には、SYN フラグのみが立ったパケットが最初に飛び、それに対する応
答パケットは SYN+ACK で、最後に応答パケット ACK が返ってきます。これによってハンドシェーク
が終了し、実際の通信が始まりますが、その通信においては全て ACK フラグが立ち、同時にデータの連
続性を保証するための番号が付与されます。この状態を established と呼びます。従来のパケットフィルタ
リングでは、これらの状態遷移を記憶していなかったために、単にこのフラグのみを見て許可するパケッ
トを考えなければなりませんでした。しかし、最近の新しいフィルタリングツールではこうした状態遷移
を記憶し、一度 setup したコネクションは特に指定しなくても許可できるようになっています。IPFilter
にもその機能があり、keep state オプションを付けることで、帰りのパケットについては一切心配するこ
となく、一度のルール記述のみで全てを許可出来るようになりました。同時に、この機能により不正なフ
ラグの組み合わせや、コネクションハイジャックなどもかなり防げるようになっています。
但し、keep state を用いて、stateful に TCP のコネクションを追いかけるにしても、最初の一発目が何
かを指定しないと状態遷移を追いかける事は出来ません。そこで、keep state を TCP に使う際には必ず
flags S を用います。これは、最初のパケットはコネクション確立要求パケットで、SYN ビットが立って
3.2. フィルタリングルール
23
いる訳ですから、そのパケットを通してしまえば、後は状態を追いかけることが出来るという訳です。
メイルサーバ (MAIL) へのアクセスの許可は次のようにします。
pass in
quick proto tcp from any to MAIL port = 25 flags S keep state group 100
pass out quick proto tcp from MAIL to any port = 25 flags S keep state group 200
同様に、Web server(WWW) へのアクセスについても、
pass in quick proto tcp from any to WWW port = 80 flags S keep state group 100
pass out quick proto tcp from any to any port = 80 flags S keep state group 200
となります。当然、Web サービスの口は 80 であると仮定していますが、他のポートでも開設している
ならばそれらを加えなければなりません。また、from any についての記述は前の節で出てきたように内部
ネットのどの IP に飛ぶのかという事を明示的に指定したほうが良いでしょう。
1. flags S
flags S を使う時に注意すべきは、flags S では、SYN ビットのみが立ったパケットを対象とします。
従って、その他の U(RG),A(CK),P(SH),R(ST),S(YN),F(IN) が同時に (正確には U,A,P,R,F ですね)
立っている場合はマッチしません。この事は、コネクションの最初のパケットが SA (SYN+ACK)
で来た場合にはそのパケットはルールにマッチしないという事を意味します。しかし、もしその他の
ビットが立っていても、このルールにマッチさせたい場合にはマスクを書く事で目的を達する事が出
来ます。例えば、
flags S/SA
は、SA 以外の SYN ビットが立っている全てのパケットにマッチします。つまり、S/SA は、S と
U,P,R,F の全ての組合せにマッチする事になる訳です。難しく聞こえるかも知れませんが、ルーティ
ングの時のマスクと意味的には同じなのです。つまり、これらのフラグがビットであると思えば、も
し下のように、入力ビットが SF であったとすると、SA でマスクすると、結果は 000010 になり、S
のみが立ったビット列と同じになります。
ビット列 UAPRSF
入力 SF
マスク SA
結果 SF & SA
比較 S
000011
010010
000010
000010
逆に、入力が SAF であったとします。すると、SAF(010011) に対して、マスク SA(010010) を適用
すると、結果は (010010) となり、S(000010) に一致しません。つまり、入力 SAF は、ルール flags
S/SA にはマッチしない訳です。同時に、flags S/SA と書く時に、/S がなぜ必要かという理由も明
らかですね。
では、flags S/SA という記述は正しいのでしょうか。例えば、入力が SF の場合はどうでしょう。実
は、これは RFC1322 拡張 TCP/IP で正規のフラグなのですが、これを受け入れるかどうかは良く
考えないといけません。元々、このような組合せは Web などへのコネクションを素早くするために、
近年考え出されたものなのですが、攻撃手段にも使われているものなのです。よしんば、SF を受け
入れたとしても、SR,SU,SP 等ははどうでしょうか。本来こうしたフラグの組合せはあり得ない筈の
第3章
24
フィルタリング II
ものですので、こうしたものを受け入れるのも考えものです。従って、結論としては、通常は flags
S で良いが、どうしても SF を受け入れたければ、flags S/SUAPR とすべきでしょう。
2. keep frags
状態遷移を見ている場合、ルールセットは、最初の SYN パケットから keep state オプションによ
り、動的に生成されます。但し、これだけですと、もし、パケットがフラグメンテーションを起こし
ている場合には通らなくなることがあります。そこで、それらのフラグメントパケットについても、
フラグを遡って見ることが出来るように、 keep frags を付けます。(フラグメンテーションを処理す
るのはネットワーク層です。)
pass in
quick proto tcp from any to WWW port = 80 flags S keep state
keep frags group 100
pass out quick proto tcp from any to any port = 80 flags S keep state
(都合上、改行していますが、実際には改行はありません。)
keep frags group 200
Mail と同じく外からのアクセスを許すようなサービスとしては、NTP (Network Time Protocol port=123)
や NNTP(Network News Transfer Protocol port=119) などもありますが、mail などと同じなので設定は
ここでは触れません。
3.2.9
DNS query
DNS query については DNS プライマリーサーバとセカンダリサーバへの問い合わせのみに限定します。
その他の 53 番ポートへのアクセスはブロックしておきます。何故ならば、内部から DNS を経由せずに外
に query することはなく、外部からはアタックの可能性があるからです。プロトコルについては UDP の
みを許可するというルールが基本になります (TCP はゾーン転送に使われるために、これを許すとセキュ
リティホールのある DNS が危険にされされることになるからです。勿論、セキュリティホールがなければ
許しても構わないのですが、転ばぬ先の杖という所です)。ここで注意しなければならないのは、stateless
で考えると、UDP によるパケットであるために、内側から外の DNS への問い合わせに対する返答を許可
しなければならない点で、そのために外から内側の 53 番ポートへのアクセスを禁止することは出来なくな
りますが、IPFilter の keep state を用いればすっきりと書く事が出来ます。
pass in
pass in
quick proto udp from any to MYDNS port = 53 group 100
quick proto udp from any port = 53 to any
group 100
pass out quick proto udp from MYDNS port = 53 to any group 200
pass out quick proto udp from any to any port = 53
group 200
この例では、MYDNS は自分のサイトの公式 DNS を意味しています。もし、セカンダリがある場合に
はセカンダリについても上と同じ記述をする事が必要になります。なお、この例では２行目の宛て先が to
any になっていますが、これは内部ネットを意味しているので、より正確には内部ネットを指定するよう
にした方が良いでしょう。これは４行目の from any についても同じです。
以上は、stateless な書き方ですが、これを stateful に書くと、
3.2. フィルタリングルール
25
pass in quick proto udp from any to MYDNS port = 53 keep state group 100
pass out quick proto udp from any to any
port = 53 keep state group 200
となります。但し、この場合でも内部の任意のマシンから外の DNS へのアクセスを許しており、同時
に、外部からのアクセスについても制限はありません。しかし、外部からのアクセスが必ず port 53 から
であるとは保証されていないので、強めるとしても次の程度でしょう。
pass in
quick proto udp from any
to MYDNS port = 53
keep state group 100
pass out quick proto udp from MYDNS port = 53 to any
port = 53
keep state group 200
但し、この場合には、nslookup などを使った外の DNS サーバの検索が出来なくなり、DNS サーバの間
のみの query とその response だけを許可することになります。実際、DNS サーバ間の通信には UDP を
用い、発信・受信ポートは共に 53 番を用いるからです (DNS が 53 番以外のポートからの発信を出来るよ
うに設定変更しない限りはですが)。
3.2.10
内部から外への自由なアクセス
内部から外への自由なアクセスを許したい場合には以下のようにします。
keep state keep frags group 200
(都合上、改行していますが、実際には改行はありません。)
pass out quick proto tcp from INSIDE port >= 1024 to any flags S
但し、この例では内部ネットは INSIDE で表しています。この場合、セキュリティ的には少し危なくな
ることを注意して下さい。
ちなみに、IPFilter の keep state は TCP だけではなく、UDP や ICMP にも拡張されており、60 秒以
内に同じポートに対して返事が返るような場合には通すようになっています。当然、ICMP の場合には何
が応答かということも判断するようになっているので、ICMP などの取り扱いも楽になっています。
例えば、traceroute を内部から外部に行いたいような場合には次のように記述することで、本来なら
block した ICMP を受け取れるようになります。
pass out proto udp from any to any port 33434 >< 33690 keep state group 200
一方、内側からの ICMP Echo を通して、その返りの ICMP EchoReply を受けたい場合には次のよう
にします。
pass out proto icmp from INSIDE to any icmp-type echo keep state group 200
3.2.11
外から内への自由なアクセス
外から内への自由なアクセスを許してしまえば、ファイアーウォールの意味がありませんが、強力な暗号
と暗号回線を使えばそうしたアクセスを許すことも出来ます。通常、こうした場合には SSH(Secure SHell)
第3章
26
フィルタリング II
が使われます。SSH は、ポート 22 番を使うので、このポートについてのみ、SSH が動いているサーバへ
のアクセスを許可するわけです。
keep state keep frags gorup 200
(都合上改行していますが、実際には改行はありません)。
pass in quick proto tcp from any port >= 1024 to SSH port = 22 flags S
勿論、その他にも公開しているサービスがあれば、それらも許可しなければなりません。
3.2.12
禁止すべきアクセス
特権ポートである 0∼1023 番へのポートアクセスは全て禁止します。当然、これ以前に必要なポートへ
のアクセスは quick 指定を使って許可していなければなりません。
block in from any to INSIDE port < 1024 group 100
但し、この場合これらのポートへのパケットを全てドロップするだけなので、明らかにファイアーウォー
ルが落としている事が分かってしまいます。そこで、ICMP の unreachable メッセージが返るようにして
置きましょう。但し、その際の発信元 IP がファイアーウォールになっていると、頭隠して尻隠さず状態に
なってしまいますから、発信 IP は先に来たパケットの宛て先 IP にして置くことで、あたかもそのマシン
が存在し、そこでそのサービスが走っていないかのごとく見せかけることが出来ます (またはそのマシンが
存在しない)。
# block with port unreachable
block return-icmp-as-dest(port-unr) in from any to INSIDE port < 1024 group 100
その他にも、以下のポートへのアクセスは禁止しておきます。
3.2.13
1025
1433
lister
SQLSPIDA
1434
1524
Slammer for MS SQL
ingreslock
2000
2049
openwin
NFS
2766
6000-6063
listner(SystemV)
X11
6667
7100
IRC
Sun Font server(TCP)
ここまでのまとめ
ここまでの内容を少し整理したものが次のルールです。
3.2. フィルタリングルール
27
#
block
in
block
pass
out on OUTIF all head 200
in on INIF all head 300
on OUTIF all head 100
pass
out on INIF all head 400
# pass loop back on lo0
pass
pass
in quick on lo0
out quich on lo0
all head 500
all head 600
#
block in log quick from any to any with ipopts group 100
block in log quick proto tcp from any to any with short group 100
#
# Deny reserved addresses
block in log quick from 10.0.0.0/8
to any group 100
block in log quick from 192.168.0.0/16 to any group 100
#block in log quick from 172.16.0.0/12 to any group 100
#
# Deny ip spoofing
block in log quick from 200.1.1.0/29 to any group 100
block out log quick from any to 200.1.1.0/29 group 200
#
# block from loop back address
block in log quick from 127.0.0.0/8 to any group 100
block in log quick from any to 127.0.0.0/8 group 100
block in log quick from 127.0.0.0/8 to any group 300
block in log quick from any to 127.0.0.0/8 group 300
#
# /* 次のページに続く */
第3章
28
フィルタリング II
# block other reserved address
block in quick from any to 0.0.0.0/8 group 100
block in quick from any to 169.254.0.0/16 group 100
block in quick from any to 192.0.2.0/24 group 100
# block in quick on OUTIF from any to 224.0.0.0/4 group 100 # multicast
#block in quick from any to 240.0.0.0/4 group 100
# block irregular IP options
block in log quick from any to any with opt rr group 100
block in log quick from any to any with opt ts group 100
block in log quick from any to any with opt ssrr group 100
block in log quick from any to any with opt lsrr group 100
#
# ICMP
pass in
pass in
quick proto icmp all icmp-type 0
quick proto icmp all icmp-type 3
group 100 # for test
group 100
pass in
pass in
quick proto icmp all icmp-type 4
quick proto icmp all icmp-type 8
group 100
group 100 # for test
pass in
pass in
quick proto icmp all icmp-type 11 group 100
quick proto icmp all icmp-type 12 group 100
pass out quick proto icmp all icmp-type 0
pass out quick proto icmp all icmp-type 3
group 200 # for test
group 200
pass out quick proto icmp all icmp-type 4 group 200
#pass out quick proto icmp all icmp-type 8 keep state
group 200
pass out quick proto icmp all icmp-type 8 group 200 # for test
pass out quick proto icmp all icmp-type 11 group 200
pass out quick proto icmp all icmp-type 12 group 200
#
pass in
quick proto icmp all icmp-type 0
group 300
pass in
pass in
quick proto icmp all icmp-type 3
quick proto icmp all icmp-type 4
group 300
group 300
pass in
pass in
quick proto icmp all icmp-type 8 group 300
quick proto icmp all icmp-type 11 group 300
pass in quick proto icmp all icmp-type 12 group 300
pass out quick proto icmp all icmp-type 0 group 400
pass out quick proto icmp all icmp-type 3
pass out quick proto icmp all icmp-type 4
group 400
group 400
pass out quick proto icmp all icmp-type 8 group 400
pass out quick proto icmp all icmp-type 11 group 400
pass out quick proto icmp all icmp-type 12 group 400
#
# default block access to FIREWALL from outside
block return-icmp-as-dest(port-unr) in from any to FIREWALL group 100
#
# ssh to FIREALL from inside
pass in quick proto tcp from any to FIREWALL port = 22
flags S keep state keep frags group 300
#
# /* 次のページに続く */
3.2. フィルタリングルール
29
# traceroute to outside
pass out proto udp from any to any port 33434 >< 33690 keep state group 200
# DNS
pass in
quick proto udp from any to MYDNS port = 53 keep state group 100
pass out quick proto udp from any to any port = 53
# mail
keep state group 200
pass in quick proto tcp from any to MAIL port = 25 flags S keep state group 100
pass out quick proto tcp from MAIL to any port = 25 flags S keep state group 200
# WWW
pass in
quick proto tcp from any to WWW port = 80 flags S keep state group 100
pass out quick proto tcp from any to any port = 80 flags S keep state group 200
#
# write any services to pass
#
但し、ここで、WWW,MAIL,FIREWALL はそれぞれの IP アドレスです。
このルールでは、内側に対する制限は緩く、内側からファイアーウォールへのアクセスのみを禁止して、
それ以外のファイアーウォールを通過するパケットについてはそのまま通すようにしています。勿論、mail
gateway や DNS をファイアーウォール上で動かす場合には、その部分へのアクセスは許可しなければな
りません。
3.2.14
テスト
rule が完成したならば、最初に紹介した ipftest を用いてテストをします。この場合、SYN ビットなど
を指定したテストや、ICMP のパラメータを指定したテストを行う必要があります。
下は、tcp のフラグをセットしたテストのためのデータの例です。
in on OUTIF tcp 200.2.1.1,200000 192.168.1.1,80
out on OUTIF tcp 192.168.1.1,80
200.2.1.1,20000
S
SA
in on OUTIF tcp 200.2.1.1,200000 192.168.1.1,80
out on OUTIF tcp 192.168.1.1,80
200.2.1.1,20000
A
A
in on OUTIF tcp 200.2.1.1,200000 192.168.1.1,80
out on OUTIF tcp 192.168.1.1,80
200.2.1.1,20000
A
FA
in
in
A
FA
on OUTIF tcp 200.2.1.1,200000 192.168.1.1,80
on OUTIF tcp 200.2.1.1,200000 192.168.1.1,80
out on OUTIF tcp 192.168.1.1,80
200.2.1.1,20000
A
この場合、200.2.1.1,20000 から内部の 192.168.1.1,80 へのアクセスがあり、データをやり取りして終了
するという流れを想定したデータになっています。
一方、不正な TCP フラグを持ったテストは以下のようなものです。
第3章
30
in
in
on OUTIF tcp 200.2.1.1,20000 192.168.1.1,80
on OUTIF tcp 200.2.1.1,20000 192.168.1.1,80
S
SA
in
in
on OUTIF tcp 200.2.1.1,20000 192.168.1.1,80
on OUTIF tcp 200.2.1.1,20000 192.168.1.1,80
SFP
SPU
一方、ICMP については、
in
on OUTIF icmp 200.2.1.1
192.168.1.1 echo
in
in
on OUTIF icmp 200.2.1.1
on OUTIF icmp 200.2.1.1
192.168.1.1 echorep
192.168.1.1 unreach
フィルタリング II
のようにします。勿論、応答がある ICMP についてはその方向を考慮したテストが必要です。
もう一度、IPFilter における ICMP type の表記を書いておきましょう。
”unreach”,”echo”,”echorep”,”squench”, ”redir”, ”timex”,”paramprob”,”timest”, ”timestrep”,”inforeq”,
”inforep”,”maskreq”,”maskrep” ,”routerad”,”routersol”
勿論、番号でも構いません。
同様に、UDP についてもテストを行う必要がありますが、この際に注意すべきは、keep state を使って
いる場合に、どちらからどちらへのコネクションを keep state を用いて許しているかです。許している方
向、許していない方向、両方についてのテストが必要です。
その他に、IP オプションやフラグメンテーション、TCP オプションなどのテストもできますが man や
IPFilter のドキュメントを参照してください。
3.3. 演習課題
3.3
31
演習課題
演習 3.1 全員、カーネルを再構築しなさい。但し、最初は設定は以下のように全てのパケットを通す設定
を/etc/ipf.rules に設定してから、行いなさい。
pass out all
pass in all
また、リブートする前に、以下のように /etc/rc.conf を設定しなさい。
ipfilter_enable="YES"
リブート後、グループ内部あるいは、直接接続した別のグループと繋がるかを確認しなさい。
演習 3.2 ICMP のルールを別のファイルに書き、ipftest を用いて各自テストをしなさい。(通るべきもの
が通っているか、落とすべきものが落ちているか。)
演習 3.3 全員、ICMP に関するフィルタリングを外部インターフェースに対して、行いなさい。但し、ping
は通るようにしておきなさい。また、quick と log を用い、その他のパケットは全部通しておくようにする
こと。
外部 (マスター以外は接続している相手、マスターは適当な別のグループのマスター) に対して ping を
打ち、導通を確認しなさい。確認したら、作成したルールを ipfstat -io で出力し、それを提出しなさい。
演習 3.4 次に、ログを取れるように設定をし、 ICMP を全てログに取るようにした上で、 ping を落とす
ように設定し、それを確認しなさい (双方向で)。確認したら、log の結果を提出しなさい。
第3章
32
3.4
フィルタリング II
演習課題
演習 3.5 メイル (TCP port 25) と DNS(UDP port 53) への外からのアクセスを許すルールを作成し、テ
ストしなさい。なお、ここでは自サイトから外へのアクセスや、内部インターフェース上でのアクセスは
全て通す設定にしましょう。
ipftest でテストをし (port 25 への tcp アクセスや、port53 への UDP アクセス)、ルールを提出しなさい。
演習 3.6 次に、内側からのアクセスは状態遷移を考慮に入れたルールセット (つまりは、ステートフルな
ルールセット) を作成しなさい。先と同様に、ipftest でテストをし、問題ないならば、テストに用いたデー
タを提出しなさい。
但し、TCP,UDP のみを考慮すれば良いでしょう。
演習 3.7 spoofing, loopback などについてのルールセットをテストの上組み込みなさい。但し、10/8 ,
172.16.0/24 , 172.17.0/24 については演習の環境の関係でブロックしてはいけません。また、マルチキャ
ストについても、今後必要になるので、ブロックしてはいけません。
その上で、head, group を用いて、フィルタリングルールを 4 つの方向について整理しなさい。
作成したルールセットを提出しなさい。
33
第 4 章 動的ルーティングと RIP
本章では、最初に行った静的なルーティングに代わって、動的なルーティングについて簡単な解説をし、
その上で RIP について説明をします。
4.1
動的ルーティングプロトコルの概要
一般にルーティング (経路制御) プロトコルは、ルーティングに必要な情報をやりとりするためのもので
す。具体的には、ルーティングテーブルを変更するのに必要な情報を交換し、それに基づいてルーティン
グテーブルを動的に変更する事を指します。従って、ルーティングプロトコルは実際のパケットの転送 (
forwarding) とは違う事に注意して下さい。
z
w
B
A
x
y
例えば、上の図で A から B へのルーティングを考えて見ましょう ( A,B,x,y,z,w は全てルータ)。ルーティ
ングでは A から B へ行くために、A はその全ての経路を指定する訳ではありません (考えるというのと
は別です)。指定は単に、x に投げるか、あるいは z に投げるかだけしかありません。そこで、ルーティン
グにおいては２つの方法が主には考えられました。A は本当に x,z しか知らないというものです。つまり、
経路上に y や w があっても、A はその存在を知らないという考え方です。同じように、x は、A,z,y しか
知らず、他のルータについても同様の状況にある訳です。勿論、これだけならば、A から B に到達するの
に、どこを通るべきかという判断基準がありませんので、通常ルーティングではコストという考え方でよ
り良い経路を計算します。ここでは、単純に隣接間のコストは 1 であるとしましょう。すると、例えば、
A->x->y->B はコスト 3 となり、A->z->x->y->B はコスト 4 となるので、前者の方が良い経路となります。
但し、このままでは、A->z->w->B とは同じコストで区別がつきません。このような考え方のアルゴリズ
ムの代表が RIP です。RIP などの良い点は、各ルータの仕事が隣接ルータのどこに送るかという判断のみ
にある点にあります。一方、問題はいずれかのルータが故障した際に、それをどのように発見し、全体に
それを通知するかにあります。当然、隣接以外のルータについての情報は受け取りませんので、ある経路
のコストが高い、あるいは無限に高い (つまり、到達できない) という情報を通じてその問題をネットワー
第4章
34
動的ルーティングと RIP
ク全体に通知しようとします (Poison reverse)。これは、些か持って回った方法で、そのために RIP には
固有の問題が存在します。
一方、全てのルータが隣のルータのみならず経路全部について知っているようなアルゴリズムも考えら
れます。この場合、A は B への最適な経路を全て考えた上で、パケットを送り出します。次に、そのパケッ
トを受け取ったルータは再び B への最適な経路を全て考え直します。このように、全てのルータがもし同
じ経路の情報を知っているならば、その考え方は一致しますので、同じ矛盾のない、最適な経路が選ばれ
ることになります。この方法の欠点は、各ルータがパケットを転送しようとする度に、同じことを考える
という点にあり、そのために無駄が生じますが、一方、ルータ z に問題が生じた際には素早く代替経路を
考えることが出来ます (全てのネットワークを理解している訳ですから当然と言えば当然ですね)。このよ
うなアルゴリズムの代表が OSPF です。
このような区別の他に色々な特徴を持ったルーティングプロトコルが存在しますが、以下ではもう少し
詳しくこれらの違いについて解説をしましょう。
4.1.1
内部、外部ルーティングプロトコル
Internet 全体を考える場合に重要な点は、それが様々なネットワーク単位の集合であるという点です。つ
まり、多くのネットワーク組織が相互に接続されているという特徴があり、そこからルーティングプロトコ
ルに対してある要請がされます。それは、組織の内部のルーティングと外部のルーティングではポリシーが
全く違うという点です。実際、組織内部では、その組織の管理者がその組織の実態に合わせて様々なルー
ティングポリシーを設定することが出来ます。一方、組織と組織の間を繋ぐ、組織の外部へのルーティング
に関しては、こうした単一の指導性、あるいは強制を行うことは難しく、綿密な協力と相互性に基づく必
要があります。このようにして、組織内部と外部では異なるプロトコルが必要であり、それらの論理を反
映するという点で、外部で用いるルーティングプロトコルを Exterior Gateway Protocol (EGP) と呼び、
内部で用いるルーティングプロトコルを Interior Gateway Protocol (IGP) と呼びます。勿論、技術的には
EGP を内部に用いても問題はありませんし、論理的には IGP を外部に用いることも考えられます。(実
際、歴史的には現在 IGP とされるものをインターネット全体の制御に使っていた時もあったのです。)
ゲートウェイプロトコルは古い言い方で、ルーティングプロトコルと同じだと思って構いません。
通常、IGP はある程度の大きさを想定しているので、それ以上の規模には対応出来ないことが多く、一
方、EGP は最初からスケーラビリティを考慮しているので内部に使う事に大きな問題はないが、IGP にあ
るような柔軟性には欠けると考えられます。
EGP として現在主要に利用されているのが BGP4 (Border Gateway Protocol version 4) です。一方、
IGP には IS-IS, OSPF, RIP などがありますが、通常 OSPF( Open Shortest Path First) を使う事が推奨
されています (IETF: Internet Engineering Task Force)。とは言え、小さなネットワークでは簡便である
ことから RIP (Routing Informationn Protocol) も良く使われています。通常の管理者が扱うのは圧倒的
に RIP,OSPF でしょう。BGP4 を使うのはかなり大きなサイトでないとお目にかからないからです。
4.1.2
ルーティングプロトコルのアルゴリズム
先に内部、外部という違いによるルーティングプロトコルの区別を紹介しましたが、通常もう一つの区
別の方法があります。それは、利用されるアルゴリズムによる区別です。ルーティングプロトコルに用いら
れるアルゴリズムには大別して２つのものがあります。一つは、距離ベクトル型 ( Distance Vector Type)
と呼ばれるものであり、今一つはリンク状態型 (Link State Type) です。RIP や BGP は距離ベクトル型
に分類され、IS-IS や OSPF はリンク状態型に分類されます。以下では、距離ベクトル型についてまず説
明をしましょう。
4.2. 距離ベクトル型と RIP
4.2
35
距離ベクトル型と RIP
距離ベクトル型の特徴は、それぞれのノードに分散して計算を行い、それらの結果が近隣に伝達される
点にあります。まず、簡単にこうした点を説明しましょう (但し、元々の距離ベクトル型のアルゴリズムに
基づいて説明し、改良されたアルゴリズムは考慮していません)。
以下の図ではルータ A,B が何らかの形で接続され、ルーティング情報を交換出来るものとします。ルー
タ B の足には 192.168.0.0/24 のネットワークがつながっています。
この時、まずルータ A は 192.168.0.0/24 へは自分はコスト０で到達出来るという情報を作成し、これを
隣のルータ B へと伝達します。ルータ B は A からの情報を元に、B から A へ行くためのコストを付加し
て 192.168.0.0/24 へ行くにはコスト２がかかると言う情報を作成する訳です。ここで、コストは色々なも
のから計算されるもので、コストが低いものが経路選択では優位にあるとみなします。
さて、次にもう少し実際的な例を考えましょう。今度は、先のルータ A,B に加え、ルータ C,D がある場
合を考えます。ルータ C はルータ A につながっていますがコストは３であるとします。ルータ D はルー
タ B,C につながっており、そのコストは両方とも１であるとします。
さて先の場合と同じように考えると、ルータ B はルータ D に以下のように伝達します。
情報元ルータ
宛先
コスト
B
192.168.0.0/24
2
従って、ルータ D は、B,D 間のコストを足して、B を使えば 192.168.0.0/24 へはコスト 3 で到達する事
が出来ると理解します。
第4章
36
ルータ
情報 1
経由ルータ
宛先
D
B
動的ルーティングと RIP
コスト
192.168.0.0/24
3
同時に、ルータ C も同じようにルータ D に情報をもたらし、それは次のようになっていますから、
情報元ルータ
宛先
コスト
C
192.168.0.0/24
3
ルータ D は C を使えば 192.168.0.0/24 へはコスト４で到達出来ることを理解します。
ルータ
D
情報 2
経由ルータ
宛先
C
コスト
192.168.0.0/24
4
このようにして最終的にルータ D は宛先に対するリストを以下のように手に入れます。
情報番号
ルータ D の持つリスト
経由ルータ
宛先
コスト
1
B
192.168.0.0/24
3
2
C
192.168.0.0/24
4
そして、コストが最も低い 1 の情報に基づいて、192.168.0.0/24 への経路としてルータ B に送り出す経路
を選択する訳です。
ここから分かるように距離ベクトル型では、ルータ D からはルータ A の存在は見えていません。隣接す
るルータ B,C が見えているだけで、言わばその背後にあるネットワークは見えていないのです。これが、
距離ベクトル型が一種の分散計算を行っていると言った理由であり、距離ベクトル型が単純であると言わ
れる理由なのです。
しかし、一方ここに上げなかった問題が存在します。それは実は上の場合でもルータ D は自分が手に入
れた情報を常に隣接するルータ B,C に流し続けるという事です。勿論、B,C はその情報を受け取り、例え
ば B は次のように自分のリストを作成します。
情報番号
ルータ B の持つリスト
経由ルータ
宛先
コスト
1
A
192.168.0.0/24
2
2
D
192.168.0.0/24
4
少し変な気もしますが、経路選択という点ではコスト２の 1 の経路が選ばれますから、この時点ではまだ
問題ではありません。(ちなみに、こうして全てのルータのリストが定まった時点を収束したと言います。)
問題はルータ A の 192.168.0.0/24 へのインターフェースが故障した時に起こります。この場合、元々の
RIP のアルゴリズムでは、自分が分かっている経路のみを流すことになっているので、ルータ A は自分の
インターフェースがダウンした事は分かりますが、その情報を積極的には流さず、単に隣接ルータに流す
情報から削除します (これを改善するアルゴリズムが Poison reverse で、無限 (16) を流すことで収束を早
くします)。
すると、この時点ではルータ B のリストは以下のようになります。
4.2. 距離ベクトル型と RIP
37
情報番号
1
ルータ B の持つリスト
経由ルータ
宛先
D
192.168.0.0/24
コスト
4
なんと、B はルータ D を経由して 192.168.0.0/24 に到達出来ると解釈してしまうのです。そして、その
結果を隣接ルータに伝達します。この情報を受け取ったルータ D は自身のリストを以下のように書き換え
るでしょう (ルータ C からの情報は簡単のために省略して考えます)。
情報番号
1
ルータ D の持つリスト
経由ルータ
宛先
B
192.168.0.0/24
コスト
5
そして、この情報を再びルータ B に伝達します。当然、先程とは違って今度はコストが往復の分だけ上乗
せされてコスト 6 となります。
情報番号
1
ルータ B の持つリスト
経由ルータ
宛先
D
192.168.0.0/24
コスト
6
もう分かりましたでしょう。プログラムの無限ループと同じように無限にカウントするために、コストが
一定の値で止まること無く無限に大きくなっていきます。これを無限カウント問題と言い、距離ベクトル
型ではこれを回避するために、上限を設定します。つまり、ある値に (あるいはその値以上に) なったらそ
れを無限であるとみなす訳です。RIP などでは 16 が無限であると定めています。
• RIP のコスト
RIP のコストは非常に単純に、一つのホップカウント (ルータの通過) に対して１と決められています。このた
めに、どれかのパスに対して 16 以上のルータ (どのパスを取っても 15 まで) で構成されるネットワークに対し
ては絶対に使うことが出来ません。最も、パス上に 15 もルータがある時点で、RIP の使用は無謀だと言えま
すが。
勿論、ここに掲げた例のような２つのルータ間のピンポンを抑制することはそれほど難しくありません
が、メッシュ状に構成されたネットワークの各所にできるループで同じような現象が距離ベクトル型では
発生します。
このように、いくつかの条件においては距離ベクトル型は収束に時間がかかるという欠点を持っていま
す (通常、RIP は 30 秒に一度メッセージをブロードキャストあるいはマルチキャストで流します)。こうし
た欠点を回避するアルゴリズムも色々と考えられましたが、ネットワークの構造を理解しないという欠点
から来る収束の問題は解決が困難でした。そのために、BGP などでは宛先へのコストだけではなく、そ
こに至る全てのルータのリストを付加して伝達することで解決を計っています (自分がそのリストに含ま
れていたら破棄することでループを抑制します)。このために BGP は単純な距離ベクトル型ではなく、パ
スベクトル型とも分類されます。勿論、距離ベクトル型を改善する更に複雑なアルゴリズムもありますが、
複雑なアルゴリズムは逆に収束時間を大きくする傾向にありますので、なかなか難しい問題です。
RIP を考えると、以上のような理由のために大きなネットワークでは使われていません。しかし、非常
に小さなネットワーク (1 ないし 2 程度のセグメントで構成) の場合には、設定が簡単なので RIP でも大
丈夫でしょう (設定は全くなく、起動するだけなので簡単以上です)。
もっとも、実際的な利用方法は、OSPF などの他のルーティングプロトコルと併用することでしょう。
何故ならば、OSPF が実装されていなくとも、RIP ならば実装されているという場合は非常に多いからで
す。つまり、ネットワーク全体のルーティングは OSPF で行い、RIP はそれを末端に伝達するために使う
ような場合がそれに当たります。
第4章
38
動的ルーティングと RIP
Quagga の構造
4.3
Quagga は多くのルーティングプロトコルを扱うためにモジュール構造を取っています。これによって、
複数のプロトコルを矛盾なく、ルーティングテーブルに反映させる事が出来る訳です。
従って、Unix カーネルのルーティングテーブルを変更するのは zebra デーモンの役割で、それぞれのルー
ティングプロトコルは別のモジュールである bgpd, ripd, ospfd デーモンなどの役割になる訳です。Quagga
の設定をする場合には、この構造を良く理解しておく必要があります。
参考 実は Zebra の開発は今ではほとんどストップしており (ZebOS という商用のシステムにシフトして
いる)、Zebra のソースコードを使って分岐した Quagga が盛んに開発がされています。Zebra のコー
ドから分岐したので、設定ファイルなどは全てそのまま使えるます。ただ、Quagga もまだ 0.99 で
リリースバージョンではありません。ここでは開発途上の Quagga を利用することにします。また、
Zebra から引き継いでいるために名前が zebra のままのこともありますので注意してください。
4.3.1
Quagga の管理
Quagga には２つの管理方法があります。一つは、通常の管理ファイルを編集して行う方法です。
Quagga の設定ファイルは、パッケージからインストールすると/usr/local/share/examples/quagga/
以下にあり、サンプルファイルがあります。
bgpd.conf.sample
ospfd.conf.sample
vtysh.conf.sample
bgpd.conf.sample2
ospf6d.conf.sample
ripd.conf.sample
ripngd.conf.sample
zebra.conf.sample
今一つの管理方法は、ターミナルのようにインタラクティブに管理する方法です。これは Cisco などの
CUI インターフェース (CLI) と同じようなものだと思えば良いでしょう (Quagga では VTY と呼んでいま
す)。従って、通常は設定ファイルを最初は書いてから、Quagga を起動し、その後の設定変更はターミナ
ルを使って行います。
FreeBSD では、/etc/services に Quagga の使うポートは既に登録されています。
4.3. Quagga の構造
39
zebrasrv
zebra
2600/tcp
2601/tcp
#zebra service
#zebra vty
ripd
ripngd
2602/tcp
2603/tcp
#RIPd vty
#RIPngd vty
ospfd
bgpd
2604/tcp
2605/tcp
#OSPFd vty
#BGPd vty
ospf6d
2606/tcp
#OSPF6d vty
4.3.2
zebra の設定
zebra の役割は、カーネルのルーティングテーブルを維持し、異なるルーティングプロトコル間のルー
ティング情報の交換を支援し、インターフェースの状態を監視し、それを告知することにあります。従っ
て、複数のプロトコルを動かさない限り、zebra に設定する内容はほとんどないと言って良いでしょう。
以下は zebra.conf の例です。
! zebra configuration
!
hostname pcss001
password zebra
enable password zebra
service password-encryption
log file /var/log/zebra.log
!
interface le0
multicast
!
interface ue0
multicast
! shutdown
!
!ip route 0.0.0.0/0 172.16.1.1
• !
コメントですが、一桁目にある時のみ意味を持ちます。
• hostname
zebra のホスト名です。
• password
view モードのパスワードです。設定がないとターミナルが使えません。
• enable password
特権モードのパスワードです。
第4章
40
動的ルーティングと RIP
• service password-encryption
生で書いたパスワードを暗号化します。今の場合には、一旦ターミナルに入って、write をしないと
暗号化パスワードが設定ファイルに書き込まれません (つまり生パスのままです)。
• log file
指定したファイルにログを取ります。
• interface
ホストのインターフェースを列挙します。別に何も指定しなくても、一度起動してから write すると
勝手に書き出してもくれます。これが必要なのは、あるインターフェースを止めておいたり、マルチ
キャストを使わないように設定したりする場合です。
• shutdown
インターフェースの欄にあると、そのインターフェースを落します。
• ip route
デフォルトルーティングを static に設定し、それをルーティングプロトコルに再配布したい場合に指
定します。例えば、外部への出口が決まっている場合に、これを設定し、同時に ripd, ospfd などでこ
の static を再配布 (redistribute) する場合に用います。但し、/etc/rc.conf などで先に static routing
を設定するのか、zebra から設定するのかは良く考えないといけません。
RIP を設定せずに、上の設定で ip route の行のコメントを外した zebra.conf を作成し、Quagga を動か
すと、静的ルーティングのみをカーネルに設定します。
4.3.3
ripd の設定
RIP を設定するには、ripd.conf を設定します。ripd.conf の設定は RIP に固有の部分を除き zebra と共
通になっています。
4.3. Quagga の構造
41
!
! $Id: ripd.conf, 2008/04/01 $
!
hostname pcss001
password zebra
!
! debug rip events
! debug rip packet
!
router rip
network
ue0
network
le0
!
! network 11.0.0.0/0
! network eth0
! distribute-list private-only
!
! access-list private-only permit 10.0.0.0/8
! access-list private-only deny any
!
! log file /var/log/ripd.log
!
log stdout
• router rip
必ずないといけません。RIP を使うための宣言です。
• network <interface name>
RIP を使うネットワークのインターフェースを指定します。この指定が全くない場合は、自動的に生
きているインターフェースを調べて、それらのインターフェースを利用します。また、この指定の他
に IP アドレスを指定した方法もあります。
network 172.16.1.3/24
• log stdout
標準出力にログを表示します。ファイルにとりたい場合には以下のように設定をします。
log
file
/var/log/ripd.log
但し、走らせるデーモンのパーミッションで書き込めるようになっていないといけません。
• その他の設定
第4章
42
動的ルーティングと RIP
1. passive-interface <interface name>
指定したインターフェースをパッシブモードで動作させる。パッシブモードでは、受信した全
ての RIP メッセージを解釈するが、そのインターフェースから自分は発信をしない。
2. deault-information originate
RIP を話さないインターフェースから外へ接続されているような場合に、その default ルーティ
ングを RIP で内部に向かって流すための設定。
3. redistribute connected
RIP を使っていないインターフェースから得た情報を RIP を使って配布する。RIP を使ってい
ないネットワークだが、そこへのルーティングをネットワークに教えるために使う。
4. redistribute ospf
OSPF から得たルーティング情報を RIP を使って配布する。
5. redistribute bgp
BGP から得たルーティング情報を RIP を使って配布する。
6. redistribute static
Quagga で静的に設定したルーティング情報を RIP を使って配布する。
7. redistribute kernel
カーネルに設定されたルーティング情報を RIP を使って配布する。
他にも細かい設定がありますが、割愛します。
Quagga の起動
4.3.4
zebra, ospfd, bgpd, ospf6d,ripd,ripngd などのデーモンは全て -d オプションをつけるとデーモンで動き
ます。あるいは、/usr/local/etc/rc.d/quagga を使って、start, stop, restart をさせます。(Zebra で用意さ
れていた zebractl は Quagga ではなくなっています。)
# zebra -d
# ripd -d
あるいは、 /etc/rc.conf に quagga_enable="YES"を設定した上で、/usr/local/etc/rc.d/quagga スクリ
プトで動かします。
#
/usr/local/etc/rc.d/quagga
start
停止、再起動などは stop, restart で行います。
あるいは、更に、/etc/rc.conf に watchquagga_enable="YES"を設定した上で、/usr/local/etc/rc.d/watchquagga
スクリプトで動かします (watchquagga は、Quagga のデーモンを監視し、もし落ちていたら再起動を行っ
てくれるデーモンです)。
# /usr/local/etc/rc.d/watchquagga
停止、再起動などは stop, restart で行います。
start
但し、設定ファイルに間違いがあるときには、エラーを出して起動しませんので、注意して下さい。
4.3. Quagga の構造
4.3.5
43
VTY での操作
RIP を設定する場合には、zebra と ripd を使うだけです (以下ではデーモンの場合は zebra、システム
全体の場合には Quagga とします)。
zebra の VTY
zebra に入るには以下のようにします。但し、パスワードを設定しておかないと入れませんので、注意し
ましょう (zebra.conf.sample には設定されているので、それを zebra.conf に copy して使えば良いでしょ
う)。また、パスワードは各々のデーモンについて設定出来ます。
のようになる。
# telnet localhost zebra
ターミナルに入ると (VTY モード)、パスワードを聞かれるので設定したパスワードを入力すると以下
# telnet localhost zebra
Connected to localhost.
Escape character is ’^]’.
Hello, this is zebra (version 0.93b).
Copyright 1996-2002 Kunihiro Ishiguro.
User Access Verification
Password:
Router>
このモードは view モードと呼び、設定を確認したりするためのものである。実際の設定には privileged
モード (特権モード) に移り、更に config モード (設定モード) に移る必要がある。また、更に詳細設定のた
めに各種の設定モードに移る必要のある時もある。簡単な help 機能が常に使えるので、分からないときに
は ? を打てば良い。更に、補間機能などもあるので、入力を補助してくれるようになっている。以下で、
少し VTY の使用例を見てみよう。
> ?
enable
exit
Turn on privileged mode command
Exit current mode and down to previous mode
help
list
Description of the interactive help system
Print command list
quit
show
Exit current mode and down to previous mode
Show running system information
terminal
who
Set terminal line parameters
Display who is on vty
次に、show コマンドで何かを見てみよう。
第4章
44
動的ルーティングと RIP
> show ?
debugging
Zebra configuration
history
interface
Display the session command history
Interface status and configuration
ip
ipv6
IP information
IPv6 information
memory
version
Memory statistics
Displays zebra version
> show
オプションのあるコマンドでは、コマンドあるいはオプションの後ろで? を入力すると、その簡易 help
が表示される。更に、それらのオプションを途中まで入力してから TAB キーを押すと補間もしてくれる。
> show ip ?
forwarding
route
IP forwarding status
IP routing table
以下に示されているのは zebra のルーティングテーブルで、それぞれ K がカーネルのテーブルから来
たもの、C が接続されているインターフェースから取り込んだもの、S が zebra で静的に設定したもの、
R,O,B が RIP,OSPF,BGP からもたらされたものである。
> show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
B - BGP, > - selected route, * - FIB route
S>* 0.0.0.0/0 [1/0] via 172.16.1.1, le0
C>* 172.16.1.2/24 is directly connected, le0
K>* 172.18.1.2/32 via 127.0.0.1, lo0
C>* 127.0.0.0/8 is directly connected, lo0
privileged(特権) モードに移るには、enable (en) と打ち、パスワードを入力します。
pc2f001-zebra> en
Password:
pc2f001-zebra#
Quagga では、現在メモリ中に保存されている設定と、ファイルに書かれた設定とは異なります。最初に
起動された時には、ファイルの設定をメモリにロードしますが、その後 VTY で設定された内容はメモリ
のみに存在します。そこで、メモリにある設定をファイルに書き戻す命令が write です。
# write
Configuration saved to /usr/local/etc/quagga/zebra.conf
一方、設定内容をメモリに反映されるコマンドは write terminal です。write terminal を実行すると、
現在のメモリ中の設定が表示されます。
これを確認したい時には、show running-config を使います。また、起動したときの最初の設定 (つま
4.3. Quagga の構造
45
りはファイル) の表示コマンドは show startup-config です。
その他、VTY 端末ではヒストリ機能などもあり、^P などで呼び出し、編集して実行するなど tcsh と同
じような機能があります。
ripd の VTY
ripd に対しても VTY での操作は zebra とほぼ同じです。ripd が既に起動していれば VTY に入ること
が出来ます。
> telnet localhost ripd
zebra との違いは設定のためにいくつかのモードを持っている点です。これらのモードの遷移について
は以下の図を見て下さい。
Ý ’è
rip
mode
enable
view
mode
“Á Œ mode
configure
terminal
router
rip
Ý ’è
mode
interface
<if-name>
Ý ’è
interface
mode
それぞれのモードで使えるコマンドは違いますので、迷ったら? を押して簡易ヘルプを常に呼び出して
下さい。
それぞれの設定モードから一つ前のモードに戻る時には、 quit(または exit) を使います。end は常に特
権モードに戻ります。特権モードでの exit は VTY から抜けますので注意して下さい。
設定モードで設定を変更した場合には write を忘れないようにして下さい。また常に設定状況を見る習
慣をつけて下さい。
また、vtysh というコマンドが用意されており、わざわざ vty 端末に入らなくても、vty に対してコマン
ドを投げて、それを表示するプログラムが用意されています。簡単な使い方は、
vtysh -c
[コマンド]
で、実際の使用例を次に掲げます。
第4章
46
4.4
#
vtysh
-c
動的ルーティングと RIP
’sh ip rip’
RIP の実際
以下少し実際の RIP の様子について見てみよう。
上の図はある RIP の VTY 端末に入り、show ip rip を表示させた結果です。172.16.0.0/24 と 172.16.1.0/24
のネットワークが RIP を通じて学習されており、双方へのゲートウェイが 172.2.1 で、前者については
Metric 3 で、後者については Metric 2 であること、自分自身が接続されたネットワークは 172.16.2.0/24
でそれを RIP で流していることが分かります。
次も同じように show ip rip を表示させた結果ですが、今度は 172.16.0.0/24 のネットワークの Metric
が 16 になっている点が異なります。つまり、172.16.0.0/24 のネットワークへは不通になった訳です (こ
れは Poison reverse と呼ばれる、障害のあるネットワークへのコストを意図的に無限 (cost 16) にして隣
接に通知する手法です)。面白い事に、実際に Quagga は Metric 16 をこのようにある程度の時間保持し、
その後、下のようにルーティングテーブルから削除している様子 (Poison reverse が流れなくなった時点)
が見て取れます。
4.4. RIP の実際
47
この時のカーネルのルーティングテーブルを表示させたのが次の図です。
その後、172.16.0.0/24 のネットワークが回復した際のテーブルが以下になります (表示が 172.16/24
に省略されてしまっています)。
第4章
48
動的ルーティングと RIP
演習課題
4.5
演習 4.1 最初に全員が Quagga を導入しておきなさい。pkg_add -r quagga で導入できます。
演習 4.2 もし、ファイヤーウォールが設定されていなければ、各自最低以下のファイアーウォールの設定
を行いなさい。特に、ファイアーウォールでマルチキャストを落とすと、RIP や OSPF で通信が出来な
くなりますので注意してください。
# out0 は外側インターフェース, in0 は内側インターフェース
pass
pass
in on
out on
out0
out0
all
all
head
head
100
200
pass
pass
in on
out on
in0
in0
all
all
head
head
300
400
#
pass
pass
#
in
quick on
lo0 all
out quick on
lo0 all
# ICMP
pass in
pass in
quick proto icmp all icmp-type 0
quick proto icmp all icmp-type 3
group 100
group 100
pass in
pass in
quick proto icmp all icmp-type 4
quick proto icmp all icmp-type 8
group 100
group 100
pass in quick proto icmp all icmp-type 11 group 100
pass out quick proto icmp all icmp-type 0 group 200
pass out quick proto icmp all icmp-type 3
pass out quick proto icmp all icmp-type 4
group 200
group 200
pass out quick proto icmp all icmp-type 8 group 200
pass out quick proto icmp all icmp-type 11 group 200
#
block in
quick proto icmp all group 100
block out quick proto icmp all group 200
マスターで既にファイアーウォールの設定を行った場合には、マルチキャストが通過できるように見直
しなさい。
演習 4.3 今の段階では、グループ内部での動作を確認することにしますので、他のグループに直接張って
いるケーブルは抜いて、指示のあるまでは繋がないようにして下さい。
最初に、zebra.conf だけを設定し、static に default ルーティングを書きなさい。
次に、以下のようにして default ルーティングを消してから、
# route delete default 172.16.1.1
但し、この例はグループ１のマスターでない人用の例です。各自、マスターの内側インターフェースに設
定しなさい。マスターは、全員 10.120.254.254 に設定しなさい。
この段階で、外にはアクセス出来ませんので、それを確認して下さい。
次に、zebra を動かすと自動的に default ルーティングが設定され、外に繋がるのを確認しなさい。
4.5. 演習課題
49
演習 4.4 マスター上で RIP を設定しなさい。但し、マスターは ripd.conf に次の設定をしておかなけれ
ばなりません (マスターのみ)。
router rip
....
passive-interface ue0
!マスターは RIP を外に流さない
default-information originate !マスターの defaultrouting を伝達
設定したら、zebra と rip を手動で動かしなさい。
演習 4.5 マスター以外のマシン上で zebra と rip を設定しなさい。先に設定した、zebra のデフォルトルー
ティンングの設定はコメントアウトし、現在のデフォルトルーティングを削除すること (マスター以外の
人は)。
# route delete
default
172.16.1.1
削除したら、外にアクセスできませんので、それを確認して下さい。
次に、上に上げた最低限のファイヤーウォールが設定されているか確認して下さい。これらが確認でき
たら、zebra と rip を動かします。但し、動作させる場合は、グループ内で相談の上、一人づつ動作させ、
一人が動かしたら、その動作を確認し、問題がないことを確認した上で、次の人が動かすようにしなさい。
なお、動作させたら、マスターからのルーティング情報がスレーブ１に伝達されているかどうかをチェッ
クしなさい。また、外へのルーティングがされているかどうかもチェックしなさい。
演習 4.6 全員が、zebra, rip が動いたら、telnet localhost
果を提出しなさい。
ripd で RIP に入り、show ip rip の結
51
第 5 章 OSPF
前の章で、距離ベクトル型の概略とその代表である RIP について学びましたが、その距離ベクトル型に
対抗する今一方のアルゴリズムがリンク状態型です。リンク状態型は一言で言えば、各ルータのつながっ
ている状態 (リンク状態) の情報を全てのルータが知っているという方式です。つまりは、全てのルータは
ネットワークの構成を知っている訳ですから、どこかのリンクが落ちた場合には、距離ベクトル型とは違
い、自ら持っている情報に基づいて代替経路を割り出すことが出来ます。このような特徴のために、リンク
状態型は距離ベクトル型に対して、非常に早い収束性を持っており、収束性に関してはスケーラビリティに
優れていると言われています。リンク状態型に分類されるルーティングプロトコルとしては、OSPF(Open
Shortest Path First) や IS-IS(Intermediate System-to-Intermediate System) などが挙げられます。一方、
そのアルゴリズムはかなり複雑ですので、リンク状態型を説明する代わりに OSPF ではどうなっているか
を次の節で見て行くことにしましょう。
5.1
OSPF の概略
リンク状態 (Link State) 型のルーティングプロトコルは非常に複雑であり、距離ベクトル型ほど簡単で
はありません。ここでは OSPF の概略を理解するために簡単な説明を試みることにします。リンク状態型
の基本は、データベースにあります。何故ならネットワークの構造がそこにあるからであり、従ってリン
ク状態型はそのデータベースを常に現実のネットワーク状態を反映するように更新し、維持しなければな
りません。これは、ある接続が切断した場合や、復帰した場合のみならず、あるルータがダウンし、復活
した場合のデータベースの再構築を考慮していなければならないことを意味します。こうしたデータベー
ス全体を常に交換するのは当然非効率的ですので、 OSPF ではこのデータベースをリンク状態広告 ( LSA:
Link State Advertisement) という要素に分解して、この LSA を交換する事でデータベースを最新に保ち
ます。LSA の集合であるデータベースはリンク状態データベース (LSDB: Link State Database) と呼ばれ
ます。
データベースが常に最新であるならば、経路はそのデータベースの中の情報を元に最も低いコストの経
路を計算して得ることが出来ます。このコスト計算に用いる方法が Shortest Path First(SPF) というアル
ゴリズムであることから、OSPF の名前が由来しています (IGP のような名前でないもう一つの理由は、
IS-IS との競争にあったようです)。RIP とは違って、OSPF ではコストは正の整数であれば良いだけなの
で (2byte)、ネットワークの早さや帯域などを考慮してコストを決める事が出来ます。つまり、ホップが長
くても、より早い経路を選ぶような事が可能なのです。但し、コストの定義は人間がしなければなりませ
ん。コストが同じ場合には、ロードバランスが可能です。また、理論的にはコストは双方向に対して同じ
でなくても構いません。従って、A から B へのコストと B から A へのコストが異なっても OSPF では
全く問題はなく、それによってパスが往路と復路で異なる事も容認します。勿論、こうした設定は管理者
としては非常に面倒なことなので、わざわざそのような設定をする管理者はいませんが。
以下ではもう少し詳しく LSA について見た後に、 OSPF を構成するネットワークについて見ることに
します。
第5章
52
5.1.1
OSPF
リンク状態広告 (LSA)
各ルータは自身のつながっているネットワークとそのコストについての情報を近隣ルータに知らせます。
これをリンク状態広告 (LSA) と呼びます。従って、全てのルータの LSA を集めれば、そこにはネットワー
クについての全ての情報が入っていることになります。距離ベクトル型と同じくコストは様々な観点から
決める事が出来ます。例えば、早さや、あるいは値段などです。但し、注意すべきはこれらのコストは最
終的にどの経路を選択するかという点で利用される訳ですから、異なる観点をコストに持ち込んでしまっ
ては意味がありません。つまり、和を取ったときに意味のあるものであり、比較したときに意味がなけれ
ばならないのです。
さて、こうした LSA が全部のルータに知らせるにはどうしたら良いでしょうか。距離ベクトル型では、
個々のルータは近隣から得た情報を再計算して流していましたが、 LSA ではその情報をそのままネット
ワーク上全てに流さなくてはなりません。そのために通常フラッディング (flooding:氾濫) が利用されます。
フラッディングは文字通り LSA をネットワーク全体に氾濫 (flood) させるものです。確かに全てのルータ
が受け取った LSA を自身の LSDB に格納すると同時に、その全てのリンクに流せば最終的にはネットワー
ク上の全てのルータが同じ LSA を受け取る事が出来ますが、当然こうした原始的な方法は無駄が多いこと
が分かります。そこで OSPF などでは、簡単な方法でこの無駄を減少させています。
今、簡単に次のような場合を考えてみましょう。4 台のルータが相互につながっており、どの 3 台も同じ
ネットワークにつながっていないと考えると、この 4 台のルータを接続するラインは 6 本あります。この
内の１台が LSA をフラッディングさせた場合、3 個の LSA パケットを出します。次にこれを受け取った 3
台のルータは、LSA を受け取ったリンク以外の 2 つのリンクに対して LSA をフラッディングさせるので、
3 台で合わせて 9 個の LSA パケットを出します。従って、ネットワーク全体に LSA が行き渡るためには
トータルで 12 個の LSA パケットが流れる訳です (図 5.1)。
図 5.1: 無駄な LSA フラッディング
これに対して、OSPF では代表ルータ (Designated Router:DR) を選出し、各ルータはこの代表ルータ
に対してフラッディングを実行します。これによって流される LSA パケットは、代表ルータへのパケット
と、代表ルータから各ルータへの LSA パケットの 3 個に減少します (図 5.2)。これは規模が大きくなる程
効果的です。
勿論、こうした方式をとると逆に DR が故障したり、DR へのリンクが切れた場合に問題になります。
そこで、OSPF では DR の他にバックアップ代表ルータ (Backup Designated Router:BDR) を用意するこ
とで対処しています。BDR は DR のフラッディングを監視し、もしフラッディングが流れない場合には素
早く交替してフラッディングを代わりに行います。
5.1. OSPF の概略
53
図 5.2: 代表ルータ方式
一方、LSA パケットの数を減少させても、LSA パケット情報に無駄があればやはりネットワークを無駄
に浪費します。このために通常 LSA は LSDB 全体ではなく、情報を細分化して生成します (逆に言えば、
LSA の集合が LSDB です)。これによって、一つのリンクに障害があった場合には、それに関する LSA の
みを更新してフラッディングさせれば良いことになります。
次に、LSA で知らせるべき内容について簡単に触れましょう。まず、必要な内容は近隣ルータについて
の情報です。どのルータとどのルータがつながっているかを知ることはネットワークの経路を構成するた
めに必要不可欠なことだからです。このために、OSPF では LSA にはいくつかの種類があり、近隣ルータ
情報は Router LSA に納められています (一つの Router LSA に自身のルータに近隣する全てのルータに
ついて情報が入っています)。近隣ルータの探索には hello プロトコルが利用されます。従って、一定時間
hello パケットが届かないならば、そのルータとの間に障害があると判断し、LSA を更新すると共に、ルー
ティング再計算を行います。但し、自らのインターフェースのダウンや、リンクダウンに比較するとこの
処理は非常に時間がかかるものになります。同時に、hello プロトコルでは相手との双方向のリンクである
ことも確認します。これによって、一方向のみのリンクを排除できます ( これは RIP では排除されないの
で、RIP ではこうした障害を検知出来ません)。
一方、自らが接続しているネットワークについての情報は Network LSA に納められます。Network LSA
が必要な理由は、OSPF でのフラッディングの非効率に対するもう一つの解答を含んでいるからです。そ
れは、ルータが同じブロードキャストネットワークにつながっている場合には、ブロードキャストあるい
はマルチキャストを用いて LSA を流せば、一つのパケットで情報伝達を行うことが可能なのですから、そ
れが可能かどうかを知る必要がある訳です (もしマルチキャストやブロードキャストが利用できないよう
なある種のポイントツーポイント接続の場合にはその設定が必要になります)。実際には、OSPF ではマル
チキャスト (AllSPFRouters:224.0.0.5 または AllDRouters:224.0.0.6) を用います。マルチキャストはセグ
メントを越えた伝達が難しく、未だにインターネット上では完全には実現されていません。しかし、同一
ネットワーク上と言う条件ならば問題はないでしょう (実践的には実はマルチキャストが一番設定やネット
ワーク設計で問題になります。OSPF を使う際にはマルチキャストを常に念頭に置かなければなりません
し、もしマルチキャストを使わないのであれば、特別な設定が必要になります)。
以前には、マルチキャストのルーティングプロトコルを使わずに OSPF を使う場合には、それらのマル
チキャストをループバックアドレスにルーティングしておくという少し変な設定をしなければならない場
合がありました (Zebra などでは)。
マルチキャストを知らない、あるいは詳しくない方々のために、少しマルチキャストについて次の節で
簡単に説明することにします。
第5章
54
5.2
OSPF
マルチキャスト
ブロードキャストセグメントではマルチキャストはブロードキャストと非常に良く似ています。単なる
スイッチは、マルチキャストを全てのポートに対して流します。ブロードキャストと異なるのは、自らが参
加していないマルチキャストアドレスは TCP/IP スタックが廃棄する点にあるだけです。一方、高級なス
イッチやルータで構成されたネットワークでは、マルチキャストを扱うための特別な仕組みが用意されて
います。その役割は、マルチキャストアドレスに参加していないホストには、本当にパケットを流さないこ
とにあります。一方、あるマルチキャストに参加しているホストには、そのホストがブロードキャストネッ
トワークに参加しているか否かに拘らずにマルチキャストパケットを流すようになっています。このよう
な機能は、実際には２つの構成部分から成り立っています。一つは、IGMP(Internet Group Management
Protocol) であり、今一つはマルチキャストルーティングプロトコルです。
IGMP は通常のネットワーク構成では、L2 スイッチと L3 スイッチの共同によって動作してます。L2 ス
イッチでマルチキャストグループへの参加・離脱を監視し、その結果を L3 スイッチに報告します。L3 ス
イッチはマルチキャストパケットがルーティングされているのならば、特別な受信者のグループを作り、
そこにマルチキャストを流します。従って、通常の IP のネットワーク構成とは無関係に、物理的なネット
ワーク構成 (とは言え、L3 のレベルという意味ですが) に基づいてマルチキャストは流されます。従って、
OSPF を扱う場合には、単なるスイッチを利用しているマルチキャストとブロードキャストが区別されな
いようなネットワークならば問題ありませんが、そうでないような場合や、マルチキャストは別個に制御
している場合には注意が必要です。
マルチキャストルーティングプロトコルは、他のルーティングプロトコルと非常に正確を異にしていま
す。その理由は、通常のルーティングでは、あくまでもパケットの宛先 IP を元にルーティングするための
情報を交換すれば良いのであるのに対して、マルチキャストルーティングでは宛先は 224.0.0.0/4 の同一
グループ宛になっているために、受信者グループの管理を最終的には含んでいる点にあります。従って、
AllSPFRouters(224.0.0.5) に参加しているホストは直接的には IGMP で管理されますが、そのホストへと
マルチキャストが配信されるよう保証するのはマルチキャストルーティングプロトコルにあります。これ
は、逆に言えば、もし OSPF ルータがマルチキャストルータに登録されていたならば、マルチキャストで
流された LSA は全てそのマルチキャストに参加しているルータに、つまりはマルチキャストルーティン
グの及ぶ限りのルータに届けられるという事を意味しています。もしも、到達した LSA が区別出来、破棄
されるならば問題はありませんが、そうでないならば非常に厄介な状況へと陥るでしょう。
5.3
OSPF のネットワーク構成
OSPF はネットワーク全体を知る事で早い収束性を実現していますが、当然ネットワークが大きくなる
と、そのリンク状態データベースは巨大なものになってしまい、逆に非効率となる恐れがあります。そこ
で、ネットワークでは良く行われる階層的なルーティングが OSPF でも導入されています。これによって
CPU やメモリのリソースの効率的な利用を計っているのです。さて、当然、このような階層的なルーティ
ングを OSPF でサポートするためには、OSPF の概念自体にそれを導入する必要があります。このための
基礎概念がエリアです。エリア内部では LSA はフラッディングされますが、エリア外部にはされません
(Router LSA や Network LSA)。その代わりに、Summary LSA という LSA が作成され、これが外部へと
伝達されます。エリアは 32bit のエリア ID によって区別されますが (IP と同じように、1byte づつ区切っ
て x.x.x.x のように記述しても、整数で表記しても構いませんが、習慣的には IP のように表記していま
す)、0.0.0.0 のエリアだけが特別なエリアで、バックボーンと呼ばれます。全てのエリアは論理的にはバッ
クボーンに直接つながっていなければなりません (図 5.3)。
5.3. OSPF のネットワーク構成
55
図 5.3: OSPF Network
それぞれのエリアは、エリア境界ルータ (ABR: Area Border Router) によって接続されます。従って、
エリア境界ルータは常に２つ以上のエリアに所属するインターフェースを自身に持ちます。そして、エリ
ア外部に対して Summary LSA を流すのはエリア境界ルータの仕事ですし、 ABR が別のエリアへの最良
のパスを探すことになります。
同時に、OSPF が IGP である以上、外部との接続について考慮する必要があります。つまり、静的あ
るいは BGP などによって設定される外部へのルーティング情報を OSPF で管理するエリア全体に流す必
要がある訳です。このような外部と接続されたルータを AS 境界ルータ (ASBR: AS Border Router) と呼
び、AS 境界ルータが OSPF のエリア全体に対して、外部接続情報 (AS external LSA) を流すようになって
います。つまり、これもエリア全体に流される特別な LSA になっています。(最低でも一つの AS external
LSA が取り込まれていなければ外部へと接続できない事になります。)
1. AS 自律システム (Autonomous System)
企業、大学、あるいはプロバイダーのような単一の組織で運営されているネットワーク単位を AS と言います。
従って、インターネットは AS の集合であると言えますし、同時に AS は階層化されてインターネットを形成し
ているとも言えます。
5.3.1
バックボーンとエリア
OSPF では、必ず一つのバックボーンがあり、全てのエリアはこのバックボーンへと繋がっていなけれ
ばなりません。その理由は、バックボーン 0 に 1,2 のエリアがあるような場合、エリア 1 の内部へのルー
ティング情報は、エリア 1 の ABR の SummaryLSA を使ってエリア 2 の ABR へと伝達されるからです。
もし、エリア 2 の背後にエリア 3 があったとしても、その経路情報はバックボーンには伝達されません。
第5章
56
OSPF
図 5.4: 仮想リンク
従って、エリア 3 が直接バックボーンに繋がっているかのように見せかける仕組みが別に用意されてい
ます。これが仮想リンクです。仮想リンクを使うとエリア 3 のルータ R3 は SummaryLSA を R1 への仮想
リンクを使って、バックボーンに流す事が出来、それによってエリア 2 などのルータもエリア 3 を知るこ
とが出来るようになります。(但し、コスト計算は別にきちんと行われます。)
このようにエリアに分割することで、LSDB の大きさを小さくし、より効率的にする事が出来ますが、良
く考えればすぐに分かるように、これは全てのネットワークの状態を OSPF ルータが知っているという事
からは少し外れてしまいます。実際先の例では、エリア 2 のルータ R2 は、エリア 1 の内部の詳細や、エリ
ア 3 の詳細は知りません。何故ならば、それに関する Network LSA も Router LSA も流れて来ないから
であり、知り得ることは Summary LSA のみだからです。従って、エリア間に関しては OSPF は実は距離
ベクトル型として動いている事になります。バックボーンに関する OSPF の制約はここに起因しています
(必ずエリアがバックボーンに接続されているという要請によって RIP のような問題の発生を抑制してい
る訳です)。このような訳ですから、OSPF の管理領域をエリアに分けるべきか否かは実は非常に難しい問
題です。全てが一つのエリア (つまりはバックボーン) ならば、OSPF 本来の有利さを発揮出来ますが、効
率が落ちます。ただ、一つ言えるのは、’90 年の前半でエリア一つにつき 200 台以下であった方が良いとい
う議論や、メーカによっては数十台以下にと言った話があった事に対して、今の能力を持ってするならば、
大抵の場合ではエリアを分割する資源能力での必要性はないのではないかと思えます。但し、エリアに分
割する利点はもう一つあります。それはエリアに分割する事で、そのエリア内部の管理責任を分割出来る
事です。これは実際に、あるエリア内部の問題は Summary されることにより、外部に伝播しづらくなり、
分割統治が可能になります。但し、これも OSPFv3 では複数の OSPF を動作させ、それらが接点を持つよ
うなモデルも可能になっていますので、どちらを取るのが最適かはまだ議論が残っていると思われます。
5.4. ospfd の設定
5.4
57
ospfd の設定
ospfd デーモンの設定も OSPF 特有の部分を除いては zebra と共通です。
! OSPFDd config
!
hostname pcs001-ospfd
password zebra
enable password zebra
service password-encryption
log file /var/log/ospfd.log
!
router ospf
ospf router-id 202.11.99.9
network 202.11.99.8/29 area 0
network 10.254.8.0/24 area 0
!
line vty
この例では、router ospf 以降が OSPF 特有の設定です。
以下それぞれについて解説します。
1. router ospf
OSPF を使うときには必ず指定しなければなりません。
2. ospf router-id <32bit 整数 >
Router ID を決めます。慣例としては、Router の IP アドレスをつけますが、32bit の (非負) 整数な
らばなんでも問題はありません ( IP と同じ記法で、x.x.x.x と書いても構いません)。この RouterID
は、designated router(代表ルータ) がダウンし、バックアップ代表ルータが昇格した時の後釜のバッ
クアップ代表ルータを決めるために用いられます。大きい値の方が優先です。ちなみに、代表ルータ
やバックアップ代表ルータは、立ち上げ順です。また、ip ospf priority はこの値よりも優先されま
すが、インターフェース毎に決めなければなりません。
3. network <network/mask> area <area ID>
OSPF で管理するネットワークアドレスと、そのエリア番号を指定します。network を指定しなかっ
た場合には、OSPF ルータとしては機能しません (データベースの維持などは行う筈ですが)。エリ
ア番号 0 はバックボーンです。 エリア番号は 32bit の (非負) 整数で指定します。
これらの設定のみを見ていると少し分かりづらいですが、ospfd の設定 (実は Quagga 全体がそうですが)
では、いくつかのセクションに設定が分かれています。これらのセクションは VTY で設定するときの状
態遷移に丁度対応しています。VTY での設定では、設定のための状態は config モードと、router モード
interface モード、line モードなどに分かれ、設定ファイルのセクションではそれらを対応するコマンドが
あればそこから先が指定のセクションとなり、別のコマンドがあれば指定のセクションに切り替わります。
通常、設定ファイルでは次の順序で記述しています (VTY モードでファイルへ write するとこの順序で書
かれます)。
第5章
58
OSPF
! ospf config
!
[ 何もない最初のセクションではコマンドを書く ]
!
interface fxp0
[ fxp0 のインターフェースセクション ]
...
!
interface rl0
[ rl0 のインターフェースセクション ]
...
!
router ospf
[ ospf ルータセクション ]
!
line vty
[ VTY の設定セクション ]
インターフェースセクションは、ホストに存在するインターフェース全てを列挙しても構いませんし、必
要なもののみを書いても構いません。また、全く書かない場合にはデフォルトの動作をします (IP などが
設定されていて、up していたら取り込まれる)。
また、最後の VTY の設定セクションでは、どのアドレスから VTY に入れるなどの設定が可能ですが、
ここでは取り上げません (実は、zebra などと共通の機能です)。
ちなみに、Quagga では設定の削除はほとんどの場合、no を頭につけるだけで出来ます。
5.4.1
ospf router のその他の設定
ospf router セクションで有効なその他の設定を見てみましょう。(重要なもののみにしぼります)
1. passive-interface <interface name>
そのインターフェースに対して受動モードを指定します。受動モードでは、受信したパケットは通常
通りに処理されますが、特別に近隣ルータなどを指定していなければ、ユニキャストもマルチキャス
トパケットも出しません。
2. auto-cost reference-bandwidth <1-4294967>
通常、OSPF のコストはバンド幅によって自動的に計算されます (勿論、後に述べるように手動で設
定も出来ますが)。その際の計算には大体以下の式を用います。
コスト =
N
バンド幅 (M bps)
つまり、N が 1000 で、バンド幅が 100M のネットワークならば、コストは 10 と計算出来る訳です。
これによって、バンド幅が 10M のネットワークのコストは 100 になりますから、経路選択でコスト
5.4. ospfd の設定
59
10 と コスト 100 の選択ならばトータルで小さな方を選ぶことが出来ます。但し、注意しなければな
らないのは、全ての OSPF のエリアでこの N は同じでなければなりません。そうでなければ正しい
経路選択は出来なくなります。では、この N をいくらにすれば良いかですが、以前は 100 に設定さ
れていたようです。しかし、すぐに分かるように 1Gbps のネットワークが出て来ると、整数計算で
は０になり、意味がなくなります。そこで最近では N にはデフォルトで 1000 が使われているようで
す (というか、N に最初から 10 がかけられている)。ところが、これも 10G とかが出て来ると意味
がなくなって来ますので、なかなか難しい問題です。
という訳で、 ここで設定されるのは計算式の分子の N ∗ 10 になっている N を設定出来ます。
3. area <area ID> virtual-link <router ID>
仮想リンクを張る際に用います。area ID は IP アドレス記法 (x.x.x.x) でも、32bit(非負) 整数でも構
いません。バックボーンに接続されていないエリアを指定します。次に、router ID にはバックボー
ンの ABR(Area Border Router) であるルータの ID を指定します。ID は IP 記法でも、整数でも同
じく構いませんが、IP アドレスではなく、あくまでもルータの ID である点に注意して下さい。
同時に、この指定は指定された ABR 側でもしなければなりません。仮想リンクは一種のトンネルな
ので、トンネルの両端で同じように設定しないと片方のみが流れても機能しないからです。
4. default-information originate
外部に接続している ASBR(AS 境界ルータ) が、AS external LSA を default ルーティングを元にし
て流すための設定です。ASBR のみで設定します。
5.4.2
ospf と rip の同時利用
OSPF で学習した内容を RIP を用いて伝播させることが出来ます。このような手法の利点は、安価な機
器で RIP のみしかサポートがないような機器を利用している場合でも、 RIP の限界に制約されません。勿
論、このような場合、RIP で学習した内容を OSPF に流す事も出来ます。
Quagga では、rip や ospf は zebra のルーティングテーブルからそれぞれのルーティング情報を学習し、
それぞれのプロトコルで伝播することが出来ます。
この際に必要な設定は主に次の２種類です。
1. redistribute rip
ospf において、rip が zebra に伝達したルーティング情報を再度 ospf に取り込み、OSPF のルーティ
ング情報として、再度配布するための設定です。zebra が取り込んだ rip の全てのルーティング情報
が対象になります。
2. redistribute connected
ospf でも rip でも、指定されたインターフェース、あるいはネットワークに含まれる情報を自動的
に取得し、ルーティング情報に含める事が出来ます。しかし、あるルータの一方の足が ospf で、他
方が rip のような場合には、ospf から見ると rip の方は指定されていないので自動的には取得しませ
ん。ここで注意するのは、rip 自身も自分の足のインターフェースについて情報は zebra に上げるこ
とはないという事です。従って、ospf 側でそのインターフェースを OSPF のエリアに含めていない
ような場合にこの設定が役に立つでしょう。
第5章
60
OSPF
1. rip での設定
ここまでの設定では、rip は ospf からの情報を受け取れません (先の設定で rip の情報を ospf は受け
取りますが)。そこで、rip が ospf の情報を受け取るようにしますが、これは実は設定としては先に
掲げた redistribute をそのまま ripd.conf でも使えますので、説明は省きます。
(a) redistribute ospf
(b) redistribute connected
5.4.3
interface の設定
インターフェースでは OSPF の細部に立ち入ったいくつかの設定がありますが、OSPF の構造をきちん
と理解せずに設定してはいけません。そこで、ここでは、そうした問題の少ない設定のみを取り扱います。
1. ip ospf priority <0-255>
この値が大きい程、そのセグメントでの代表ルータ (あるいはバックアップ代表ルータ) になりやすく
なります。デフォルトは１です。0 にすると、代表ルータには絶対になりません。実際、代表ルータ
はそれなりに負荷が高いので、非力なホストは代表にはならないように設定した方が良いでしょう。
また、逆に強力なマシンは最大に上げておくとほぼ代表ルータになります。
2. ip ospf cost <1-65535>
そのインターフェースのリンクコストを設定します。通常は自動的に計算されますが、例えば同じ早
さの経路があり、どちらかを優先させたい場合には、優先させたい方のリンクコストが標準通りに
10 だとするならば、他方を例えば 11 などに設定することによって、コスト 10 が優先されるように
なります。但し、OSPF におけるコストは経路に沿ってコストの和で決定されるので、どこかの経路
に例えば 9 のコストの経路があると、11 との和では優先性がなくなる (その 9 と 11 の和が 20 で) と
いうこともあります。
5.5
OSPF の動作の確認
OSPF の動作の確認にはいくつかの注意が必要です。まず、OSPF が正しく動いた結果の経路の変化に
ついて理解していなくてはいけません。次に、それらの経路を実際に確認することが必要になります。そ
の際に、利用するコマンドが traceroute です。他の章で解説したように traceroute は UDP パケットの
TTL を１つづつ大きくしながらネットワーク上に送り、返って来た ICMP の unreachable を見て、経路
を表示します。従って、原理的に往路の経路を調べている事になりますので、往路と復路が異なる場合に
は、両方で調べないといけません。勿論、往路と復路が同じ場合であっても、両端で調べるのは基本です
が (OSPF ではこうしたことが簡単に起こってしまいます)。
次に、同じネットワーク内の OSPF ルータが経路の変更に伴い、他の OSPF ルータに変わった場合には
注意が必要です。何故ならば、クライアントはデフォルトルータを静的に設定しているために、経路の変更
は ICMP redirect によってなされます。ところが、経路が復旧しても、クライアントは一定時間は ICMP
redirect の結果を保持しますので、クライアントから見た経路が元に戻るまでにはそれなりの時間がかかっ
てしまいます。こうした場合には、明示的にクライアントのルーティングテーブルをフラッシュする必要
5.5. OSPF の動作の確認
61
があります (なお、OSPF などの動的ルーティングプロトコルが走っていない場合にはテーブルが消えます
ので、default は最低再設定が必要です)。
# route flush
また、OSPF は収束性が良いと言っても、経路の復元や、リンク断の検出などにはそれなりの時間がか
かります。こうした場合に役立つのが、ospf の持つ各種の情報です (実際には LSA です)。まず、こうした
情報を確認し、同時にインターフェースの状態をチェックした後で、設定の不具合を疑って下さい。
以下では、実際に ospf の出す情報について少し見て行くことにします。
ospfd の VTY に入っているとします (view モードでも特権モードでもどちらでも構いません)。
1. show ip ospf
OSPF の現在の状態を表示する。
以下は実行例である。
ospfd# show ip ospf
OSPF Routing Process, Router ID: 202.11.99.9
Supports only single TOS (TOS0) routes
This implementation conforms to RFC2328
RFC1583Compatibility flag is disabled
SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
Refresh timer 10 secs
Number of external LSA 1
Number of areas attached to this router: 1
Area ID: 0.0.0.0 (Backbone)
Number of interfaces in this area: Total: 2, Active: 4
Number of fully adjacent neighbors in this area: 3
Area has no authentication
SPF algorithm executed 40 times
Number of LSA 9
最初に RouterID があり、AS external LSA が一つ保持して、このルータには一つのエリアがあるこ
と、そしてそのエリアは areaID:0 のバックボーンであることが分かる。同時に、隣接ルータが３つ
このエリアにあり ( Number of fully adjacent neighbors in this area:)、格納されている LSA が９個
であることが分かる。
2. show ip ospf interface
ホストのインターフェースと、そこに結合されたリンクの状態を表示する。
ここで表示されるのは少し長いので分割して、ゆっくり見てみよう。
第5章
62
OSPF
ospfd# show ip ospf interface
rl0 is up, line protocol is up
Internet Address 202.11.99.9/29, Area 0.0.0.0
Router ID 202.11.99.9, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 202.11.99.9, Interface Address 202.11.99.9
Backup Designated Router (ID) 202.11.99.10, Interface Address 202.11.99.10
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:01
Neighbor Count is 2, Adjacent neighbor count is 2
まず、インターフェース rl0 に関する情報のみを掲げた。ここから rl0 は 202.11.99.9/29 の IP アド
レスを持ち、area 0 に属していて、RouterID は 202.11.99.9 で、リンクコストは 10 であることが
分かる。
State DR の表示から、自身が代表ルータ (DR) であることが分かります。
一方、Backup DR は 202.11.99.10 であることが、その下の行の記述から分かります。その下の
Timer intervals はこれまで説明して来なかったが、Hello パケットの間隔が 10 秒毎で、隣接ルー
タへのリンクが落ちているか否かの Dead の判断が 40 秒 (Dead の値を使って WaitTimer が設定さ
れる)、応答のないルータに対して LSA を再送するまでの時間が 5 秒であることが分かります。これ
らの時間は設定で変更出来ますが、全てが同じ設定でなければなりません。従って、これらの値の変
更はあまり推奨されていません。
最後に、近隣ルータの数が２で、それらの近隣ルータとは完全な隣接関係 (adjacent neighbor) であ
ることが分かります (adjacent neighbor はデータベース同期を完了しているルータです。これが近
隣ルータの値と異なっていると同期が完了していないか、同期に失敗している可能性があります)。
次の情報は fxp0 についてのものです。
fxp0 is up, line protocol is up
Internet Address 10.254.8.13/24, Area 0.0.0.0
Router ID 202.11.99.9, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State Backup, Priority 1
Designated Router (ID) 202.11.99.81, Interface Address 10.254.8.111
Backup Designated Router (ID) 10.254.8.13, Interface Address 10.254.8.13
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:02
Neighbor Count is 1, Adjacent neighbor count is 1
rl0 との違いは、DR が 10.254.8.111 (ID 202.11.99.81 ) で、自分が Backup DR になっていること
が分かります (自身の IP アドレスと Backup Desinated Router との IP アドレスが等しい事から分
かります)。
その他の情報は、自身のループバックインターフェース (lo0) を除いて、全てリンクがないものの情
報です。
5.5. OSPF の動作の確認
63
faith0 is down, line protocol is down
OSPF not enabled on this interface
lo0 is up, line protocol is up
OSPF not enabled on this interface
ppp0 is down, line protocol is down
OSPF not enabled on this interface
sl0 is down, line protocol is down
OSPF not enabled on this interface
3. show ip ospf neighbor
このコマンドは近隣ルータを表示します。
ospfd# show ip ospf neighbor
Neighbor ID
Pri State
202.11.99.10 1
202.11.99.33 1
202.11.99.49 1
Dead Time Address
Interface RXmtL RqstL DBsmL
Full/DROther 00:00:32 202.11.99.10 rl0:202.11.99.9
Full/DR
00:00:32 10.254.8.32 fxp0:10.254.8.32
0
0
0
0
0
0
Full/Backup
0
0
0
00:00:34 10.254.8.49 fxp0:10.254.8.32
この表示で重要なのは、State が Full か twoway のどちらかでなければならない点です。通常、近隣
関係は Full あるいは twoway(DR とだけ通信している) かのどちらかです。それ以外の場合は近隣
関係に問題があると思って良いでしょう。勿論、近隣に DR がない場合や、Bakcup がない場合も問
題があります。
4. show ip ospf route
これは ospf のルーティングテーブルを表示します。もし、ここに本来あるべき経路がなかったなら
ば、その LSA が届いていないことになります。従って、LSA の伝播を発生源から順に追いかけてみ
る必要があります。恐らく、どれかの DR が公告していないのが理由です。公告をしないのは、いく
つもの原因が考えられます。インターフェースや、リンクなど基本的な接続にまで遡って、調査が必
要です。
更に、最後とその一つ手前のテーブルから、 AS external LSA が 202.11.99.81 によって生成されて
いると考えられます。
第5章
64
OSPF
ospfd# show ip ospf route
============ OSPF network routing table ============
N
202.11.99.8/29
[10] area: 0.0.0.0
directly attached to rl0
N
202.11.99.16/24
[10] area: 0.0.0.0
directly attached to fxp0
N
202.11.99.24/24
[10] area: 0.0.0.0
directly attached to fxp0
N
202.11.99.32/24
[10] area: 0.0.0.0
directly attached to fxp0
============ OSPF router routing table =============
R
202.11.99.254
[10] area: 0.0.0.0, ASBR
via 202.11.99.81, fxp0
============ OSPF external routing table ===========
N E2 0.0.0.0/0
[10/10] tag: 0
via 202.11.99.81, fxp0
5. show ip ospf database
最後に LSDB(LinkStatus Database) 全体を表示するのが、このコマンドです。
異常の際には、バックボーンのルータでは全てのルータからの LSA が来ているかどうかや、あまり
にも古い Age の LSA がないかなどを見ます。
Age は LSA 発行からの経過時間 (秒単位) を表します。OSPF では、LSA の寿命は 3600sec(1 時間) ですが、通
常 30 分 (1800sec) 経つと発行元が新しい LSA を出す筈です。時間は OSPF では少しいい加減ですので、正確
に 1800sec ではありませんが、1 時間近く経っても来ない場合にはその発行について調査した方が良いでしょう。
5.5. OSPF の動作の確認
65
ospfd# sh ip ospf database
OSPF Router with ID (202.11.99.17)
Router Link States (Area 0.0.0.0)
Link ID
202.11.99.9
ADV Router
202.11.99.9
Age Seq#
CkSum Link count
960 0x80000019 0x193f 2
202.11.99.17
202.11.99.25
202.11.99.17
202.11.99.25
460 0x80000017 0x6a32 2
959 0x80000013 0xaf6b 2
202.11.99.33
202.11.99.33
971 0x80000006 0x0d60 2
202.11.99.41
255.0.0.2
202.11.99.41
255.0.0.2
459 0x80000018 0xfb12 2
968 0x8000001a 0xea04 2
Net Link States (Area 0.0.0.0)
Link ID
ADV Router
Age
Seq#
CkSum
202.11.99.9
202.11.99.17
202.11.99.97
202.11.99.17
955 0x80000005 0xed45
459 0x80000004 0x2264
202.11.99.81
202.11.99.81
968 0x80000008 0x1d23
AS External Link States
Link ID
0.0.0.0
0.0.0.1
ADV Router
202.11.99.81
Age Seq#
CkSum Route
367 0x80000004 0x8fbc E2 0.0.0.0/0 [0x0]
第5章
66
5.6
OSPF
演習課題 1
演習 5.1 ます、Quagga が走っていれば、それを止めなさい。また、/usr/local/etc/quagga/ripd.conf
を別の名前に変更し、RIP が走らないようにしなさい。また、他のグループとのケーブルは抜いて、グルー
プ内部のみで、全員 ospf を走らせるための準備をせよ。
演習 5.2 マスターは、default-information originate と、passive-interface ue0 を設定し、OSPF
でデフォルトルートを伝播させるようにしなさい。
全員、Router-ID は、内部ネットワーク ( 172.16.N.M ) のインターフェース IP に設定しなさい。
全員で OSPF を走らせ、OSPF の情報を確認しなさい。
演習 5.3 グループ内で全員 OSPF が動いたら、show ip ospf neighbor の結果を提出しなさい。
演習 5.4 次に、上の課題が終わった (OSPF が無事に動いた) グループとの接続をしなさい。当然、OSPF
の設定をしておかなければなりません ( 172.17.X.Y のネットワークの設定が必要です)。２つ以上のグ
ループとの接続ができ、OSPF で経路情報が交換されていれば、全員 sh ip ospf route の結果を提出し
なさい。
67
第 6 章 BGP
これまで、RIP,OSPF と学習をしてきましたが、最後に学ぶ BGP はこれらのものと違って EGP として
設計されています。そのために、少し IGP と趣きが異なるので注意してください。
6.1
BGP 概略
BGP は、先に説明したように距離ベクトル型のアルゴリズムを採用していますが、経路情報にその経路
情報が通ってきたパスの情報を追加するので、パスベクトル型のアルゴリズムとも言われています。BGP
は RFC1771 にその基本機能が、RFC2545,2283 に拡張機能 (IPv6 などへの対応) が決められています。
BGP が BGP の情報を交換する際に重要な概念として、自律システム (AS: Autonomous System)
があります。AS は単一の経路ポリシーを持ったネットワーク組織と解釈されています。AS には、いくつ
かのルータがあり、AS は他の AS と境界ルータ (BR: Border Router) によって接続しています。BGP は、
こうした AS 同士が自らのポリシーや、両者の合意に従って経路情報を交換し、パケットを転送するため
に作成されています。このために、複数の AS が接続されていた時に、お互いの AS 間の情報はやりとりし
ても、他の AS の第三者の AS への通信が自分のネットワークを途中経路として利用するような、言わば
通過 (transit) を許可しないようなポリシーを定義することが出来ます。
BGP では信頼性のある方法で情報交換を行うために、TCP を用います (port179 番)。このことは、BGP
ルータは非 BGP ルータを越えて BGP のメッセージを伝達できることを示しています。また、TCP で提供さ
れる全ての信頼性を享受できるので、BGP が独自に提供するのは、相手の生存を確認すること (KeepAlive)
や、エラー時の伝達だけ (Notification) で済みます。一方、BGP は BGP ルータ間の情報伝達を行うため
に、情報伝達を行うと決めた隣の BGP ルータ (ピアリングと言う) 全てと BGP セッションを張る必要が
あります。このピアリングを張ったルータ間を BGP メッセージが、それぞれの BGP ルータの情報が付加
されたり、他の情報とマージされて、伝達されていきます。そうした意味で距離ベクトル型のアルゴリズ
ムを採用していますが、同時にそのパス情報の中に様々な属性と呼ばれる値をエンコードすることにより、
BGP ではポリシーに従った経路選択や、ループの排除、通過の許可などを行えるようになっています。
パス情報は、それぞれの AS の番号 (2byte) の順序列、あるいは集合で構成されます (何故集合がこの情
報に含まれるかは後で説明します)。
BGP では伝統的に特別な用語がいくつかあるので、それを先に解説しましょう。
• RIB(Routing Information Base) 経路制御表と同じ意味だが、 BGP 内部に蓄積されているものを
指す
• ASN AS 番号 (世界で唯一であることが必要)
• BGP スピーカ BGP 情報を話すノード (ルータでない場合もある)
• トランジットサービス パケットを自 AS を単に通過させるサービス
• ルート 宛先情報とパス属性情報の組
• プレフィックス 集約された宛先情報 (例 202.11.0.0/16 )
第6章
68
6.2
BGP
BGP セッションとメッセージ
BGP セッションは、ピアリング関係にある隣接 BGP ルータと TCP によるセッションを確立し、各自の
識別メッセージ (ASN,RouterID) やその他のパラメータを交換することで確立されます。一旦セッション
が確立されると、BGP セッションはほとんどつながったままで、BGP メッセージをお互いに交換します。
BGP メッセージは、最初は全ての経路情報などを載せて送りますが、その後は変更のみを通知します。受
け取る側は、受け取っても自 AS のポリシーに合わなければ利用しなくても構いません。また、受け取っ
た BGP メッセージを再度別の AS に流すか否かも、そのメッセージの情報によって選択されます。
BGP のメッセージの基本タイプは以下の通りです。
• Open 最初にやり取りされるメッセージです。ASN,BGP ID などのパラメータをやり取りします。
BGP ID(4byte) には伝統的に IP アドレスが使われますが、ルーティングの設計のしやすさのため
に、ルータ内部に仮想的な IP アドレスを振り、それが BGP ID に使われることもあります (物理イ
ンターフェースと区別し、ルータそれ自体への到達性を考えたい時に良く使われるテクニックです)。
• Update プレフィックスの変更など、情報に変更が生じた時に流れるメッセージで、BGP ルータ間
で流れる情報の大部分はこのメッセージになります。この情報で、新しく学習されたプレフィックス
の広告や、存在しなくなった経路の削除などが伝達されます。また、この情報の中に同時にパス属性
情報が含まれており、これが BGP の特徴の一つとなっています。
• Notification エラーあるいはその他の特別な状態の場合に出されるメッセージで、エラーの場合に
は Notification(通知) メッセージが出されてから接続が閉じられます。
• KeepAlive 周期的に送られる生存を確認するためのメッセージです。
6.3
パス属性情報
パス属性情報は、宛先情報と並んで、その宛先に付随する様々な情報を伝達する方法です。BGP の属性
には、well-known(既知) と、optional(オプション) があります。前者は全ての BGP の実装で解釈できなけ
ればなりませんが、後者は理解できないものがあっても良いとされ、そのルータが解釈出来る出来ないを
意味するのではない点に注意してください。
パス属性には主には以下のものがあります。
• ORIGIN 属性
必須の既知属性で、伝達されたそのプレフィックスが出発点となる (Origin AS:起源となる AS)AS で
どこから学習したかを示し、以下の区別があります。
– IGP IGP から学習した。つまり、起源 AS 内部にその宛先情報がある。
– EGP EGP から学習した。つまり、起源 AS 外部にその宛先情報がある。
– INCOMPLETE 不完全な情報。つまり、他の手段で学習した。多くの場合、静的経路情報か
ら来る。
• AS-PATH 属性
必須の既知属性で、そのプレフィックス情報が通ってきたパスの情報が、ASN で表される。以下の
種別があります。
6.4. その他の機能
69
– AS SET(AS 集合) アップデートメッセージ内部の経路情報が経由した AS の順序がついてな
い集合です。これは多くの場合、経路情報が集約された場合に用いられます。つまり、ASN 10
のプレフィックス AX/24 と ASN 11 の AY/24 を集約すると、A/16 というプレフィックスにな
る場合、10 と 11 の AS は順序が付けられません (そこで分岐するから)。従って、{10,11} の
集合に対して A/16 のプレフィックスを公告するようにします。
– AS SEQUENCE こちらはメッセージの経路情報が通ってきた AS の順序列になります。
AS-PATH 属性は、以上の種別がその通ってきたパスを全て反映しているので、順序列と集合が混在
するリストになっています。つまりは、3-7-15-{10,11}-78 のように順序列と集合が並ぶことになり
ます (勿論、集約がされなければ直線的なリストとなります)。
• NEXT HOP 属性
必須の既知属性です。宛先に対する次ホップとして使うべき境界ルータを掲載します。これは、BGP
ルータでないようなルータが隣接 AS にあり、それを別のピア AS に教えるのに有効です (特に自 AS
を通らずにピア AS がそのルータに到達できるような場合)。
• MULTI EXIT DISCRIMINATOR 属性
オプション属性で、しかもピア AS 間でのみ交換され、AS を通過して伝達はされません。複数経路
で接続されたピア AS に、自 AS の背後にある別の AS への経路としてどこが最適化 (あるいはどこ
を使って欲しいか) を伝達するために利用され、メトリックを設定することでそれを達成します。
• LOCAL PREF 属性
オプション属性で、AS 内部の他の BGP スピーカに宛先に到達するための経路の優先度を伝達する
ために設定されます。例えば、AS の外部の宛先 X に到達するために、AS 内部の経路として、P,Q
があった場合、P,Q どちらを優先するべきかを値をつけて優先度を決めます。値が大きい方が優先さ
れます。
• ATOMIC AGGREGATE 属性
重複した経路を BGP スピーカがピア AS から受け取り、何らかのポリシーのために、その BGP ス
ピーカがプレフィックス長の少ない経路を選択して、公告を行う際に、その公告にこの属性をつけま
す。それによって、その公告を受け取る BGP ルータは、その宛先への経路が AS PATH にない AS
を通るかも知れないということを知ることが出来ます。
• AGGREGATOR 属性
オプションの通過属性です。アドレスを集約する際に、集約をしている AS やルータを示すためにつ
けられます。但し、使いたくない時には使わなくても構いません。つまり、集約を行ってアップデー
トメッセージを出すか否かは、AS のポリシーで決められることだからです。
6.4
その他の機能
BGP は属性拡張の自由度が高いために、この他にも色々な属性や機能が追加されてきています。例え
ば、BGP セッションはフルメッシュを要求するために、内部 BGP や、あるいは IX(Internet eXchange)
などでは多数の BGP ルータがフルメッシュでセッションを張る必要があります。すると当然これは２乗
のオーダーで増えるために性能的な問題が顕著になってしまいます。こうした問題を避けるために、BGP
セッションをフルメッシュに張らずに済ますルートリフレクタとクラスタという内部の集合体や、あるい
はそれと同じだが外部 BGP で同じことを行うルートサーバシステムなどの工夫がされています。また、切
第6章
70
BGP
断回復が激しいようなリンクのピアに対して、その経路公告を頻繁に行わないようなルートフラップダン
ピングの仕組みも考えられています。
ここではこれ以上の詳細については述べませんので、冒頭に掲げた RFC を参照してください。但し、
ウェブ上にある日本語訳には少なからず誤訳がありますので必ず原文を参照しながら読んで下さい。
6.5
bgpd の設定 1
BGP の設定は bgpd.conf にします。
以下の例では、BGP ルータがこのサイトに全部で３台あり、それぞれ IP アドレスは 202.11.99.{9,10,11}
で、以下は 202.11.99.9 のルータの設定です。外部 BGP ルータは 3 台あり、10.254.8.60 と 172.17.0.2,172.17.1.2
です。このサイトは、202.11.99.8/29 のネットワークを持っています。また、202.11.99.9 を主に使うルー
タとして設定をします。
BGP ASN は 65001 です。ピアリングしているのは図では、65010, 65002 の AS と行っています。
AS 65010
10.254.8.60
AS 65001
202.11.99.8/29
10.254.8.10
202.11.99.9
172.17.0.1
202.11.99.80/29
AS 65002
172.17.0.2
202.11.99.10
202.11.99.11
172.17.1.1
202.11.99.16/29
172.17.1.2
6.5. bgpd の設定 1
71
! BGPd config
!
hostname pc2f001-bgpd
password zebra
enable password zebra
log file /var/log/bgpd.log
!
router bgp 65001
bgp router-id 202.11.99.9
network
202.11.99.8/29
! I-BGP router
neighbor
neighbor
202.11.99.10 remote-as 65001
202.11.99.11 remote-as 65001
! prefer this route
neighbor
10.254.8.60
neighbor
!
10.254.8.60
remote-as 65010
route-map LOCAL-PREF1 in
!redistribute static
!
route-map LOCAL-PREF1 permit 10
match as-path R65010
set local-preference 200
!
ip as-path access-list R65010 permit ^65010_
! --- end of config --
以下、上の例にもとづいて解説します。
1. router bgp ASN
この BGP ルータの所属する AS の番号を表します。AS 番号は、IP アドレスなどと同じように APNIC
から取得しなければなりませんが、単一のプロバイダーなどに所属しているような場合や、 IGP と
してのみ使うような場合には、プライベート ASN が利用できます。
この例では、65001 が ASN です。
private AS number: 64512-65535
また、router セクションは他の定義が続きます。
• 参考
同じ AS 番号を持つ BGP を特別に iBGP と言います。逆に異なる AS に所属する BGP は eBGP
と言います。
2. bgp router-id BGP-ID
ルータの BGP-ID を決めます。設定をしないと、インターフェースの IP アドレスの内、もっとも
大きな番号のものが自動的に振られます。但し、zebra を動かさず、bgpd のみを動かしていると、
第6章
72
BGP
zebra からインターフェースの情報を取れませんので、注意してください。また、先に説明したよう
に、ループバックアドレスに仮想的なアドレスを振ることもされます。これは、インターフェースが
ダウンした場合の対策です。
3. network IPaddress/prefix
このルータが他のピアルータに公告を行うネットワークを書きます。
4. neighbor IPaddress remote-as ASN
ピアリングを行うルータを全て指定します。 neighbor で指定されないルータとはピアリングをしま
せん。IP address で指定しなければいけません。また、ASN も書きます。なお、iBGP と eBGP の
区別はなく、ASN から自動的に外と内の区別がされます。
5. neighbor IPaddress route-map NAME [in | out]
ここに指定したピアルータから入っていくる (in)、あるいは出て行く (out) アップデート情報に対し
て、属性を付けます。つける属性は様々な組み合わせや、プレフィックスによる選択が可能なように
別の定義に書きます。この定義は route-map の後ろに指定した名前 (NAME) を使って、結合しま
す。route-map コマンドは後で説明します。
6. neighbor IPaddress ebgp-multihop hop-count
もし、eBGP のピアルータが隣になく、幾つかのルータをホップして接続されるならば、TTL(TimeToLive)
を大きくする必要があります。eBGP では標準では、TTL は 1 に設定されているので、適切な TTL
になるように、hop-count を指定します。
neighbor 202.11.98.67 ebgp-multihop 3
これで、TTL は 3 に設定されます。
7. redistribute other-proto
カーネルのルーティングテーブルや、静的な設定、あるいは他の RIP や OSPF で学習したプレフィッ
クスを再配布する場合に、other-proto に指定します。但し、IGP で学習したものを再配布するのは原
則的には行わない方が良いでしょう。コメントアウトされた行では、静的に設定されたルートを再配布
していますが、必要かどうかを良く考えてから設定をして下さい。other-proto には、static,kernel,
connected, rip, ospf などが設定できます。
8. route-map NAME [permit|deny] seq-num
ルートマップセクションの始まりを表します。名前 (NAME と順序番号 (seq-num) を与えます。ルー
トマップで設定された内容は全てのアップデートメッセージに対して、適用するか否かが考慮された
上で、順にセクション内に記述された set コマンドを実行するか (permit)、あるいは実行されません
(deny)。
9. match cond ac-list-name
この route-map セクションに合致するものを指定するための条件文です。cond には以下のようなも
のが指定可能ですが、通常は ip か as-path でしょう。
6.5. bgpd の設定 1
73
as-path
AS パスリスト
community
extcommunity
BGP コミュニティリスト
BGP/VPN 拡張コミュニティリスト
ip
ipv6
IPv4
IPv6
metric
origin
ll
ルートメトリック
BGP オリジンコード
ac-list-name には、アクセスリストの名前を指定します。
10. set attribute-command
属性を設定します。attribute-command には多くの属性設定コマンドがありますが、ここではローカ
ルプリファレンス ( local-preference) を設定しています。
set local-preference <0-4294967295>
local-preference の後ろには、値を指定します。ローカルプリファレンスでは大きな値ほど高い優先
順位になります。ここでの例では、ピア eBGP ルータから入ってくる情報全てにローカルプリファ
レンス属性をつけていますが、10.254.8.60 からのアップデート情報のルーティングを優先させるた
めに、それに高い値をつけて内部のピアルータにアップデートメッセージを送っています。当然、内
部の他のピアルータは 200 より低い値をつけて、他のアップデートメッセージを流すようにしないと
いけません。(デフォルトでは 100 がつきます。)
(a) タイブレーク
AS パスが同じで、どちらかを優先するような条件 (例えばこの local-preference) がないような場合をタ
イブレークと言います。タイブレークになった場合には、タイブレークルールが適用され、どちらを利用
するかを決定します (RFC1771)。
11. ip as-path access-list ac-list-name [permit|deny] reg
条件に一致する AS パス情報を選びます (permit)。あるいは、deny ならば一致するものは除外され
ます。上の例では、ac-list-name を使って route-map セクションの match コマンドで引用をしてい
ます。reg には、正規表現を用いた ASN の指定が出来ます。また、AS パスの表現では、アンダース
コア (_) でパスの途中を表しますので、以下のような表現が可能です。なお、AS パスは先頭にもっ
とも近いピアの ASN が入り、最後には起源 ASN が入ります ( つまりは常に先頭に自分の ASN を追
加する)。
指定
意味
^65000_
_5600_
パスの先頭に 65000 がある。
_100$
パスの最後に 100 がある。
パスの中に 5600 がある。
これに対して、202.11.99.10 の BGP ルータの設定は以下のようにします。但し、AS65002 とピアを張っ
ています。
第6章
74
BGP
! BGPd config
!
hostname pc2f002-bgpd
password zebra
enable password zebra
log file /var/log/bgpd.log
!
router bgp 65001
bgp router-id 202.11.99.10
network
202.11.99.8/29
! I-BGP router
neighbor
neighbor
202.11.99.9 remote-as 65001
202.11.99.11 remote-as 65001
!
neighbor
172.17.0.2 remote-as 65002
neighbor
!
172.17.0.2 route-map LOCAL-PREF2 in
route-map LOCAL-PREF2 permit 20
match as-path R65002
set local-preference 150
!
ip as-path access-list R65002 permit ^65002_
実は、ここまでの例では十分でない点があります。それは、BGP では AS は一つのエンティティとして
考えられる事に起因し、iBGP 間では NEXT-HOP が変更されません。実際、外部ネットへの NEXT-HOP
として、202.11.99.9 は 10.254.8.60 を受け取ります (eBGP 間では NEXT-HOP は BGP が適切に処理し
ます)。これを、202.11.99.9 の BGP ルータはそのまま処理するので、このメッセージを受け取った他の
iBGP ルータは 10.254.8.0/24 がどこにあるかを予め知っておかなければならないのです (解決できない場
合には、RIB(Routing Information Base) にも載りません)。
この解決方法は３つ考えられます。１つは BGP が iBGP に対しても適切に NEXT-HOP を処理する
ようにする。２つめは静的に設定を行うことです。最後に、３つめは IGP(RIP や OSPF) を利用して、
202.11.99.9 の外側インターフェースのアドレスを学習・伝播させることです。
静的に設定する場合には、
# route
add -net
10.254.8.0/24 202.11.99.9
をホストに設定をします (勿論、他の 172 のネットについても同様です)。
Quagga の RIP や OSPF を使う場合には、202.11.99.9 の外側インターフェースの存在を学習させるた
めに、redistribute connected (11.4.2 参照) を ripd.conf あるいは ospfd.conf に追加する点を忘れない
で下さい。
最後に、BGP で適切に NEXT-HOP を処理させるには、router bgp セクションの中に以下の設定を加
えます (接続している iBGP 全てに指定して下さい)。
6.6. bgpd の設定 2.
75
!neighbor
neighbor
202.11.99.9
202.11.99.10
next-hop-self
next-hop-self
neighbor
202.11.99.11
next-hop-self
1. next-hop-self
通常、iBGP は受け取った NEXT-HOP 属性を書き換えずに他の iBGP に伝達します。これを強制的
に自分のアドレスに NEXT-HOP 値を書き換える役割をします。
bgpd の設定 2.
6.6
先の設定では、自分の AS から出て行くパケットについては、202.11.99.9 を優先させていますが、外部
ピアに関してはそのポリシーは反映されていません。つまり、外部から 202.11.99.8/28 に来る際にどの入
り口を使うかは、ネットワークのコストに応じて自動的に決まります。しかしながら、メインの入り口を
一つに決めたい場合には、ピア AS に MED(Multi-Exit-Descriminator) 属性値を設定することでそれを知
らせますが、MED はピア AS にしか伝わりません。そこで、もしネットワーク全体に対してそれを伝えた
い場合には、少し工夫が必要です。
ここではネットワーク全体に通知する設定について述べます。BGP は DV 型ですので、基本的はコスト
はパスが短いものを優先させます。そこで、外部にある特定の入り口を選択させるように、外に流すアッ
プデートメッセージで、自分のネットワークの通常使いたくない BGP ルータが出すメッセージのパスを
長くするようにします。
勿論、主に使いたい BGP ルータの方ではこうしたテクニックは使いません (つまりは、ここから発せら
れるメッセージのパスが最短になるようにします)。
以下では、先の設定との違いのみを掲げます (先の設定に追加するだけです)。
! BGPd config
!
hostname pc2f003-bgpd
中略
!
!
neighbor
172.17.1.2 route-map LOCAL-PREF2 in
! 以下の行で、出て行くメッセージを指定する
neighbor
172.17.1.2 route-map LONG-PATH
out
!
!
中略
! パスを長くする
route-map LONG-PATH permit 40
match ip address MYNET
set as-path prepend 65001 65001 65001 65001
! 自分のネットワークの情報のみ
access-list MYNET permit 202.11.99.8/29
(上の設定はメインではないルータに設定する点に注意して下さい。)
設定内容は以下の通りです。
第6章
76
BGP
1. access-list ac-list-name [permit|deny] ip-range
条件に一致する IP アドレスを選びます (permit)。ac-list-name に番号を使う場合には注意してくだ
さい (別の使い方をします)。名前で設定すると良いでしょう。ip-range は、プレフィックス長を指定
した書き方が使えます。
2. match ip address ac-list-name
先に指定した IP の範囲にマッチした場合条件が満たされます。
3. set as-path prepend AS-list
パスに AS-list を追加します。ここでは念のために、65001 を 4 つ追加します ( 何故ならば、202.11.99.10
のホストも同じように AS path を長くしており、上の例のホストは 3 つのゲートウェイの内、一番最後
に選択されるようにしたいからで、202.11.99.10 のホストは 65001 を 2 つ追加しているものとします)。
そのために、このアップデートメッセージを受け取った AS は、パスに 65001,65001,65001,65001,65001
が入っているのを発見するでしょう (5 つめはデフォルトで挿入される自 ASN です)。一方、主なゲー
トウェイにしたいルータから出たメッセージのパスには、65001 が１つだけしか入っていません ( 2
番目のゲートウェイから出たパスは 65001 が 3 つ入っているでしょう)。それによって、これらのメッ
セージを受けた BGP ルータは、202.11.99.8/29 への経路として、もっとも短いパスを選択すること
になります。勿論、このゲートウェイに何かがあった場合には、次の選択として、長いパスを流して
いる BGP ルータを経路として選ぶことになります。
4. 注意
外向けのフィルタで注意することは、自 AS の AS 番号はフィルタを通った後から追加される点です。
従って、自 AS から出る情報を引っ掛けるために自 AS 番号で AS パスを指定すると引っかからない
ので注意してください。
6.7
BGP の動作の確認
BGP の動作の確認も、基本は traceroute などを使った調査になります。その上で、bgpd の VTY に入っ
て各種の状態をチェックします。但し、BGP は OSPF よりも遅いので、必ずしもすぐに設定が反映される
訳ではなく、また、他のサイトの設定ミスで狂うこともありますので、注意して下さい。
1. show ip bgp
BGP の現在の BGP テーブルを表示します。BGP テーブルには、様々なパスを経由してもたらされ
た全てのプレフィックスが表示され、実際にルーティングに使っていない情報も保持されています。
そのことによって、現在利用している経路に問題が生じた際には別の経路に切り替えることが出来る
訳です。
6.7. BGP の動作の確認
77
bgpd# show ip bgp
BGP table version is 0, local router ID is 202.11.99.9
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
* i202.11.99.8/29
* i
Next Hop
Metric LocPrf Weight Path
202.11.99.11
202.11.99.10
*>
0.0.0.0
*>i202.11.99.16/29 10.254.8.45
0
0
0
0
100
100
200
0 i
0 i
32768 i
0 65002 i
Total number of prefixes 2
ここで採用された経路 (ベストルート) の頭には > が付きます。その他のルートもあれば表示されま
す。Next Hop には、そのネットワークにマッチするパケットの転送先が表示され、ローカルに生成
された情報の場合には 0.0.0.0 が表示されます。LocPrf は、ローカルプリファレンスの値です。次
の Path が、パス属性のリストです。最後に、’i’,’e’,’ ?’ のいずれかのオリジン属性が表示されます。
それぞれ、IGP(Internal-GP)、EGP(External-GP) からの学習で、’ ?’ は Incomplete(静的その他か
ら) です。
2. show ip bgp IP[/prefix]
指定した IP ネットワークに対する BGP テーブルのエントリを表示します。先のテーブルで見づら
い場合にはこちらで見ると良いでしょう。
bgpd# show ip bgp 202.11.99.16/29
BGP routing table entry for 202.11.99.16/29
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Not advertised to any peer
65002 65002 65002
172.17.0.2 from 172.17.0.2 (202.11.99.18)
Origin IGP, localpref 150, valid, internal, best
Last update: Thu Jun 23 14:34:44 2008
65002
202.11.99.9 from 202.11.99.9 (202.11.99.18)
Origin IGP, metric 0, localpref 200, valid, external
Last update: Thu Jun 23 14:21:00 2008
3. show ip bgp neighbors [peer-IP]
ピア BGP ルータの状態を表示します。これを見ることによって、ピアとの BGP セッションが確立
されているのかどうかなどがチェックできます。ピアルータの IP アドレスを peer-IP に指定しない
場合には全てのピアが表示されます。
第6章
78
bgpd# show ip bgp neighbors
BGP neighbor is 10.254.8.60, remote AS 65010, local AS 65001, external link
BGP
BGP version 4, remote router ID 202.11.99.81
BGP state = Established, up for 00:18:25
Last read 00:00:25, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received (old and new)
Address family IPv4 Unicast: advertised and received
Message statistics:
Inq depth is 0
Outq depth is 0
Sent
1
Rcvd
1
Notifications:
Updates:
0
1
0
1
Keepalives:
Route Refresh:
37
0
33
0
Cpability:
Total:
0
39
0
35
Opens:
Minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
Community attribute sent to this neighbor (both)
Inbound path policy cofigured
Outbound path policy configured
Route map for incoming advertisements is *LOCAL-PREF1
1 accepted prefixes
Connections established 2; dropped 0
Last reset 00:18:36, due to Peer closed the session
Local host: 10.254.8.10, Local port: 57141
Foreign host: 10.254.8.60, Foreign port: 179
Nexthop: 10.254.8.10
Nexthop global: fe80::290:27ff:feba:aff5
Nexthop local: ::
BGP connection: non shared network
Read thread: on
...
Write thread: off
4. show ip bgp summary
上のピアルータの表示の要約がでます。
6.7. BGP の動作の確認
79
bgpd# show ip bgp summary
BGP router identifier 202.11.99.9, local AS number 65001
4 BGP AS-PATH entries
0 BGP community entries
Neighbor
V
AS MsgRcvd MsgSent
TblVer
InQ OutQ Up/Down
State/PfxRcd
10.254.8.60
202.11.99.10
4 65010
4 65001
314
378
320
381
0
0
0
0
0 04:06:04
0 06:19:09
1
3
202.11.99.11
...
4 65001
377
379
0
0
0 06:24:53
1
5. show ip bgp paths
BGP パスが表示されます。
bgpd# show ip bgp paths
Address Refcnt Path
[0x8218510:0] (5)
[0x8218780:201207] (1) 65002 65002 65002
[0x8218730:19968] (1) 65001 65001
[0x82187f0:120316] (1) 65001 65002
[0x82187b0:59903] (3) 65010
なお、VTY を使って bgpd の設定を変更させた場合には、Soft reconfig を使って設定を反映させる必
要があります。
bgpd# clear bgp * soft
第6章
80
6.8
BGP
演習課題
演習 6.1 グループ内部で、全員で BGP の設定を行いなさい。マスターは必ずすべてのグループのマスター
と接続するように設定しなさい。
AS 番号は、65000 + (グループ番号) を使いなさい。つまり、グループ 1 ならば 65001 が AS 番号にな
ります。
RouterID は、自分に割り当てられた IP アドレス 172.16.1.1 を利用しなさい。
ゲートウェイの外部側インターフェースのセグメントへのルーティングに関しては、next-hop-self を設
定する方法をとります。
マスター以外の人は、一旦他のグループとは接続せずに、i-BGP としてマスターや、グループ内部の他
の人と BGP 接続をする設定をしなさい。
マスター間の接続がうまく接続でき、それらの情報が交換されているかをチェックし、うまく行けば show
ip bgp の結果を報告しなさい。
演習 6.2 次に、マスター以外の他のグループに接続している人は、その相手とピアを張りなさい。設定は
内部からはマスターが優先的なゲートウェイとなるように設定しなさい。うまく接続できたら、show ip
bgp neighbors の結果を提出しなさい。

 Download  Report
News Release 都市研 Quick 調査 ユネスコ世界文化遺産登録に関する

News Release 都市研 Quick 調査 ユネスコ世界文化遺産登録に関する

show ip route

show ip route

新生児聴覚スクリーニング検査（赤ちゃんのきこえの検査）について

新生児聴覚スクリーニング検査（赤ちゃんのきこえの検査）について

フェンリル、プレビュー機能が追加され画像や PDF を確認しながら ラベル

フェンリル、プレビュー機能が追加され画像や PDF を確認しながら ラベル

EQUIOS導入後、わずか2週間で、 RIP処理全体の50％を移行

EQUIOS導入後、わずか2週間で、 RIP処理全体の50％を移行

SJC QuickView概要紹介

SJC QuickView概要紹介

「10歳の壁」を乗り越える くぐり期 - NPO法人 国際臨床保育研究所

「10歳の壁」を乗り越える くぐり期 - NPO法人 国際臨床保育研究所

OFTWARE - Marposs

OFTWARE - Marposs

「Quick Time」での再生方法はこちら

「Quick Time」での再生方法はこちら

Paperzz.com

Your Paperzz

© Copyright 2024 Paperzz