一台のOpenVPNクライアントに二つのサービスアドレス：irouteとlo

アプリケーションはトンネルアドレスで応答しますが、そのために文書化したアドレスはどこにも届きません。OpenVPNのログには何の不満も出ず、ピアは接続済みと表示され、ハブにはクライアントが一台だけ表示されます。欠けているのは、クライアント上の二つ目のアドレスが二つの別々の事実だという点です。ホストがそれを所有し、ハブがどのピアが所有するかを知る必要があります。片方だけを扱えば、トラフィックはハブで止まるか、帰りの経路なしで到着します。

エイリアスはローカル、所有権はリモート

トンネルアドレスはネゴシエーションされるため、両端がハンドシェイク中にそれを知ります。追加のサービスアドレスはまったくネゴシエーションされないので、それを足してもハブ側では単独では何も変わりません。クライアントはすぐにアドレスを所有できますが、サーバーはそのトラフィックを既定の経路に送るか破棄します。レコードは二つ、別々の場所に作成する必要があります。

クライアントではアドレスはホストに属し、ループバックは物理リンクに決して現れるべきでないサービスIDの自然な住まいです。ハブでは、ピアとプレフィックスの対応はサーバーだけが読む別の宣言です。どちらのレコードも他方を暗黙に含みません。

メモでも二つの範囲を区別しておいてください。例の中のアドレスは文書用の値であり、実在のLANと重ねるのは、動作する設定を壊れて見せる最短の方法です。

クライアントにアドレスを永続的に追加する

サービスアドレスをホストプレフィックス付きでループバックに置き、ホストが到達すべきサブネットではなくローカル入力として扱うようにします。ip address add 10.66.0.10/32 dev loは一つのアドレスに対してそれを行い、二つ目のアドレスに対してコマンドを繰り返すと二つのサービスをモデル化できます。

まず一度きりのテストとして実行し、その後はホストのネットワーク設定を所有するものへ移してください。実行時の追加は再起動で消え、再接続のたびに重複がたまります。ネットワークの後に順序付けられたsystemdユニットが一つの選択肢で、ディストリビューションのネットワークマネージャーがもう一つです。どちらを選んでも、アプリケーションがバインドする前にアドレスが存在しなければ、サービスは誤ったソケットで起動します。手動コマンドの後ではなく、再起動後にip address show dev loで確認してください。

バインドはアドレッシングとは別の決定です。すべてのアドレスで待ち受けるアプリケーションは、意図しなかったインターフェースでトラフィックを受け入れるので、特定のサービスアドレスを指定してください。そうすればローカル入力ポリシーに正確に一致する対象ができます。

ハブが実際に読むCCDファイルでそれを要求する

サーバーでは、所有権の宣言は認証されたコモンネームで選ばれるクライアントごとのファイルに入ります。それはclient-config-dirで指定されたディレクトリの中です。行はiroute 10.66.0.10 255.255.255.255で、アドレスごとに一行であり、その宛先のトラフィックをどのピアが受け取るべきかをサーバーに伝えます。

二つの詳細がこれを静かに壊します。ファイル名はサーバーが実際に使う名前と一致しなければならず、username-as-common-nameが関与するとそれは異なります。そしてirouteは、クライアント設定ディレクトリが設定されたTUNモードでのみ有効なので、ブリッジ構成では同じ行は何もしません。既存のファイルを置き換えるのではなく行を追加してください。固定アドレスやpushオプションが既に入っている可能性があります。OpenVPN 2.6のリファレンスはディレクトリと所有権ディレクティブの両方を文書化しています。

ハブ自身のカーネルもそれらの宛先への経路を必要とします。ローカルで生成されたトラフィックがトンネルプロセスに入るためです。サーバー設定のroute 10.66.0.10 255.255.255.255はサーバー自身が発信するトラフィックをカバーし、他のクライアントは宛先を自分で学ぶためにpush "route 10.66.0.10 255.255.255.255"を必要とします。

ルーティングと承認は別々のままです。プッシュされた経路はクライアントにパケットの送り先を伝えるだけで、何も許可しません。サービスは依然として呼び出し元を独自の条件で受け入れる必要があります。

入力ポリシーと応答経路を確認する

エイリアス宛のパケットは所有ホストにローカル入力として届くので、問題はローカルのファイアウォールがその送信元とポートを許可するかどうかです。アドレス全体を開けるのではなく、VPN送信元範囲から特定のサービスポートを許可してください。

応答には呼び出し元への戻り経路が必要です。通常のトンネルプール内の呼び出し元にはその経路がすでにあり、トンネルデバイスがそれを運びます。別のルーティングされたネットワークの背後にいる呼び出し元には、そのネットワークの戻り経路も必要で、ここで非対称な構成がパケットを失います。

同じポートで別のアドレスにバインドされた二つ目のリスナーに注意してください。カーネルは一致するソケットに配信するため、結果はランダムに見えます。ss -lntpで確認し、バインドされたアドレスがサービスエイリアスであることを確かめてください。ここでは送信元NATは不要で、追加するとログが依存する呼び出し元のIDが隠れます。

アドレスと所有権を別々にテストする

二つの手順でテストします。まず、所有ホストが自分自身からエイリアス上のサービスに到達できることを確認します。これによりバインドとファイアウォールの問題をルーティングから切り離せます。次に、アプリケーション自身の認証を使って実際のVPN呼び出し元からテストします。最初が通り二番目が失敗するなら、欠けている部分はハブ側です。

接続後も残る障害モードも確認してください。トンネルが落ちてもエイリアスは割り当てられたままで、ピアがいなくてもハブは経路を保持します。どのオブジェクトも単独ではサービスが到達可能であることを証明しないので、二段階のテストはノートPCからの一回のpingに勝ります。