AQUOS sense6 の WiFi-AP 切り替え不具合を解消したお話し

 

 

WiFi-AP① につながっていた AQUOS sense6 が、WiFi-AP② エリアに移動しても切り替えされず、4G または WiFi-AP① 接続を継続しようとする事象に陥っていました。

 

 

それまで接続されていた WiFi-AP から離れて、強い電波の WiFi-AP に移動しても、弱くなった電波の WiFi-AP から切り替わってくれないのです。

 

 

OPPO や Umidigi、iPhone SE3 などではちゃんと自動的に切り替わります。

AQUOS sense5G で同様の事例が下記にあり、Smart WiFi Selector や、WiFi Prioritizer アプリでは解消しなかったようです。

https://bbs.kakaku.com/bbs/J0000034432/SortID=24138465/#tab

【WiFi 接続管理アプリで解決】

WiFi Connection Manager というアプリがあり、これをインストールして設定したところ、うまく切り替るようになりました。

 

 

アプリを起動すると次の画面になります。

右上の︙（メニューボタン）をタッチします。

 

 

一番上が WiFi-AP① で ４番目が WiFi-AP② です。

 

 

 

【Settings】をタッチし、各項目についてウチでは次のように設定しました。

 

 

１．Display の設定

 

 

 

２．Scan の設定 

 

 

 

３．Connection Management の設定 ⇨ ココが重要

 

 

　・Switch signal threshold：-65dBm に設定

　　-65dBm よりも弱いときに切り替える設定

 

　・Switch time threshold  ：10 seconds に設定

　　-65dBm 弱い状態が 10 秒以上で切り替える設定

 

　・Skip poor signal network にチェックを入れる

　　お粗末な信号レベルのネットワークに接続しない設定

４．Background service の設定

　　アプリをバックグラウンドで動作させる設定

 

 

５．Misc の設定

 

 

以上です。

 

 

WiFi-AP① から WiFi-AP② のエリアに移動すると以前は切り替わらなかったのが、自動的に切り替るようになりました。

 

 

３項の Connection Management の設定で、

 

　・Switch signal threshold：-65dBm に設定

　・Switch time threshold  ：10 seconds に設定

　・Skip poor signal network にチェックを入れる

 

としたのが有効に作用していると思われます。

 

 

 

これにより切り替わらなかったストレスから開放されました。

 

 

 

 

 

 

 

 

GL•iNet -- OpenWrt 搭載ルーター

 

 

１万円台で手に入る GL•iNet -- OpenWrt 搭載ルーターがお勧めです。

 

GL.iNet MT2500A に DS-lite ルーターとしての設定をしたお話し を参考ください。

 

 

PPPoE は勿論のこと、IPv4 over IPv6 方式である MAP-E や DS-Lite にも対応できます。

 

前者は V6 プラス、OCN バーチャルコネクトなどのサービス名で提供されており、後者は transix、Xpass などのサービス名で提供されています。

 

違いは前者が IPv4 の NAT 変換をルーターで行っているのに対し（NAT ステートレス）、後者は JPNE などの VNE 側（通信事業者）で行なっていることです（NAT ステートフル）。

 

 

どちらの方式でも固定 IPv4 サービス契約でない場合、複数の加入者間で IPv4 アドレスを共有しており、一度に使えるポート数を制限しています。

 

　・加入者１：ポート1 〜 ポート2

　・加入者２：ポート3 〜 ポート4

　・加入者３：ポート5 〜 ポート6

　　　　︙

　　　　︙

 

 

この制限は、一度に使えるセッション数に制限があるということです。

 

 

例えば Web サイト閲覧時に、一つのサイトで 100 セッションを越えることがあります（例えばニチバンサイト）。

 

 

複数のデバイスでネットを使っているとセッションオーバーになることがあり、利用中ポートが解放されるまで新たな閲覧ができない、またはタイムオーバーエラーになることがあります。

 

 

RTX830 の場合、ポートセービング IP マスカレードという機能があり、宛先 IP アドレスが異なれば同じポート番号が使えるという働きをします。

 

