2024-09-17

macOS Sequoia 15.0 が降ってきた

 

 

2024年 9月17日(火)に macOS Sequoia 15.0 が降ってきました。

 

 

新 OS は初期不良の可能性があるので、メインマシン・Mac mini M1 へのアップグレードは少し見合わせます。

 

Sonoma のときも SSD の異常書き込みがあり、Spotlight の検索対象になっていると異常書き込みになることを突き止め、Spotlight の対象から外したことがあります。

 

 

こういう重大問題を含んでいることがあるので、メインマシンへのアップグレードは1ヶ月くらいは様子見です。

 

 

サブマシンの iMac 2019 の方には macOS Sequoia 15.0 にアップグレードしました。

 

データ類はすべてメインマシンの方なので、サブマシンに異常が生じても再インストールすれば済むのです。

 

 

 

同時に macOS Sonoma 14.7 も降ってきています。


14.7 はセキュリティパッチです。


あと、Command Line Tool for Xcode と Safari もアップデートがあり、これらは Mac mini M1 にもアップデートを実施しました。




 

iOS 18 もデリバリされましたが、iOS 17.7 にいったんアップデートしないと iOS 18 は降ってきませんでした。


ウィジェットやホームのアイコンの配置がやっとこさ自由になりました。

 

スティーブ・ジョブスがずーっと拒否していたホーム画面の自由配置です。




iMessage が RCS に対応しましたが、実際に利用するためにはキャリア側の対応が必要で、現時点で KDDI は非対応です。

 

Android 機で Google メッセージの RCS が使えるかは未確認です。

 


 

楽天モバイルやドコモは Google メッセージで RCS に対応していますが、Rakuten Link の RCS ベースのメッセージングや +メッセージとは非互換です。



メッセージングはまだまだ世界的統一は無理なようです。

 

あれこれ使い分けるのも疲れますねぇ。

 


 

 

 

 

 

2024-09-16

Windows 用キーボードとして Magic Keyboard を使う

 

 

MacBook Air 2012 にデュアルブートで OCLP により Monterey をインストール、併せて Boot Camp により Windows 11 Enterprise をインストールしています。


Windows 11 は RDP でメインマシンの Mac mini M1 2020 から画面共有しています。



このときにキーボードは Mac 純正の Magic Keyboard を、Mac Mini M1 の画面と RDP による Windows 11 の画面で共有しています。



Mac 側は純正キーボードなので、なんら問題はありません。

 

Apple Magic Keyboard


 

Windows 側は次のような Windows 用キーボードではないので、少し工夫が要ります。

 

Macally Keyboard


Windows 11 のキーボード初期値は「英語キーボード(101/102キー)」のようで、Magic Keyboard とは記号キーの配置が異なっていて、キートップの記号とは違う記号になってしまいます。

 


具体的には、記号類が Windows 用キートップとは配置が異なるので、記号類を Magic Keyboard のキートップと一致させる必要があります。


② 半角・全角漢字キーがないので、Magic Keyboard の[英数]キーと[かな]キーを同じ目的で使えるようにします。

 

① ② を設定することでメインマシンの Mac mini M1 の画面と RDP/Windows 11 の画面を同じ操作感でキーボードが使えるようになります。

 

 

 

 

 

 

 ① キートップと、記号類を含む入力文字を一致させる 


[システム設定]⇨[時刻と言語]⇨[言語と地域]⇨[キーボード]と進みます

 

 

 

[キーボードレイアウト: 日本語キーボード(106/109 キー)]になっているかを確認する

 

なっていなければ[レイアウトを変更する]をクリックして[日本語キーボード(106/109 キー)]を選択し、システム再起動で反映させます

 

以上です。

 


 

 

 

 

 ② 半角・全角漢字キーがない 

 

半角・全角漢字キーの代わりに「英数」キーと「かな」キーをこれに当てますが、後ろの方に記載の Google 日本語入力 プロパティ のキー設定・編集で「英数」キーと「かな」キーを指定できません。

 

そこで PowerToys アプリを使い「英数」キーと「かな」キーをそれぞれ仮想的な F14 と F13 に割り当てます。

 

Google 日本語入力 プロパティ のキー設定・編集では Fnn を指定することができます。

 

つまり F14 は「英数」キーを指定したことになり、同様に F13 は「かな」キーを指定したことになるわけです。

 

 

 

まず PowerToys のリリースページにアクセスします

 

自分のマシンのアーキテクチャーに合致した .exe ファイルをダウンロードし、これを実行します

 

[Keyboard Manager]⇨[Keyboard Manager を有効化する:スイッチオン]



 

 

