Category Archives: network

ブロードキャストドリーム

さてみなさん。GWはいかがお過ごしでしょうか。 まずはTCPのエコーサーバーとクライアント、続いてUDPでのエコーサーバーとクライアントと進みまして、そのまま進むとTCPのエコーサーバーでfork、thread、selectとなるのですが、その辺はひとまずメインディッシュにして先に進もうと思います。 こないだ作ったウェブサーバーにMIXできればいいですね。 シグナルのとこはちょっとあいまいなままですが、5章の後半にびゅーんと一気に進みます。 TCP/IP Socket in C の前からですが、ずーっと1対1の通信ですたね。 これはユニキャストと言うて、ユニはラテン語で1を指すらしい単語らしいです。 なんで1だけラテン語なんでしょうか。 今回はブロードキャストをやってみますですが、ブロードキャストというと全体に送信するよ~という事くらいしか知らなかったですが、本の解説で書いてあったのだが、転送レートが3Mbpsとしてユニキャストで1Mbpsで送信すると3ユーザーしかサポートできないけど、ブロードキャストやマルチキャストを使って、コピーをネットワークに任せる事で、クライアントへの送信を1Mbpsのストリームで済むという解説がしてあって、にゃるほどなあと思いました。 それと同時にですが、ストリームからストームへっていう言葉のチョイスを思い出して、車田正美さんは時代を先取りしていたんだなぁと・・・ゴゴゴ。   それでは、今回の試みですが、今回は本のサンプルコードを使って、サーバー側からストリームな感じを体験しようと思います。 ブロードキャストにも2種類あって、有名な255.255.255.255はローカルブロードキャストアドレス、もう1個は特定のネットワーク内にたいする送信で、ダイレクトブロードキャストアドレスといいます。 画像がちょと見づらいかもですが、一番下が送信者、2番目がレシーバーです。なんですが、ブロードキャストで送信しているので、ネットワーク内の端末すべてが受信している確認です。 分かりやすくしようと思って、連打してますが余計分かりづらくなったかも・・・ まずはダイレクトブロードキャスト、うちのLANは192.168.24.0の/24になっているので、192.168.24.255です。 ローカルセグメントの192.168.24.以下にいってるのが分かりますな。 続いてローカルブロードキャスト。なんだかどっちか間違いそうなネーミングだね。 こんな感じです。一緒じゃん! サブネットでネットワークを分けての実験はやってないんだな。これが。 手抜きでごめんなさい。 ちなみにブロードキャストストームを扱った記事はこちらになります。 STPの実験をしようとしてもできなかったのだが、何かが起きたのでSTPを有効にしてみたら解決した。 偶然ブロードキャストストームが発生してしまった例になります。   てな感じで今回は終わりです。タイトルには意味がないですが、夢がひろがりんぐみたいな感じで、なんとなく語呂がよかったんでタイトルにしてみました。 ばいばいきーん。  

UDPよりTCPの方が??

