プライベート DNS 名か、それとも IP だけか？共有する前に決める

プライベートサービスを遠隔ユーザーに開放すると、二つの問いが混ざり合う。一つ目はクライアントがどの名前を使うか、二つ目はサービスがどの送信元を許可するかである。この順に答えること、誤ったアクセス規則の後ろにある正しい名前はやはり失敗し、解決しない名前の後ろにある正しい規則は決して試されないからだ。

条件その一：クライアントはどのリゾルバー経路を持つか？

プライベート名は、クライアントのリゾルバーがそれに答えられる場合にだけ機能する。つまり、許可された遠隔クライアントはゾーンを保持する DNS サーバーに到達しなければならず、トンネル経由でも、組織が遠隔ユーザー向けにすでに運用しているリゾルバー経由でもよい。トンネルは輸送手段であり、ディレクトリではない。クライアントにリゾルバーへの経路を与えるが、どのゾーンを問い合わせるかは伝えない。

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

ノート PC が VPN に接続したからといって、公開リゾルバーがプライベートゾーンを学習することはない。

サフィックスにも同じ注意が必要だ。組織が管理するドメインのサブドメインを使い、所有権と証明書の計画を明示的に保つ。 .local は避けること： マルチキャスト DNS の仕様 がそのサフィックスをリンクローカル解決に結び付けており、ルーティングされたトンネルはその挙動を再現しない。

条件その二：サービスはどの送信元を受け取るか？

許可規則はアドレスに対して書かれるので、有用な問いは、ルーティングと変換の後にサービスがどのアドレスを見るかである。 10.20.30.40 にある例のサービスでは、オフィスのクライアントは 10.20.30.0/24 から到着し、遠隔クライアントは 10.99.0.0/24 のような別のプールから到着する。

ゲートウェイが遠隔プールを変換すると、サービスは変換器を見ることになり、 10.99.0.0/24 のために書かれた規則は一致しない。

これはクライアント側ではなくサービス側から読むこと。サービスのホスト上のリスナーログやパケットキャプチャは実際に到着した送信元を示し、クライアント自身のアドレスは、経路を生き残ったものについての推測にすぎない。

条件その三：名前はサービスに結び付くか、ホストに結び付くか？

一台のマシンのアドレスを指す名前は、すべてのクライアントをそのマシンに結び付ける。ロードバランサーや安定したサービスアドレスを指す名前は、その背後のホストの交換に耐える。後で変更するということは、すべてのクライアントのブックマークと、すべての証明書の主体を変更することを意味するため、意図して選ぶこと。

単一の内部サービスなら、直接のレコードで通常は十分であり、考えるのも簡単だ。

交換、再構築、拡張されるものには、安定したフロントエンドが追加設定に値する。テストは簡単だ：ユーザーに告げずにバックエンドを交換できるなら、名前はサービスに結び付いており、できなければホストに結び付いている。

二つの決定を別々にテストする

まず解決し、それから接続する。期待されるアドレスを返す解決テストは、名前の経路を証明し、許可については何も言わない。接続テストは経路と規則を同時に証明するので、解決が成功した後にだけ実行する。

curl -sv --max-time 5 https://files.corp.example/health

次に、禁止された送信元を一度テストし、結果を記録する。

文書では二つの記録を分けておく：名前とそのゾーン、許可された送信元と規則の所有者である。一方が変わっても、他方は変える必要がない。

決定がたいてい誤るところ

よくある失敗は、オフィスネットワークでしか解決しない名前の下に公開されたサービスと、オフィス範囲だけを許可するアクセス規則の組み合わせだ。遠隔ユーザーは壊れたサービスを報告するが、実際には二つの別々の抜けである。二つ目のよくある失敗はその逆で、名前の問題を消すために広いアクセス規則を追加すると、誰も意図しなかった送信元からサービスに到達できてしまう。どちらも設定の抜けであり、ユーザーの席からは同じに見える。

どちらの誤りも、一度の成功したテストからは見えない。だからこそ二つの決定には別々の記録と別々のテストが必要であり、同じ人物が両方を決める場合でもそうだ。

サービスを稼働させる前に両方を書き留めること、次の変更を考えるのが楽になるからだ。記録は短い：名前とそのゾーンに一行、許可された送信元と規則の所有者に一行である。