こんにちは。アマゾンウェブサービス（AWS）サポートの有賀と申します。好きなサービスはAmazon Virtual Private Cloud（VPC）です。これからAWSサポートの各メンバーがそれぞれ「今一番AWSユーザーに伝えたいこと」を連載の形でお届けしていきます。筆者の担当する本稿では、AWSの「ネットワーク」について見ていきたいと思います。今回は、ネットワークの「論理設計」について解説します。 本稿でお伝えするのは下記の第2回の内容です。全3回に渡って解説していきます。 AWSのネットワークの物理的な側面 ⇒ 第1回 AWSのネットワークの論理的な側面 ⇒ 第2回 AWSのネットワークにおけるベストプラクティス ⇒ 第3回 AWSのネットワークにおいて過去に発生した問題の事例 ⇒ 第3回 必ずしもAWSの使い方といった内容ではないので、今日すぐに使える知識にはならないかもしれませ

はじめに インフラ構築やアプリケーションのネットワーク構成を設計する際、ルーティングの動きさえ分かっていれば、ルーティングテーブルに何を設定したら良いのか、どのように結線したら良いのかなどが分かると思います。そこでルーティングの基本の基本をメモとして記載します。IPアドレスやセグメント(=サブネット)についても説明しようと思いましたが、長くなるのでこれらについては知っているものとします。 ルーティングとは ルーティングとは、特定の宛先IPアドレス(またはセグメント)に向けて送信された通信パケットを、どのネットワークインタフェースから送出したら良いかの対応付けのことです。この対応付けの一覧のことをルーティングテーブルと言います。 言葉だけだと分かりづらいので絵で説明します。上の絵の色のついた小さい四角はネットワークインタフェースを表しています。色はセグメントを表していて、同じ色は同じセグメン

Linuxのファイアウォール「iptables」について入門から実践まで解説 数回に分けてLinuxのファイアウォール「iptables（アイピーテーブルズ）」について解説します。 ネット上に有益な設定が溢れているので、あまり理解しないままコピーペーストで運用している方も多いはず。 しかしそれでは実際に攻撃された際に対処できません。 そこでこのページでは、初めてファイアーウォールについて学ぶ方でも理解できるように、全体像と細かな設定の意味について解説します。 目次 ファイアーウォールの種類 NATについて パケットフィルタリングの概要と書式 テーブルについて チェインについて オプションについて パラメータについて 拡張パラメータについて iptablesの記述順序とルールの適用順について ポリシーについて ファイアーウォールの種類 ファイアウォールと聞いて、まず何を思い浮かべるでしょうか

昨年の12月頃らしいですが、GCEでもSubnetがサポートされました。最初、これを知った時 なんて無駄な機能をつけたんだ！Googleのパワーをこんなしょうもないことに使うな と思いましたが、調べてみるとGoogle流の考慮は入っていました。 ひとまず、このエントリに引っかかった人は、最後まで読んでください。tl;dr とかでは表せませんが、無理やり概要をまとめると、 GCEもsubnetという太古のダサい技術をサポートしてしまったが、他のパブリック・クラウドとは一味ちがうから安心して！ となります。 今までのGCE:Network GCPドキュメント上では、Legacy mode と書いていますが、こちらのほうが よっぽど先鋭的 です。簡単にまとめると ローカルIPアドレスの CIDRだけ指定する そのCIDRは全リージョンにまたがる たったこれだけです。AWSで言い換えると 全リージ

前回の続きです。 前回はネットワーク周りの設定を何もせずにKVM仮想マシンを作成しました。 この状態だと、ゲストOSはネットワーク的に孤立した状態となっていて外部と通信できません。 そこで今回はこのマシンからホストOSを通して外部に通信できるようにしていきます。 現在の設定内容の確認 まずはホストマシン、ゲストマシンそれぞれ現在どのようになっているかを確認しておきましょう。 ほぼろの環境では下記のようになっていました。 $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_

