以下の記事内容について、奥一穂氏（@kazuho）より、「connectのエラーコードが信頼できなくなるといった欠点もあるのに透過 SOCKS プロキシが汎用的に良いように読めてしまう」というご指摘をいただきました。確かに、下記内容は当社が抱えていた複数の課題を短期間で解消できる「ワークアラウンド」として透過 SOCKS プロキシという技法もあることを紹介したものであり、NAT と比較して常に良いという主張をしたかったわけではありません。また、記事内では解説を省きましたが、従来より HTTP(S) 通信は NAT ではなく HTTP プロキシを利用しています。謹んで補足・訂正とさせていただきます。 猫が好きだけど猫アレルギーで近寄ることができない山本泰宇です。 先日アーキテクチャ刷新プロジェクト「Neco」を紹介しましたが、今回はその活動の一環として実施したネットワークアドレス変換(NAT
こんにちは、arukasaです。 今回IPv6 (NAT64/DNS64) のWi-Fi環境構築という貴重な経験をしましたので、情報共有を兼ねて寄稿させて頂きます。 背景 Appleが、2016年1月以降はIPv6環境で動作しないアプリはリジェクトすると宣言しましたので、ミクシィ社内でもその検証環境が必要になりました。 現時点ではApple側も回線から上位はv4想定のようなので、検証環境もそれに倣いLAN側はIPv6、WAN側はIPv4の構成を取りました。 構成 ネットワーク uplinkはIPv4 only クライアントはIPv6 only サーバとASA間のみv4&v6 併用 機器構成 ASA 5505 ( NAT64 ) Raspberry Pi DNS64 (unbound 1.5以降) RA (radvd) Aruba (Wi-Fi) 実は構成が確定するまでが一番苦労した部分で、
タイトルは若干釣りです ;-) 一般的な Web サービスにおいて、VPC にプライベートサブネットは必要ですか？という話です。 VPC の設計でよくあるのが、パブリックサブネットとプライベートサブネットを持つ 2 層レイヤの VPC です。公式ドキュメントにも例があります。 シナリオ 2: パブリックサブネットとプライベートサブネットを持つ VPC パブリックサブネットがいわゆる DMZ セグメントで Web / App サーバが配置されます。プライベートサブネットはインターネットから隔離されたセグメントで DB サーバが配置されます。 このプライベートサブネットは AWS の良さを殺してしまうだけで意味がないと思っています（AWS を前提に書いていますが、オンプレミスにも同じことが当てはまると思います）。 プライベートサブネットが不要だと思うワケ Web / App サーバの設定ファイ
「LT駆動開発 15 - 水光紫陽花」に行ってきました。 LT駆動開発というのは参加者がそれぞれLT(ライトニングトーク)をして参加者自身が学ぼうという勉強会らしいです。 今回僕は「NAT超えってなんぞや」というタイトルで発表しました。 今回は時間上の都合で大まかな動作概要しか説明する事ができませんでしたが、詳細な仕様についてはRFCを参照していただければ幸いです。 STUNはRFC5769・RFC5389・RFC5780、TURNはRFC6156・RFC6062・RFC5766、ICEはRFC5245・RFC6544などに対応しています。 LT駆動開発はほぼ毎月開催予定ですが、ネタ系から技術系まで幅広いジャンルを受け入れてくれる雰囲気なので興味があれば参加してみてください。
WebRTC is secure,� or not secure? - WebRTC セキュリティ概説 -
「Raspberry Pi Model B+」を買いました。 Raspberry Pi Model B+ (Plus) 出版社/メーカー: raspberrypi.org メディア: エレクトロニクス この商品を含むブログ (1件) を見る SoftEtherについては、以前LIVAでインストールしたまま放置してましたが、このラズパイに再度インストールした上でVPNを実現します。 Raspberry Pi でSoftEther VPN 1.0 RC2を試す | よもやま雑記帳 を参考にさせていただきました。 なお、今回はwgetによるダウンロードではなく、直接HPからダウンロードしています。ラズパイの場合はSofEtherはOS: Linux、CPU: ARM EABI (32bit)を選択します。 ※セッティング方法を書こうと思いましたが、上記参考サイトとまるっきり同じなので割愛（手抜き
WebRTCにおけるNAT越えの課題へのアプローチ - Qiita に移転しました。
Wizardによる標準構成のVPCにおいてNATインスタンスはSPOFであり、インスタンス障害や、単一AZの障害、AZ間接続障害によっても両AZのインターネット接続性が損なわれる可能性がある。そこで、NATインスタンスをAZ毎に用意し、障害発生時にfailoverする仕組みを考えてみた。 方針 なるべくAWSの１リージョン内で完結し、別リージョンや外部に監視用ホストなどをおかない 瞬間的にフェイルオーバーはおこなわず、毎分ごとにインターネット上のターゲットIPへの疎通を確認し、障害と思われる状態になったらフェイルオーバーを行う 疎通が回復したと思われた場合には、元の状態に戻す 構成 非常にわかりづらい図になっていますが、構成要素としては Subnet x 4 (Public, Private を AZ毎に１つずつ) NATインスタンス x 2 (AZ毎に１つずつ、当然ElasticIPも1
こんにちは！がねこまさしです。前回は複数人の同時通話まで実現しました。社内で使うには十分なレベルです。 しかし本格的な企業ユースとなると、まだまだ障害があります。会社と家、自社と別の会社さんなど、実際に通信しようとするとNATやFirewallといった壁が立ちはだかります。 NATを越えよう NATの役割は NAT(+IPマスカレード)は企業だけでなく、一般家庭でも使われています。ブロードバンドルーターやWiFiルーターでは、1つのグローバルIPアドレスを、複数のPCやデバイスで共有することができます。このとき、NATには2つの役割があります。 インターネットにつながったグローバルなIPアドレスと、家庭内/社内のローカルなネットワークでのIPアドレスの変換 複数のPC/デバイスが同時に通信できるように、ポートマッピングによるポート変換 WebRTCでNAT越しに通信すること考えてみましょう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
