移動するノートPC：安定した名前か、固定のオフィスアドレスか

自宅から管理コンソールを開き、ノートPCを名前で検索すると、オフィスを離れた時点で無効になったアドレスが返ってきますが、そのとき反射的にオフィスのアドレスをVPNアダプターに載せてすべてを動かし続けようとします。しかしその修正はたいてい別の何かを壊します。デバイスを見つけること、その通信を許可すること、セッションを生かし続けることは、三つの異なる問題だからです。アドレスの設計を選ぶ前に、それらを分けてください。

三つの要件を分ける

三つのうち、実際に失敗しているのはどれかを書き出します。人やツールがサービスを見つけられない、送信元アドレスが一覧にないためサーバーが要求を拒否する、インターフェースが変わるとアプリケーションが落ちる、という三つです。表計算の上では同じに見えますが、必要な修正は異なります。

ローミングの苦情のほとんどは最初の分類に入り、DNSで解決します。安定した識別名を付けるのは安価で、最初のケースを覆います。アドレスの保持は高価で、ポリシーをどうせ書き換える場合にしか二番目の助けになりません。

名前を安定したものにする

呼び出し元から到達できる任意のアドレスに解決する名前をノートPCに付けます。この例では、オフィスのアドレスは192.168.50.42、リモートアクセスのプールは10.90.0.42を配布し、laptop17.corp.exampleは接続に追随します。最後のオクテットが一致する必要はなく、その一致を前提に設計すると無駄な作業が生じます。レコードは、呼び出し元が実際に使えるアドレスを指すべきで、ノートPCがこれまで持ったすべてのインターフェースを指すべきではありません。

dig +short laptop17.corp.example

リゾルバーは応答をキャッシュするため、変更は全員に即座に反映されません。短いTTLが助けになり、アプリケーションの再接続ロジックはさらに助けになります。

送信元の許可リストが本当の制約である場合

送信元の許可リストが見るのは、あらゆる変換の後に保護されたサービスが受け取るアドレスです。それは多くの場合、ノートPC自身ではなくゲートウェイやNATのアドレスであり、だからこそDNSレコードを編集しても拒否された要求は決して直りません。実際に届くアドレスにポリシーを更新するか、リストを認証された識別情報に置き換えてください。

サーバーで受け入れられた要求を一つ捕まえて送信元フィールドを読み、次にリモート経路から繰り返します。二つのアドレスが異なるなら、ポリシーには二つの登録か別の仕組みが必要です。両方のアドレスをポリシー登録とともに記録し、次の人がなぜ二つあるのか分かるようにします。同じリンク上で既に有効なアドレスを再利用するのは、独自の検出規則を持つ別の競合問題です。

継続性が実際に求めるもの

接続の継続性は最も難しい要件で、最も誤解されるものです。TCP接続は両方のアドレスと両方のポートで識別されるため、DNSが何と言おうと、新しいローカルアドレスは別の接続です。重要なアプリケーションは再接続する必要があり、それはネットワークの小細工ではなく、セッション層か再試行するクライアントを意味します。移動中にセッションを観察すると、切断は即座に起こり、徐々にではありません。

ss -tnp state established '( dport = :443 )'

MACアドレスを複製してもこれは解決しません。DHCPリースの識別情報は明示的なクライアント識別子を使えますが、一つの識別情報を共有する二つのインターフェースには依然として調整されたルートが必要です。モビリティをアプリケーションと割り当ての設計として扱い、アドレスがネットワークに追随する間、デバイスの識別情報を安定させてください。