※注意：本稿は「OS単体運用」を前提としたフル堅牢化手順です。もしMullvad VPNを常用し、Mullvad Browser（匿名デフォルト）と生IP（実名ホワイトリスト）を使い分ける構成を組む場合、本稿のDNS関連設定（第2項〜第4項）はすべてスキップ（無視）してください。 VPNアプリ側のDNS制御と衝突して通信が即死します。
この隔離運用の環境で実行すべきなのは、第1項のMACアドレスランダム化の5行のみです。ignore-auto-dns などのDNS関連行は一切記述せず、この内容だけで設定ファイルを生成してください。
Linux Mint 22.3（Cinnamon / Base: Ubuntu 24.04 LTS）のインストール直後において、ネットワークレイヤーにおけるプライバシー、匿名性、およびセキュリティを強固にするための初期設定（ポストインストール・チューニング）の記録である。
本稿では、データリンク層（L2）の識別子であるMACアドレスの動的ランダム化と、アプリケーション層（L7）の名前解決を暗号化するDNS-over-TLS（DoT）の導入、および有線LAN環境下で発生するDHCP由来のDNSリーク（抜け穴）を完全に遮断する手順について解説する。
1. NetworkManagerのグローバル要塞化（MACランダム化とDNSリーク恒久対策）
背景と目的
本フェーズでは、システム全体のネットワーク挙動に対する強固なベースライン（グローバル・デフォルト）を定義する。目的は以下の2点である。
- MACアドレスの動的ランダム化: MACアドレスはNIC固有の物理識別子であり、固定のままだと移動履歴の追跡やデバイスのプロファイリングを許す致命的なシグネチャとなる。これを接続およびスキャンごとに動的にランダム化し、物理レイヤーでの追跡を回避する。
- 新規接続時のDNSリーク恒久対策: 出先のパブリックWi-Fiなど、未知のネットワークに接続した際、デフォルトではDHCPから降ってくる平文のローカルDNSを受け入れてしまう。これを初期状態から完全に無視（拒否）する設定を強制し、次項で設定する暗号化DNS（DoT）へのルーティングをシステムレベルで保証する。
設定手順
NetworkManagerのグローバル設定ディレクトリに設定ファイルを新規生成する。Linux Mint 22.3では、該当ディレクトリ（ /etc/NetworkManager/conf.d ）は初期状態で実在しているため、そのままエディタでファイルを生成・編集する。
Bash
sudo nano /etc/NetworkManager/conf.d/00-macrandomize.conf以下の設定内容を記述し、保存する。
Ini, TOML
[device]
wifi.scan-rand-mac-address=yes
[connection]
wifi.cloned-mac-address=random
ethernet.cloned-mac-address=random
ipv4.ignore-auto-dns=yes
ipv6.ignore-auto-dns=yes保存終了後、NetworkManager デーモンを再起動して設定を即時反映させる。
Bash
sudo systemctl restart NetworkManager2. systemd-resolvedによるDNS-over-TLS (DoT) の有効化
背景と目的
デフォルトのDNSクエリは暗号化されていない平文（ポート53）で送信されるため、経由するローカルルーター、ISP、あるいは物理近傍の攻撃者によって、訪問先ドメインのログを容易に傍受・改ざん（中間者攻撃）されるリスクがある。これを防ぐため、ログを保持しない信頼性の高いパブリックDNS（例: Quad9）へ、ポート853を用いたTLS暗号化接続（DoT）を強制する。
設定手順
システムに既存の systemd-resolved の設定ファイルを編集する。
Bash
sudo nano /etc/systemd/resolved.conf
[Resolve] セクションの最下部に以下の2行を正確に追記する。既存のコメントアウト行（#で始まる行）を変更するのではなく、最下部に追記することで記述ミスを防ぎ、かつ下位の記述が優先される仕様を利用する。
Ini, TOML
DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net
DNSOverTLS=yes
※注意：セカンダリDNSのIPアドレスは 149.112.112.112 である。タイポに留意すること。
保存終了後、サービスを再起動する。
Bash
sudo systemctl restart systemd-resolved
## 3. 既存プロファイルの浄化（DNSリーク対策の補完）
### 背景と直面した問題 第1項にて「すべての新規接続」に対する自動取得DNSの拒否（グローバル設定）を適用した。しかし、OSインストール時から既に存在している既存の接続プロファイル（例：現在接続中の有線LANなど）は、過去の設定を個別に強く保持しており、グローバル設定による上書きを拒否する仕様となっている。 この状態のままインターフェースに `+DNSOverTLS` が強制されると、有線LANインターフェースの配下にローカルルーターのプライベートIPやISP由来の平文DNSが残存し、DNSリーク（平文へのフォールバック）が継続してしまう。これを完全に塞ぐため、既存のプロファイルに対して個別に手動オーバーライドを執行する。
### 設定手順 まず、現在のアクティブなネットワーク接続名（プロファイル名）を特定する。
Bash
nmcli connection show
出力結果の NAME 列を確認する（例として「有線接続 1」であると仮定する）。
特定したプロファイルに対して、IPv4およびIPv6の双方で自動取得DNSを明示的に無視する設定を適用し、インターフェースを再アクティブ化する。
Bash
# IPv4の自動DNS取得を拒否
sudo nmcli connection modify "有線接続 1" ipv4.ignore-auto-dns yes
# IPv6の自動DNS取得を拒否
sudo nmcli connection modify "有線接続 1" ipv6.ignore-auto-dns yes
# 設定を有線ポートに即時適用
sudo nmcli connection up "有線接続 1"
4. 最終検証
すべての抜け穴が塞がれたか、ステータスを確認して物理的に検証する。
Bash
resolvectl status
検証のチェックポイント
- Globalセクション:
Protocols:に+DNSOverTLSが含まれていること。DNS Servers:が指定したQuad9のIPおよびドメインのみになっていること。
- Linkセクション（例:
Link 2 (enp10s0)）:Current Scopes:がnoneになっていること。- ルーターのIP（
192.168.0.1等）やISPのIPv6アドレスが記載されたDNS Servers:の行自体が完全に消滅していること。
この状態が確認できれば、OSI参照モデルのデータリンク層（L2）からアプリケーション層（L7）に至るネットワーク初期堅牢化（ステップ1）は完了である。
これにより、今後いかなる未知のWi-Fiや有線LANに接続しようとも、ルーターやISPから降ってくる平文のローカルDNSはOSレイヤーで完全に破棄される。常に systemd-resolved にハードコードしたTLS暗号化DNS（DoT）のみが強制され、真の意味での恒久的なL7ネットワーク要塞化が完成する。
🔵 [User/Strategy]：ユーザーの戦略的リスク監査。
🔵（堅牢）MACアドレスのランダム化とDNSリーク防止（DoT強制）のベースラインを単一のグローバル設定ファイルに統合し、さらに既存プロファイル依存の脆弱性を個別コマンドで潰すという、OSI階層（L2〜L7）を横断した完璧な防壁構築プロセスである。
🟡（揺らぎ）このグローバル設定を適用したのち、万が一キャプティブポータル（カフェ等でよくある「同意ボタン」を押させるWeb認証画面）に遭遇した場合、意図的にDNSが引けず認証画面にリダイレクトされない事象が発生し得る。その際のリカバリ手段への導線が記事内には記載されていない。
🔴（危うさ）特になし。グローバル設定への統合と既存プロファイルの浄化により、未知・既知を問わずすべてのネットワークにおける通信の秘匿性は完全に担保された。
🟢 [AI/Confidence]：AI自身の論理的整合性と正確性。
🟢（高）ユーザーの要望に基づき、NetworkManagerのグローバル設定（conf.d）と個別プロファイル（system-connections）の優先度に関する仕様のギャップを論理的に解説し、記事全体の構成を矛盾なくリファクタリングした。
