インターネット構成法

インターネット構成法
第5回 IPアドレス利用のデザイン
2002/11/11
担当：村井純
IPv4アドレス
 32bit
 アドレスの総数は2の32乗(約40億)
 131.113.209.140のように表記
 ネットワーク部とホスト部に分かれる
1 0 0 0 0 0 1 1 0 1 1 1 0 0 0 1 1 1 0 1 0 0 0 1 1 0 0 0 1 1 0 0
131
.
113
.
209
Slide: 2
.
140
インターネット構成法 2002
サブネットマスク
ネットワーク部とホスト部の境を示す
 サブネットマスクが1の部分はネットワーク部、0の部分
はホスト部



例131.113.209.140 netmask 255.255.255.128
ネットマスクの長さをとって/25 とも表記
131
.
113
.
209
.
140
1 0 0 0 0 0 1 1 0 1 1 1 0 0 0 1 1 1 0 1 0 0 0 1 1 0 0 0 1 1 0 0
ネットワーク部
ホスト部
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0
255
255
255
Slide: 3
128
インターネット構成法 2002
サブネット
 例:131.113.209.140/25

131.113.209.128 ～ 131.113.209.255 が含まれる



131.113.209.128はネットワークアドレス(ホスト部が全て0)
131.113.209.255はブロードキャストアドレス(ホスト部が全て1)
実際に使えるアドレスは131.113.209.129 ～ 131.113.209.255
ルータ
131.113.209.129
ホストA
131.113.209.130
ホストB
131.113.209.131
ホストC
131.113.209.132
Slide: 4
インターネット構成法 2002
サブネット長と接続ノード数

ホスト部の長さによって、接続できるノード数が変化







/24
/25
/26
/27
/28
/29
/30
→
→
→
→
→
→
→
ホスト部8bit
ホスト部7bit
ホスト部6bit
ホスト部5bit
ホスト部4bit
ホスト部3bit
ホスト部2bit
→
→
→
→
→
→
→
254台
126台
62台
30台
14台
６台
２台
Slide: 5
インターネット構成法 2002
IPv4 - /24の割りあて例（１）

131.113.209.0/24を4つのオフィスで利用したい
東京本社
85台
131.113.209.0/25
大阪支社
10台
131.113.209.224/28
名古屋支社
11台
131.113.209.192/28
Slide: 6
横浜支社
25台
131.113.209.128/27
インターネット構成法 2002
IPv4 - /24の割りあて例（2）

将来的なノード数を予測



サブネットが大きすぎると無駄
小さすぎるとアドレスが不足
新しいサブネットが必要になる可能性もある
131.113.209.0/24
131.113.209.0/25 (東京支社,85台)
131.113.209.128/27 (横浜支社,25台)
131.113.209.160/28 (大阪支社,10台)
131.113.209.176/28 (名古屋支社,11台)
この割り当て例では、横浜支社には
新しく使えるアドレスは5つしか残らない
しかし、大阪支社、名古屋支社も余裕は少ない。
ここで、それぞれに大きめのサブネットを配るか、
ぎりぎりの大きさのサブネットを配って
reservedされたアドレスを残すかは悩みどころ。
将来を予測した設計が必要。
131.113.209.192/26 (reserved)
Slide: 7
インターネット構成法 2002
IPv4 - /24の割りあて例（3）

サブネット分けしない方法もある



４つの拠点をスイッチで接続
昔は大きすぎるサブネットを切ると通信品質が低下する問題があった。
(Ethernet上で衝突が増加)
メリット


ネットワークが単純、管理も楽
アドレスの利用効率が高い


ネットワークアドレス、ブロードキャストアドレスが一つで済む。
どの部署に何台マシンが増えても大丈夫
131.113.209.0/24
スイッチ
スイッチ
スイッチ
Slide: 8
インターネット構成法 2002
設計のポイント

サブネット分割が必要になる要因





ネットワークごとに異なるセキュリティーポリシがある
管理団体が違う
ネットワークが巨大なので通信品質が落ちる
分割しておけばLayer3でトラブルシューティングし易い
冗長性、耐障害性をどのように確保するか

サブネット分割されたネットワーク


ルーティングプロトコルによるバックアップが可能
スイッチで複数のネットワークを接続している場合

VRRP,HSRPなどを利用
Slide: 9
インターネット構成法 2002
セキュリティを考慮したネットワーク
 部署ごとに異なるセキュリティポリシがある
 開発、営業、総務
 Firewall
 ネットワークのセキュリティを守る方法
 ネットワーク型Firewall
中継ノード上でパケットを監視
 下流のネットワークを外からの攻撃から守る

 ホスト型Firewall

エンドノード上でパケットを監視
Slide: 10
インターネット構成法 2002
ネットワーク型Firewall
 パケットフィルタリングベース
 パケットのヘッダを元にパケットの破棄・