相手先のIPアドレスがわかるなら、そこだけにユニキャストで１対１で通信知ればいいじゃん！と思ってしまいます。L3視点でみると。しかしARPプロトコルではブロードキャストを利用します。 なんで？おかしくない？ まぁ、答えは、IPアドレスだけでは通信はできない、MACアドレスを知らないと通信ができないから。IPアドレスはあくまでも理論的なアドレス。物理アドレスであるMACアドレスを知らないと、通信は行えない。 と、まーた悩んじゃったので書き出しておいて、いつかまた悩んだときに読み返すために備忘録。思考の足跡にでもなれば。 でも文章にするのは難儀なので箇条書きでいこうｗ ARPが必要な理由とか 最終的に、MACアドレスを知らないと機器同士（カッコよく言うとノード間）の通信は行えない。 でも大体相手のIPアドレスしか知らないよねー IPアドレスからMACアドレスを知る。それがARP。 え？じゃあど

前回は、NTT東西がIPv6サービスを提供する必要性と意義について解説した。続いては、NTT独自の理由から2種類の方式が提供される同サービスの仕組みを紹介しよう。 独特なNTT東西のネットワーク サービスや機能の説明に入る前に、NTT東西とそのネットワークについて簡単におさらいをしたい。NTT東西は会社としてもネットワークとしても、他に国に例を見ない、かなり特殊なものだ。 NTT東西のサービスを理解する上で、2つのことは必ず知っておかなければならない。 NTT東西は直接のインターネット接続サービスを提供しない。ISPが行なう。 NTT東西はIPv6による巨大バックボーンネットワークを持っている。 NTT東西は、ユーザーに対してインターネット接続サービスを提供しない。インターネット接続サービスを提供しているのは、BIGLOBEやOCNといったISPである。たしかに、OCNはNTTグループのN

Internet Week 2014 「初めての人のためのインターネットルーティング」より https://internetweek.jp/program/t04/ Read less

ネットワークの世界じゃ、有名(だと思う)な、ともちゃさんが個人でBGPのASNを取得したようです。 ともちゃ日記 – 元大学生のぐだぐだ日記、ジジイと呼ばれたOL生活- Foundary機器を利用してBGP4を利用していた経験からすると、個人でASN取得したり、運用しようと思うこと自体がすごいなぁ。 そもそも、BGP(Border Gateway Protocol)ってなに？ ほとんどの場合は、BGP4というルーティングプロトコルのことを指しています。で、このプロトコルはなにかというと、実質的に今のインターネットすべてのネットワークを支えているといっても過言ではないプロトコルなのです。 インターネットの世界はIPアドレスでホストの居場所を探すわけですが、このIPアドレスは基本的にはネットワーク帯ごとに事業者などに割り当てられます。この事業者は割り当てられたネットワークをインターネットのどの

2017/04/20 Kubernetes Meetup Tokyo #4

何の話かというと Kubernetesの環境をセットアップする際は、コンテナ間で通信するための内部ネットワークを用意する必要があり、このためのツールとして、Flannelがよく利用されます。この時、バックエンドにVXLANを指定すると、物理ネットワークの上にVXLANによるOverlay方式で内部ネットワークが構成されます。 ここでは、Flannelが構成する内部ネットワークの仕組みを解説しつつ、VXLANについて学んでみたいと思います。RHEL7.1でKubernetes+Flannelの環境を構築する手順は、下記を参照ください。 RHEL7.1でKubernetesを実体験（構築編） Flannelが構成する内部ネットワーク 上記の手順で環境構築すると、下図のように内部ネットワークが用意されます。各ノード（Minion）には、VXLANデバイス「flannel.1」が作成されて、VXL