[キーの再マップ]をクリックします

 


[+ キーの再マップの追加]をクリックすると、
で囲んだ部分が現れます

 

 

[選択]欄をクリックして[かな]キーをクリックすると VK242 が設定されます


[キー/ショートカット]欄をクリックして[F13]を選択します

 

つまり[かな]キー = F13 とするわけです


 

同様に[+ キーの再マップの追加]をクリックしてもう一つ追加します

 

[選択]欄をクリックして[英数]キーをクリックで VK244 が設定されます


これには[キー/ショートカット]欄をクリックし[F14]を選択します

 

つまり[英数]キー = F14 とするわけです

 

 

 

F13 も F14 も実際には存在しない仮想的なキーなので、システムへの影響はありません

 

右上の[OK]をクリックします

 


 

上図のような警告が出ますが[それでも続行する]で反映させます

 


 

PowerToys の設定は以上です

 

実際に[英数]キーと[かな]キーに機能を割り当てていきます

 

IME の 部分を右クリックし[プロパティ]をクリックします

 


 

Google 日本語入力 プロパティが表示されます

 


 

[編集]をクリックし現れた画面の[編集]で[エントリーを追加]します

 


 

下図の画面になりますので[入力文字なし]の[F14]を[IME を無効化]とし、もう一つエントリーを追加して[直接入力]の[F13]を[IME を有効化]とします


 

 

[OK]をクリックし Google 日本語入力 プロパティ画面にもどります

 


 

[適用]⇨[OK]として反映させます

 

以上で[かな]キーが【かなモード】、[英数]キーが【英数モード】になります

 


 

 

実際にそれぞれのキーをタッチしてみます

 

まず[かな]キーです

【かなモード】になっています

 


 

次に[英数]キーです

【英数モード】になります

 


 

 

以上です。

 

これで Magic Keyboard をメインマシンの Mac mini M1 と、RDP 共有した Windows 11 で同じ操作感で共有できました。

 


 

 

 

 


 

 

2024-09-08

Rakuten Casa 接続で LTE を吹く

 

 

最近また Rakuten Casa がつながらない、LTE を吹かないという件に関してコメントで問い合わせが来るようになりました。

 

 

Google 検索をチェックしてみると「こうすればつながる/つながったと」いう多くが、セキュリティに配慮しない IPv6 パススルー(または IPv6 ブリッジ)でLTE を吹くようになった、というものです。



これは大変危険です。

 


IPv6 パススルー(または IPv6 ブリッジ)は世界中にあなたの IPv6 が筒抜けになっています。

 

ポートスキャンでポートの穴を見つけると、そこから侵入される恐れがあります。

 

なので、正しく VPN プロトコルだけを通す設定で「つなぐ」必要があります。

 

そうすれば暗号化と鍵交換でセキュリティが確保されますから安心なのです。

 

ここではそのことに関して記載しています。


ーーーーーーーーーー

 

ウチでは楽天電波がどの部屋でも入るようになっていますので、Rakuten Casa は 2022年1月に返却済みです。

 

2020年12月に Rakuten Casa がつながった頃の接続に関して改めて整理してみました。

 

 

出典:楽天モバイルの Rakuten Casa に関するホームページより抜粋
 

Rakuten Casa は小型基地局で、家の中に楽天モバイルの LTE 電波が飛ぶ(吹く)ようになります。


Rakuten Link のみならず、標準通話アプリや標準メッセージアプリによる通話や SMS も安定します。

 

Rakuten Link ログインの際も SMS 認証が必要で、このときも Casa 設置の意味があります。

 

 

 

Rakuten Casa は接続に際して VPN を介しており、そのためルーターに IPsec IKE/esp VPN をパススルー設定(開放設定)しなくてはいけません。

 

 

パススルー設定とは、特定のプロトコルやポートを開放して外部サーバー側からの通信を通してやる、ということです。

 

IPsec IKE/esp と Rakuten Casa の振る舞いについては後ろの方に解説します。

 

 

 

 

 Rakuten Casa のパススルー設定について 


フレッツ網を使っているプロバイダを利用している場合はIPv6IPsec IKE/esp をパススルー設定します。

 

これは楽天モバイル側がフレッツ網につながって IPv6 で VPN を張るようにしているからです。

 

 

具体的には、

 

 ① esp(暗号化);プロトコル番号 = 50

 ② IKE(鍵交換);プロトコル = UDP、ポート = 500

 ③ NAT Traversal;プロトコル = UDP、ポート = 4500

   IPv6 では NAT は通常は使いませんので ③ は設定不要です


を、ルーターの IPv6 フィルター設定機能を使ってパススルー設定します。

 

