IPv6のプライバシーアドレスかRDP許可リストか、そのトレードオフを選ぶ

リモートデスクトップのアクセスは一か月間機能していたが、その後、許可リストは誰の目にも見える理由もなく一致しなくなった。ホストは移動しておらず、ファイアウォールも何も編集されていなかった。Windowsはランダムなインターフェース識別子を持つIPv6の一時アドレスを作り続けては廃止するため、サーバーがある日に見る送信元アドレスは、誰もルールに書いていないものかもしれない。その挙動を無効にすれば一致は直るが、同時にホストは長期間有効な識別子に変わってしまう。後半を受け入れる前に、代替案を比較検討してほしい。

ルールが一致しなくなった理由

RFC 4941が説明する一時アドレスでは、ホストがランダム化した識別子で追加のアドレスを作っては廃止するため、観察者は同じホストを訪問をまたいで関連付けられない。Windowsはその挙動を実装しているため、昨日の送信元アドレスが今日のものとは限らない。予測可能なアドレスはインターフェース上に依然として存在するが、外向きの接続が優先するのはそれではない。

だから障害は全滅ではなく断続的に見える。アドレスが作られてからしばらくはルールが一致し、廃止されると一致しなくなり、誰かが編集するとまた一致し始める。送信元アドレスでまとめた監視や、ホストアドレスをキーにしたライセンス確認は、同じ周期で壊れる。編集直後は動き、三週間後に失敗するルールは、たいていこれであって、ファイアウォールの再読み込みではない。

選択肢その一：安定したアドレス一つ、プライバシーは減る

よくある修復は、ホスト上の二つの回転機構を両方とも切る。netsh interface ipv6 set privacy state=disabled store=persistentとnetsh interface ipv6 set global randomizeidentifiers=disabled store=persistentを実行し、再起動を待たずに変更を反映させたいならstore=activeを追加し、識別子をネットワークをまたいで予測可能にしたことを受け入れてほしい。

その予測可能性こそ、拡張機能が防ぐために作られたものだ。ホストをカフェからオフィス、そして家まで追いかけるアドレスは、便利なフィルターキーであり、同じくらい便利な追跡キーでもあり、二つ目の性質は一つ目を求めたチケットより長く生き残る。

選択肢その二：プレフィックスか名前を許可する

完全なアドレスではなく/64を許可すれば、回転は保たれ、このマシンは自分の家庭ネットワーク上にあるという、弱いが多くの場合正直な主張に合う。そのプレフィックスに受け入れたくないホストが含まれた瞬間にそれは十分ではなくなり、家庭回線では人が思うより小さい集合であることが多い。動的DNSで公開した名前のほうが運用しやすく、レコードがホストに追随するため、ポリシーが機器を追加するたびに広がる範囲ではなく身元として読める。

どちらの選択肢も、サーバーが信頼できるリゾルバーと簡単にはなりすませない名前を必要とするため、ルールの見た目の変更ではなく身元についての政策判断として扱ってほしい。その名前に答えるリゾルバーがどれかを書き留めておき、ルールは背後にあるレコード以上には信頼できないと心得てほしい。

選択肢その三：トンネルにアドレスを割り当てさせる

接続が自分で管理するVPNを通るなら、サーバーは自分のプールからアドレスを渡せ、許可リストが参照するのはクライアントが好む値ではなくサーバーが選ぶ値になる。これは管理されたクライアントにはよく効くが、クライアントが上書きできるものには悪いので、自分の配備ではどちら側が実際に勝つのかを確かめてほしい。

判断をアドレスから完全に切り離し、クライアント証明書や認証済みゲートウェイへ移すことが、オペレーティングシステムが変更する権利を持つ値に依存しなくなるため、規模の面で通用する選択肢だ。

追跡コストを見据えて選ぶ

四つの選択肢を実際の要件に照らして書き出し、組み合わせるのではなく一つを選ぶ。それでもプライバシーを切るなら、必要とするホストに限定し、ルールのそばに理由を記録し、プラットフォームが対応するならRFC 7217の安定プライバシーアドレス指定を検討してほしい。プレフィックスごとの識別子を保ちながらハードウェア由来の識別子を晒さずに済むからであり、許可リストを置き換えたら拡張機能は再び有効にしてほしい。

変更は、それが支えるルールのそばに記録する。その注記がなければ、次の管理者はプライバシー拡張が切られたホストを見つけ、説明もないまま、片付けの最中にそれを再び有効にしてしまう。