昨日に引き続いてソケット通信な話です。 conntrack-toolsを導入してパケットの流れを見たりしてる今日この頃ですが、流れを見たときに conntrack v1.2.1 (conntrack-tools): 19 flow entries have been shown. こんな感じで表示されるんですけど、flowってなんやと思たのでちょこっとググってみました。 正しいのかどうか分からないけど、おそらくnetwork flowのflowのことだと思う。 ネットワークの頂点をノード、枝をアークと呼ぶ。1つのノードに流入するフローとそのノードから流出するフローは常に等しい。なにかに例えるとすると、道路網の交通量、パイプを流れる液体、電気回路を流れる電流とかみたいです。なんとなくイメージはできたかもしれない。   んで、敵を知るにはまずは味方からという事でこのflowをおーばーどらいぶー!っという感じで大量に流してみたいと思った。のだが、これがなかなか手ごわい。結果を言うとこの戦いはまだ終わっていないのだ。   とりあえずPythonなら何とかなるので、PythonのDoSのプログラムを拾ってきてVM同士で流してみることにした。 というかCが多いんだな。ただソケットなら同じものが使えたりするのでそこそこ役にはたった。 学生時代に中途半端にやってたからおじさんになってから苦労するんだよ。   ちょっと話が逸れてしまったが、パケットをガンガン流してもどういう事か最大でも5万flowくらいにしかならず。オプションEで監視してみるとdestroyということで破棄か何かになっているみたいだ。新しい接続も追いついてないみたいでそれで最大でも5万flowとな。 これがうちのネットワークの限界かどうかも分からないので、ためしにVM4個にそれぞれプログラムの配置をしてホストに向かって一斉に流してみたが、これってDDoSにあたると思ったんだけど、これも何故か分からないけども、5万flowにしか届かず。   これはもうプログラムの書き方に問題あるのかもしれないなあと思ったので、UDPのブロードキャストを飛ばすPythonのプログラムを拾ってきて、ちょっと改変して1~65535ポートまでガンガン流すプログラムにいじって実行してみた。 やはり記述が問題だったようで、今度は20万flowまでいった。 でも、これも最大で20万。これが限界なのかー! と思ったが、イメージ的にTCPよりUDPの方が確認をせずにドバドバ流すから大量にflowが流れると思ったんだけど、なんとなくTCPのプログラムに変えてみた結果なんと50万flowに達した。   しかしこれもflowの最大値は上がったのだけど、いくら流してもパケットドロップまでは起きなかった。 ちなみにだけど、ブロードキャストに流してみてサーバーの隣のWindowsにどれくらい影響があるか試してみたら、flowが5万くらいのプログラムですら20Mbpsくらいの帯域を使ってた。 こわいこわい。 CTUは超えないはずなので問題ないけど、一歩間違えたらえらいことになっちゃうから、気を付けるようにした方がいい。 論よりコードというけれど、今回の話は公開はしないです。あとちょっとだけ試してみようかなあと思ったけど、やっぱりやめたOpenflowというのがあって、これはflowtableでflowの制御ができるものみたい。 動的にネットワークを作れるのだそうだ。 ちまたで有名なSDNってやつみたい。SDN48ってあるの最近知ったけど、まったく関係ない(笑) CDNとか3文字ばっかりでややこしいんだー。  

Conntrack-toolsであそぼう

みなさまメリクリます。 いつかapt系を使うようになったらやろうと思ってたのだけど、(でもrpmでもあるようだ)conntrack-toolsというのがある。 とりあえずTCPについてちょっと高校の教科書くらいな感じで補足を書く。 クライアント サーバー SYN     → ←  SYN+ACK ACK     → こんな感じで相手の確認をしてから手をつなぐ3ハンドシェイクという接続です。確認するので信頼性が高いです。 逆にストリーム動画なんかで使われてるのはUDPというのです。簡単に書くと送りっぱなしジャーマンです。 Conntrack-toolsはこいつの状態をチェックしたり、切ったりするツールです。 インストールですが、aptの場合は $ sudo aptitude update $ sudo aptitude install conntrack conntrackd これでOKです。 それではPythonのポートスキャンのプログラムをやってみよう。向きはVM1からVM2へ飛ばします。 どうなるかっなー、はてはてふふ~。     [NEW] tcp      6 120 SYN_SENT src=192.168.24.100 dst=192.168.24.102 sport=21640 dport=213 [UNREPLIED] src=192.168.24.102 dst=192.168.24.100 sport=213 dport=21640 [DESTROY] tcp      6 src=192.168.24.100 dst=192.168.24.102 sport=21640 dport=213 [UNREPLIED] src=192.168.24.102 dst=192.168.24.100 sport=213 dport=21640     [NEW] tcp      6 120 SYN_SENT src=192.168.24.100 dst=192.168.24.102 sport=21641 dport=214 [UNREPLIED] src=192.168.24.102 dst=192.168.24.100 sport=214 dport=21641 [DESTROY] tcp      6 src=192.168.24.100 dst=192.168.24.102 sport=21641 dport=214 [UNREPLIED] src=192.168.24.102 dst=192.168.24.100 sport=214 dport=21641     [NEW] tcp      6 120 SYN_SENT src=192.168.24.100 dst=192.168.24.102 sport=21642 dport=215 [UNREPLIED] src=192.168.24.102 dst=192.168.24.100 sport=215 dport=21642 [DESTROY] tcp      6 src=192.168.24.100 dst=192.168.24.102 sport=21642 dport=215 [UNREPLIED] src=192.168.24.102 dst=192.168.24.100 sport=215 dport=21642     [NEW] tcp      6 […]

なぞの帯域制限?