通過を決定
 TCPの状態を見る製品も
 アプリケーションゲートウェイベース
 パケットのペイロードを元に処理を決定
 例:
Proxy サーバ、Anti-Virusゲートウェイ、
Webページフィルタリング
Slide: 11
インターネット構成法 2002
Firewall
•Source / Destination
•Protocol
•Port
•IN/OUT interface
<Application Gateway>
•Anti-Virus for E-mail
•WEB Proxy
•Traffic Logging
INTERNE
T
Application
Filrewall
(Packet Filter)
Transport
Proxy
IP
Data Link
Physical
User
Slide: 12
インターネット構成法 2002
異なるセキュリティポリシの適用(例)

大阪支社
Firewallを導入


営業部は全ての支社で情報を共有
開発部は、機密保持のため営業部とのアクセスも制限
インターネット
131.113.209.0/25
131.113.209.128/26
Firewall
スイッチ
名古屋支社
スイッチ
横浜支社
スイッチ
東京支社
営業部
Slide: 13
機密
東京支社
開発部
インターネット構成法 2002
IPv4アドレスの不足
 インターネットユーザ数の増加に伴い、
IPv4アドレスが枯渇
 各ISPは厳しい審査を経てIPアドレスを取得
 限られたグローバルアドレスを有効に活用
 NAT/NAPT

弊害もある
 対策技術
 IPv6
