CONBU LL Diver/YAPC::Asia 2014 Network

YAPCとLL､異なるカンファレンスのNWをさくっと構築する

10月29日@Mixi

Copyright © 2014 COnference Network BUilders . All rights reserved. 1

話している人

名前: 髙橋祐也

所属: CONBU

本業: 某通信キャリアのNWエンジニア


話してる人


CONBUが実施した事

アプリケーション層

プレゼンテーション層

セッション層

トランスポート層

ネットワーク層

データリンク層

物理層

OSI参照モデル+α

ファシリティ

政治層

ケーブル/WiFi

L2SW

ルータ

ネットワークサービス

DHCP/DNS等

いろいろ…

今後やりたい

私が主に話す範囲

セキュリティ

テーマについて



会場ネットワークのテーマ

ポータブル化ポータブル化低コスト化低コスト化


テーマの理由

LL

{ “開催日” : “2014年 8月 23日”, “会場” : “日本科学未来館” }

{ “開催日” : “2014年 8月 28 – 30日”, “会場” : “慶応義塾日吉キャンパス協生館” }

YAPC


テーマの理由(続)

( ^o^)会場ネットワーク頑張って作るよ！ ( ˘⊖˘) 。o(待てよ？準備期間は何日あるんだ？) |カレンダー|┗(☋｀ )┓三 ( ◠‿◠ )☛そこに気づいたか・・・炎上プロジェクトに参加してもらおう ▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂うわああああああ

準備期間が44日日しかない


当日までの準備

計画現地調査 (下見)

検証机上設計

物理

論理

物理

論理

設計

通常はこの流れを1-2ヶ月程で実施


当日までの準備(2ライン体制)


検証机上設計

物理

論理

物理

論理

設計

2ライン体制は人も物も厳しい


検証机上設計

物理

論理

物理

論理

設計

それでも増える要件

セキュリティ？

高速性？

低コスト？

IPv6？



( ´ー｀).oO(どうやってやるんだろうか)

でもやるしかない！

テーマの実現に向けて


会場ネットワークで求められる機能はイベントを問わず変わる事は少ない一度作ったネットワークの再利用による低コスト化


テーマ達成に向けて

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃それをすてるなんてとんでもない！ ┃ ┃ ▼ ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛


各パートの共通化の検討

共通化できる作業共通化できない作業

•計画

•何を目的とするか

•どのような事をするか

•論理設計

•IPアドレスのアサイン等

•(一部)検証

•サーバ側のサービス等

•物理設計

•ケーブル、装置設置場所

•無線設計

•現地調査(下見)

•既設配線、WLAN等

•(一部)検証

•会場での接続性等


会場ネットワーク構築方法検討

案 1

案 2

案 3

装置を設定してから運搬

テンプレートを作って会場でデプロイ

ネットワーク機能をクラウドに置く

確実性経済性再利用性挑戦性流行性

案1 △ △ ☓ ☓ ☓

案2 △ △ △ ○ ○

案3 △ △ ○ ◎ ○

各案の検討結果

採用

【案1】装置を設定してから運搬する

確実性→△ すべての機能が現地でつないでみないと最終結果がわからない。

運搬に失敗(遅延、破損)等ですべての機能が停止する。

経済性→△ 持ち込む機材が増えることにより運搬費と設営リソースが多い。

我々の学習コストは少ない

再利用性→☓ なし。イベント毎に作り直すことが多い。

挑戦性→☓ なし。従来通り。

流行性→☓ なし。従来通り。

Copyright © 2014 COnference Network BUilders . All rights reserved.

16

【参考】構築方法検討資料(案1)

【案2】テンプレートを作って会場でデプロイ

確実性→△ 検証環境の物を本番環境に確実にデプロイ出来るか未知数。

経済性→△ 基盤構築やツールの設定ファイル等の準備が必要

我々の学習コストは高い(仮想化技術、プロビジョニングツール等…)

再利用性→△ 提供サービスの設定等は再利用出来る。

ネットワーク機能の再利用はまだ難しいと想定。

挑戦性→○ あり。サーバ/ネットワークの設定のオートメーション化を目指せると良い。

流行性→○ あり。プロビジョニング/オートメーションはサーバインフラ系では流行中。



【案3】ネットワーク機能をクラウドに置く

確実性→△

会場とクラウドの接続性が不安材料(※検証でリカバー可能)

経済性→△

クラウドの利用料や構築費用がかかる。

再利用性→○

クラウド側のネットワーク構成は変えなくても良い。

挑戦性→◎

会場ネットワークとしては今までとは異なるネットワークの構築となる。

この方法で成功することで今後の会場ネットワーク提供がもっと楽に出来る。

流行性→○

ネットワークやネットワーク機能仮想化はネットワーク業界でバズっている

Copyright © 2014 COnference Network BUilders . All rights reserved.

18


会場ネットワークをクラウドに置くメリット