ちわ~、たけけんです。 まずはこのZabbixの画像を見てください。 この画像は、Zabbixのウェブ監視の機能で(たぶん)ブラウザからアクセスしたときの速度をはかっています。 んで、左の方を見てみると、ググっと数値が下がったところがあります。これはZabbixを設定してからだいたい1日経ったくらいですかね。監視の設定をした後にグラフをちょこちょこ見たりはしないんで、気づいたのはつい最近でしたのでした。 サーバーが落ちてた訳じゃないしねー。 当時の記憶はほとんど残ってないんだけど、何をしてたか考えると、まず出てくるのがやっぱりpagespeedだ。 とりあえずoffにしてみたけど変わりないし。と、唐突に今思い出したのだが、そういえばpagespeedを全体に効かせてたのをVhostだけにしたんだったなあ。なんだできるじゃん!ってやったのが多分時期が一致?? もしかしてそれかも・・・と。 何かを文字にしてみるというのは、なかなか脳を刺激するんだなあと思ったな(笑)   では、さっきまでは何をしてたかというと帯域制限といえば、まずは過去にやったmod_bwを思い出した。 またこないだの、Xcacheみたいに設定したときからそのまま放置しているんじゃあ!と思って調べてみたけど、さすがにこれは放置はされておらずに、跡形ごとなくなっていました。 あと気になるのはpagespeed.confの中に、なにか制限をするもののような記述があるのかどうか。だね。 ざっと抜き出すと。 # grep -v ‘#’ /etc/httpd/conf.d/pagespeed.conf | grep -v ‘^$’ <IfModule !mod_version.c>   LoadModule version_module /usr/lib64/httpd/modules/mod_version.so </IfModule> <IfVersion < 2.4>   LoadModule pagespeed_module /usr/lib64/httpd/modules/mod_pagespeed.so </IfVersion> <IfVersion >= 2.4.2>   LoadModule pagespeed_module /usr/lib64/httpd/modules/mod_pagespeed_ap24.so </IfVersion> <IfModule !mod_deflate.c>  LoadModule deflate_module /usr/lib64/httpd/modules/mod_deflate.so </IfModule> <IfModule pagespeed_module>     ModPagespeed off     ModPagespeedInheritVHostConfig on     AddOutputFilterByType MOD_PAGESPEED_OUTPUT_FILTER text/html     ModPagespeedFileCachePath            “/var/cache/mod_pagespeed/”     ModPagespeedEnableFilters rewrite_javascript,rewrite_css     ModPagespeedEnableFilters defer_javascript     ModPagespeedFileCacheSizeKb          102400     ModPagespeedFileCacheCleanIntervalMs 3600000     ModPagespeedLRUCacheKbPerProcess     1024     ModPagespeedLRUCacheByteLimit        16384     ModPagespeedCssFlattenMaxBytes       2048     ModPagespeedCssInlineMaxBytes        2048     ModPagespeedCssImageInlineMaxBytes   2048     ModPagespeedImageInlineMaxBytes      2048     ModPagespeedJsInlineMaxBytes         2048     ModPagespeedCssOutlineMinBytes       3000     ModPagespeedJsOutlineMinBytes        3000     ModPagespeedFileCacheInodeLimit        500000     […]

Vyattaで遊ぼう、NATの設定をしてみよう。

前回までに作成したVyattaの輪にサーバーを付け足そうという試みでござる。サーバーを付け足しただけだと、ネットワーク内の通信には問題ないけど、それだとつまらないのでとりあえずPINGとかWHOISとかYUMのアップデートくらいはできるようにした。 ようするに外にパケットが出るようにしたのです。なんかうまく説明ができないw パケットを外に出すとなると、NATの設定の出番という訳ですが、作ったVyattaの全部にNAT設定が必要なのかというと、そんなことはなくて、デフォルトゲートウェイにあたるVyatta1だけでOKです。 ネームサーバーはCTUのアドレスでOKです。が、そうなるとCTUまでもパケットが届く必要もあるのです。 CTUはもちろんすでにNATされているので設定不要です。 という仮説を考えてみたのですが、実験の結果はまったく問題なしですた。   まず図を載せてみる。 つーかさ、VMを6つ起動しているのでパソコンが重たいのだが!!こんなに貧弱なパソコンだったとは。 けっこう悲しいけど、それは置いといてネットワークの構成はこんな感じになっています。   サーバーの設定は/etc/sysconfig/network-scripts/ifcfg-eth0と/etc/resolf.confの設定をしたのみになっています。まずはVyatta1のNAT設定から載せてみる。 vyatta@vyatta# show nat  source {      rule 1 {          outbound-interface eth0          source {              address 192.168.20.0/24          }          translation {              address masquerade          }      }      rule 2 {          outbound-interface eth0          source {              address 192.168.22.0/24          }          translation {              address masquerade          }      }  } [edit] 設定はsetから順にコマンドを入れていきますが、自分が持っていたVyattaはバージョンの6.4ですが、6.3と6.4で仕様が変わっているようでして、RIPの設定をしたときにコマンドが違っていたのはそのためのようでした。 以下はshow systemの結果の1部分になります。Vyatta2~4は同じなので端折ってます。 Vyatta1  gateway-address 192.168.24.1  host-name vyatta  name-server 192.168.24.1 Vyatta2/3/4 gateway-address 192.168.20.1  host-name vyatta2  name-server 192.168.24.1 NATの設定は内から外向けにしかしてませんので、もちろんこのWindowsパソコン(192.168.24.51)からはパケットは届きません。 よって直接SSH接続はできません。    IPv4 アドレス . . . . . . . . . . . .: 192.168.24.51    サブネット マスク . . . […]

