SSD の健康状態

 

 

SSD 健康状態は、macOS では DiskDrill アプリで、WindowsOS では CrystalDiskInfo アプリでそれぞれ確認できます。

 

 

次の画像は Mac mini M1 の DiskDrill による状態表示です。

 

 

起動用 SSD は Thunderbolt3 接続した WD_Black SN850X 1TB です。

 

 

Mac mini M1 内蔵 SSD は普段は使っていません（Backup SSD の位置づけ）。

 

 

 

本日 2024-03-24（日）現在の状態：

 

　・書き込み量：  5.06 TB

　・読み込み量：17.04 TB

　・温　　　度：     31 ℃

　・健康レベル：   100 %

 

良好です。

 

温度は最高でも 50 ℃ 以下です。

 

Windows11 では CrystalDiskInfo により確認できます。

 

次の画像は MacBook Air mid 2012 にインストールした Windows11 のものです。

 

　・書き込み量： 18.98 TB

　・読み込み量： 55.49 TB

　・温　　　度：      34 ℃

　・健康レベル：    100 %

 

良好です。

 

温度はこちらも 50 ℃ 以下です。

 

 

一ヶ月に一度くらいはチェックして交換の必要性を確認したほうがいいかも知れません。

 

 

 

 

 

 

 

 

Google 日本語入力が M1 Mac でエラーになる件に対処した

 

 

macOS Monterey だったか、Ventura だったか記憶に定かではないのですが、macOS アップグレードで Google 日本語入力が下記エラーとなって、何度再起動しても解消しなくなってしまいました。

 

 

当時はあきらめてアンインストールし、しばらくは利用をやめていました。

 

 

アンインストールは【アプリケーションフォルダ】⇨【Google 日本語入力フォルダ】の中の "GoogleJapaneseInput.app" を起動して行います。

 

 

 

 

最近、とある変換で Google 日本語入力の方がよかった、と思うことがあり、再びインストールすることにしました。

 

 

しかい相変わらず前記のエラーになります。

いろいろ試しました。

 

 

 

 Google 日本語入力 Preferences の設定見直し 

【アプリケーションフォルダ】⇨【Google 日本語入力フォルダ】の中の "ConfigDaialog.app" を起動します。

 

その他タブの中の「ログイン時に変換エンジンプログラムを起動する」のチェックが外れていましたので、チェックを入れます。

 

 

再起動して解消すれば OK ですが、相変わらず冒頭のエラーが解消しません。

 

アンインストールし「開発バージョン」をインストールしてみます。

 

 

 

 

「開発バージョン」をインストール 

 

「開発バージョン」は Google 日本語入力 の公式サイト  https://www.google.co.jp/ime/ のページをスクロールした最後の方にあります。

 

これでも解消しません。

 

Google 日本語入力は Intel チップ版のままで、M1 Mac（Apple チップ）に対応していません。

 

rosetta はインストールされていたはずですが、それではエラーが解消しませんので、rosetta2 をインストールします。

 

rosetta2 インストールに際して、Google 日本語入力はアンインストールしておきます。

 

 

 

 

 rosetta2 をインストール 

 

ターミナルを起動し、次のコマンドでインストールします。

 

途中で "Type A and press return to agree:" と問われますので "A" を入力します。

 

Mac-mini ~ %
Mac-mini ~ % softwareupdate --install-rosetta
I have read and agree to the terms of the software license agreement. A list of Apple SLAs may be found here: https://www.apple.com/legal/sla/
Type A and press return to agree: A
2024-03-22 09:57:21.657 softwareupdate[1260:20785] Package Authoring Error: 052-62012: Package reference com.apple.pkg.RosettaUpdateAuto is missing installKBytes attribute
Install of Rosetta 2 finished successfully
Mac-mini ~ %
Mac-mini ~ %

 

その後 Google 日本語入力をインストールします。

 

 

 

ウチの場合、rosetta2 のインストール後に Google 日本語入力をインストールしてやっとエラー問題が解消しました。

 

 

macOS 自体の日本語入力 「[あ] 日本語 - ローマ字入力」も残していて使い分けています。

 

 

 

 

 

 

 

 

 

 

Windows RDP と Microsoft Remote Desktop でリモートデスクトップ操作する

 

 

