OpenVPNクライアントの通信をゲートウェイのどこで見るか

接続中のクライアントがどの宛先に到達しているかを知りたいので、VPNサーバーでシェルを開きssと入力します。役に立つものは何も現れず、トンネルが壊れているという結論は少しばかり安易に導かれます。ルーティング型のOpenVPNゲートウェイはクライアントのパケットを転送するだけで、そのTCP接続を終端せず、ソケットも保持しません。証拠は別の場所にあり、その場所はトンネルを出た後に通信がどう扱われるかで決まります。

どの構成を見ているのかを決める

よくある二つの形は、まったく異なる証拠を生みます。ルーティング型ゲートウェイはカプセル化を解除して転送し、場合によっては送信元NATも行うため、クライアントの接続はローカルソケットなしで端から端まで存続します。

プロキシは通信を終端します：接続を受け入れ、次に自身の上流接続を開きます。この構成では一つの要求に対して二つの接続があり、両者の対応関係はプロキシ自身の記録にしか存在しません。どちらを配備したかを知ることで、カーネルのフロー状態を読むべきか、アプリケーションログを読むべきかが決まります。

混乱の多くは推測から生まれます。ツールを選ぶ前に形を確認してください。その存在が以後のすべての手順を変えるため、まずサーバー設定にプロキシ指示があるか読んでください。それがなければパケットの経路はルーティングであり、カーネルのフロー状態が証拠になります。

まずアドレスをセッションに結びつける

サーバーのセッション状態から始め、クライアントの現在の内部アドレスを特定します。プールのアドレスは再利用されるため、アドレス単体は借用であって本人ではありません。

時刻と認証済みの身元を一緒に記録し、そのクライアントの背後にLAN全体が隠れていないか確認します。遠端がサブネットをルーティングしている場合、見えている内部アドレスは元のホストかもしれず、変換されたものかもしれません。

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

この組は二つの問いに同時に答えます：トンネルインターフェースがどのプレフィックスを提供しているか、そして関心のある区間でどのセッションが有効だったかです。誤ったセッションに結びついた説得力のあるタプルは証拠がまったくないより悪いので、フローエントリを解釈する前にこれを行ってください。

ルーティング型ゲートウェイでフローテーブルを読む

アドレスと区間が確定したら、追跡された接続の読み取り専用の一覧が、ゲートウェイがそのために何を転送しているかを示します。テーブル全体を読まないよう、元の送信元で絞り込みます。

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

各エントリは二つのタプル、元方向と応答方向を保持し、これは一つのフローの二つの向きであって二つのアプリケーションではありません。送信元NATの経路では、元のタプルはトンネルのアドレスを保ち、応答側は変換されたゲートウェイのアドレスを示し、だからこそ出力は一見おかしく見えるのです。

一覧は履歴ではなく生きた状態として扱ってください。短いフローはすでに期限切れかもしれませんし、追跡されない通信は決して現れず、別のネットワーク名前空間は別のテーブルを示します。conntrackのリファレンスがフィルタと双方向の出力を説明しています。

読み取りを確かめる一つの範囲を絞ったキャプチャ

トンネルインターフェースが自分の見ている場所に見えるなら、範囲を絞ったキャプチャが一つあれば、特定したパケットが回線上のものかどうか決まります。フィルタは狭く、パケット上限は小さく保ってください。

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

タイムスタンプ、プロトコル、ポートをフローエントリと、テストとして行った要求と比較します。NATの後に取ったキャプチャはゲートウェイの公開アドレスしか示しませんが、トンネル側はまだクライアントのアドレスを示すことがあり、その差は矛盾ではなく情報です。

インターフェースが何も見ないなら、クライアント間の通信や一部のオフロード経路は見ている地点を決して通らないので、クライアントが待機中だと結論する前にデータ経路を確認してください。

プロキシログと、見たものの限界

プロキシが経路上にあると、その上流ソケットはソケットテーブルに見えますが、特にプーリングや多重化では、VPNクライアントと一対一には対応しません。プロキシに設定されたトランザクションログを使い、クライアントの身元、宛先、タイムスタンプ、記録される要求識別子を関連づけてください。

すべての要求が既定で記録されると思い込まず、配備されたバージョンのログ設定を確認してください。

最後に、範囲について正確に述べてください。内部のHTTPSセッションはトンネルとは無関係に独自の保護を保つため、宛先アドレスとポートはメタデータであり、URLでもページ内容でもありません。何を観察したか、どの観察点から、いつ、を報告してください。