befs_anneの日記

雰囲気でネットワークをやっている

はじめてのLinux Network NamespaceとLinux Bridge

概要

TremaやRyuを使ってOpenFlowをキメたかったが、gemだのpipを使いこなせずLinuxの仮想ネットワーク機能で飢えを凌ぐ。実行環境はCentOS7.3。

Linux Network Namespaceとは(ざっくり)

  • Linux上に独立したネットワーク空間(多分OpenFlowで言うところの「テナント」)を構築できるスグレモノ。
  • 「ip netns hogehoge」でホストをほげほげする。

Linux Bridgeとは(ざっくり)

  • Linux上にネットワークブリッジを作る機能。多分。
  • 「brctl hogehoge」でブリッジをほげほげする。

参考

https://qiita.com/norin/items/f2c1b0158ee34abcdd0c

d-net.robata.org

作ったネットワーク

ブリッジを介して全てのホストが単一セグメントにいる簡単なもの。

f:id:befs_anne:20171019010106j:plain

流れ

bridge-utilsのインストール

インストールすればbrctlが使えるようになる。

# bridge-utilsのインストール
sudo yum -y install bridge-utils

ブリッジ、ホストの作成

# 以降すべてrootで作業
sudo -s

# ブリッジ作成
brctl addbr br1

# ホスト作成
ip netns add host1
ip netns add host2
ip netns add host3
ip netns add host4

リンク(veth)作成

vethというものを使う。どうやら、片っぽから入ったフレームがもう片っぽから出てくる二対一組のインタフェースっぽい。

ip link add br1_host1 type veth peer name host1_br1
ip link add br1_host2 type veth peer name host2_br1
ip link add br1_host3 type veth peer name host3_br1
ip link add br1_host4 type veth peer name host4_br1

ブリッジとリンクのバインド

vethの一方をブリッジにバインドする。

brctl addif br1 br1_host1
brctl addif br1 br1_host2
brctl addif br1 br1_host3
brctl addif br1 br1_host4

ホストとリンクのバインド

vethのもう一方をホストにバインドする。

ip link set host1_br1 netns host1
ip link set host2_br1 netns host2
ip link set host3_br1 netns host3
ip link set host4_br1 netns host4

IPアドレスの割り当て

ホスト(厳密にはホストにバインドしたveth)にIPアドレスを割り当てる。「ip netns exec {ホスト名} {コマンド}」で指定したホストで指定したコマンドを実行できる。

ip netns exec host1 ip addr add 10.0.0.1/24 dev host1_br1
ip netns exec host2 ip addr add 10.0.0.2/24 dev host2_br1
ip netns exec host3 ip addr add 10.0.0.3/24 dev host3_br1
ip netns exec host4 ip addr add 10.0.0.4/24 dev host4_br1

ループバックアドレスの割り当て

ip netns exec host1 ip addr add 127.0.0.1/8 dev lo
ip netns exec host2 ip addr add 127.0.0.1/8 dev lo
ip netns exec host3 ip addr add 127.0.0.1/8 dev lo
ip netns exec host4 ip addr add 127.0.0.1/8 dev lo

ループバックアドレスのリンクアップ

ip netns exec host1 ip link set lo up
ip netns exec host2 ip link set lo up
ip netns exec host3 ip link set lo up
ip netns exec host4 ip link set lo up

ホストのインタフェースのリンクアップ

ip netns exec host1 ip link set host1_br1 up
ip netns exec host2 ip link set host2_br1 up
ip netns exec host3 ip link set host3_br1 up
ip netns exec host4 ip link set host4_br1 up

ブリッジの起動

brctlで作ったブリッジはip link showの結果に出てくるので、ip link setで起動する。

ip link set br1 up

ブリッジのインタフェースのリンクアップ

ip link set br1_host1 up
ip link set br1_host2 up
ip link set br1_host3 up
ip link set br1_host4 up

疎通確認

疎通確認もip netns execを使って各ホストからpingを実行する。

[centos73 shino]#ip netns exec host1 ping 10.0.0.2 -c 1
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.072 ms

--- 10.0.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.072/0.072/0.072/0.000 ms
[centos73 shino]#ip netns exec host1 ping 10.0.0.3 -c 1
PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
64 bytes from 10.0.0.3: icmp_seq=1 ttl=64 time=0.070 ms

--- 10.0.0.3 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.070/0.070/0.070/0.000 ms
[centos73 shino]#ip netns exec host1 ping 10.0.0.4 -c 1
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
64 bytes from 10.0.0.4: icmp_seq=1 ttl=64 time=0.080 ms

