ゲートウェイか転送されたクライアントか？送信元アドレスの読み方

ウェブサーバーは一つのアドレスを記録し、誰もがそれはゲートウェイ自身のプロセスに属すると考えます。翻訳の段階でプライベートアドレスが消えた転送クライアントのものである可能性があります。宛先が見るのは可視のネットワーク送信元だけで、それ以上ではありません。これは境界についての記述であり、起源を決して特定できないという主張ではありません。

宛先が実際に見るもの

10.20.0.7 のクライアント、外部アドレスが 198.51.100.10 のゲートウェイ、インターネット上の宛先を考えます。ゲートウェイがクライアントの送信元を翻訳すれば、宛先のソケットは 198.51.100.10 を記録します。プライベートアドレスはパケットから消え、宛先はそのヘッダーから読み戻せません。これらの数字は例示であり、あなたのネットワークからの取得ではありません。

観察は依然として有用で、宛先が許可または遮断すべきネットワーク送信元を特定します。ただし、その背後にいる人物やプロセスを特定するものではありません。宛先の運用者にとって、この区別は遮断がネットワークの判断かアカウントの判断かを決めます。

翻訳の状態は宛先に見えない

ゲートウェイは翻訳された接続と元のクライアントの対応を保持しており、宛先に欠けているのはまさにその状態です。従来の NAT の説明 は翻訳記録を、後から見えるヘッダーから分離します。片側を読んでももう片側は得られません。

設計が違えば証拠も変わります。送信元アドレスを保持したルーティングではクライアントの実アドレスが見えますが、アプリケーションプロキシは接続を終了して新しい接続を作ります。送信元を保持する経路は、クライアントのアドレスが宛先から逆方向にルーティング可能であることも必要で、すべての配備がそれを提供するわけではありません。ログ行を解釈する前に、どの設計が配備されているかを尋ねてください。

conntrack -L -s 198.51.100.10
tcpdump -ni eth0 host 198.51.100.10

TTL とフィンガープリントは手がかりであり、証明ではない

IPv4 の TTL は送信者が選ぶ初期値と、パケットが通過したホップ数に依存します。両方の事実がなければ、値は VPN ホップが起きたことを証明できません。既知の余分なルーティングホップも、LAN ルーター、トンネル経路、その他の転送構成を区別できません。TTL の差は結論ではなく問いとして扱ってください。

他の信号も同じように振る舞います。User-Agent ヘッダーはアプリケーションが設定でき、タイミングの類似は共有された人物ではなく共有されたインフラを反映することがあります。複数の利用者が一つの出口を共有でき、一人の利用者がセッション間で経路を変えることもあります。まとめて集めれば、複数の弱い信号はゲートウェイの記録を詳しく見る根拠になり得ますが、積み重なっても強い証拠にはなりません。

アドレスではなく識別情報で認可する

宛先がゲートウェイの管理と遠隔利用者の活動を分ける必要があるなら、それらの役割に別々の認証済みアカウントと許可された操作を与えてください。共有された公開の送信元は依然としてネットワーク制限として機能できますが、利用者や端末の認証の代わりにはなりません。

証拠はラベル付きで保ってください: 観測された送信元、認証されたアカウント、タイミング、および検討中の推論。「ここに内部送信元は見えない」を「どこでも帰属は不可能」と訳さないでください。何か月も後に、調査に関与していなかった人が記録を読むとき、ラベルが重要になります。

観察の日付と、それを生成したシステムを記録してください。帰属のないログ抜粋は、後で防御するのが難しいものです。