OpenVPNクライアントの背後にあるサブネットに到達できないのはなぜか？

サーバーのトンネルアドレスへのpingは成功し、クライアント自身のルートテーブルも正しく見えるのに、その背後のLANには依然として到達できません。クライアントのルーティングテーブルは正しく見え、サーバーにはトンネルへ向かうルートがあり、それでもパケットは消えます。これは、クライアントのひとつがゲートウェイでもあることを知らないlayer-3トンネルの典型的な症状です。

tunインターフェースにはクライアントごとのネクストホップがありません。カーネルは多数のピアを持つ単一のインターフェースを見るため、リモートLAN宛てのパケットをどのクライアントが受け取るかはOpenVPNプロセスの内部で決める必要があります。その判断はirouteで設定され、それがなければパケットの行き先はありません。

サーバーはインターフェースではなくクライアント単位でルーティングする

サーバーがクライアントのトンネルアドレスへパケットを送る必要がある場合、答えは明白で、そのアドレスはそのクライアントのセッションに属します。宛先がそのクライアント背後のサブネット全体になると、アドレスはサーバーが知る誰のものでもなく、カーネルのトンネルへのルートは「このインターフェースから」としか言わず、どのピアかを示しません。

OpenVPNは、宛先プレフィックスを特定のクライアントに割り当てる内部ルーティングテーブルでこれを解決します。そのテーブルはirouteエントリから作られるため、サーバーホスト上の通常のルートでは足りません。カーネルのルートはパケットをトンネルインターフェースまで運び、内部マッピングがどのセッションが受け取るかを決めます。だからこそ、修復がカーネルのルート出力に現れることはありません。

マッピングがない場合、パケットはサーバーに届き、トンネルのルートと一致しますが、どのクライアントも宛先を主張しないため破棄されます。何も明確なエラーを記録しないため、障害はルーティングループではなく静かなブラックホールのように見えます。

クライアントを名指しするirouteエントリを書く

irouteはサーバーのメイン設定ではなく、クライアント固有の設定ファイルに置きます。client-config-dirオプションでサーバーをディレクトリに向け、次にクライアントの証明書のコモンネームを名前にしたファイルを作り、その中にプレフィックスを入れます。

LANが10.20.0.0/24で、証明書のコモンネームがbranch-routerである支店の場合、そのパスのファイルにはiroute 10.20.0.0 255.255.255.0のような行が入ります。メイン設定にはディレクトリオプションだけが必要で、プレフィックスはクライアント側にあります。

コモンネームが壊れやすい部分です。別のsubjectで発行された証明書や、ファイルは証明書名なのにユーザー名で認証する配置では、決して読まれないファイルができます。サーバーが実際にセッションに対して報告する名前を確認し、一致しないクライアントをルートなしで黙って接続させるのではなく失敗させるオプションを検討してください。ファイルを証明書に合わせて改名するのは、非常に長い夜を防ぐ五分の修正です。

ひとつのクライアントが複数のプレフィックスを持つこともあります。ネットワークごとにiroute行をひとつ追加し、マッピングを監査可能に保つため、リストをそのクライアントの他の設定の隣に置いてください。

両方向の戻り経路を構築する

リモートLANにパケットを届けるのは仕事の半分です。クライアントはそのLANのトラフィックもトンネルへ送る必要があり、通常はクライアントにルートをプッシュして行い、push "route 10.8.0.0 255.255.255.0"のような行が、サーバー側のネットワークへの到達方法を各クライアントに伝えます。支店の場合、同等のルートはサーバー側で到達すべきものすべてをトンネルへ向けます。

戻り方向には遠い側の所有者が必要です。その側では誰かが帰り道を知っている必要があり、それはVPNプールをサーバーへ向けるLANルーターの静的ルートか、トラフィックがLANに入る前のサーバーでのアドレス変換です。静的ルートは元のアドレスをログとアクセスルールで見えるままにしますが、LAN所有者の協力が必要ですが、変換は自己完結でありながら実際に誰が接続したかを隠します。

サーバーホストでフォワーディングを有効にする必要があります。これがないと、カーネルはトンネルからパケットを受け取ってLANインターフェースへ渡すことを拒否し、クライアントから見るとirouteの欠落とまったく同じに見えます。

適切なプローブで到達性を確認する

遠端をpingして推測するのではなく、層ごとにテストします。サーバーからは、プレフィックスの内部マッピングが存在し、カーネルのルートがトンネルを指していることを確認します。クライアントからは、プッシュされたルートがインストールされ、LANアドレスへの既定の経路がトンネルであることを確認します。

次にパケットを観察します。トンネルインターフェースでのキャプチャは、サーバーがクライアント方向へ送信しているかを示し、LANインターフェースでのキャプチャはフォワーディングしているかを示します。前者がパケットを示し後者が何も示さなければ、問題はフォワーディングかフィルターで、どちらも何も示さなければ検索はもっと早く失敗しています。

トンネルで結ばれた二台のサーバーは両側で同じルールを繰り返し、それぞれが相手のプール用のirouteを必要とし、経路を対称にするルートとフォワーディングを必要とします。ここではルーティングとポリシーは別の関心事です。ルーティングはパケットがどこへ行けるかを決め、FORWARDルールは行ってよいかを決めるので、二つのiroute行を持つクライアントは、フィルターが別段の定めをしない限り両方のプレフィックスに到達できます。