--- 10.0.0.4 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.080/0.080/0.080/0.000 ms
[centos73 shino]#

おわり

今回は単なるホストだったけど、ルーティングもできるのでもっと面白いことができそう。

公開鍵認証を使ったSSHログイン設定手順

概要

いつまで経っても覚えられない自分のために……。

手順

サーバー側

# キーペアの生成、インタラクティブ操作は割愛
$ ssh-keygen

# 秘密鍵(id_rsa)のパーミッションを600に変更
$ chmod 600 ~/.ssh/id_rsa

# authorized_keysに公開鍵(id_rsa.pub)を追記
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

# パスワード認証の無効化(「PasswordAuthentication yes」をコメントアウトする
)
$ sudo vim /etc/ssh/sshd_config

# .sshディレクトリのパーミッションを700に変更
$ chmod 700 ~/.ssh

# authorized_keysのパーミッションを600に変更
$ chmod 600 ~/.ssh/authorized_keys

クライアント側

サーバー側から公開鍵を持ってくる。

ホスト毎に使い分けるなら

クライアントの~/.ssh/configに以下を追記する。

Host {ホスト名}
    IdentifyFile ~/.ssh/{秘密鍵ファイル名}

データセンターに置いといたら便利(そう)なもの

概要

備忘録。データセンターによっては備品(主に工具類)を貸してくれたり、ポリシーで持ち込めないもの(特に燃える可能性のあるもの)があったりするがその辺りは特に考慮しない。

PC、デバイス

PCが調子悪くて作業延期とか割とシャレにならないので、予備として置いておけるなら。最悪ディスプレイとキーボードがあれば、サーバーに直接繋げて作業できることも。

  • PC
  • マウス
  • キーボード
  • ディスプレイ
  • コンソールケーブル
  • USBメモリ

ケーブル類

メディア類の初期不良にも何度か遭遇しているので、予備として置いておきたい。

工具、文房具類

  • ドライバー
  • 刃物類(はさみ、ニッパー、カッターなど)
    • 開梱で大活躍。
    • LANケーブル撤去の際、コネクタのところを切ればあとはスーッと引っ張るだけなので楽。
  • ケージナット取り外しするやつ
    • ケージナットクリッパーというらしい。
    • マイナスドライバーでやってのける人も多いけど、絶対これ使ったほうが楽。しかも篠原電機のやつ(以下リンク)は磁石がついてて更に楽そう。

ケージナットクリッパー 楽ackリッパー(ラクリッパー)|ケージナット着脱工具 楽リッパー(ラクリッパー)|ケージナットクリッパー|データセンター|製品情報|電材部品の開発メーカー、篠原電機株式会社

  • 結束バンド
    • タイラップ インシュロック そんなの ひとの かって
  • 手袋
    • 滑り止めがついてるやつ。でかい機械をうっかり足に落として骨折、という悲劇を2回見ている。しかも同じ現場。以来そこでは着用必須になった。
  • 養生テープ
  • サインペン
  • ケーブルテスター
  • ケーブルタグ

その他

  • 上着
    • データセンターはクソ寒い。作業場所の都合上ホットアイルで暖をとることが難しい場合もあるので、常に置いておけると嬉しい。
    • データセンターのロビーにカラオケ屋の貸衣裳よろしく作業着のブルゾンが何着か掛かったハンガーラックが置かれる未来を待っている。

Spoilerwallで遊ぶ

概要

TCPアクセスに対して映画のネタバレを返す次世代(?)ファイアウォールSpoilerwallなるものがTLに流れてきたので試してみた。

github.com

  • 仮想化環境: Virtualbox
  • クライアント: CentOS7.3
  • サーバー: Ubuntu 16.04

手順

ほぼReadmeの通りだが、一部Virtualbox用に変更。

# リポジトリをクローン
$ git clone git@github.com:infobyte/spoilerwall.git

# iptablesでenp0s3(Wi-Fiルータに繋がっているブリッジインタフェース)に対する全TCP通信の宛先IP/ポート番号を変換する設定を追加
$ sudo iptables -A PREROUTING -t nat -i enp0s3 -p tcp --dport 1:65535 -j DNAT --to-destination 127.0.0.1:8080

# localhostにルーティングする場合は必要……?
$ sudo sysctl -w net.ipv4.conf.enp0s3.route_localnet=1

Readmeではserver-spoiler.pyを編集してspoilerwallが待ち受けるIPアドレス/ポート番号を設定することになっているが、デフォルトで127.0.0.1:8080が設定されているのでこのまま動かす。

$ cd ~/spoilerwall
$ python2 server-spoiler.py