これによってセッションオーバーしにくいということですが、NAT 変換をルーター側で行う MAP-E 方式で有効な機能です。

 

 

 

OpenWrt ルーターではこのポートセービング IP マスカレードと同様のことが iptables で実現できるそうですが、未確認です（ウチは Xpass -- DS-Lite 方式 -- のため）。

 

  

 

GL•iNet 製品の中でも家庭用ルーターとしては AXT-1800 (WiFi 付き) または MT2500A (WiFi なし) が性能的にお勧めです。

 

 

MT2500A は WiFi なしですがハードウェアアクセラレーターが搭載されており、高性能で YAMAHA の RTX830 に迫る性能です。

 

 

AXT1800 はアマゾンで 15,000 円前後、MT2500A は１万円前後で入手できます。

 

次に示すのは AXT1800 です。

 

出典：GL•iNet 社の製品ページから抜粋

 

 

 

次に示すのは MT2500 (プラスチックケース)、および MT2500A (金属ケース) で仕様はまったく同一ですが、放熱性能がよい金属ケースの MT2500A がお勧めです。 

出典：GL•iNet 社の製品ページから抜粋

 

国内メーカー品に比しても安定稼働し、安価です。

 

 

OpenWrt を搭載していますので、ルーターとしての機能性も十分です。

 

 

 

ウチでは YAMAHA RTX830 を長らく使っていましたが、現在は MT2500A にメインルーターを変えています。

 

大変コンパクトで、光ケーブルが引き込まれている居間の中央監視盤（インタホン本体兼火災報知器）まわりがスッキリできるのが RTX830 を MT2500A に置き換えた理由です。

 

RTX830 は WiFi 機能なしルーターなので、以前はこれに WG1200HS4 を組み合わせ、ONU も結構な大きさでした。

まず、ONU を小型ONU に変更し、MT2500A をルーターにしたことで、中央監視盤まわりのゴチャゴチャがスッキリコンパクトになった、ということです。

 

当初は MT2500 に WiFi ドングル (IEEE802.11n) を挿していましたが、現在は IEEE802.11ac に対応している WG1200HS4 を WiFi-AP としてつないでいます。

 

 

Xpass ですが現在までにセッションオーバーとおぼしき事象には見舞われていません（と、思います）。

 

セッションオーバーはルーターの問題ではなく、IP アドレス共有型契約の IPv4 over IPv6 の宿命です。

セッションオーバーが多発するようであれば、ポートセービング IP マスカレードを行うか、全ポート（1 〜 65535）が使える固定 IP アドレス契約に変更するか（セッションオーバーにはならない）、です。

 

 

 

 

 

Mac のフォルダを Android で共有する

 

 

Google Drive や iCloud などでフォルダ共有はできますが、Mac に共有用のフォルダを作成し、それを Android スマホで共有します。

次の各ステップで行います。

　・ Mac 側での設定（macOS Sonoma での設定事例）

　・ Android 側での共有設定と Mac のファイルの共有

　・ 便利技【その1】：共有フォルダへのジャンプ

　・ 便利技【その2】：共有フォルダへのショートカット作成

　・ Mac 側での Android のファイルの共有

　・ Android のファイルなどを Mac に送り込む場合のやり方

　・ Mac のファイルなどを Android で取り込む場合のやり方

 Mac 側での設定（macOS Sonoma での設定事例）

 

まず、共有フォルダを作成します。

 

本事例では "Mac_SharedFolder" という名称で作成しています。

 

 

次に [システム設定] ⇨ [一般] ⇨ [共有] と進み「ファイル共有」をオンにします。

「ファイル共有」スイッチの右側のの部分をクリックします。

 

 

次のようなダイヤログが現れます。

左側の「共有フォルダ」欄の ➕ マークをクリックして共有フォルダ "Mac_SharedFolder" を追加します。

 

右側の「ユーザ」欄には初期値で「管理者」と「すべての人」が設定されていて、「管理者」には「読み/書き」権限があたえられており、「すべての人」には「アクセス（権）なし」設定されています。

 

 

権限を変更するにはユーザ名の右の ∧∨ 部分で変更します。

 