見よう見まねでVyattaでOSPFを試してみた。

昨日のRIPに続いて今日はOSPFをやってみたいと思います。 参考にしたサイトは昨日と同じで、今回は技術評論社のVyatta入門も参考にしました。   構成もRIPと同じく以下の図です。 けしてイカロスではありません。   今回やった設定は参考サイトのままになってます。 vyatta1 set protocols ospf parameters router-id 127.0.0.1 set protocols ospf redistribute connected set protocols ospf area 0.0.0.0 network 192.168.20.0/24 vyatta2 set protocols ospf parameters router-id 127.0.0.2 set protocols ospf redistribute connected set protocols ospf area 0.0.0.0 network 192.168.20.0/24 set protocols ospf area 0.0.0.0 network 192.168.22.0/24 vyatta3 set protocols ospf parameters router-id 127.0.0.3 set protocols ospf redistribute connected set protocols ospf area 0.0.0.0 network 192.168.20.0/24 set protocols ospf area 0.0.0.0 network 192.168.22.0/24 vyatta4 set protocols ospf parameters router-id 127.0.0.4 set protocols ospf redistribute connected set protocols ospf area 0.0.0.0 network 192.168.22.0/24   今回もVyatta1からVyatta4へPINGを飛ばして、Vyatta2を停止、んでからVyatta2を起動して、今度はVyatta3を停止してみた。 上がVyatta2を停止した時、下がVyatta3を停止した時。 64 bytes from 192.168.22.4: icmp_req=80 ttl=63 time=0.424 ms 64 bytes […]

見よう見まねでVyattaでRIPのテストをしてみた。

今回からはルーティング第1弾ということで スタティックなルーティングではなくて、ダイナミックにルーティングしてくれるプロトコルで、参考書の一番最初に出てくるようなシンプルな動きをするRIPのテストを試してみたナウ。 SPECー天ーの栗山千明みたいな言い方になってるが気にするな。 とにかく見よう見まねで、コマンドはTAB補完で出てこなかったのでとりあえず適当にやってみたけど、動いたので記事にしてみる。 Vyattaの初期設定とEtherNetの設定は省略する。 ただVMwareの設定は外につながっているVyatta1サーバーのeth0だけはCTUと直接つながっている。 よってSSHを起動させて、Windowsからターミナルで接続可能にした。 設定はこんな感じで、参考サイトとかなり似ているが多少違うところは注意が必要。 vyatta1 set protocols rip redistribute connected set protocols rip network 192.168.20.0/24 vyatta2 set protocols rip redistribute connected set protocols rip network 192.168.20.2/24 set protocols rip network 192.168.22.2/24 vyatta3 set protocols rip redistribute connected set protocols rip network 192.168.20.3/24 set protocols rip network 192.168.22.3/24 vyatta4 set protocols rip redistribute connected set protocols rip network 192.168.22.4/24 今までの知識からするとVyatta1からVyatta4へはNATの設定をしないと、別のネットワークの192.168.22.4とは通信できないはずだけど、RIPの設定をすると通信ができた。 これがルーティングというやつか。 実際に見て見るとおもしろい。 今回はちゃんと図を作った。   動作確認という事で、vyatta1からvyatta4へPINGを打ち続けて、Vyatta2を停止してみた。 見せてもらおうか、動的なRIPの性能とやらを。 vyatta@vyatta:~$ ping 192.168.22.4   PING 192.168.22.4 (192.168.22.4) 56(84) bytes of data. 64 bytes from 192.168.22.4: icmp_req=1 ttl=63 time=0.546 ms 64 bytes from 192.168.22.4: icmp_req=2 ttl=63 time=0.820 ms 64 bytes from 192.168.22.4: icmp_req=3 ttl=63 time=0.833 ms 64 bytes from 192.168.22.4: icmp_req=4 ttl=63 […]