VPNクライアントにパブリックプレフィックス: 実際に壊れるもの

数字が見栄えするから選ばれたクライアントプールは、インストールを待つ経路です。VPNが動くためにプレフィックスがプライベートである必要はなく、他人のブロックを使ってもユーザーが自動的にインターネットへ露出するわけではありません。それがするのは、トンネルが上がっている間はそれらのアドレスを別の意味にし、切れたらまた別の意味にすることです。以下の五つの確認を順番に進め、答えが「他所に割り当て済み」のところで止めてください。

割り当ては告知ではない

アドレスをトンネルインターフェースに置いても、インターネットへ告知されるわけではありません。公的な到達性には経路、認可された経路、そしてそれを運ぶ意思のあるプロバイダーが必要で、クライアントがプールからアドレスを受け取ったからといってどれも現れません。ファイアウォールポリシーとホスト認可は、また別の判断です。

だからリスクは多くの人が想定するものではありません。借りたプレフィックスはクライアントを到達可能にするのではなく、他人の宛先をあなたのクライアントから到達不能にします。これは所有者が違う別の障害です。攻撃も受けず、告知も漏れません。ユーザーは昨日まで動いていたサイトを開けなくなるだけで、ヘルプデスクがVPNプールを疑う理由はありません。

プールを選ぶとき、この区別は重要です。懸念がインターネットへの露出だけなら、何も告知しないパブリックブロックは安全に見えます。懸念はそのプレフィックスのためにクライアントが入れるローカル経路であり、その経路は他人が見えるかどうかに関係なく入ります。

クライアントの経路が実際に捕捉するもの

トンネルが上がると、クライアントはプールのプレフィックスへの経路を受け取り、その経路はその中のあらゆる宛先に対してデフォルト経路に勝ちます。そのブロック内の正規のホストへのリクエストは、いまインターネットではなくVPNへ行きます。失敗するか、固まるか、間違ったサーバーに届くかは、あなたの側がそれをどう扱うか次第です。

ip route get 198.51.100.20
ip -br addr show tun0
traceroute -n 198.51.100.20

トンネルを上げた状態で検索を実行し、下げた状態でもう一度実行します。アドレスは前者ではある意味を持ち、後者ではまったく別の意味を持ち、その切り替えをまたいで接続や名前解決をキャッシュしたアプリは一貫しない動作をします。この一貫性のなさは、きれいな失敗よりサポートが難しくなります。タイミングに依存するからです。間違った瞬間に再接続したユーザーは、そうでないユーザーと違う体験を得ます。

見慣れたIPアドレスが身元の証明にならないのも同じ理由です。実際の宛先に対しては証明書とサーバー名の検証を保ってください。五分前に到達した数値アドレスは、いま別の会話のものかもしれないからです。

プールを、知っているすべてのネットワークと比べる

RFC 1918は私的利用のために三つのブロックを確保しています。192.168.0.0/16、172.16.0.0/12、10.0.0.0/8です。何百万もの別々の組織が再利用しているので、プライベートとは割り当てについての記述であり、誰も同じ番号を選んでいないという約束では決してありません。

候補のプールを、オフィスのLAN、クラウドのVPC、他のVPNプール、パートナー回線、そして在宅勤務者が自宅で持っていそうな範囲と比べてください。自宅の事情は奇妙なプレフィックスを発明する理由ではなく、プールを小さく文書化して保つ理由です。

割り当てはルーティングを所有する人と調整し、戻り経路も同じ場所に記録します。誰も逆方向にルーティングできないプールは、障害のときに再発見されるプールです。プールはサイトの範囲と同じ文書に置き、一人だけが編集したクライアント設定には置かないでください。次の衝突を避けられるのは文書のおかげです。

パブリックアドレスが正解になる場合

適切に割り当てられたグローバル空間を持つ組織は、パブリックアドレスのVPNプールを構築できます。変換を避けるために意図的にそうする例もあります。その設計にもルーティング、送信元検証、アクセス規則、クライアント認証が必要で、割り当てはそのどれも与えません。

それが与えるのは一意性であり、借りたプレフィックスに欠けている性質です。ブロックを保有していれば、クライアントが入れる経路は本当にあなたのもののアドレスを指し、トンネルが切れても意味は変わりません。

プール選択を補うためにNATを自動で追加しないでください。明示的な戻り経路を持つルーティングされたプライベート設計は、アドレッシングが計画されなかったからといって適用する変換より清潔です。IPv6にはIPv4の前提のコピーではなく、独自の意図的な計画が必要です。

アクセスを失わずに悪いプールを廃止する

プールがすでに展開されているなら、変更する前に棚卸しをしてください。アドレスの予約、導入済みの経路、そのブロックに解決するDNSレコード、ファイアウォールの範囲、それらに依存するアプリケーションです。その後、他のルーティング切り替えと同じ注意深さで変更を計画します。気づく人には告知してください。プールが移るとセッションが切れるからです。クライアントアドレッシングの静かな変更は、作業と無関係に見えるサポートチケットを生みます。

削除するプールに依存しない復旧経路を残してください。それを取り下げる瞬間は、リモートアクセスも一緒に消えるかもしれない瞬間だからです。その後、両方向を検証します。意図したプライベート宛先はまだ動き、以前は捕捉されていたインターネット宛先は本物の所有者に解決されます。

望ましいのは、ネットワークチームがひとつのまとまりとして割り当て、ルーティングし、廃止できるプールです。アドレスの形式だけでは安全性も接続性も確立しません。