IPv6接続の新しい方式？ 本日もIPv6関連のお話です。先日プレスリリースで発表いたしましたが、7月21日より家庭向け(ブロードバンド回線向け)の新しいIPv6接続サービスが始まりました。 NTT東西の「フレッツ光ネクスト」回線に対応した「IPoE方式 (旧称:ネイティブ方式)」のIPv6サービスです。 IIJ、個人向けサービスでNTT東西の新たなIPv6接続方式に対応したサービスを開始 IIJmio FiberAccess/NF いろいろな方法があってそろそろ皆さん混乱されているのではないかと思います。このblogでも、フレッツ光ネクスト PPPoE方式(トンネル方式)・IPv6仮想アクセスなど、家庭用IPv6接続サービスの紹介をしましたが、今回のはそれとどう違うの？という疑問はもっともかと思います。技術的な面からその違いを説明することもアリですが、今回は【試してみた】記事と言うことで

最近というほど最近でもないんだけど、近頃はとにかくフレッツ回線のスループットが出ない。 下手をすると、モバイルネットワークの方が速いので時間帯によってはテザリングをし始めるような始末だった。 今回は、そんなスループットの出ないフレッツ回線を何とか使い物になるようにするまでの流れを書いてみる。 先に断っておくと、今回はいつものような特定の技術に関する解説という側面は強くない。 思考の過程なども含んでいるので、いつもより読み物的な感じになっていると思う。 調べ物をして、それらについて理解した内容のまとめになっている。 結論から書いてしまうと、今回のケースでは IPv6/IPoE 接続と DS-Lite を使って何とかなった。 DS-Lite というのはゲーム端末ではなくて IPv4/IPv6 共存技術の一つである RFC6333 (Dual-Stack Lite Broadband Deplo

Google によるフルマネージドサービスである GKE では Kubernetes のマスタやノードのことは理解しなくとも Kubernetes の API を使って実現したいことに集中できる。 しかし、本番運用をはじめてから「なぜ動いているのかもなぜ動かないのかも分からない」というような状態ではいざという時に困る。 特に Service がどのようにクラスタの外から Pod へのアクセスを提供しているのかはブラックボックスになっていたため、今回は GKE での Service の L3(〜L4) の挙動について Kubernetes の内外を調査した。 (後で図や参照情報へのリンクを追加予定) 図解が出てきたので追加しなかった。 追記(2018年10月5日) Kubernetes Engine の Network Overview が良いのでこちらも読むと良いでしょう。この記事を書いた

前回、「次回もシグナルのことを書く」と書いたのでシグナルのことを書く*1. ソケットプログラミングの落とし穴は色々あるけど、ここでは個人的に嵌ったシグナル関連の落とし穴に関して書き殴る． 結論から書くと、コネクションが切れたソケットに書き込み(send(2)とかwrite(2)とか、同じものだけど)を行うと、SIGPIPEシグナルが発生してプロセスが強制終了するので、きちんとSIGPIPEシグナルをハンドリングしておこうという話． 以下では、サンプルコードを使って、実際にパイプの書き込み先をkillして、SIGPIPEの発生を疑似体験してみる． SISGPIPEを受けたプロセスの挙動とソケットプログラミングでの対応策 「sigpipe」で検索すると、同様の話はいくらでも記事になっていて、例えば、 「私の書いたサーバが突然死するんです。どうしてでしょうか」という質問を受けることがあります。こ

改造Firefoxで日米間6.5GbpsのWebアクセス。東大が世界最速達成 -BB Watch より。私は 1Gbps 以上の世界は完全に未知の世界なので、今回の記事は「どうやって 6.5Gbps ものデータ転送速度を達成するか」ではなく「何故、改善前は（そんな高速ネットワーク環境下で） 6Mbps 程度のデータ転送速度しか出せないのか」と言うお話です。 TCP のデータ転送（ダウンロード）では、ソケットバッファの値を弄っただけで劇的にデータ転送速度が改善される場合があります。 ソケットバッファとは？ あるサーバ/クライアント間でデータ通信をする際、パケットが、受信ホストに到着するタイミングと（受信ホストの）アプリケーションが、到着したパケットを読み込むタイミングは非同期です。そのため、パケット（データ）は到着したのだけれどアプリケーションがまだ読み込みに来てくれないと言う場合に、そのデ