トンネルの /32 をコピーしてもオフィスのサブネットは経路化されない

VPN は接続し、インターフェースには三十二ビットマスクのアドレスが表示され、オフィスのサーバーには到達できないままです。次の一手は多くの場合、そのマスクをルートで再利用することです。インターフェースがトンネルの到達範囲を表しているという理屈です。そうではありません。そのアドレスはポイントツーポイントリンクのローカル側の端を表し、重要な宛先はその反対側の別のプレフィックスにあります。

二つの異なるものが混同されています。トンネルが与えたアドレスと、それを通じて到達したいネットワークです。

二つのアドレス、二つの役割

ポイントツーポイントトンネルでは、リンクの反対側にちょうど一つのピアしかいないため、クライアントアドレスは単一のホストアドレスであることがよくあります。共有セグメントも ARP もないので、Ethernet では不合理に見えるマスクもここでは完全に正常です。

宛先プレフィックスはオフィスネットワークについての事実であり、トンネルについてのものではありません。サーバーが一つだけ必要なら、ルートはそのサーバーへのホストルートです。オフィスのサブネット全体が必要なら、ルートはそのサブネットです。どちらの答えもインターフェースから読み取ることはできず、トンネルのアドレスの隣に現れたという理由で一方を選ぶのが、動作している設定を壊す方法です。

その三行目が、楽観が停止に変わる場所です。一つのサイトだけを提供するトンネルにプライベート範囲全体を流すと、無関係なトラフィックが配信できない経路に押し込まれ、その結果の障害は広すぎるルートではなく壊れた VPN のように見えます。

要件からプレフィックスを選ぶ

プロファイルに触れる前に、要件を一文で書きます。どのホストに到達できる必要があり、それらを覆う最も狭いプレフィックスは何ですか？単一のサーバーならホストルートです。サブネットならサブネットルートです。サブネットの範囲は集約であり、集約はその内部のすべてのアドレスに到達できるという約束ですが、それはめったに真実ではありません。

次に、その数値をオフィスが実際に使っているものと照合します。サイトのアドレス計画と確認せずにチャットメッセージからプレフィックスをコピーすることが、誰も所有していないサブネットをルートが指す原因になります。

ルートは経路であって許可ではないことも忘れないでください。ゲートウェイは依然としてクライアントが宛先を使えるかを決め、サービスは依然として拒否できます。ルートを正しくインストールしてもパケットはそこに届きますが、認可については何も答えません。

プロファイルに追加し、決して置き換えない

NetworkManager プロファイルのルートは複数値のプロパティであり、設定と追加の違いは一文字です。プラス形式を使ってエントリを追加し、すでに保存されているすべてを保持します。

nmcli connection modify uuid 11111111-2222-4333-8444-555555555555 \
  +ipv4.routes "10.40.20.9/32"

プラスがないと、代入はリスト全体を置き換えます。すでに複数のプレフィックスを持つプロファイルでは、動作していたものが黙って削除され、症状は後になって、以前はこのラップトップから到達できたサービスとして現れます。

名前ではなく UUID を使います。復元後に名前は重複し、編集している接続がトラフィックを運んでいる接続とは限りません。まず同一のエントリが存在しないか確認してください。重複の追加は無害でも乱雑です。

この ルートプロパティのリファレンス は、インストールされているバージョンの宛先、省略可能なネクストホップ、メトリック、属性の構文を文書化しています。ネクストホップを追加する前に読んでください。必要かどうかは統合とトポロジーに依存し、インターフェース一覧の最初のアドレスから推測するのは方法ではありません。

デフォルトルートと DNS は別々の決定

Adding an office prefix says nothing about where the rest of your traffic goes. If policy requires ordinary internet traffic to stay outside the tunnel, that is the ipv4.never-default decision, and it belongs to whoever owns the connection policy rather than to whoever is fixing one unreachable server.

自動ルートは、軽率に触るべきではないもう一つのものです。欠けているエントリを一つ解決するためにそれらを抑制すると、動作しているものが複数失われることがあり、それを提案した人はたいてい別のプッシュを持つ別のプロファイルを見ていました。

DNS には独自の経路と独自の障害があります。間違ったリゾルバーで正しいアドレスに解決される名前、またはプライベートゾーンに答えられないリゾルバーは、ルートが完璧であってもルーティングの問題のように見えます。アドレスと名前を別々にテストし、どの層が実際に失敗したかを判断してください。

何が適用されたかを確認する

保存された変更は適用された変更ではありません。マネージャーのサポートされたライフサイクルで再接続し、意図した宛先の実際のルートと、どのテーブルが参照されるかを決めるポリシールールを確認します。

プレフィックスがあり、それでも接続が失敗するなら、別の問題に移っています。送信元アドレスの選択、遠端の戻りルート、またはクライアントを拒否するサービスです。どれも、すでに修正したプロファイルよりも見るべき場所です。