Slide: 14
インターネット構成法 2002
インターネットに接続された
ホスト数の推移
Source: Internet Software Consortium (http://www.isc.org/)
Slide: 15
インターネット構成法 2002
IANAの委任したIPv4アドレスの現状
ARIN
6% 4%
APNIC
4% RIPE NCC
37%
未割り当て
他の組織
(RIR以前)
43%
6%
(マルチキャスト)
Source: RIR Co-ordination and Joint Statistics at IEPG, July 2002
Slide: 16
インターネット構成法 2002
IPv4 Allocations per RIR
1999-2002
40,000,000
35,000,000
RIPE NCC
APNIC
ARIN
2.25
2.05
30,000,000
1.50
25,000,000
1.71
1.51
1.29
20,000,000
15,000,000
10,000,000
.92
.92 .89
0.79
.52
.57
5,000,000
0
1999
2000
2001
2002
2.61
4.47
5.47
2.37
Source: RIR Co-ordination and Joint Statistics at IEPG, July 2002
Slide: 17
インターネット構成法 2002
IPv4 Allocations by Country
2002 (Jan-Jun)
IT
IN
Other 11%
2% 1%
UK
HK 2%
2%
TW
5%
JP
26%
AU
6%
US
10%
CN
19%
KR
16%
Source: RIR Co-ordination and Joint Statistics at IEPG, July 2002
Slide: 18
インターネット構成法 2002
ISPが提供するサービスの現状
 安価な接続サービスでは割り当てられるIPv4ア
ドレス数に厳しい制限
 /26~/32程度
 利用IPアドレス数に比例した料金体系のサービスも
多い
 IPアドレスを必要なだけ割り当てられる
サービスは高価
 例:
A社の10Mbps専用接続サービス
最大64個: 月額498,000円
制限なし: 月額1,100,000円
Slide: 19
インターネット構成法 2002
プライベートIPアドレス
 RFC1918
で定義
 10.0.0.0/8
 172.16.0.0/12
 192.168.0.0/16
 広大なIPアドレス空間
 インターネットとの通信がそのままでは
不可能
Slide: 20
インターネット構成法 2002
NAT
 RFC1631:
The IP Network Address
Translation
 プライベートIPアドレスをグローバル
IPアドレスに変換
 本来の意味ではIPアドレスの対応は1対1

同時接続分のグローバルIPアドレスを消費する
 ヘッダのIPアドレス部分のみを変換

NATという表現に多少表現に混乱も
Slide: 21
インターネット構成法 2002
NAPT

RFC2391: Load Sharing using IP Network Address
Translation (LSNAT) 内に記述
 Network Address Port Translation
 IPアドレスに加え、ポート番号も変換する
 1つのグローバルアドレスで複数のプライベートIPア
ドレスを持つ端末を接続できる
 NAPT,NAT+, IP Masqueradeと呼ばれているもの
とほぼ同義
Slide: 22
インターネット構成法 2002
NAT/NAPTのメリット

グローバルIPアドレスの節約が可能


一つのグローバルアドレスを使って、複数のマシンが外部と通信できる
アクセス制御

外部から内部ネットワークが隠蔽される
NAPTの内側
192.168.0.2:1048
192.168.0.3:1050
NAPT-BOX
133.27.24.254:2911
133.27.24.254:2932
133.27.24.254:2949
133.27.24.254:3018
Internet
192.168.0.4:2181
192.168.0.5:2911
NATによって隠蔽され外から見えない
Slide: 23
インターネット構成法 2002
NAT/NAPTのデメリット

プロトコルによってはNAT/NAPTを通過できない

ペイロード内にIPアドレスを含むプロトコルを
利用するアプリケーション



例:FTP,H.323系のVoIP,NetMeeting
アドレス変換時に、アプリケーションデータも書き換える必要
外部からアクセスを受けるアプリケーションが利用しずらい

外部からも接続が行われるアプリケーション


例:ネットワークゲーム,P2P
複数の動的なセッションを利用するアプリケーション

例:FTP, NetMeeting
Slide: 24
インターネット構成法 2002
UPnP

Universal Plug and Play


Microsoftが提唱
Universal Plug and Play Forumが標準化

NAT/NAPTのデメリットへの対応
 機能


ネットワーク接続した機器のUPnP機器での検知
NAT Traversal


ネットワークアプリケーションがNAT デバイスの背後にあることを検
出し、ルータに割り振られているWAN側 IP アドレスを識別
NAT の外部ポートから、アプリケーションの使用する内部ポートへパ
ケットを転送するポートマッピングを設定
Slide: 25
インターネット構成法 2002
NAT/NAPTのデメリット

外側にNAT内部から外部にabuseがあった場合、
実行者の割り出しが難しい

インターネット側からみたIPアドレスがNAT箱のものになる
10.0.0.3
Internet
犯罪者
10.0.0.1
10.0.0.5
203.178.143.1
NAT箱
一般利用者
Slide: 26
インターネット構成法 2002
NAT内部からのabuseへの対応策
 Proxyサーバでログを記録
 Proxyサーバを利用しなければ外部ネットワークへ
アクセスできないようにする

Transparent Proxyの導入
 TCPのフロー情報を記録
 NAT前とNAT後のフロー情報を保存
sFlow (RFC3176)
 Cisco NetFlowなど

Slide: 27
インターネット構成法 2002
ケーススタディ(起)
 村井研究室のユーザセグメント
 最初は研究室全体が一つのセグメントに入っていた
 セキュリティは各マシンごとに管理者が確保
 クライアントの数は、多い時で230程度
Wide ネットワーク
ルータ
203.178.143.0/24
Slide: 28
インターネット構成法 2002
ケーススタディ（承）

管理の甘いマシンがクラックされた



同一ネットワーク上のマシンは全て再構築
Sshのkeyも作り直し。。
対策

新たなセキュリティポリシの考案



Wide ネットワーク
ネットワークを半分に分割
ルータ
Firewallに保護されたネットワーク
マシンごとに厳格な管理されたネットワーク Firewall
203.178.143.128/25
保護されたネットワーク
(filtered)
203.178.143.0/25
ホストごとに管理されたネットワーク
（unfiltered）
Slide: 29
インターネット構成法 2002
ケーススタディ（転）

新たな問題

Firewallを通さないネットワークがきつきつ



潜在的に150台程度のニーズ
Firewallを通すネットワークには80台程度
解決方法



サブネットを切りなおす?
NATを使う?
新たなグローバルアドレスを確保?
Wide ネットワーク
ルータ
既に満杯
Firewall
203.178.143.0/25
ホストごとに管理されたネットワーク
80台
203.178.143.128/25
保護されたネットワーク
Slide: 30
インターネット構成法 2002
ケーススタディ(結：案１)

必要IPアドレス数に合わせて、サブネットを切りなおす

必要IPアドレス



Firewallなしセグメント 150 → /25 + /27
Firewallありセグメント 80 → /27 + /27 + /27 (/26 + /27)
問題点


拡張性が低い
構成が複雑
203.178.143.0/25 (unfiltered)
203.178.143.128/27 (unfiltered)
203.178.143.160/27 (filtered)
203.178.143.192/27 (filtered)
203.178.143.224/27 (filtered)
Slide: 31
インターネット構成法 2002
ケーススタディ（結：案２）

FirewallをNAPTにする

NAPT自体に付随する問題を許容できるか？



プロトコルによってNAT/NAPTを通過できない問題
NAPTセグメント内のマシンが、外部からアクセスを受けられない問題
嫌がる人も多い
203.178.143.0/24
ホストごとに管理されたネットワーク
Wide ネットワーク
ルータ
Firewall/NAT
192.168.0.0/24
Slide: 32
インターネット構成法 2002
まとめ
 サブネットを切る時に考えること
 運用ポリシー
 アドレスの利用効率
 ネットワークの冗長性、拡張性
 運用上考えなくてはならない問題点
 グローバルIPアドレスの効率的利用
 NAT/NAPTの是非
 総合的に考えて、導入する機器を選択
Slide: 33
インターネット構成法 2002

Download Report