新しくユーザを追加するには「ユーザ」欄の ➕ マークをクリックして追加します。

 

 

【完了】キーを押して終了します。

 

 

 

 

 

 Android 側での共有設定と Mac のファイルの共有 

 

Google Play Store から「ファイルマネージャー」をダウンロードしてインストールします。

 

開きます。

 

次の画面コピーはファイルマネージャーの HOME 画面です。

 

 

「リモート」をタップします。

 

 

「➕ リモートロケーションを追加する」をタップして「ローカルネットワーク」をタップすると追加できる Mac や NAS が現れますので対象となる Mac を追加します。

 

上の画面コピーはすでに追加済みです。

 

mac-mini をタップするとその中の SSD などに加えて「共有フォルダ」設定した "Mac_SharedFolder" が現れているはずです。

 

 

これで Mac のファイルやフォルダを、Android 側で共有することが可能になりました。

 

 

 

 

 

 便利技【その1】：共有フォルダへのジャンプ 

 

ファイルマネージャーの HOME 画面から共有フォルダへ一気に飛ぶ方法を示します。

 

 

まず、共有フォルダ設定した "Mac_SharedFolder" をタップします。 

 

次のような画面になりますので、左上の三本線メニュー ≡ をタップします。

 

 

次のようにメニューの中に共有フォルダ設定した "Mac_SharedFolder" が現れます。

 

 

この共有フォルダの右にある縦三点リーダー ︙ をタップするとサブメニューに【固定】と【削除】が現れます。

 

 

【固定】をタップするとこのメニューに固定されます（ピン留めマークが付きます）。

 

 

次からはファイルマネージャーの HOME 画面からピン留めしたフォルダをタップして、直接この共有フォルダに飛ぶことができるようになります。

 

 

 

 便利技【その2】：共有フォルダへのショートカット作成 

 

共有フォルダへのショートカットをスマホのホーム画面に作成する方法を示します。

 

このショートカットをタップで直接、共有フォルダ設定した "Mac_SharedFolder" に飛ぶことができます。

  

 

やり方ですが、mac-mini の配下の SSD や 共有フォルダを表示して、共有フォルダ設定した "Mac_SharedFolder" を長押しします。

 

そして右下の縦三点リーダー [その他] をタップします。

 

 

現れたサブメニューの「ホーム画面に追加」をタップします。

 

「ホーム画面に追加」がサブメニューに現れないときは「設定」をタップし、「ホーム画面に追加」にチェックを入れます。

 

 

 

そうするとサブメニューに「ホーム画面に追加」が現れるようになりますから、これをタップすると次のように、スマホのホーム画面にショートカットが追加されます。

このシートカットをタップすると、一発で共有フォルダ設定した "Mac_SharedFolder" に飛びます。

 

--便利技はここまで-- 

 

 

 

 

 

 Android のファイルなどを Mac に送り込む場合のやり方 

 

[対象のファイルやフォルダ] を長押し ⇨ [共有マーク] をタップ ⇨ [ファイルマネージャー] をタップし、便利技【その1】で示したメニューから共有フォルダ設定した "Mac_SharedFolder" をタップして [保存] すると "Mac_SharedFolder" に保存されます。

 

 

 

 

 

 Mac のファイルなどを Android に取り込む場合のやり方 

 

対象のファイルやフォルダを "Mac_SharedFolder" に置きます。

 

そして Android 側で [ファイルマネージャー] をタップし、便利技【その2】で示したショートカットから [取り込み対象のファイルやフォルダ] を長押し ⇨ [コピーまたは移動] をタップします。

 

そしてファイルマネージャー HOME 画面から [メインストレージ] をタップ ⇨ [コピーまたは移動先フォルダ] をタップ ⇨ [貼り付け] をタップ、で取り込み完了です。

 

 

 

mac-mini 側は配下の他のフォルダでも構いませんが、その場合はタップがもう３〜４回必要になりますので、共有フォルダ経由の方がやりやすいと思います。

 

 

 

 

 

 

 

 

 

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 内に限定化できますし、動きも少し軽い感じです。