これでサーバー側は準備OK。同じセグメントに属するクライアントからcurlしてみる。

$ curl http://192.168.100.125/
Pokmon: The Rise of Darkrai
darkrai dies
curl: (56) Recv failure: Connection reset by peer

劇場版ポケモンダークライが死ぬというネタバレを食らった後、追い打ちをかけるようにRSTされる。

dic.nicovideo.jp

Chromeでアクセスすると「このサイトにアクセスできません」になった。ネタバレは単にHTTPパケットにDataくっつけているだけ(pcapもしてみた)なので当然か。

おわりに

spoilerとは「台無しにする人」という意味があるらしい。ネタバレ情報はspoiler.jsonにまとまっているようだが、それをいじって遊ぶのはまた別のお話。

ejje.weblio.jp

データベーススペシャリストを目指して勉強し始めて途中帰宅するまで

DBを受けた動機

ネスペにすら合格できない程度の専門性ではこの先生き残れないと思ったので、何か別の強みを持っておこうと思った。

勉強の過程

3月上旬からテキストを少しずつやってたら、 いつの間にか試験一週間前だった。 過去問題集に手を付けたのは4月10日で、午前Ⅱはチョロかったものの午後Ⅰ・Ⅱはろくに手を付けられず。

試験

午後Ⅰ

免除。次の春期試験まで?

午後Ⅱ

十中八九パスしている。考えても分からないような問題も1問ぐらいしかなかった。

午後Ⅰ

問1と問2を選んだけど、問1が終わった段階で既に時間を半分以上使っていて、問2のデッドロックの問題でフリーズしてそのままタイムアップ。

午後Ⅱ

敗因

安定の午後対策不足。同じ失敗を何度繰り返すのか……。

対策

午後Ⅰ・Ⅱの対策をちゃんとやる(特に午後Ⅱ)

これに尽きる。午後Ⅱが精神的にキツ過ぎるので、はじめは1問丸ごと片付けようと思わずに2日で1問やっつけるぐらいの心づもりでやる。

テキストに時間かけない

知り合いにテキスト読まない(読んでも1回、ノートはとらない)で問題集だけやる人がいるんだけど、私は理論を頭に入れてアウトプットに臨みたくなってしまうタイプでどうもテキスト→問題集のクセが染みついてしまっている。「問題集でよく出るところをテキストで抑える」のほうが効率がいい場合が多そう。いかにテキストを妥協できるか?いかに問題集での不正解の連続に耐えられるか?が私の資格試験全般に言える課題だと思う。

感想

DBについて

データベースを触ったことがない状態からのスタートだったので全てが新鮮だった。「候補キーを全て答えよ」とか「リレーションシップを完成させよ」系の問題で完全正解した時のカタルシスは、とにかくIPAのご機嫌取りに終始させられるNWにはない。ロジックだけで点が取れる優しい世界。

勉強の取り組み方

自身の勉強の取り組み方を見直す良い機会だったとポジティブに捉えておく。これで何かを変えないと本当にタダのグズ野郎なので、秋期のNWは テキストやりません。

Cybozu Meetup #2 SRE に参加してきた

概要

資料

docs.com

所感

顧客の増加傾向から見る設備投資

サイボウズは顧客の増加が単調(スライド27枚目)。サービスの需要予測が容易なので、無駄な設備投資の恐れがないんだそう。インフラって開発やデザイナーと比べるとビジネスが見えにくいから、たまにビジネスの傾向(サイボウズの場合は安定した顧客増)がインフラの領域に現れてくるのが新鮮で嬉しかったりする。私だけ?

オンコール当番制を可能にする要素

私がSREという試みにおいて関心を寄せていることのひとつに「如何にして夜間対応の準備をするのか?」があるんだけど、サイボウズはメルカリ同様2人1組でのオンコール当番制を採用しているとのことだった。

サイボウズのSREの皆さんはタレント集団という感じ(まさに「フレンズによって得意なことは違う」)で、「当番の2人ともが(スキルセット的に)対応できないことってないの?」って聞いたら「切り分けやプロセス再起動など最低限緊急対応に必要な水準は全員が満たすようにしている」とのこと。SRE Tech Talksでも思ったけど、オンコール当番制がきちんと回るかどうかって「最低限緊急対応に必要な水準=標準スキル」が定まっているかどうかが大きな要素だと思った。できることとそうでないことが人によって違う→2人ともできないから当番じゃない人叩き起こそう、なんてことが横行するようだとそうとう無理がある。

