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