従来のホットステージとは

事前検証・構築の時間

会議室等に関係者が集まって実施

ホットステージの課題

本業が有るため人が集まることが難しい

会議室等を確保することが難しい

機能をクラウドに置いたメリット

ホットステージの時間削減

いつでも構築可能


クラウドに機能を置くメリット(1)

戦

荷物の発送

設定した装置やケーブル類を借り入れ元からホットステージ会場経由で会場まで運搬する必要がある

荷物の課題

大量の装置やサーバやケーブル類の運搬には送料等も掛かってくる

機能をクラウドに置いたメリット

少しは減らすことができた？（疑問）

これからもっと少なく出来るかも？

※荷札の貼り間違えには注意しましょう


クラウドに機能を置くメリット(2)

会場ネットワークをクラウドに置くための技術と設計


数年前までは…

ネットワーク機器(物理)を借りて現地に持ち込みorリモートに設置

最近のネットワーク業界のバズワード

NFV(Network Functions Virtualization)がバズりだし仮想アプライアンス(仮想化基盤の上で動くバーチャルルータ)の製品も販売が開始されている

会場ネットワークの規模であれば仮想アプライアンスでも提供が可能と判断してほぼすべての機能を仮想化基盤上で構築


ネットワーク装置

※すべての環境において適応出来るかはわかりません


YAPC/LL構成概要図

TheThe InternetInternet ExternalExternal

WIDE WIDE ProjectProject L2L2

マネジメントNW

ユーザーNW

LAN内公開サーバNW

グローバル公開サーバNW

Global-RT

NAPT


Biglobe

すべての装置及び、VMが

接続されるため結線省略 Private-RT

Internet Tunnel GW

WIDE Tunnel GW

.1

.17

.129 .130 .131 .132…

.129 .130 .131 .132…

.33

.1

.1 .5

.1

.5 .1

.5

.11 .12 .13 .14 .15 .16 .17 .18…

AP1AP1 AP2AP2 AP3AP3 AP4AP4 AP5AP5 AP6AP6 AP7AP7 AP8…AP8…

.253

.254

クラウド

会場

IPsecトンネルでクラウドと接続アクセスラインの違いを吸収

会場内の機器は最小限トンネル終端+AP+スイッチだけ

今回はIPSecを採用

採用理由

NAT越えが容易、暗号化の仕組み有り


トンネル技術の選定

実装 NAT越暗号化複雑度

IPsec ○ ○ ○ ☓

GRE ○ ☓ ☓ ○

OpenVPN △ ○ ○ ○

主要プロトコルの検討結果

採用

【IPsec】

実装→○

*nix系OSやネットワーク機器に実装が多い

NAT超え→○

NAT-T機能によりUDPでカプセリングして通信可能

暗号化→○

DESや3DESを始めAES等の暗号化機能が利用可能の場合が多い

複雑度→☓

仕様が複雑で細かく設定をしなければ動作しない

装置や実装による動作差分が多く相性問題が発生する事も有る


【参考】トンネル方式検討資料(IPsec)

【GRE】

実装→○

*nix系OSやネットワーク機器に実装が多い

NAT超え→☓

プロトコル番号47を利用するが装置で設定が必要

家庭向けや小規模向けの安価な装置だと設定項目すらない場合もある

暗号化→☓

暗号化機能が無いため、IPsecなどと組み合わせる必要がある

複雑度→○

設定する項目は少なく比較的簡単に接続可能


【参考】トンネル方式検討資料(GRE)

【OpenVPN】

実装→X

*nix系の実装は多いがネットワーク機器での実装は少ない

NAT超え→○

UDPやTCPの上で動作させることが可能なため容易

暗号化→○

利用可能

複雑度→○

ノウハウ等が公開されていることも多く相性問題なども少ない


【参考】トンネル方式検討資料(GRE)


YAPC/LL構成概要図

TheThe InternetInternet ExternalExternal

WIDE WIDE ProjectProject L2L2


ユーザーNW

LAN内公開サーバNW

グローバル公開サーバNW

Global-RT

NAPT


Biglobe

すべての装置及び、VMが

接続されるため結線省略 Private-RT

Internet Tunnel GW

WIDE Tunnel GW

.1

.17

.129 .130 .131 .132…

.129 .130 .131 .132…

.33

.1

.1 .5

.1

.5 .1

.5

.11 .12 .13 .14 .15 .16 .17 .18…

AP1AP1 AP2AP2 AP3AP3 AP4AP4 AP5AP5 AP6AP6 AP7AP7 AP8…AP8…

.253

.254

クラウド

会場

コア&ディストリビューション層

アクセス層

役割を完全に分離

ここら辺まとめられないの？

→1台にまとめることは可能だけど…


【参考情報】 Ciscoの階層型設計モデル

キャンパスネットワークの設計モデルが存在

