-
ARPが正しいのに通信できない時に疑うべきポイント【L2正常でも止まる理由】
arp -a で確認するとMACアドレスは正しい。 スイッチのMACテーブルも正常。 それなのに通信できない。 この状態は、 ARPが原因ではありません。 本記事では、 ARPが正常なことをどう確認するか L2が成立しているのに止まる代表パターン どこまで到達してい... -
CDN＋LB＋nginx構成でIP制御を安全に行う方法【X-Forwarded-For設計の正解】
CDN＋ロードバランサ＋nginx構成でIP制限を実装する場合、 正しく設計しないとIP制限は簡単に突破されます。 よくある誤解： X-Forwarded-Forを見ればクライアントIPが分かる real_ip_recursiveをonにすれば安全 CDN配下ならIP偽装はできない すべて不十分... -
real_ip_recursiveを誤解すると起きる事故（IP偽装を招く設定ミスの正体）
nginxでX-Forwarded-Forを扱う際、多くの現場で見落とされているのが real_ip_recursive の正しい理解 です。 「とりあえずonにする」「サンプル通り設定する」 この状態で本番運用すると、 IP制限が突破される重大事故 が起きます。 本記事では、 real_ip... -
real_ip_header / set_real_ip_from の正しい設計（X-Forwarded-Forを安全に扱う方法）
ロードバランサ（LB）やプロキシ配下でnginxを使う場合、 real_ip_header / set_real_ip_from の設計を誤ると、IP制限が簡単に突破されます。 にもかかわらず、 とりあえずX-Forwarded-Forを使う サンプル設定をそのまま流用する といった導入が非常に多い... -
X-Forwarded-Forを信頼してはいけないケース（誤判定・事故を防ぐ判断基準）
ロードバランサ（LB）配下のHTTP/HTTPS構成で、 「クライアントIPはX-Forwarded-Forを見ればいい」 と説明されることは非常に多いです。 しかし実務では、 IP制限がすり抜ける ログのIPが信用できない 攻撃元を誤認する といった事故が、X-Forwarded-For（... -
Proxy Protocol導入時に必ずハマる罠（通信断・誤判定の正体）
ロードバランサ（LB）配下でクライアントIPを保持するために、 「Proxy Protocolを有効にしました」 ──その直後から、 通信できなくなった アプリが応答しない ログが壊れた というトラブルに直面するケースは非常に多いです。 Proxy Protocolは便利ですが... -
SNATありLB構成でクライアントIPを扱う設計判断（なぜ迷うのか・どう決めるのか）
ロードバランサ（LB）構成でよくある悩みが、 「SNATを有効にするとクライアントIPが見えなくなるが、これは問題なのか？」 というものです。 ログにLBのIPしか出ない アクセス制御ができない でも通信自体は正常 この状態で、 「SNATを切るべき？」「Prox... -
ロードバランサ配下で戻り通信が消える典型パターンと切り分け方法
ロードバランサ（LB）配下のシステムで、次のような現象に遭遇したことはないでしょうか。 クライアントからの通信はLBに届いている バックエンドサーバにも到達している しかし、レスポンスが返ってこない このとき多くの現場で言われるのが、 「ルーティ... -
ルーティングは正しいのに戻り通信が来ない時の切り分け（非対称通信の落とし穴）
ネットワークトラブルで特に厄介なのが、 「ルーティングは合っているのに、なぜか通信が成立しない」 というケースです。 pingの送信は出ている ルートも正しい tcpdumpでも送信は見える それでも戻り通信が来ない。 この状況は、単なるルーティング問題... -
ARPキャッシュとMACテーブルの違いと切り分け方法（L2通信障害の最短ルート）
ネットワークトラブルの現場で、 「ARPがおかしいのか？MACテーブルがおかしいのか？」 と迷ったことはないでしょうか。 この2つはどちらもL2に関係しますが、 役割・保持主体・障害の出方がまったく異なります。 混同したまま切り分けを進めると、 確認ポ...
