先頭から末尾までの IP 範囲を正確な VPN ルートに変換する

誰かが先頭と末尾のアドレスを渡して VPN ルートを求めています。誘惑されるのは両端を含む最短のプレフィックスを選ぶことですが、その選択は誰も尋ねていない宛先を静かに追加します。CIDR ブロックのサイズは常に二の累乗で、開始アドレスはそれに整列しているため、任意の範囲には通常一つでは足りません。範囲をたどり、正確に分割し、そのすぐ外側のアドレスを確認します。

プレフィックスではなく範囲から始める

他の何かを書く前に、先頭のアドレスと末尾のアドレスを書き留めます。この組が要件であり、プレフィックスはその可能な表現の一つにすぎず、ときに誤った表現です。二つの数値はマスクよりはるかに確認しやすいという利点もあります。

整列した範囲は一つのブロックにまとまります。整列していない範囲は複数に分解され、その分解は近似ではなく正確です。やってはいけないのは外側に丸めて「十分近い」と呼ぶことで、余分なアドレスはルートが持つポリシーをそのまま受け取ります。

誤りの両方向が重要です。トンネルへのルートでは、余分なアドレスが VPN に引き込まれます。バイパスの例外では、余分なアドレスがそれを迂回します。どちらの結果も、インストールしたプレフィックスだけを示すルートテーブルには現れません。

ケース一：範囲がたまたま整列している

198.51.100.64 から 198.51.100.127 を取ります。先頭のアドレスは 64 アドレス境界に整列しており、範囲はちょうど 64 アドレスなので、一つの /26 が余りなくそれを記述します。

これは簡単なケースであり、要件がすでにプレフィックスで考えていた人によって書かれた可能性が高いので見分ける価値があります。確認も短くて済み、サイズが二の累乗で開始がそのサイズの倍数であることを確かめます。

ドキュメント用の範囲が良い例になるのは、誰もそれを所有していないからです。これらのアドレスを実際のトンネルにインストールせず、珍しく見えるというだけで与えられた範囲をドキュメント用空間と決めつけないでください。

ケース二：整列していないので分割する

次に 198.51.100.100 から 198.51.100.107 を取ります。これは八アドレスで二の累乗ですが、100 は八の倍数ではありません。そのサイズの一つのブロックはそこから始められないため、範囲は複数のブロックで覆う必要があります。

正確な被覆は二つの /30 ブロックです：198.51.100.100/30 が 100 から 103 を覆い、198.51.100.104/30 が 104 から 107 を覆います。合計八アドレスで、範囲外はなく、分解は与えられた範囲に対して一意です。

python3 -c "from ipaddress import ip_address, summarize_address_range as s; print(*s(ip_address('198.51.100.100'), ip_address('198.51.100.107')), sep='\n')"

標準ライブラリの関数が計算を代行し、ipaddress のドキュメントが何を返すかを定めています。それがしないのは、ゲートウェイの選択、アドレスの所有者の決定、背後のサービスへのアクセス許可です。

より広いプレフィックスが何を捕まえたかを測る

近道を受け入れる前に、そのコストを計算します。198.51.100.96 から始まる /28 は 96 から 111 を覆い、八ではなく十六アドレスになります。余分な八は 96 から 99 と 108 から 111 で、そのすべてがルートを継承します。

python3 -c "from ipaddress import ip_network as n; w=set(n('198.51.100.96/28')); t=set(n('198.51.100.100/30'))|set(n('198.51.100.104/30')); print(len(w), len(t), sorted(w-t))"

余分な八つの宛先は、変更依頼に書ける具体的な数です。近道が許容できるかを決めるのもこの数であり、それは算術ではなくポリシーの問題です。

算術と発見を分けておきます。ネットワーク運用者から提供された範囲は正確に変換されます。変化するサービスの DNS 応答一つでは、そのサービスの完全または恒久的な範囲は確定せず、無関係な名前が同じアドレスを共有することもあります。

正確な集合をインストールし、端を検証する

得られた各プレフィックスを VPN 設定の所有者に渡し、サポートされた仕組みでインストールしてもらいます。要件が二つのエントリを必要とするなら、フォームを短くするために一つを広げるのではなく、二つのエントリを保ちます。

sudo ip route add 198.51.100.100/30 via 10.90.0.1 dev tun0
sudo ip route add 198.51.100.104/30 via 10.90.0.1 dev tun0
ip route get 198.51.100.101
ip route get 198.51.100.97

最後の二つのコマンドこそ、人が飛ばすものです。内側の先頭アドレスは新しいルートに従うべきで、範囲のすぐ外側のアドレスは従うべきではありません。両方が同じ道を通るなら、要件と設定の間のどこかで範囲が広げられています。

先頭のアドレス、末尾のアドレス、それらを表すプレフィックスを記録します。次にルールを見直す人は、算術をやり直さずに要件と設定を照合でき、正確なルートと便利なルートの差が可視のまま残ります。