VPN の背後で PHP の REMOTE_ADDR が実際に語るもの

VPN 利用者が、ゲートウェイに属するアドレスで、あるいは昼食後に変わったアドレスで、アプリケーションのログに現れるのはなぜか、という質問があります。答えはまず、この値が何であるかから始まります。ウェブサーバーがリクエストの環境に置いた一項目です。トンネルへの問い合わせではなく、証明書の身元でもなく、その番号が一人のものだという約束でもありません。この三つのどれかとして読むと、それぞれ違う形で間違った、自信に満ちた答えが生まれます。

値はサーバーから来るのであって、トンネルからではない

PHP はリクエストの環境を、スクリプトを実行したものから受け取ります。PHP のサーバー変数のリファレンスは、これらの項目をウェブサーバーが作ったものと説明し、その可用性はリクエストがどう届いたかによるとしています。

VPN のコマンドラインフックとして走るスクリプトは、まったく別の実行コンテキストです。ウェブリクエストもクライアントソケットも REMOTE_ADDR もなく、だからこそフックにコピーしたウェブのコードは、誤った値ではなく空の値を返します。フックにはデーモンが埋める独自の環境があり、それは別に文書化されています。そこで REMOTE_ADDR を求めるのは、一度も設定されていない変数を求めることです。

二つのログを比べる前に、この違いを覚えておいてください。ページのリクエストとフックを比べているのかもしれず、それは比較にすらなっていません。まず実行コンテキストを確認し、そのあとでアドレスを見てください。

番号を信じる前に、リクエストの経路をたどる

報告されるアドレスは、ウェブサーバーが見た接続の相手です。クライアントとそのサーバーの間に何かを挟めば、相手は変わります。変換、終端、負荷分散は、いずれも観測を利用者から一歩遠ざけます。

よくある四つの経路は、四つの異なる観測を生みます。

経路は、宛先の名前、アドレスの種類、そして変換点ごとに書き留めてください。その地図がなければ、正しい値も誤った値もログの一行では同じに見えます。図の二行が、半日分の議論を省きます。

置き換えが起きるのは、設定されている場所だけ

サーバーやフレームワークは、クライアントのアドレスを意図的に置き換えられます。Apache の remote-IP モジュールと NGINX の real-IP モジュールはどちらもこれを行い、PHP が受け取る値はその設定と、スクリプトハンドラに渡されるパラメータによります。

つまり REMOTE_ADDR は、常に手を触れられていない TCP の相手ではありません。サーバーが自らの方針を適用したうえで、報告すると決めた相手です。この違いが、その値が証拠なのか飾りなのかを決めます。

この配備でどの項目が権威を持つのか、置き換えが起きたときに元の相手がどう保たれるのかを、サーバーの所有者に尋ねてください。誰も答えられないなら、そのログはまだ何も証明していません。

転送ヘッダーを信頼して読まない

呼び出し側は自分で転送ヘッダーを送れます。カンマで区切られた最初の項目を検証済みの利用者アドレスとして扱うのは、接続してきた誰でも信じるという判断であり、ヘッダーの目的の正反対です。ヘッダーは連鎖を記述するもので、その連鎖を保証できるのは信頼できる層だけです。

サーバーやフレームワークの信頼できるプロキシの仕組みを、実際のプロキシ連鎖を設定して使い、その連鎖の外の出所からの値を捨てさせてください。手書きの解析こそが、興味深い不具合の大半が住む場所です。

プロキシが報告するアドレスも、上流のファイアウォールが見るパケットの出所を変えません。HTTP のメタデータとネットワークのフィルタリングは別々の観測として保ってください。答える問いが違うからです。

判断にはアプリケーションの身元を使う

利用者の記録へのアクセスは、認証された主体とアプリケーションの認可規則に頼ってください。内部アドレスは再割り当てされ得ますし、変換された一つのアドレスは何百人もの同時利用者を表し得ます。どちらの性質も、アドレスの確認では直せません。

運用がリクエストを VPN セッションに結びつける必要があるなら、観測したアドレスと時刻を、文書化した変換モデルに従って権威あるセッション記録に結びつけてください。それなら弁明できる関連づけになります。アドレスだけではそうなりません。

診断には、サーバー配列の全体ではなく必要な数項目だけを記録してください。配列はヘッダーや認証情報を運び得ます。有益な結論は、この値がこの配備で何を意味するかを述べるものであり、どの値が最もクライアントらしいかではありません。