MULTI: クライアントからの不正な送信元アドレス：それは誰のアドレスか
内部の送信元が、それを届けたクライアントと一致していません。トンネルの割り当て、クライアント背後の LAN、重複した ID のどれに当たるかを見極めます。
サーバーのログは MULTI: bad source address from client を出力し、パケットを破棄しますが、セッションは接続されたままです。この組み合わせは、このメッセージを認証の失敗と読む人を混乱させます。そうではなく、クライアントは認証を終えており、届いたパケットは、サーバーがそのクライアントのインスタンスに対応づけられない内部の送信元アドレスを持っていました。検査は配送の前に行われるため、トンネルは正常に見えるのに、その中を有用な通信が通りません。
サーバーが配送前に比較するもの
クライアントから届くパケットごとに、ユーザー空間のサーバーはトンネル内の送信元アドレスを見て、内部のルーティング状態にそのアドレスの持ち主がどのクライアントかを問い合わせます。持ち主が別のインスタンスである場合、あるいは持ち主がまったく無い場合、パケットは破棄され、警告が出されます。
トンネルインターフェース経由の通常の配送は決して行われません。
この順序は、ホストのファイアウォールのカウンターが動かないという人を戸惑わせる細部を、パケットがファイアウォールに到達していないという事実によって説明します。ホスト側で逆経路フィルタリングを調整しても、拒否はデーモン自身の対応づけ検査で起きているため、ここでは何も変わりません。メッセージは所有権についての記述として読み、そのうえで三つの状況のどれがそれを生んだのかを特定してください。
一致しない内部アドレスの三つの出所
クライアントは、割り当てられていないアドレスから、誰も自分のものだと宣言していないネットワークから、あるいはすでに持ち主がいる ID の複製から送っているのかもしれません。三つとも同じログ行を生みます。違うのは、あなたが何を変えるべきかです。アドレスと現在の割り当て一覧から始め、その二つの事実にケースを選ばせてください。
それらを区別するには、ログにある拒否されたアドレスと、サーバーが現在有効とみなす割り当てという二つの事実が要ります。後者は稼働中のインスタンスの状態表示または管理表示から得られ、設定ファイルは意図を記録するもので現在の状態ではないため、参照する価値のある唯一の権威です。
何かを変える前に両方を記録し、それから分類します。後から撮ったスクリーンショットは、警告を生んだ状態の記録ではありません。割り当てはセッションの間で移動するため、時刻も残してください。
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
クライアント背後の LAN と iroute
拠点クライアントが自前のプライベートネットワークをルーティングする場合、そのネットワークはクライアントに属すると宣言する必要があります。iroute エントリを持つクライアント固有のファイルがそれを行い、エントリはクライアントが運んでよいプレフィックスを名指しします。
同じプレフィックスをトンネルに向けるカーネルルートは別の要件であり、それを足してもデーモンの内部的な所有権は何も変わりません。
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0有効な ID がファイル名と一致していることを確認してください（一致しない場合、ファイルは決して読み込まれず、症状はエントリ欠落と同一です）。警告を黙らせるために広い iroute を足すのは、予期しない送信元を許可済みの送信元に変えるだけで、クライアントがなぜ送ったのかには答えていないため、避けてください。OpenVPN 2.6 のマニュアルは、iroute、duplicate-cn、ID の対応づけを別々の制御として記述しています。
二台のマシンで同じ ID
二台目のノート PC にコピーしたプロファイルは、同じ証明書と同じコモンネームを持ちます。サーバーの設定によっては、新しい接続が古い接続を置き換えることがあり、所有権を持つインスタンスが対応づけ検査に勝ちます。
そのため障害は断続的に見え、両方の端末が起きているときだけ現れます。
コモンネームの重複を許すと両方とも接続できますが、独立した固定アドレスや独立した所有権は与えられません。二台が共存しなければならないなら、それぞれを別々に登録し、独自の ID と独自の割り当てを持たせてください。重複の設定をこの警告の修理とみなすと、謎はそのまま残り、もう一つ増えます。
対応づけが変わったことを証明する
設定の所有者を通して修正を適用し、そのうえで影響を受けたクライアントを再接続して新しいポリシーを読み込ませます。
同じ流れを繰り返し、パケットの内部の送信元、サーバーが対応づけるクライアントのインスタンス、そしてその後の宛先の挙動という三つのことを確認します。
警告が止まってもアプリケーションがまだ失敗するなら、問題は消えたのではなく移動しています。転送、ファイアウォールの規則、戻り経路は別々の段階であり、対応づけ検査を通ることは、パケットがトンネルを出ることを許されたというだけのことです。