マネージドサービス部 佐竹です。 以前 NAT Gateway 集約のためのネットワーク設計においてトラブルを発生させてしまったことがあり、その再発防止のためのブログを記載します。 はじめに 各 VPC ごとに NAT Gateway を構築した場合 NAT Gateway の利用料 AWS Transit Gateway を用いて集約する NAT Gateway 集約と経路設計 Transit Gateway を構築する Transit Gateway Attachment (Type VPC) を各 VPC で作成する 「VPC A」と「VPC C」の Subnet の経路を修正し、 NAT Gateway を削除する 一度ここで経路確認を行ってみる Transit Gateway のルートテーブルに「0.0.0.0/0」を追加する Reachability Analyzer での動作
うおおおおおおおおお!!! ってなったけどなんで歓喜しているんだっけ? こんにちは、のんピ(@non____97)です。 皆さんはNetwork Load Balancer (以降NLB) にセキュリティグループをアタッチしたいなと思ったことはありますか? 私はあります。 本日8/11についにサポートされましたね! 早速、偉大な先人がアップデートをまとめてくれています。 細かい仕様は以下AWS公式ドキュメントにも記載があります。 うおおおおおおおおおおおおお!!! という感じで目が覚めたのですが、なぜ私はこんなに歓喜しているんでしょうか。 この感情を言語化してみました。 いきなりまとめ クライアントIPアドレスを保持する場合、NLBを介さずに直接アクセスされるのを防ぐことが簡単になった 従来はターゲットのセキュリティグループでクライアントのIPアドレスからの許可をする必要があったため、NL
2021年、最もメジャーなWi-Fiの認証方式といったらWPA2-PSK(AES)かもしれないが、既にKRACKなどの脆弱性報告も2017年辺りからあり、常設のWi-Fi APにおいては可能な限り802.1X方式での認証を使いたい。*1 EAP-PEAPはIDとパスワードを覚えるのが煩雑なので、EAP-TLSで運用していたわけだけど、この度Android 11に上げた端末(Pixel 3a, Pixel 3a XL)で証明書を入れ替えたところ繋がらなくなったので試行錯誤。その時のメモ。 Android 11で追加されたWi-FiにおけるEAP-TLS認証に対する制約 ググったところ、最初に出てきたのが、2020年12月頃のアップデートで「CA証明書を検証しない」オプションが塞がれたという情報。 個人レベルで、機器毎に標準的なルート証明機関が署名しているCA認証局でわざわざ証明書を購入するこ
ども、大瀧です。 現在開催中のAWS re:Invent 2022で発表されたVPCの新機能、Amazon VPC Latticeをご紹介します。 VPC Latticeとは VPC Latticeはサービス間通信をシンプルに実現するVPCの新しい機能です。サービス間通信に利用できるAWSの機能としてELB(Elastic Load Balalncing)やAPI Gateway、RAMによるVPCサブネット共有などがありますが、VPC LatticeはVPCの一機能という特性を活かし、ネットワーク構成を極力意識せずに利用できる点や異なるAWSアカウントおよびVPCとの連携を一元的に扱える点がユニークと言えそうです。 VPC Latticeの構成 ELBの構成によく似ています。以下をそれぞれ設定し、サービス連携に利用します。 リスナ: 1つまたは複数のリスナを任意のポート番号とプロトコルで
前回は、ゼロトラストネットワーク(ZTNA)の学習用環境としてCloudflare Zero TrustのPOC環境を構築し、自宅の環境でも手軽にゼロトラストネットワークを体験出来た。 疎通確認としてYouTubeへのアクセスをBlockするポリシーを設定し、想定どおりアクセスをブロックさせる事が出来たが、今回はもう少し踏み込んだ内容でポリシーを設定してみた。 当記事は、ポリシーの設定および疎通確認のメモ。 前回の記事の内容、Cloudflareのアカウント作成からCloudflare Zero Trustの設定、そしてクライアント側の設定までの流れに関しては、以下のリンク先を参照。 https://debslink.hatenadiary.jp/entry/20221103/1667482863 Cloudflare Zero Trustを導入してみた - POC環境構築編 追加記事の内
This post is also available in: 日本語 (Japanese) Executive Summary This tutorial is designed for security professionals who investigate suspicious network activity and review packet captures (pcaps). Familiarity with Wireshark is necessary to understand this tutorial, which focuses on Wireshark version 3.x. Emotet is an information-stealer first reported in 2014 as banking malware. It has since evol
WireGuard® is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. It aims to be faster, simpler, leaner, and more useful than IPsec, while avoiding the massive headache. It intends to be considerably more performant than OpenVPN. WireGuard is designed as a general purpose VPN for running on embedded interfaces and super computers alike, fit for many different c
ここ1年くらい、OpenFlowが結構話題になっています。 最近はOpenFlow単体で語られるよりも、SDN(Software Defined Networking)の実現手法のひとつとして紹介されることも多いのですが、とにかく色々なところでOpenFlowの話題を耳にします。 話題の中には、日本でのOpenFlowを活用した新ビジネスの開始や、導入事例紹介もあります。 ただ、OpenFlowの話題に関して、日本とアメリカで随分と温度差を感じることもあります。 OpenFlowが産まれ、仕様が決定されている本場アメリカよりも、日本の方がOpenFlowに関して凄く盛り上がっているようにも思えます。 導入事例の方向性も多少違うイメージがあります。 アメリカでOpenFlowを活用している事例は、大規模データセンターを保有する企業が自力でOpenFlowを活用して柔軟に管理が可能なネットワー
iPhone 5 に変更するついでに、ソフトバンクモバイルさんから KDDI さんに変えて、実機環境で調べてみたメモ。 ・KDDI は iPhone 5 で 3G と LTE で、SBM は iPhone 4S で 3G のみ ・tracert には Nice Trace を利用 ・対象は、apple.com, facebook.com, google.com, twitter.com として、どのあたりのIPアドレスに名前解決するかは、環境にまかせる ・前提知識として、ソフトバンクモバイルはソフトバンクグループのソフトバンクテレコム(日本テレコム)のネットワークで外にでていくし、au は KDDI なんで基本自前のネットワークで出て行く。 結果詳細 ・どちらも端末に付与される内部 IP は 10.x.x.x のプライベートアドレス。今や SBM も NAPT の範囲が広がってるんですねぇ
ここ数日、8.8.8.8や8.8.4.4というIPv4アドレスを持つGoogle Public DNSに関する話題が盛り上がっているのですが、多くの人が「よくわからないけど設定変更したら早い!」と言っているので、そこら辺の話を調査してみました。 昨日、Twitterとブログでtracerouteやdigによる調査協力のお願いを発信し、8.8.8.8へのtracerouteを37件、8.8.8.8とISP DNSへのtraceroute比較及びAkamaiキャッシュサーバへのtraceroute比較を21件、日本各地及び海外のいくつかの地点からご協力頂けました(皆様ありがとうございました!)。 それらのデータをもとに、Google Public DNSを利用した場合の通信経路と、それによる遅延に関する検証を行いました。 Google Public DNSに対する私の感想 まず最初に。 調査前
先日の記事「OpenFlowの本質は「プログラマブルであること」」を公開したところ、多くの方にツイッターやブックマークでコメントをいただきました。その中にはOpenFlowに関する疑問、質問も含まれていました。 この記事ではその中からOpenFlowでよくありそうな質問を3つ、「OpenFlowのスケーラビリティ」「コントローラが単一障害点になる可能性」「トラブル時の切り分け」をピックアップして、OpenFlowについての講演なども行っている、NTTデータ 技術開発本部 ITアーキテクチャソリューションセンタ シニアエキスパートの樋口晋也氏に聞いたことをまとめたものです。 (本記事は「OpenFlowに関するよくありそうな質問と、専門家からの答え(前編)」の続きです。 コントローラが単一障害点になる可能性は? ─── OpenFlowのスケーラビリティには問題ないとして、もう1つOpenF
透過型プロキシ (Transparent Proxy) というのは、 ブラウザから 「見えない」 プロキシのこと。 ブラウザ自身は WWW サーバにアクセスしているつもりなのに、 ブラウザが送信したリクエストをプロキシが横取りし、 プロキシから出し直す。 サーバからのレスポンスは当然プロキシに返り、 プロキシがそれをブラウザに送信するのだけど、 パケットがブラウザに届くまでの間に送信元アドレスが書き換えられて、 サーバから直接レスポンスが届いたようにブラウザからは見える。 フツーの 「見える」 プロキシは、 ブラウザ等でプロキシ設定が必要であるのに対し、 透過型プロキシだと設定が不要。 だから一部の ISP (インターネット接続プロバイダ) などで、 フツーのプロキシの代りに使われていたりする (ユーザにプロキシ設定の方法を説明する必要がなくてサポートコストが削減できる)。 あるいは企業等
グーグル、マイクロソフト、Yahoo!、Facebookらが新しいネットワーキング技術の実現へ「Open Networking Foundation」を結成 サーバの仮想化やクラウドが普及したことで、「サーバを用意すること」の意味が、物理的なサーバを調達することから、サーバのインスタンスを立ち上げることへと変わろうとしています。いまではAPIを叩けば、CPUの性能やメモリ容量を指定し、いくつインスタンスを立ち上げ、いつシャットダウンするのか、すべてAPIから指定できる環境が広まっています。 同じことがネットワークでも起ころうとしています。現在のところ「ネットワークを構築する」こととは、ケーブルを引いてルータやスイッチの設定画面からルーティングやVLANを設定することです。設定されたネットワークは基本的にスタティックなものであり、構成を変えるには再びルータやスイッチの設定画面を開いて設定をや
The horrific earthquake and the ensuing tsunami in Japan have caused widespread damage to undersea communications, according to data collected by telecom industry sources. Initially, it was thought that the damage to the cables that connect Japan and Asia to each other and other parts of the world was limited, but new data shows the extent of the problems. According to research firm, Telegeography
サーバ間通信の有力な担い手 InfiniBandで変わるデータセンター内通信(前編) 松本直人 仮想化インフラストラクチャ・オペレーターズグループ チェア さくらインターネット研究所 上級研究員 2011/2/15 10年以上前から存在していた「InfiniBand」が、ここにきて、データセンターでのサーバ間通信を担う技術として急速に注目を集めるようになりました。その特徴と基本的な設定方法を紹介します。(編集部) 注目集めるInfiniBand InfiniBandは「インフィニバンド」と発音し、2000年に業界団体であるInfiniBand Trade Associationによって策定された規格です。スーパーコンピューティングなどHPC(High Performance Computing)分野で使われているサーバ間データ通信技術の1つです。 イーサネットによるLAN間接続と同様に、I
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く