第5回 IPアドレス利用のデザイン 2002/11/11 担当：村井 純

Presentation on theme: "第5回 IPアドレス利用のデザイン 2002/11/11 担当：村井 純"— Presentation transcript:

1 第5回 IPアドレス利用のデザイン 2002/11/11 担当：村井 純
インターネット構成法 第5回　IPアドレス利用のデザイン 2002/11/11 担当：村井　純

2 IPv4アドレス 32bit . . . アドレスの総数は2の32乗(約40億) 131.113.209.140のように表記
ネットワーク部とホスト部に分かれる 1 1 1 1 1 1 1 1 1 1 1 1 1 1 . . . 131 113 209 140

3 サブネットマスク . . . ネットワーク部とホスト部の境を示す サブネットマスクが1の部分はネットワーク部、0の部分はホスト部
例 netmask ネットマスクの長さをとって/25 とも表記 131 113 209 140 . . . 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 1 1 1 1 1 1 1 1 1 1 1 1 1 1 255 255 255 128

4 サブネット 例: /25 ～ が含まれる はネットワークアドレス(ホスト部が全て0) はブロードキャストアドレス(ホスト部が全て1) 実際に使えるアドレスは ～ ルータ ホストA ホストB ホストC

5 サブネット長と接続ノード数 ホスト部の長さによって、接続できるノード数が変化 /24 → ホスト部8bit → 254台

6 IPv4 - /24の割りあて例（１） 131.113.209.0/24を4つのオフィスで利用したい 東京本社 85台
/25 大阪支社 10台 /28 名古屋支社 11台 /28 横浜支社 25台 /27

7 IPv4 - /24の割りあて例（2） 将来的なノード数を予測 サブネットが大きすぎると無駄 小さすぎるとアドレスが不足
新しいサブネットが必要になる可能性もある /25 (東京支社,85台) この割り当て例では、横浜支社には 新しく使えるアドレスは5つしか残らない しかし、大阪支社、名古屋支社も余裕は少ない。 ここで、それぞれに大きめのサブネットを配るか、 ぎりぎりの大きさのサブネットを配って reservedされたアドレスを残すかは悩みどころ。 将来を予測した設計が必要。 /24 /27 (横浜支社,25台) /28 (大阪支社,10台) /28 (名古屋支社,11台) /26 (reserved)

8 IPv4 - /24の割りあて例（3） 131.113.209.0/24 サブネット分けしない方法もある ４つの拠点をスイッチで接続
昔は大きすぎるサブネットを切ると通信品質が低下する問題があった。 (Ethernet上で衝突が増加) メリット ネットワークが単純、管理も楽 アドレスの利用効率が高い ネットワークアドレス、ブロードキャストアドレスが一つで済む。 どの部署に何台マシンが増えても大丈夫 /24 スイッチ スイッチ スイッチ

9 設計のポイント サブネット分割が必要になる要因 冗長性、耐障害性をどのように確保するか ネットワークごとに異なるセキュリティーポリシがある
管理団体が違う ネットワークが巨大なので通信品質が落ちる 分割しておけばLayer3でトラブルシューティングし易い 冗長性、耐障害性をどのように確保するか サブネット分割されたネットワーク ルーティングプロトコルによるバックアップが可能 スイッチで複数のネットワークを接続している場合 VRRP,HSRPなどを利用

10 セキュリティを考慮したネットワーク 部署ごとに異なるセキュリティポリシがある Firewall 開発、営業、総務
ネットワークのセキュリティを守る方法 ネットワーク型Firewall 中継ノード上でパケットを監視 下流のネットワークを外からの攻撃から守る ホスト型Firewall エンドノード上でパケットを監視

11 ネットワーク型Firewall パケットフィルタリングベース アプリケーションゲートウェイベース
パケットのヘッダを元にパケットの破棄・ 通過を決定 TCPの状態を見る製品も アプリケーションゲートウェイベース パケットのペイロードを元に処理を決定 例: Proxy サーバ、Anti-Virusゲートウェイ、 Webページフィルタリング

12 Firewall <Application Gateway> Protocol Anti-Virus for E-mail
Source / Destination Protocol Port IN/OUT interface <Application Gateway> Anti-Virus for WEB Proxy Traffic Logging INTERNET Application Transport Filrewall (Packet Filter) Proxy IP Data Link Physical User

13 異なるセキュリティポリシの適用(例) Firewallを導入 営業部は全ての支社で情報を共有
開発部は、機密保持のため営業部とのアクセスも制限 インターネット　　　 /25 /26 Firewall 機密　　　 スイッチ スイッチ スイッチ 大阪支社 名古屋支社 横浜支社 東京支社 営業部 東京支社 開発部

14 IPv4アドレスの不足 インターネットユーザ数の増加に伴い、 IPv4アドレスが枯渇 各ISPは厳しい審査を経てIPアドレスを取得
限られたグローバルアドレスを有効に活用 NAT/NAPT 弊害もある 対策技術 IPv6