間違ってもIPv6 パススルー(または IPv6 ブリッジ)設定はしないでください。

 

 

Rakuten Casa 接続に際して一時的にIPv6 パススルー(または IPv6 ブリッジ)設定を行った場合でも、必ず IPv6 フィルター機能で設定し直してください。

 

Rakuten Casa のホームページの設定に関しIPv6IPsec IKE/esp をパススルー設定のほかにIPv6 パススルー(または IPv6 ブリッジ)設定が書かれていますが、これはセキュリティ上、非常に問題がある記述で、ネットワーク技術やセキュリティリテラシーが極めて低いヒトが記載したものでしょう(こういうところは楽天表現そのものでいただけません)。

 

 

 

 

当ブログの下記記事にIPv6IPsec IKE/esp をパススルーの仕方を Buffalo ルーターや Aterm ルーターの設定事例として記載していますので参考ください。


Rakuten Casa がつながりました!!! (2020-12-24)

 

 

 

フレッツ網以外の場合は IPv4 IPsec IKE/esp をパススルー設定します。

 

 

IPv4 の場合は NAT traversal も通過設定が必要かも知れません。

 

 ③ NAT Traversal;プロトコル = UDP、ポート = 4500

 

 

Nuro や コミュファ光などの特殊なルーター(F660P/A や F2883S)は ① esp をパススルー設定できませんので、ALG(Application Layer Gateway)で IPsec を通過させるようにします。 


 

 Nuro のルーター・F660P/A の場合 

 ・ルーターの LAN ポートと Casa の WAN ポートを LAN ケーブル(CAT6 以上)で接続
 ・ファイアウォール機能を有効:チェック入れる
 ・ファイアウォールレベル (IPv4):高
 ・SPI (IPv6) を有効:チェックを入れる
 ・ALGスイッチ:IPSEC ALGにチェック入れる
 ・上記以外デフォルト




 コミュファ光のルーター・F2883S の場合  
 

 ・ルーターの LAN ポートと Casa の WAN ポートを LAN ケーブル(CAT6 以上)で接続
 ・ALG設定:IPSEC ALG をオンにする
 ・上記以外デフォルト






 Rakuten Casa 接続時の LTE ランプの状態 

 

Casa に故障や楽天モバイル側の出荷時のミスがなく、接続設定が正しければ次のように変遷します。

 

 1️⃣ 消灯  :30〜50秒間、消灯状態

 2️⃣ 緑色点滅:1秒間隔で繰り返し、80〜90秒続く

   LTE が再接続されれば OK(緑 "点灯" になる)

   LTE が再接続できないと ③ に移る

 3️⃣ 黄色点滅:4回点滅を繰り返し、10分以上続く

   再び 1️⃣ から繰り返す

つまり 1️⃣ 〜 3️⃣ は、1時間に 約5回 ほど繰り返す、ということになります。

この一連の表示遷移を長時間繰り返しますが(1日〜数日?)、放置しておけばそのうちに LTE 再接続されます。

 

ランプ表示がこのように遷移しない場合は、ルーター側の設定問題か、Rakuten Casa の故障などが考えられます。
 

 

設定が正しい場合、Rakuten Casa のサポートに連絡して接続認証状態を確認してもらう必要があります。

 

 

 

 

 Rakuten Casa の接続動作について 

 

以下は一部に推定を含みます。

 

当初の Casa のバージョンでは接続ログを見れましたから、ある程度処理内容の推定ができました。

 

いまはログが見れないようです。

 

Casa 接続までの処理ルートは次のようになっています。

 

 [Casa]⇨[ルーター]⇨[インターネット]⇨[認証サーバー]⇨

   ⇨[VPN Gateway]⇨[Rakuten LTE Controller] 

 

Casa は最初に認証処理を行いますが ID として Casa の WAN 側の MAC アドレスを用いています(ログで確認済み)。

 

この MAC アドレスを用いた認証に失敗すると VPN 接続フェーズに移行しません。

 

 

失敗の原因は故障や LAN ケーブル接続不良など以外では Casa 出荷に際して認証サーバー(Radius か)に登録する MAC アドレスを誤っているケースです(人災です)。

 

 

MAC アドレスが正しくても、認証手続きが一定回数または一定時間内に成功しないと認証サーバーはロックします。

 

ロックを解除してもらわない限り接続再処理には移行しません。

 

ちなみに楽天モバイルの Rakuten Casa サポートでは認証サーバーのことを「コントローラー」と呼んでいるようで「Rakuten LTE Controller」と混同します。

 

 

 

