そのトンネルアドレスはピアであり、閲覧できるサブネットではない
ポイントツーポイントリンクのマスクは遠端を表し、隣接ホストの範囲を表すのではない。サブネットがおかしいと判断する前に、ピアのアドレスを読んでほしい。
クライアントが接続すると、アドレスの組、あるいは 255.255.255.255 マスクを付けた 一つのアドレスが表示され、最初の反応は「サーバーが壊れたものを配った」になる。壊れてはいないのは、トンネルインターフェースがポイントツーポイントリンクであり、マスクがその一本のリンクの遠端を表していて、隣接ホストの範囲を表しているわけではないからである。組をローカルとピアとして読めば、奇妙なマスク、その隣にある単一ホスト経路、欠けている隣接テーブルの説明がつく。同じ読み方で言い訳できないのは、オフィスのネットワークと重なるアドレス計画のほうである。
トンネルリンクでマスクがおかしく見える理由
Ethernet インターフェースでは、アドレスとマスクは、このホストがアドレスを所有していること、そしてプレフィックス内のすべてが直接の隣接ホストであること、という二つのことを述べている。カーネルはその二つの事実からリンク上の経路を導き、存在するとみなす隣接ホストのためにリンクアドレスを解決する。ポイントツーポイントインターフェースは所有だけを残して隣接ホストを捨てるので、クライアント行の二番目のアドレスは共有セグメント上の別ホストではなく遠端である。ハードウェアアドレッシングも解決トラフィックも参加すべきブロードキャストドメインもないから、このインターフェースは宛先がちょうど一つだけのパイプのように振る舞う。
広いマスクの隣に単一ホスト経路があるのが症状ではなく正常なのも、同じ理由である。このリンクでの到達性は 一つのアドレスを意味し、カーネルはまさにそれを書き留める。 二つのアドレスを並べて読む 設定が間違っていると判断する前に、どちらか一方だけを見れば誤りに見えるからだ。
二つのトポロジー、二つのアドレスの形
古いポイントツーポイントのトポロジーは各クライアントに小さなブロックを与えて中央の 二つのアドレスを使うため、マスクはプールではなくネットワークの断片のように見える。サブネットのトポロジーはプールからプールのマスク付きでアドレスを配り、サーバーのトンネルアドレスをピアと呼ぶ。どちらも有効なリンクを作り、違いはプロファイルに現れるアドレスと、利用者が疑問を持ちそうなマスクだけである。
| Topology | Client address shape | Peer | Route to expect |
|---|---|---|---|
| Point-to-point block per client | Two neighbouring addresses inside a small block | The far address of that block | A single host route on the tunnel device |
| Shared pool | One address carrying the pool mask | The server's tunnel address | A single host route on the tunnel device |
どの行がクライアントに当てはまっても、まずピアを読んでほしい、遠端を名指しするのでマスクの説明になるからだ。トポロジーの異なるサーバー間でプロファイルをコピーすると、新しい家に合わない形が表示され、その不一致はサーバーの不具合と誤解されやすい。
プールとオフィスのネットワークが同じビットを取り合うとき
リンクがルーティングされる以上、プールにはサーバーが到達できるネットワークのどこにも現れないプレフィックスが必要だ。一つを共有すると、クライアントは 二つの場所を意味する範囲に対して 一本の経路だけを持ち、どちらが勝つかは最後にインストールされた経路が決める。障害はクライアント側に現れるが、その背後の判断はアドレス計画に属している。利用者が報告するのは、トンネルが上がるとローカルルーターが消える、あるいは一部のオフィスホストしか応答しないというものだ。
似て見えるだけのプレフィックスは別の話であり、オクテットを目で比べるのはプレフィックスの比較ではない。両方を書き出してマスクされたビットを数える：192.168.4.0/24 と 192.168.6.0/24 はビット 22 まで一致し、ビット 23 で分かれ、三番目のオクテットが 00000100 と 00000110 として読めるからで、つまりこの二つのネットワークは本当に別である。10.8.0.0/24 の隣に別の 10.8.0.0/24 を置くとマスクされた 24 ビットがすべて一致し、一本の経路では 二つの場所を表現できないことになる。比較がどこで止まるかはマスク長が決め、後からインストールされたネットワークが負ける。
ルーティングされたリンクが届けられないもの
ブロードキャストとマルチキャストはルーティングされたリンクを越えないが、よく知られた機能のいくつかはそれらに依存している。ブラウズリスト、名前の通知、サービス検出はいずれも共有セグメントを前提とするので、ファイルサーバーはアドレスでどの要求にも応答できても、一覧に決して現れないことがある。リンクローカルのブロードキャストに依存する名前解決も同じ理由で失敗し、プロファイルをどう編集してもトンネルが運べるものは変わらない。それが重要かどうかはルーティングではなく要件の問題である。
それらの配送が本当に必要なクライアントにはブリッジインターフェースが要り、Ethernet フレームを運ぶためブロードキャストドメインが保たれる。代償はより騒がしいリンク、上で述べたきれいなアドレッシングの喪失、そしてループが現れた後のずっと大きな障害面である。切り替える前に要件を正当化し、要件が名前だけに関するものならルーティングされたリンクで動く名前サービスを選ぶとよい。
プロファイルを編集する前にインターフェースを読む
プロファイルが語っているように見えることではなく、カーネルが何をインストールしたかを尋ねる。アドレスの出力はマスクを説明するピアを示し、経路の出力はそこへの道があるかを示す。両方をトンネルデバイスに対して実行すれば一瞬で済み、疑問は片づく。
ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1その 三つが一致していれば、プロファイルは設定どおりに動いており、残る問題は別のところにある。トポロジーを変えるのは欠けた能力を名指しできる理由があるときだけにし、見慣れないマスクはその理由にならない。