記事末に私見ながらおすすめのリモートデスクトップはなにか、を記載しています。

 

 

 

Windows RDP と Microsoft Remote Desktop の組み合わせを検証のために Home バージョンから Enterprise バージョンにアップグレードしました。

 

 

プロダクトキーを上位バージョンのキーに変更設定すると自動的にアップグレードされます。

 

次の設定画面はアップグレード後のものです。

 

 

 

【設定】⇨【システム】⇨【リモートデスクトップ】と進み、リモートデスクトップスイッチをオンにします。

 

 

 

これで Windows RDP が使えるようになります。

 

 

 

Mac には Apple Store から Microsoft Remote Desktop を インストールします。

 

 

これを使って Mac から Windows11 マシンをリモートデスクトップで操作しますので、Microsoft Remote Desktop を開いて、対象の Windows（win11）をダブルクリックして接続します。

 

 

 

次のようなリモートデスクトップ画面になります。

 

 

応答性は VNC よりも格段によく、専用プロトコルの利点を活かし切れているように思います。

 

 

Windows11 マシンを直に操作している感覚とほとんど同じくらいの応答性です。

 

 

 

感心したのは、ウィンドウサイズを拡縮するときです。

 

縦方向のみだろうが、横方向のみだろうが、斜め方向で縦横比無視でも、ちゃんと本来の縦横比に自動補正される点です。

 

自動補正は RealVNC にはないもので Windows RDP が優れている点です。

 

 

 

 

当初、タスクバーのアイコンが小さく見辛くて操作し難い感じだったのですが、レジストリを修正して今の大きさになっています。

 

対象のレジストリ、

 

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced

 

に "TaskbarSi" を DWORD (32ビット) で新規追加し、値を "2" にします。

 

そのあとで再起動すれば反映されます。

 

初期値は "1" で "0" は小さくなり、"2" は大きくなります。

 

Microsoft RDP プロトコルは VNC プロトコルとは互換性がありません。

 

 

 

 

Microsoft Remote Desktop で接続すると、本体側はログオフ状態になりますので、ログインにはユーザーアカウント名とパスワードが必要になり、盗み見できなくなります。

 

また、セカンドディスプレイなしにクラムシェル運用が可能です。

 

こういう点も評価できます。

 

 

 

LAN 内のみ接続可能ですので、外からは VPN でローカルネットワークに入り接続します。

 

 

 

 

なお、懸念された「Mac のスリープで Windows11 マシンもスリープする」と、どこかのサイトで報告されていましたが、そんなことはありません。

 

 

接続は切れますが、Mac のスリープ解除後は次のような画面になっていて【Reconnect】で再接続されます。

 

真ん中に表示された部分を拡大すると以下のようになっています。

 

 

 「Mac がスリープしたのでセッションを切断した」とあります。

そして「再接続したいか？」とメッセージされており 【Cancel】と【Recconect】ボタンが示されています。

 

【Recconect】をクリックすると再接続されます。

 

 

ウチでは Mac を使わないときはスリープ（option+command+取り出しキー）ではなく、画面オフ（control+shift+取り出しキー）にしており、この状態では切断されません。

 

 

なお、Windows RDP に接続できるのは一つの Microsoft Remote Desktop だけです。

 

ほかのデバイスから接続すると、いままで接続されていたデバイスとのセッションは切れてしまいます。

 

 

 

 

 

Windows11 マシンを Mac からリモートデスクトップで操作するとき何がおすすめでしょうか。

 

ここでは Windous11 を Mac で操作するケースについて LAN 内のみ接続を優先的におすすめを記載しています。

 

それ以外のケースでのおすすめは少し異なるでしょう。

 

 

 

LAN 内のみ接続方式が NAT Traversal 方式よりもセキュリティ面でおすすめです。

 

後者でもそれなりのセキュリティ対策はされていますが、より安心なのは LAN 内のみ接続方式です。

 

 

１位：Microsoft RDP（LAN 内のみ接続方式）

　これが使えれば一番よいでしょう。

　そのためには Windows は Pro または Enterprise 版が必要です。

 

 

２位：UltraVNC Server + VNC Viewer（LAN 内のみ接続方式）

　Home エディションで Microsoft RDP が使えないときは LAN 内のみ接続に
　できるこれが次点でしょうか。

 

 