15 インターネットに接続された ホスト数の推移
Source: Internet Software Consortium (

16 IANAの委任したIPv4アドレスの現状 ARIN APNIC RIPE NCC 未割り当て 他の組織 (RIR以前) (マルチキャスト)
Source: RIR Co-ordination and Joint Statistics at IEPG, July 2002

17 IPv4 Allocations per RIR 1999-2002
2.25 2.05 1.71 1.50 1.51 1.29 .92 .92 .89 0.79 .52 .57 2.61 4.47 5.47 2.37 Source: RIR Co-ordination and Joint Statistics at IEPG, July 2002

18 IPv4 Allocations by Country 2002 (Jan-Jun)
Source: RIR Co-ordination and Joint Statistics at IEPG, July 2002

19 ISPが提供するサービスの現状 安価な接続サービスでは割り当てられるIPv4アドレス数に厳しい制限
/26~/32程度 利用IPアドレス数に比例した料金体系のサービスも多い IPアドレスを必要なだけ割り当てられる サービスは高価 例: A社の10Mbps専用接続サービス 最大64個: 月額498,000円 制限なし: 月額1,100,000円

20 プライベートIPアドレス RFC1918 で定義 広大なIPアドレス空間 インターネットとの通信がそのままでは 不可能 10.0.0.0/8
/12 /16 広大なIPアドレス空間 インターネットとの通信がそのままでは 不可能

21 NAT RFC1631: The IP Network Address Translation
プライベートIPアドレスをグローバル IPアドレスに変換 本来の意味ではIPアドレスの対応は1対1 同時接続分のグローバルIPアドレスを消費する ヘッダのIPアドレス部分のみを変換 NATという表現に多少表現に混乱も

22 NAPT IPアドレスに加え、ポート番号も変換する
RFC2391: Load Sharing using IP Network Address Translation (LSNAT) 内に記述 Network Address Port Translation IPアドレスに加え、ポート番号も変換する 1つのグローバルアドレスで複数のプライベートIPアドレスを持つ端末を接続できる NAPT,NAT+, IP Masqueradeと呼ばれているものとほぼ同義

23 NAT/NAPTのメリット グローバルIPアドレスの節約が可能 アクセス制御 Internet
一つのグローバルアドレスを使って、複数のマシンが外部と通信できる アクセス制御 外部から内部ネットワークが隠蔽される NAPT-BOX NAPTの内側 Internet :2911 :2932 :2949 :3018 :1048 :1050 :2181 :2911 NATによって隠蔽され外から見えない

24 NAT/NAPTのデメリット プロトコルによってはNAT/NAPTを通過できない 外部からアクセスを受けるアプリケーションが利用しずらい
ペイロード内にIPアドレスを含むプロトコルを 利用するアプリケーション 例:FTP,H.323系のVoIP,NetMeeting アドレス変換時に、アプリケーションデータも書き換える必要 外部からアクセスを受けるアプリケーションが利用しずらい 外部からも接続が行われるアプリケーション 例:ネットワークゲーム,P2P 複数の動的なセッションを利用するアプリケーション 例:FTP, NetMeeting

25 UPnP Universal Plug and Play NAT/NAPTのデメリットへの対応 機能 Microsoftが提唱
Universal Plug and Play Forumが標準化 NAT/NAPTのデメリットへの対応 機能 ネットワーク接続した機器のUPnP機器での検知 NAT Traversal ネットワークアプリケーションがNAT デバイスの背後にあることを検出し、ルータに割り振られているWAN側 IP アドレスを識別 NAT の外部ポートから、アプリケーションの使用する内部ポートへパケットを転送するポートマッピングを設定

26 NAT/NAPTのデメリット 外側にNAT内部から外部にabuseがあった場合、 実行者の割り出しが難しい Internet NAT箱
インターネット側からみたIPアドレスがNAT箱のものになる Internet 犯罪者 NAT箱 一般利用者

27 NAT内部からのabuseへの対応策 Proxyサーバでログを記録 TCPのフロー情報を記録
Transparent Proxyの導入 TCPのフロー情報を記録 NAT前とNAT後のフロー情報を保存 sFlow (RFC3176) Cisco NetFlowなど

28 ケーススタディ(起) 村井研究室のユーザセグメント 最初は研究室全体が一つのセグメントに入っていた セキュリティは各マシンごとに管理者が確保
クライアントの数は、多い時で230程度 Wide ネットワーク　 ルータ /24

29 ケーススタディ（承） 管理の甘いマシンがクラックされた 対策 同一ネットワーク上のマシンは全て再構築 Sshのkeyも作り直し。。
新たなセキュリティポリシの考案 ネットワークを半分に分割 Firewallに保護されたネットワーク マシンごとに厳格な管理されたネットワーク Wide ネットワーク　　　 ルータ Firewall /25 ホストごとに管理されたネットワーク （unfiltered） /25 保護されたネットワーク (filtered)

30 ケーススタディ（転） 新たな問題 解決方法 既に満杯 80台 Firewallを通さないネットワークがきつきつ サブネットを切りなおす?
潜在的に150台程度のニーズ Firewallを通すネットワークには80台程度 解決方法 サブネットを切りなおす? NATを使う? 新たなグローバルアドレスを確保? Wide ネットワーク　　　 ルータ 既に満杯 Firewall 80台 /25 ホストごとに管理されたネットワーク /25 保護されたネットワーク

31 ケーススタディ(結：案１) 必要IPアドレス数に合わせて、サブネットを切りなおす 必要IPアドレス 問題点
Firewallなしセグメント → /25 + /27 Firewallありセグメント → /27 + /27 + /27 (/26 + /27) 問題点 拡張性が低い 構成が複雑 /25 (unfiltered) /27 (unfiltered) /27 (filtered) /27 (filtered) /27 (filtered)

32 ケーススタディ（結：案２） FirewallをNAPTにする NAPT自体に付随する問題を許容できるか？ 嫌がる人も多い ルータ
プロトコルによってNAT/NAPTを通過できない問題 NAPTセグメント内のマシンが、外部からアクセスを受けられない問題 嫌がる人も多い Wide ネットワーク　　　 /24 ホストごとに管理されたネットワーク ルータ Firewall/NAT /24

33 まとめ サブネットを切る時に考えること 運用上考えなくてはならない問題点 総合的に考えて、導入する機器を選択 運用ポリシー
アドレスの利用効率 ネットワークの冗長性、拡張性 運用上考えなくてはならない問題点 グローバルIPアドレスの効率的利用 NAT/NAPTの是非 総合的に考えて、導入する機器を選択