認証が OK になると Rakuten Casa から楽天モバイルの VPN サーバーに接続処理し、その先にある「Rakuten LTE Controller」と接続して LTE を吹くという手順になります。

 

この場合、VPN サーバー側からはユーザーのグローバル IP がわからないので Rakuten Casa は「アグレッシブモード」で接続処理しているはずです。

 

両者間の IP アドレスが分かっている場合は通常「メインモード」で接続処理なのですが、Rakuten Casa は「アグレッシブモード」での接続処理と思われます。

 

 

「アグレッシブモード」では Rakuten Casa 側は ID とパスワードで、VPN サーバーの IP アドレスを指定して接続処理に移ります。

 

ここでの ID も Rakuten Casa の WAN 側の MAC アドレスが使われていると思われます(推定ですが、世界中で一意に定まるので)。

 

 

VPN サーバーの先にある「Rakuten LTE Controller」からの戻りパケットを受け入れるために "IPsec IKE/esp" プロトコルのパススルー設定が必要になります。

 

 

LTE を吹くようになると IPsec VPN の「DPD(デッド・ピア検出)定期メッセージ」を5秒間隔でサーバーとやり取りし、VPN の「生死確認」をしています(ログで確認済み)。  

 

まずは Rakuten Casa 側から「Rakuten LTE Controller」に向けてメッセージを送ります。

 

これに対する応答メッセージ(IPv6 パケット)が「Rakuten LTE Controller」から送られてきます。

 

Rakuten Casa が受け入れできるように Casa を接続しているルーターの WAN の IPsec IKE(ポート 500)/ esp プロトコル(50)を開放しておく必要があります。

 

 

この「生死確認」が長時間途絶えると再接続に際して「正当に接続していた Rakuten Casa なのか」を確認し、その手順に時間がかかるようです。

 

長時間途絶える、という状態は Casa の設置場所を別の部屋に変えるなど、電源を落としたまましばらく時間が経ったときとかです。

 

 

なお、VPN 接続に際して IPv6 パケットでやりとりしており、これができないときに IPv4 にフォールバックしますが、フレッツ網ではフォールバックが失敗するようです。

 

フレッツ網以外では IPv4 での VPN 接続になっています。

 

 

このような技術解説を楽天モバイルがしてくれるとよりいっそう理解が深まりますし、無用な問い合わせが減ると思うのですが。。。

 

 

 

 

 

 

 

2024-09-05

Tailscale の Relay Server unavailable エラー

 

 

ご参考;

    Mac mini M1 に Tailscale の Subnets & Exit Node 設定  を後ろの方に記載

 

 ・Subnets でローカルネットワークに入る

 ・Exit Node のセキュリティ上の有効性

 

ーーーーー

 

 

Android 版 Tailscale の本記事執筆時点の最新版は ver. 1.72.0 ですが、"Relay Server unavailable" メッセージが出るバグがあります。

 

 

⭕️印のエラーは Relay Server unavailable エラー

 

 

エラー内容は次のようになっていますが、実際にはリレーサーバー経由の動作はしていません。

 


"Health warnings" 自体は 1.72.0 で Android デバイス向けに実装された機能で「健康警告;もしあればアプリケーションのメインビューに表示される」とあります。

 

ですが、実際には「健康警告」がないのに表示されるのはバグです。

 

 

 

Tailscale のステータスでは、OPPO Reno9 A は下記のように android active; direct … とあり、Relay Server 経由では動作しておらず直接接続で動作中なのに、なぜかエラーメッセージが出ます。

 



 

次のアップデートで修正されるまでは仕方がないので無視をすることにしましたが、いったん Disconnect して再度 Connect すると警告は消えました。

 

Tailscale アプリのインストール後の最初の起動・Connect ででるようですが reConnect で 消えます。

 








 Mac mini M1 に Tailscale の Subnets & Exit Node 設定 

 

Tailscale の Subnets 機能は、ローカルネットワークに外からでも入ることができる機能です。

 

つまり Wireguard VPN で構成された Tailscale の P2P VPN により自宅のローカルネットワークに入るれることを意味します。

 

 

一方 Exit Node は Tailscale VPN で自宅ローカルネットワークに入れるだけではなく、自宅ネットワークを経由してインターネットにアクセスすることができる機能です。

 

これがどういう意味を持つかというと、フリー WiFi などのセキュリティが確保できない WiFi 利用時に、Exit Node 経由だと VPN トンネルを張ってセキュリティが確保できる、というものです。

 

 

 

現在 Subnets と Exit Node は、WiFi-AP にしている GL-AXT1800 に設定しています。


これを Mac mini にも設定してみます。