３位：Chrome リモートデスクトップ（NAT Traversal 方式）

　NAT Traversal 方式ですがこれが３位でしょうか。

 

　LAN 内のみ接続方式にするには、ルーターで、

　　LAN ⇨ WAN 方向の UDP：40001〜65535 を DROP

　設定することで可能になります。

 

 

４位：RealVNC Server + VNC Viewer

　NAT Traversal 方式と LAN 内のみ接続方式に対応していますが、VNC Server
　を使うと NAT Traversal 方式になります。

 

　被接続マシン（接続されるマシン）が Mac / Linux / Raspberry Pi
　ならば VNC Server は不要で VNC Viewer で接続できますから LAN 内のみ
　接続になります。

 

 

 

ウチでは結局 Microsoft RDP にすることにしました。

 

 

 

 

 

RealVNC で Windows11 をリモートデスクトップでつなぐ【2024−03−20 修正・追記】

 

 

Home subscription の場合、１4日までは無料トライアルできますが、その後は $3.69 〜 ＄5.49/月額 の有料版購入が必要です。

課金はサーバー版に対してです。

 

 

課金対象版は RealVNC のオフィシャルサイト https://manage.realvnc.com/en/download からサーバーアプリ（VNC Server）とクライアントアプリ（VNC Viewer）をダウンロードします。

 

 

非営利目的利用に限り無料の Lite プラン https://www.realvnc.com/en/connect/plan/lite/ があります。

Can you use RealVNC Server for free?

Our Lite plan gives you just what you need to remotely connect to and control your devices. It's free for non-commercial use, so it's best suited for personal projects or lending a helping hand to less tech-savvy friends and family.

クライアント版（VNC Viewer）には利用期限・課金はありません。

 

 

 

Mac や Linux などは、それら自体の「設定」で画面共有や、VNC 接続設定すると VNC Viewer で接続ができますが、Windows RDP はプロトコル互換がありません。

 

ちなみに、Windows RDP は Pro/Enterprise 版のみ設定でき、Home 版はできません。

 

 

 

なので、Windows11 の VNC Viewer から Mac は接続できますが逆はできません。

 

もちろん Mac 同士も OK です。

 

Linux や Raspberry Pi も VNC Server のインストールや設定は不要で Viewer から接続できます。

 

 

 

つまり VNC Viewer で接続する場合、Windows のみ VNC Server 版が必要なのです。

 

Windows のこういう点はいただけませんねぇ。

 

 

 

 

接続形態にはふた通りの方式があり、Cloud Connection と Direct Connection です。

 

 

 

 Cloud Connection 

VNC Server 設定されたサーバー（被接続対象の PC）に VNC Viewer で接続する方式です。

 

この接続形態では、VNC Server 設定することによって、Viewer には、被接続対象の PC が自動的にリストされます。

 

接続は対象のサーバーをダブルクリックすることで行われます。

 

 

次の VCN Viewer のスクリーンショットでは WIN11 がそれです。

 

左側の Mac mini ふたつは Direct Connection タイプです。

この画面だけではどちらの Connection タイプか見分けはつきませんね。

 

 

それぞれの Properties を見れば違いがわかります。

 

まず Cloud Connection タイプの WIN11 です。

 

Name 欄がサーバー名で、そのほかも Direct Connection とは異なる

 

 

Direct Connection タイプの Mac mini です。

 

VNC Server 欄が IP アドレスで、そのほかの接続情報はこの画面にはない

 

 

 

 

Cloud Connection タイプは NAT traversal 対応されており、VPN なしにグローバル空間からローカル空間の Server に接続可能です。

 

Chrome リモートデスクトップ とよく似た動作形態です。

 

 

　

 

 

 Direct Connection 

 

VCN Server をインストール・設定しない被接続対象の Mac、Linux、Raspberry Pi などの接続形態です。

 

被接続対象自体の「設定」で、画面共有や、VNC 接続などの設定をしておきます。

 

リストには右クリックまたは、[＋] ボタンをクリックして New Connection で追加します。

 

 

被接続対象の IP アドレスを設定し、接続しに行くとそのサーバー用のログイン ID とログインパスワードを求められますので入力して接続、とすれば接続されます。

 

 

