そもそも何をしたかったのか
操作対象として、家にMacBook 2台とWindows PC 2台がある。PCが増えたのは、整理できていないからではない。それぞれに必要なアプリ、作業中の状態、OS固有の役割があり、一台へまとめない方が都合がよかった。
一方で、操作する場所まで4つ必要とは限らない。別のPCを少し確認するたびに席を移り、画面と入力機器を持ち替える。数分の作業でも、その前後で思考の流れが切れる。
欲しかったのは、性能の高い新しいPCでも、4台を1台へ移行する計画でもなかった。4台はそのままに、普段使うメインPCから一つの作業机として扱うことだった。
私の場合、メインPCはVRにも使うWindows機だが、この構成はVRを前提にしない。デスクトップPCでもノートPCでも、NoMachineのクライアントが動けば同じ考え方で使える。
そこで、メインPCを「操縦席」にして、家にある4台を同じ画面・キーボード・マウスから扱えるようにした。やりたかったのは、単なる遠隔操作ではない。
- MacとWindowsを一つの操作方法にそろえる
- メインPCから、必要なPCへすぐ切り替える
- メインPCのマイクをMacやWindowsへ渡し、Codexへ音声入力する
- 家の外からは接続できないようにする
- 使わないときは、迷わず閉じられるようにする
結果として、いつもの席から必要な端末を選び、画面操作やCodexへの音声入力まで続けられるようになった。接続は家庭内LAN上の直接IPだけで、インターネット公開、クラウド経由の接続、ルーターのポート転送は使っていない。
この記事は、NoMachineの機能紹介ではない。便利な遠隔操作を、必要な範囲だけ開けて運用するまでの話である。
この記事が役立つ人
次のような人を想定している。
- 家にMacとWindowsが複数あり、メインPCからまとめて操作したい
- 外出先からの接続は不要で、家庭内LANだけで使いたい
- NoMachineを入れた後、どこまで閉じればよいか迷っている
- 画面操作だけでなく、必要なときはマイクも転送したい
- セキュリティ製品を新設するほどではないが、異常には気づけるようにしたい
反対に、外出先から自宅PCへ接続したい人や、企業向けのゼロトラスト構成を探している人には、そのまま当てはまらない。
何ができるようになったのか
先に、完成後の変化をまとめる。
| 以前 | 今 |
|---|---|
| PCごとに席を移動して操作 | メインPCから4台へ直接接続 |
| MacとWindowsで操作方法がばらばら | NoMachineに統一 |
| 音声入力のたびに対象PCのマイクを使う | 接続中だけMic Inを有効にし、メインPCのマイクを転送 |
| リモート機能が今開いているか分かりにくい | デスクトップの切替から有効／無効を明示 |
| 設定が変わっても気づきにくい | 署名・設定・通信・認証失敗を継続監視 |
| 異常時に人が止める | 重大異常ならセッションを切り、再起動後も無効化 |
感覚としては、家庭内LAN上に「ソフトウェア版のKVM」を作ったのに近い。KVMとは、複数のPCを一組の画面・キーボード・マウスから扱う仕組みのことだ。
ただし、便利さのために4台を常時開放したわけではない。必要なときだけ開き、使い終わったら閉じるところまでを一つの機能にした。
なぜNoMachineにしたのか
今回の判断軸は、「一番有名か」ではなく、4台を同じ運用へそろえられるかだった。
| 候補 | 良い点 | 今回の判断 |
|---|---|---|
| Windows RDP | Windows同士では導入しやすい | macOSを含む4台を同じ方式にそろえにくい |
| VNC | 対応製品が多く、仕組みも分かりやすい | 音声を含む操作体験を別途組み立てる必要がある |
| RustDesk | 複数OSで使いやすい | 今回は不採用とする前提だった |
| NoMachine | macOS／Windows、物理画面、入力、音声、LAN直結を一つで扱える | 採用。ただし不要機能は閉じる |
NoMachineは、家庭内LANのIPアドレスを指定して直接接続できる。ベンダーの中継サービスを通さず、MacとWindowsを同じクライアントから操作でき、マイク転送も扱える。この要件への収まりがよかった。
採用バージョンは9.8.2以上とした。9.8.2はサーバー側の権限昇格につながり得る問題を修正しているため、「新しい方がよさそう」ではなく、セキュリティ上の最低ラインとして決めた。公式リリースノート
道具は決まった。次は、画面が映るところから、毎日使える状態まで仕上げる必要があった。
動作確認の先にあった、運用の完成条件
NoMachineをインストールし、画面が見えて、キーボードとマウスが動く。接続試験としては成功である。
ただし、日常的に使う仕組みとして見ると、まだ答えていない問いが残っていた。
- TCP 4000へ実際に接続できるのは誰か
- 画面や入力へ触れられる強いOS権限を、どのコードへ預けるか
- アップデートや設定変更で、閉じた機能が戻っていないとどう確認するか
- 作業後に、接続口が閉じたことをどう確認するか
実際のプロセスと通信を調べると、対策すべき境界も具体的になった。
- 接続を受ける
nxdは、TCP 4000を広いアドレスで待ち受ける - macOSでは、画面収録・アクセシビリティ・入力監視・マイクという強い権限を持つ
- 初期設定のままでは、今回使わない共有機能や外部接続機能も選択肢に入る
- 管理者権限で動く切替スクリプト自体も、置き方を誤ると攻撃の入口になる
つまり、NoMachineの設定画面だけを見ていても足りない。アプリを家の玄関だとすれば、実際の門扉はOSのファイアウォールである。さらに、門の状態が変わっていないかを確かめる仕組みも必要になる。
そこで完了条件を、「接続できる」から、家庭内からだけ接続でき、使い終われば閉じ、状態が変われば検知できるへ更新した。
採用した構成：3層で閉じる
[メインPC / NoMachine Client]
|
| NX over TCP 4000
v
[家庭内LAN 172.16.0.0/21]
| |
v v
[Mac: Application FW + pf] [Windows Defender Firewall]
| |
+--------> nxd <----------+
Internet ──X── Routerのポート転送なし
UPnP / NAT-PMPなし
NoMachine Networkなし
NoMachineのNX接続は、既定ではnxdがTCP 4000で受ける。UDPも映像・音声に利用できるが、今回は構成を単純にするためTCPだけにした。NoMachineのポート仕様
1. 接続経路を閉じる
- 家庭内LANからの直接IP接続だけを使う
- 許可範囲は
172.16.0.0/21。これは家庭内で使うIPアドレスの範囲を表す - NoMachine Network、Machine ID接続、UPnP／NAT-PMP、Web接続、SSH経路を使わない
- ルーターへポート転送を追加しない
- DHCPで端末のIPが変わっても、家庭内サブネット内なら接続できる
運用の本線は直接IP接続であり、LAN探索には依存しない。NoMachine Networkは設定でも無効化した。無効化方法の公式資料
2. 使う機能だけ残す
認証はNoMachine専用パスワードを増やさず、macOS／Windowsの正規ユーザーへ一本化した。
ゲスト接続、仮想デスクトップ、ファイル・ディスク・プリンター・USB・スマートカード・ポート・クリップボード転送、画面録画は無効にした。主用途として残したのは、画面、キーボード、マウス、マイクである。
マイクは常時の標準入力にしない。セッション中にMic Inを有効にしたときだけ、メインPCのマイクを対象PCへ渡す。音声出力はマイク機能を壊さず全体だけを無効化できなかったため、セッション側でミュートする運用にした。
3. 変化を監視し、迷ったら止める
「設定した時点で安全」ではなく、「その状態が続いているか」を見る。
Mac側ではrootのLaunchDaemonを60秒間隔と重要ファイル変更時に動かし、コード全体のハッシュは5分間隔で確認するようにした。
- 公式署名とTeam ID、実行コードの所有者・書込権限
- NoMachine設定、
pf、Application Firewall - TCP 4000の接続元、UDP、予期しない待受・外向き通信
- 家庭内ネットワークの既定経路とゲートウェイ
- 接続ログと、重複を除いた認証失敗数
重大異常なら、接続中のセッションを終了し、NoMachineを停止する。その後も自動復帰させず、利用者が原因を確認して明示的に有効化する。
Windows側も観測軸は同じで、Authenticode署名、サービス状態、TCP接続、Defender Firewall規則、イベントログへ対応付ける。OSが違っても、見るべき境界は「コード」「設定」「通信」「認証」の4つで変わらない。
macOSとWindowsで変えたところ
共通の方針は同じだが、OSが提供する防御機能は異なる。
| 観点 | macOS | Windows |
|---|---|---|
| 受信制限 | Application Firewallを維持し、専用pf設定でTCP 4000を家庭内LANに限定 |
Defender FirewallのPrivateプロファイルだけに、TCP 4000＋送信元範囲の規則を作成 |
| 広すぎる許可 | IPv6 TCP 4000とNoMachine用UDPを明示的に遮断 | インストーラーが作った広い許可やUDP許可を残さない。Public／Domainでは許可しない |
| 起動 |
pfを先に読み込み、安全確認後にnxdを起動 |
ネットワークプロファイルと専用規則を確認してサービスを利用 |
| 正規性 | Apple公証、Gatekeeper、Team ID、コードハッシュ | Authenticode署名、発行元、サービス実行ファイル |
| OS権限 | 画面収録、アクセシビリティ、入力監視、マイク | マイクとデスクトップアプリのマイク利用 |
macOSのApplication Firewallはアプリ単位の許可には向くが、接続元のIPアドレス範囲までは絞りにくい。そのため、既存設定を置き換えず、pfの専用設定を追加した。pfはmacOSが持つ、通信を細かく制御する仕組みである。
Windowsでは、Privateプロファイル、TCP 4000、送信元172.16.0.0/21の3条件がそろう専用規則を作った。大切なのは新しい規則を追加することより、同じポートをAnyから許可する古い規則を残さないことである。Windows Firewall規則の公式仕様
実際に観察して分かったこと
設定値だけでなく、待受ポート、確立済み通信、署名、ファイル変更、ログを見た。
| 対象 | 観察結果 | どう判断したか |
|---|---|---|
nxd |
TCP 4000を広いアドレスで待ち受ける | 想定動作。ただし接続元制限はOSファイアウォールに依存するため、規則の消失を重大異常とした |
nxserver / nxnode
|
セッション管理にローカル通信を使う | ループバック通信は正常系として、外部への通信と分けて観察した |
| Network / UPnP / Web / UDP | 今回は不要 | 無効状態、UDPソケット、外部ポート割当ての再発を監視した |
| NoMachine本体 | 公式署名を確認 | macOSでは設定ファイルがアプリ内にあるため、実行コードの署名とコード領域のSHA-256を分けて確認した |
| 仮想マイク | セッション中だけ利用 | 強い権限を持つため、常時利用より停止しやすさを優先した |
| 管理者用の切替処理 | サービスを停止・起動できる | デスクトップには入口だけを置き、実処理はroot／管理者所有の固定ヘルパーへ分離した |
詳細ログを取得できたMac側では、導入時と監視導入後の観測範囲で、不審な外部接続や、許可していないUDP待受は見つからなかった。確認できたのは内部通信と、自分で行った接続試験だけだった。
これは「問題がない証明」ではない。今後の変化と比べるための基準値ができた、という意味である。
普段の使い方
日常の操作は難しくしなかった。
- 対象PCのデスクトップからNoMachineを有効化する
- メインPCから、家庭内IPのTCP 4000へ接続する
- 音声入力が必要なときだけ
Mic Inを有効にする - 作業が終わったらNoMachineを無効化する
無効化すると接続中のセッションを終了し、TCP 4000を閉じ、その状態を再起動後も維持する。ファイアウォール自体は無効にしない。
有効化も単なるサービス開始ではない。家庭内ネットワーク、ファイアウォール、危険な設定、署名・ハッシュを事前確認し、一つでも外れていれば起動しない。
正式アップデートでコードハッシュが変わった場合も、安全側へ停止する。新しい版の署名と変更点を確認した後、その端末上で基準値を作り直す。
この構成が保証しないこと
この仕組みはEDRやマルウェア対策の代替ではない。また、次までは保証しない。
- 家庭内LAN上の正規端末そのものが侵害された場合の本人判定
- root／Administratorを奪われた後の完全な検知
- ベンダー署名鍵の侵害や、基準値作成前から存在する高度な攻撃
- OSの権限機構だけによる、マイクや画面情報の完全な利用監査
- MacBookの蓋を閉じた状態や、FileVaultログイン前画面からの確実な操作
それでも、家の外から使わないなら外へ開けない、使わない機能は止める、変化を観察する、判断できない異常では止める。この順で考えると、遠隔操作ソフトのリスクを説明しやすくなる。
今回得られた一番大きな価値は、4台を遠隔操作できたことだけではない。4台を一つの作業机として扱いながら、必要なときだけ開き、使い終われば閉じるところまでを、同じ操作にできたことだった。