会社の制度によるサポートもまたポイントだと思っていて、メルカリもそうだけどよく夜間対応手当とか自宅勤務とかスピーディに導入できるよなあと思う。開発したツールのOSS公開について「ナレッジの公開って会社としてハードルないんですか?」って聞いたら@ymmt2005さんが「私が会社ですから」って言ってたのには超シビれた。"技術部署の偉いさんが技術の人である"っていう当たり前に思えるようなことが、こういうことを可能にするんだろうなー。弊社に合掌。

その他

  • 夜景きれい。27階すごい。
  • 本たくさん。ボドゲもたくさん。
  • 調達額すごすぎてボリュームディスカウント効きまくってるっぽい。標準PCのメモリが32GB?ストレージはMVNe 512GB?世の中じゃメモリ8GBが人権(最近16GBに上がった?)なんて言われている昨今、32GBものメモリを「標準」として乗っけられるサイボウズ、すごい。
  • テッキーな話もいいけど、ことSREに関しては今回のような仕組みの話のほうも気になっているので、色んな会社でSREチームが発足して、立ち上げノウハウみたいなのがある程度テンプレ化するといいなと思った。
  • ちょっとだけ期待していたネットワークの話はなかった。懇親会で少しお話聞けたからよかったかな。新卒の方(自分からSREチームを志願したらしい。すごい)もネットワークの自動化とかやっていきたいっておっしゃっていたと思うので、もし実現したら是非お話聞きたいです。

ホストであるサイボウズの皆さんだけじゃなくて、参加者の方ともたくさんお話できてよかったです。ありがとうございました。

フランクに原典にあたるということ

概要

最近RFCを読み始めた人の所感。

TL;DR

何らか調べものにおいて「原典にあたる」ということをはじめて教わったのは、マッキンゼー卒業生の人が書いた本だった。 これだったかな?

https://www.amazon.co.jp/マッキンゼー流-入社1年目問題解決の教科書-大嶋-祥誉/dp/4797369531www.amazon.co.jp

その頃はまだ前職に在籍していて、そんなに歳も変わらないのにかなり仕事のできるネットワークエンジニアがいた。彼はトラブルが起きた時の解決の手段として「RFCを読む」という選択肢を持っていて、ベンダマニュアルレベルで一通りの手段を試しても問題が解決しなかった場合、RFCに目を通してプロトコルの動きを確認していた。「当たり前だろ」と思う人もいるんだろうけど少なくとも私はそうじゃなくて、純粋に「すげーなこの人」と思っていた。

何が「すげー」かったのか?

純粋に「RFCを読む」ためには少なくとも英語が読めなきゃならない。今でこそ私も技術英語に慣れてきて、ベンダのKBぐらいならある程度の速度で読めるようになったものの、当時は今以上(以下というべきか)の英語弱者だったし、RFCはものにもよるけどボリュームがあるうえ抽象的な表現も多いし、トラブル発生時というのは通常業務に比べてインプットにかけられる時間も限られるので、そのスピード感の中であれを読むという選択肢は私は選べなかった。Google先生とベンダ、テクサポ頼み。エンジニアとしてはあまりかっこよくない。

最近の話

最近は業務に余裕が出てきたことと、もっと英語に慣れなきゃいけないということ、そしていい加減Google先生および「ネットワークエンジニアとして」離れをしなきゃならないという思いから、新しい技術に触れる時はRFCを読むようにしている。

しかし、RFCだけでそのプロトコルを理解しようとするのは中々にキツくて、他の日本語のドキュメントを参照してみたり、ツールを利用して少しでも読みやすくしたりしながら少しずつ読んでいる。

フランクに原典にあたるということ

はっきり言って今の私にとって原典(RFC)にあたるというのは結構なストレスだ。それでも、理解や問題解決の手法として「それ」を選べるということは、(業界で必須かどうかは一旦どうでもよくて)自意識のレベルで必要なことだと思っている。当たり前のようにRFCを読むということを選択できる彼のようには未だになれていないけど、いつか必要になる時のために、ヘルパーを頼りつつ目を通してみるのも悪くないと思う。

フランクに原典にあたるために使っているもの

「マスタリングTCP/IP」シリーズ

業界に飛び込んだ頃からの付き合いだけど、このシリーズの偉大さをあらためて思い知らされている。

www.amazon.co.jp

Google Dictionary Extension

ダブルクリックで単語を翻訳してくれる優れもの。Google翻訳が格段におりこうさんになったのは聞き及んでいるが、ページ丸ごと翻訳はしないという鉄の掟を守っている。

chrome.google.com

RFC読書会

……なるものをたまに見かける。気になる。一回身内(弊社内or同業の友人達)でやってみる?