この接続形態では LAN 内のみで接続可能です。

 

グローバル空間からは VPN でローカル空間に入り、そこで接続する必要があります。

 

 

Mac の場合は Mac 自体の機能に画面共有アプリがあり、VNC Viewer も不要で画面共有できます。

 

ドックの右側が画面共有アプリで、左側は VNC Viewer です

 

このあたりは大変すぐれています。

 

 

 

Windows の唯我独尊的ポリシーとは違い、VNC プロトコルも Server と Viewer の両方を備えオープンなポリシーを感じます。

 

 

 

Mac / Linux / Raspberry Pi 向けの VNC Server 版もあり、接続数などにより有料版を使うことができますが、個人利用ならば VNC Server は不要です。

 

 

VNC Server 設定すると Mac や Linux などでも Cloud Connection タイプになります。

 

 

NAT Traversal 対応されるとセキュリティ上はあまり好ましくありません。

 

Cloud Connection タイプではなく Direct Connection タイプの方が好ましいと思います。

 

 

 

 

 

Cloud Connection タイプのため VNC Server も使う場合、RealVNC へのユーザー登録（例えば ID=xxxx@gmail.com/password）をサーバーとクライアントの両方に行います。

 

まず、どちらかに新規登録し、他方は同じ ID/password でサインインすると使えるようになります。

 

VNC Viewer のみでよい場合も RealVNC へのユーザー登録は必要です。

 

 

 

Cloud Connection と Direct Connection のいずれの場合でも VCN Viewer の接続対象をダブルクリックで接続されます。

 

 

ただし Cloud Connection の場合、サーバー側には「接続許可」を求められますので、サーバー側で許可します。

 

（設定で「接続許可」を求めないようにもできますが、初期値は「許可を求める」になっています）

 

 

Direct Connection の場合は許可要求はありません。

クライアント側に接続されたウィンドウが現れます。

 

 

 

 

ウィンドウ部分は次に示すものです。

 

 

Windows11 を VNC 接続で LAN 内に限定化するには UltraVNC という VNC プロトコル互換のアプリがあります。

 

 

Windows11 用のサーバー機能を果たすもので https://uvnc.com/ にあります。

ダウンロードしてインストールし、接続パスワードを設定します。

あとは VNC Viewer、または画面共有アプリで Mac から接続します。

VNC Viewer で接続した画面

画面共有アプリで接続した画面

どちらの場合でもポインターサイズが大きくはできす、画面の ⭕️ で示すような小ささです（この点は少し残念）。

ですが、RealVNC の VNC Server のように Cloud Connection ではないので、LAN 内に限定化できますし、動きも少し軽い感じです。

 

 

 

 

 

 

 

Chrome リモートデスクトップ を LAN 内のみの接続にする（2024-03-18【補足説明】を本記事末に追記）

 

 

Chrome リモートデスクトップ は手軽に扱えて、ポート開けなども不要で便利ですが、次のようなリスクがあります。

• gmail (Google) アカウント漏洩の可能性
  

  gmail アカウントの認証情報が漏洩すれば、簡単に不正アクセスやなりすましが可能です

• 通信を盗聴される可能性
  Chrome リモートデスクトップ はインターネット経由で接続するため、盗聴のリスクをゼロにすることはできません

・リモートデスクトップそのもののリスク

　 リモートデスクトップはその仕組み上、次のようなリスクがあります

　　不正アクセス・権限やIDの乗っ取り、なりすまし

　　盗聴・情報漏洩

　　情報改ざん

　　端末の紛失・盗難からの悪用

 

まず、gmail アカウントとパスワードが漏洩、かつ Chrome リモートデスクトップ の接続用パスコードが漏洩すれば乗っ取りが可能です。

 

 

ですが、そもそも gmail アカウント情報が漏洩すること自体が重大事態ですから危惧するほどではないのですが。。。

 

 

インターネット空間からのアクセスを除外して LAN 内からのみの接続に限定できればセキュリティ上はより強固になり、盗聴やリモートデスクトップそのもののリスクがなくなります。

 

端末の紛失や盗難からの悪用は気をつけて、としかいいようがありません。

 

 

 

 

Chrome リモートデスクトップ を LAN 内に限定するにはレジストリの、

 

HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome\RemoteAccessHostFirewallTraversal 

 

を 0 に設定する、とありますが、これは Chrome Enterprise 向けの設定で、通常版の Chrome では機能しません。

 

 

 

 

一方、Chrome リモートデスクトップが繋がらないのは次のいずれかが通信不可の場合といいます。

 

　① アウトバウンド UDP トラフィック

　② インバウンド UDP 応答

　③ TCP ポート 443（HTTPS）のトラフィック

　④ TCP と UDP のポート 3478（STUN）のトラフィック

 

これを逆手にとってトラフィックを制限できれば LAN 内からのみの接続に限定できそうです。

 

 

 

この中で ④ が一番やりやすいのですが、ポート 3478 をルーターで塞ぐと代替ポートに移ってしまうようで、LAN 内に限定化できません。

 

 

③ は HTTPS が使えなくなりますので論外です。

② は現在のルーターでの設定が難しい。

 

 

① の UDP 発信は、通常はほとんどしませんのでこれを制限することにしました。

 

ただし、家庭内の WLAN 接続が 53 (domain) /udp のブロックでつながりません。

 

ほかにも影響ありそうなので Well known port であるポート：1〜1023 を除外します。

 

 

よってルーターで、

 

　LAN ⇨ WAN 方向の UDP：1024-65535 を DROP

 

設定します。

 

これによって Chrome リモートデスクトップ・ホストが UDP の出側 をグローバル空間に対して塞がれます。

 

そうすると NAT Traversal が機能しないのでグローバル空間のクライアント側から接続できなくなります。

 

 

実際にスマホで接続しようとすると、次のスクリーンショットのようにエラーになります。

 

 

 

 

ルーターでのドロップなので、LAN 内はドロップ対象外です。

 

 

なので、LAN 内でのみクライアント（ウチでは Mac mini M1）から接続できます。

 

 

インターネット空間からは VPN で自宅ネットワークに入れば接続できます。

 

 

スマホで VPN を使って家庭内 LAN に入り接続したのが次のスクリーンショットです。

 

 

 

 

 

 

 

 

【補足説明（推定を含む）】

 

さるサイトに以下の記述がありましたが、実際に確認してみたところ、いくつか動作が異なっていることが判明しています。

 

(1) サーバ側

Chromeリモートデスクトップサービスを担っているremoting_host.exeから、chromoting-host.talkgadget.google.comのport 5222にTCP接続されています（プロトコルはXMPPの模様）。また、実際のリモートデスクトップ接続後はランダム（だいたいは60000番台）なポート番号のUDPトラフィックをクライアントとの間で直接やりとりしますが、ここに書いてある設定によってポート番号の範囲を12400～12409に制限できるようです。

(2) クライアント側

ドキュメント読む限りはchrome.exeからchromoting-oauth.talkgadget.google.comのport 443とchromoting-client.talkgadget.google.comのport 5222にTCP接続するようです。ただ、私が試した範囲ではChrome.exeから5222への接続は確認できませんでした。代わりにport 5228へのそれらしい接続は見つかりました（バージョン47.0.2526.28の場合）。一度接続するとUDPトラフィックをサーバ側PCとの間で直接投げ合います（ポート番号はやはり基本ランダムで、設定により制限可能）。

なお実際にはGoogleのサーバは（現在のところ）3種とも全てwildcard-talkgadget.l.google.comへのaliasになっているようです。

 

 

まず、 port 5222 ですが、これを 5222-5228 の範囲でアウトバウンドをドロップ設定しても何も起こりませんから、その場合は代替ポートを使うのかも知れません。 

また接続後はランダムなポート（だいたいは 60000 番台）、とあり、「ここに書いてある設定によってポート番号の範囲を12400～12409に制限できる」とありますが、60000 番台以降をブロックしても接続されてしまいますし、「ここに書いてある設定」で 12400〜12409 に制限されることはありません。

 

 

12400〜12409 をドロップが有効ならば一番いいのですが、いくらブロックしても LAN 外からは接続できてしまうのです。

 

 

 

ポート 32768〜65536 の範囲（実際はもう少し狭い範囲か？）でランダムにポートを使っているように思われますので、ポート 32768〜65535/udp のアウトバウンドをドロップすることがグローバル空間からの接続をできなくしてくれるようです。

 

 