ハイアベイラビリティかつモジュール性が考慮されている

【参考】 http://www.cisco.com/web/JP/news/cisco_news_letter/mail/0304/6k_ha/campus_network_design.pdf

http://www.cisco.com/web/JP/news/cisco_news_letter/mail/0304/6k_ha/campus_network_design.pdf

設計から本番までの間で設計変更が入ると見込んだ

実際に本番数日前のテストでうまくいかないトラブル発生

予備プランの予備プランを急遽構築した

結果、仮想ルータを1台追加し多少の設定を加えるだけで対応


まとめないで独立させた理由(2)

上流上流開通日開通日

アクセスアクセス回線回線@LL@LL 試験日試験日

アクセスアクセス回線回線@YAPC@YAPC

試験日試験日

WIDE(VLAN方式)を構築することが決定

既存の装置は可能な限り触りたくない

複数種類のアクセス回線を収容

インターネット面

WIDE面(IPSec)

WIDE面(VLAN)

一つの装置に複雑な設定を入れると…

人為的誤りを起こしやすい

バグを踏みやすい

後から他の装置や実装に移動し辛い


まとめないで独立させた理由(1)

ネットワークのトラブルの紹介と YAPC::Asia会期中の仕事


設営

トラブル対応現地対応@多目的教室

トラシュー@控室

検証@控室

Abuse対応

セキュリティ、無線チームと共に怪しい通信の特定等…


会期中のCONBU

会場X NOC


トラブル紹介(VLANがおかしい)

発生事象

一部の会場(部屋)で通信が不安定

どうやら無線APが再起動をしているように見える

原因

想定していた設定と異なるVLAN設定でEtherフレームが流れていた

情報コンセント

情報コンセント

VIDx

VIDy

VIDx

Ether

Ether

Ether

IP+Data

IP+Data

IP+Data

コントロール通信

ユーザ用通信

スタッフ用通信

VIDx

VIDy

VIDx

Ether

Ether

Ether

IP+Data

IP+Data

IP+Data

コントロール通信

ユーザ用通信

スタッフ用通信

VLAN IDが付加されているはずが、コントロール向けのタグがない状態で流れてきていた

その場で設定変更を実施して対応


トラブル紹介(IPsec通らない)

通常の通信

IKEの通信

パケットが破棄される

発生事象会社の環境にリモートアクセス出来ない

L2TP/IPsecを利用しているとのこと

再現

L2TP/IPsecでの通信が出来ない事象は再現

IKEによる鍵交換フェーズでエラーとなる

原因概略

発生事象

会場ネットワークから会社にトンネルが張ることが出来ない

発生原因

IKEによる鍵交換要求のパケットが途中のネットワークで廃棄される

原因調査の記録

Twitterで指摘される

スタッフ控室で簡易検証環境を構築

被疑装置判明

対応検討





検証構成

参加者PCみなし会場側トンネル終端装置トンネル終端及びリモートサーバみなし

検証目標及び検証方法: “参加者PCみなし”と”リモートサーバみなし”の間でIPsecを開始し被疑箇所を特定する



想定する動作

参加者PCみなし会場側トンネル終端装置トンネル終端及びリモートサーバみなし

IP IKE UDP IP UDP IP ESP IKE

IP TCP IP TCP IP ESP

実際の動作

IP IKE UDP IP UDP IKE

IP TCP IP TCP IP ESP

IKEパケットのみがカプセル化されずに中間経路に送信される

パケットのお漏らし

動作の理由

デフォルト動作の確認漏れ

明示的に指定しない場合はデフォルト動作として、 IKEをカプセリングしない


IKE パケットのバイパス設定入力形式 ipsec ike-passthru no ipsec ike-passthru パラメータなし説明 IKE パケット（ポート 500 番）に対して IPsec を適用するか否かを設定します。デフォルト値有効。 IKE パケットに対して IPsec を適用しません。実行モードグローバルコンフィグモードユーザ権限 Administrator 入力例 ipsec ike-passthru no ipsec ike-passthru ノートなし

コマンドリファレンス抜粋

今回の会場ネットワークの改善点と目指すところ


会社等へのリモートアクセスが出来ない事ある程度の人が会場ネットワークに求めている

原因は判明しているので次回以降に反映

仮想化を自分たちで用意したこと Vmware ESXiをCONBUで用意した

可能であれば、VPS等を提供している所で試したい

AWSとかでも出来るはず(コストは計算していない)

一部会場(部屋)のポート設定が会場側とうまく調整できていない事前のテストは欠かせないですね


ネットワーク部分の今回の反省点とこれから

先述のトラブルのように運用中に気がつく事も数多くあります！

今からでもいいので、気になった等があればTwitterやメールやCONBUの人を捕まえて教えて下さい！むしろ今日お願いします!


フィードバックのお願い

CONBU WEB

http://conbu.net/


お問い合わせ [email protected]