まず、AXT1800 にターミナルからログインして、Tailscale を一時停止します。


root@GL-AXT1800:~# opkg flag hold tailscale tailscaled


 

次に Mac のターミナルから Subnets と Exit Node を広告します。

 

Mac-mini ~ % /Applications/Tailscale.app/Contents/MacOS/Tailscale up --advertise-routes=192.168.xxx.0/24 --accept-routes --advertise-exit-node --accept-dns=false


ブラウザで Tailscale Console を開き Mac mini M1 の Edit route settings … で Subnets と Exit Node を有効化します。


以上で設定は終わりです。

 

 

スマホをモバイル接続し、Tailscale アプリを起動し、これを接続します。

 



Tailscale アプリ画面で "EXIT NODE" で "mac mini" を選択し、 ( Enable ) ボタンをタッチしてスマホが Exit Node を使えるようにします。

 

 

ブラウザから https://www.cman.jp/network/support/go_access.cgi にアクセスして自局の IPアドレスを確認します。



Exit Node 経由だと自宅ネットワーク経由でのアクセスなので、自局 IPアドレスになっているはずです。

 

[スマホや PC 等]⇨ [Tailscale VPN]⇨[モバイル網 IMS]⇨[インターネット]⇨[Tailscale VPN]⇨[自宅ローカルネットワーク] [インターネット] 


 青く塗った部分 は VPN トンネルが張られた部分で他者からは見えない
  (セキュリティが確保されている)

 

 

つまり、あたかもローカルネットワーク内からインターネットアクセスしていることと等価になります。

 

したがって自局のセキュリティは自局ルーターの設定に依存します。

 

 

下図の IP アドレスは 部分の IP アドレスです。


133.32.1xx.xxxenひかりの自局 IP アドレス



次に ( Disable ) ボタンをタッチして Exit Node を未使用状態にします。


Exit Node を経由しないとモバイル網の IPアドレスになっているはずです。

 

[スマホや PC 等]⇨[モバイル網 IMS]⇨ [インターネット]

 

下図の IP アドレスは 部分の IP アドレスです。

 

133.106.xxx.xxx楽天モバイルの IP アドレス

 

 

前記の[モバイル網 IMS]自体はキャリアがセキュリティ確保してくれていますが、この部分をフリー WiFi]に置き換えてみると、この部分がセキュリティ確保されていない箇所になります。

 

接続用パスワードの設定の有無に関わらず、同じフリー WiFi を使う人からは、あなたの IP アドレスが見えてしまいます。



ポートスキャンなどで侵入を試みるヒトがいるかも知れません。

 

 

 

なので、Exit Node はフリー WiFi]に対して有効なセキュリティ確保手段になります。




 

 

 

 

 

 

2024-09-03

Android Auto ワイヤレス接続が切れる【2024-09-07 修正】

 

 

カーナビ EONON GA2193K を AQUOS sense6 とワイヤレス接続しているときに、エンジンスタートでワイヤレス接続できないことがよくある。


エラー内容;スマートフォンが5GHzのWi-Fi接続をサポートしていません

 

TANAX によれば、一部スマホのバグらしく、原因は次のようなことだとある。

屋外で使用する接続チャンネル「W56」をスマートフォンが5GHz帯と認識せず通信を遮断する

 

AQUOS sense6 は自宅 WiFi-AP の W56 には接続できるので、カーナビの WiFi W56・DFS を誤認識しているのでしょうか。

 

 

同じく TANAX によれば下記機種で発生する模様。

  Xperia Ace III     

  AQUOS sense7

  AQUOS sense6

  AQUOS sense5G          

  AQUOS wish3 

  AQUOS wish2      

 

AQUOS はほぼ全滅状態。

 

これが発生すると Android Auto アプリのストレージを削除して、初期化状態にしないと接続が再開されない、という結構厄介なバグです。

 

そんなわけで、AQUOS sense6 から OPPO Reno9 A にメインスマホを替えました。


OPPO Reno9 A は手持ち品で有休になっていたものです。

 

ほぼ1週間経過していますが、いまのところワイヤレス接続が切れる事象はなく安定してつながっています。

 

 

ただ、電池保ちがあまりよくなく -0.5%/h という状況です。

 

AQUOS sense6 は -0.25 ~ -0.3%/h という消費率でした。

 

 

それ以外には一回り大きいといういうことくらいでしょうか。

 

・OPPO OPPO Reno9 A

 164 x 74 x 7.8mm / 183g

 

・AQUOS sense6

 152 x 70 x 7.9mm / 156g

 

 

 

生体認証は OPPO Reno9 A の方が圧倒的に速い。