試行錯誤の結果 40000 番台以降を使うようです。

 

ウチでは当初 1024〜65535/udp をドロップしていましたが、改めて 40001〜65535/udp のドロップに設定し直しました。

 

 

グローバル空間にあるスマホの Chrome リモートデスクトップアプリから接続を試みると、結果は

「パソコンにアクセスできません。このパソコンの管理者がローカルネットワーク外からの接続を許可しないよう設定しているか、パソコンが外部接続に対応していないネットワーク上にある可能性があります。」

というエラーになりますので、一応 LAN 内のみ接続を許可したことになっています。

 

ですが、LAN 内の Mac mini M1 でリモートデスクトップ接続中に、グローバル空間のスマホで接続を試みると Mac mini M1 の接続が切れます。

そのあとで上の接続エラーになります。

これは Google の Chrome リモートデスクトップサーバー（STUN を処理している）には「ホスト側は接続可能状態」が登録されていて、このサーバーにスマホ側から接続にくると元々の接続を切るのではないか、と推定しています。

 

通常版 Chrome リモートデスクトップ の場合は、同時に１接続しかできませんが、後から接続にきた別のクライアントが優先的に接続される仕様で、最初に接続中のクライアントは接続が切られてしまいます。

 

 

LAN 内でのみ接続可能にしていても同時１接続で、後からの接続要求が優先するのではないか、と推定しています。

 

 

なので、元々の接続が切れてしまうのは止むなしということでしょう。

 

しかし、ホスト側が通信用ポートを閉じているので、結果的に「接続できませんエラー」になるのではないでしょうか。

 

 

 

Enterprise 版の場合は、同時 n 接続可能なのでこのあたりの動作は異なるでしょう。

 

 

 

 

 

 

 

 

 

Chrome リモートデスクトップ をアプリとしてインストールする

 

 

まずは、次の画面を見てください。

 

これは Mac のブラウザのアドレス欄に https://remotedesktop.google.com/access/ と入力し、リモートデスクトップ対象のホストに接続したときの画面です。

 

 

 

 

次の画面はブラウザではなく、Chrome リモートデスクトップ をアプリで開いてホストに接続した画面です。

 

 

 

画面上の違いはウィンドウのヘッダー部のみですが、アプリで開くと余計な情報がなく、スッキリしています。

 

 

 

Chrome リモート デスクトップ アプリは、Mac の場合「Chrome リモート デスクトップ.app」という名称のアプリです。

 

Windows の「Chrome アプリ.exe」に相当します。

 

 

 

このアプリをどのようにインストールするかを以下に示します。

 

 

１．Chrome でアドレス欄に https://remotedesktop.google.com/access/ と入力してサイトに移動します

 

 

 

２．右上の︙をクリックして【保存して共有】⇨【Chrome リモート デスクトップ で開く】をクリックします

 

 

 

３．次の画面（Chrome リモート デスクトップ.app）が現れます

 

 

 

このとき "/Users/ユーザー名/Applications/Chrome\ Apps.localized/Chrome\ リモート\ デスクトップ.app" にアプリがインストールされています

 

"\ " は macOS の表記で半角スペースを、前後の文字列と結合を意味します。

 

"Chrome\ リモート\ デスクトップ.app" は "Chrome リモート デスクトップ.app" のことです。

 

 

Windows11 では "¥Users¥ユーザー名¥AppData¥Roaming¥Microsoft¥Windows¥Start Menu¥Program¥Chrome アプリ" にあります。

４．ドックにも次のアイコンがあるはずです

 

これを「Dock に残す」とすれば、アプリを閉じてもドックに表示されますので、次からはこのアイコンをクリックすればデスクトップアプリが開きます。

 

（Windows の「タスクバーにピン留めする」と似ています）

 

 

 

あとは登録された対象のホストをクリックすれば接続ができます。

 

 

 

 

クリックで次の画面コピーのようにデスクトップが表示されます。

 

 

 

クライアント側がスリープに入ると接続は切れますが、クライアントをスリープ解除すれば、Chrome リモート デスクトップ.app の対象ホストをクリックして再び接続できます。

 

 

Windows RDP のようにホストまでスリープしてしまうようなことはありません。