DHCPオプション121でLANのホストにVPNの戻りルートを与える

リモートのVPNクライアントが接続し、LANのサーバーが応答し、その応答は通常のインターネットルーターを通って外へ出て、そこで死にます。サーバーが一つなら静的ルートで直せますが、サブネット全体となれば、すでにネットワーク設定を受け取っている場所で扱うほうが賢明です。DHCPv4のオプション121は、まさにそうした宛先ルートを配布するもので、デフォルトを忘れた途端に人が間違えるのはこの部分です。症状は一方向の通信です。要求は届くのに応答が消えます。

まず三つのアドレスに名前を付ける

具体的なLANを考えます。192.168.50.0/24 があり、通常のデフォルトルーターが 192.168.50.1、別個のVPNゲートウェイが 192.168.50.2 です。認証済みのリモートクライアントは 10.90.0.0/24 を占めます。

参加するすべてのホストに必要なルートは 10.90.0.0/24 via 192.168.50.2 です。宛先はクライアントプールで、ネクストホップはゲートウェイのトンネルアドレスではなくLANアドレスです。

クラスレス静的ルートとしてエンコードする

オプション121はプレフィックスとネクストホップの組を運び、RFC 3442 が符号化とそれに続くクライアントの動作の両方を定めています。この例示的なLANだけにサービスしている既存のdnsmasqインスタンスなら、設定の形は次のとおりです。

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

これは断片であって、新しいDHCPサービスではありません。複数のセグメントを扱うサーバーでは、すでに使っているタグやネットワークポリシーでオプションを限定してください。元に戻すには再起動ではなく、もう一度リースを更新する必要があるので、以前の設定は手元に置いておきます。

デフォルトルートを失わない

ここが罠です。オプション121を受け取ったクライアントは通常のRouterオプションを無視しなければならないため、VPNプールのルートだけを広告すると そのホストはデフォルトルートをまったく持たなくなる ことがあります。マシンは設定済みに見えたまま、静かにインターネットを失います。利用者は、すべてのインターフェースが上がっているのにネットワークが落ちたと表現します。

上の断片がそうしているように、意図したデフォルトを同じリストに入れてください。クラスレスルートを実装していないクライアントのために、通常のRouterオプションもそのまま残します。誰に何を送るかはサーバー自身のオプション処理が決めます。

クライアントが何を受け入れるか確かめる

手動でアドレスを設定したホストは、リースを要求しないのでこれを取り込みません。クライアントの対応もさまざまなので、どの機器もオプション121に従うと決めつけず、実際に使っているオペレーティングシステムで試してください。そのサーバーの持ち主に、どれが静的アドレスなのかを確認します。そうしたホストには独自のルート項目が必要で、なければ単に参加しません。

管理されたDHCPサービスも制約です。クラウドのネットワークによっては管理者が任意のオプションを公開できないことがあり、同じセグメントに競合するDHCPサーバーがあるのは、オプションがまったくないより悪いです。

リースを確かめ、次に参照を確かめる

DHCPの担当者に変更を適用してもらい、そのうえでクライアントのリースを更新します。既存のリースは更新されるまで古い設定を保つので、即座に結果が出るとは限りません。

Linuxのクライアントで実際のルートを読み、二つの項目を確認します。

ip -4 route
ip -4 route get 10.90.0.23

文脈に応じた参照では、プールのルートが 192.168.50.2 経由、デフォルトが 192.168.50.1 経由で表示されるはずです。デフォルトが欠けていれば、上の罠を再現したことになります。

次に実際のやり取りを試す

ルートの配布は経路のすべてではありません。別個のゲートウェイには、転送とリモートピアの所有、サーバーを許可するアクセスポリシーが依然として必要で、DHCPは誰も認証しません。

最後に、撤去の計画を用意します。学習した静的ルートはVPNが落ちても自分から取り下げられないため、古いネクストホップはトンネルが消えたずっと後まで、そのプレフィックスをブラックホールにし得ます。