Windowsのタスクバーにリソースをモニタできるソフトの紹介

Windowsのタスクバーにリソースをモニターしたい

Windowsを使っていると、裏で重いプロセスが動いていたり、インターネットの速度が遅くて今の速度を確認したかったり、バッテリー稼働時に可能な限り消費電力を抑えるためにCPU利用率や消費ワット数を見たくなったりする。

これらの情報を見るためにタスクマネージャーを毎回開いたりしているが、別ウィンドウで見たいときに瞬時に見れないし、そこそこCPUも使うし、扱いづらい。

かといって、Windowsの通知領域に表示しておくのはアイコンしか見れないし、勝手に隠れるので使いづらかった。

そこで、Windowsのタスクバー空き領域に表示できるツールがあって使ってみたら便利だったので紹介する。

XMeters

XMeters
XMeters一通りのリソース情報をタスクバーに表示できるアプリケーションだ。

標準設定で扱いやすく、個人利用ならこれ一択と言って過言ではない。

ただし、シェアウェアであるので無料版もあるが機能が制限される。
また、OSSではないので、商用利用や会社のPCへの導入は難しいだろう。

Perfmonbar

Perfmonbar

Perfmonbar はGithubにあるOSSのパフォーマンスモニタソフトだ。

XMetersほど、標準ですぐ使える状態になっておらず、色々調整が必要。

Perfmonbarはグラフは表示できず、テキストのみ利用可能なので、グラフィカルなモニターを求めるのであれば、やめたほうが良いだろう。

コマンドプロンプトで以下を実行すると表示可能なメトリックの一覧が取得できる。

typeperf -q

メトリックは非常に多く、ほぼなんでも表示可能。
おすすめは以下とか。

• \Memory\Committed Bytes
• \Processor Information(_Total)\% Processor Time
• \Network Interface(Realtek PCIe GBE Family Controller)\Bytes Received/sec
• \Network Interface(Realtek PCIe GBE Family Controller)\Bytes Sent/sec

Perfmonbarは何といってもOSSということだ。 ライセンスはGPLでちょっと好みではないけど、利用としてはなんの問題もない。

Perfgraph

Perfgraph

Perfgraphはおそらく開発が終了しているリソースモニタ。

Windows7の頃はこのソフトを愛用していたが、開発終了ということと、レイアウト崩れが気になり、最近は使わなくなった。

しかしタスクマネージャーのようにグラフで時間軸を持つリソースモニタはこれ以外知らないので、このような表示スタイルを好む人はおすすめ。

MacOSで iStatという非常に高機能で見やすいリソースモニタがあった。 表示のグラフも自由に変えられるし、オンマウスするとより詳細な情報が表示されるもの。

このレベルのソフトがウィンドウズにあれば、有料でも買いたい。

BootCampのMacbookでスリーブ復帰時に高精度タッチパッドドライバが停止するのを防ぐ方法

bootcampのMacbookに高精度タッチパッドを導入する方法

こちらの記事でWindowsのMacにWindows10の高精度タッチパッドを導入する方法を紹介している。

MacBookのBootCampのWindowsに高精度タッチパッドドライバを導入

SPI系のタッチパッドを持つMacbookではスリープ復帰に失敗する

このオープンソースの高精度タッチパッドにはスリープ復帰に失敗する問題がある。

Github Trackpad doesn't work after sleep 203

Windowsのスリープからの復帰時に高精度タッチパッドのドライバが停止して、Windowsを強制終了するしかない問題があり、非常に問題だった。

この問題が解決しない限り、Windowsを完全にシャットダウンしないといけないため、スリープまたは休止モードの利用ができなかった。

※ 正確には運よく復帰に成功することもあるので、復帰に失敗したら強制終了という運用。。。

Trackpad doesn't work after sleep は未解決(2020/12/01時点)

この問題は2019年初頭から報告されているが、解決されていない。

原因はSPIドライバが最新のMacbookでは採用されておらず、古いMacbookにしかない。

このため、修正意欲も弱かったり問題の再現性が乏しいということだった。

しかし、私はMacbook12をWindows機として使い倒す気満々だ。

今のところMacBook12以上に優れた小型のWindowsは存在しないと自負している。 高解像度でUSB type-C(PD)で 軽量薄型でUS配列を条件にすると市販のPCで該当するものが無くなる。

ということで何とかこの問題を解決できないか検討した結果、回避できたので共有させていただく。

タッチパッドのスリープ復帰時停止を回避する方法

スリープ復帰時に正常に停止しなかったタッチパッドがエラーを返すのが原因なので、 スリープに入る前に強制的にハードウェアを停止させる。

そしてスリープ復帰時に手動でハードウェアを復帰させることで回避する。

PowerShell で タッチパッドをOnOffするためにIDを取得

デバイスマネージャーで表示できるApple SPI Precision TouchPad DeviceがOnOffする対象だ。

以下のコマンドを管理者権限のPowerShell ISE で実行する。

Get-PnpDevice -FriendlyName "Apple SPI Precision Touchpad Device" | ft -wrap -AutoSize instanceid

以下のような結果が得られればOKで、SPIから始まるIDを控える。

OnOffするスクリプトを作成

PowerShellのスクリプトを作成する。

各スクリプトの一行目にあるif はPowerShellを管理者権限で実行しなおす処理だ。

二行目がタッチパッドをOnOffするコマンド。

touchpad_On.ps1

if (!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) { Start-Process powershell.exe "-NoProfile -ExecutionPolicy Bypass -File `"$PSCommandPath`"" -Verb RunAs; exit }
Enable-PnpDevice -InstanceId "SPI\VID_05AC&PID_0275&MI_02\5&33D07321&0&02" -Confirm:$false

touchpad_Off.ps1

if (!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) { Start-Process powershell.exe "-NoProfile -ExecutionPolicy Bypass -File `"$PSCommandPath`"" -Verb RunAs; exit }
Disable-PnpDevice -InstanceId "SPI\VID_05AC&PID_0275&MI_02\5&33D07321&0&02" -Confirm:$false

これらのスクリプトを手動で実行し、タッチパッドが無効化、有効化できるかを確認しておく。

スクリプトをWindowsのタスクスケジューラに登録する

最後にWindowsがスリープに入出するときにこれらのスクリプトが実行されるようにする。

タスク作成方法

1. タスクスケジューラを起動
2. 操作からタスクの作成
3. タスクの作成
   1. 全般の最上位の特権で実行するにチェック
   2. トリガーの新規からタスクの開始で以下を選択
      • タッチパッドOffスクリプト ⇒ ワークステーション ロック時
      • タッチパッドOnスクリプト ⇒ ワークステーション アンロック時
   3. 操作の新規から作成したスクリプトを起動プログラムに指定
4. 完了

実際に試してみる

スリープや休止モードを試してみて、問題なくタッチパッドが回復すれば良い。

私の環境ではこれで完全にタッチパッドが停止する問題を回避できた。

ヤマハルータ(RTX830)とVyOSでIPSecで拠点間VPNする

RTX830とVyOSのIPSec設定

VyOSのIPSecの接続事例があまりなく、VPN構築をした際に苦戦したので記録を残します。

前提情報

• RTX830側
  • PPPoE接続
  • VPNLAN: 192.168.10.0/24
  • インタフェース: 192.168.10.1/24
• VyOS側
  • さくらVPNでグローバルIPをeth0が所持
  • VPNLAN: 192.168.100.0/24
  • インタフェース: 192.168.100.1/24

192.168.10.0/24と192.168.100.0/24の拠点間VPNをやります。

RTX830側の設定

console character en.ascii
login timer 300
ip routing on
ip route default gateway pp 1
ip route 192.168.100.0/24 gateway tunnel 1
ip lan1 address 192.168.10.1/24
pp select 1
 pppoe use lan2
 pp auth accept pap chap
 pp auth myname <PPPoEセッション情報>
 ppp lcp mru on 1454
 ppp ipcp ipaddress on
 ppp ipcp msext on
 ip pp mtu 1454
 ip pp nat descriptor 1
 netvolante-dns hostname host pp server=1 <ネットボランチDDNS>
 pp enable 1
tunnel select 1
 ipsec tunnel 1
  ipsec sa policy 1 1 esp 3des-cbc md5-hmac
  ipsec ike group 1 modp1024
  ipsec ike keepalive log 1 off
  ipsec ike keepalive use 1 off
  ipsec ike local address 1 192.168.10.1
  ipsec ike nat-traversal 1 on
  ipsec ike pre-shared-key 1 text <Secret>
  ipsec ike remote address 1 <VyOSのIPアドレスまたはドメイン>
 ip tunnel tcp mss limit auto
 tunnel enable 1
 tunnel select none
nat descriptor type 1 masquerade
nat descriptor masquerade static 1 1 192.168.10.1 udp 500
nat descriptor masquerade static 1 2 192.168.10.1 esp
nat descriptor masquerade static 1 3 192.168.10.1 udp 4500
ipsec auto refresh on
telnetd host lan
dhcp service server
dhcp server rfc2131 compliant except remain-silent
dhcp scope 1 192.168.10.11-192.168.10.199/24
dhcp scope option 1 dns=8.8.8.8
dns server pp 1
dns private address spoof on
statistics traffic on

VyOS側の設定

set interfaces ethernet eth0 <VyOSのグローバルIP>
set interfaces ethernet eth1 192.168.100.1/24
set service ssh port 10022
set service ssh allow-root
set system gateway-address <VyOSのゲートウェイアドレス>
### vpn settings
set vpn ipsec ipsec-interfaces interface 'eth0'
set vpn ipsec esp-group ESP compression 'disable'
set vpn ipsec esp-group ESP mode tunnel
set vpn ipsec esp-group ESP pfs enable
set vpn ipsec esp-group ESP lifetime '3600'
set vpn ipsec esp-group ESP proposal 1 encryption 3des
set vpn ipsec esp-group ESP proposal 1 hash md5
set vpn ipsec ike-group IKE ikev2-reauth no
set vpn ipsec ike-group IKE key-exchange 'ikev1'
set vpn ipsec ike-group IKE lifetime '3600'
set vpn ipsec ike-group IKE proposal 1 dh-group 2
set vpn ipsec ike-group IKE proposal 1 encryption 3des
set vpn ipsec ike-group IKE proposal 1 hash md5
set vpn ipsec ike-group IKE dead-peer-detection action restart
set vpn ipsec ike-group IKE dead-peer-detection interval 15
set vpn ipsec ike-group IKE dead-peer-detection timeout 90
set vpn ipsec site-to-site peer <RTX830のアドレス> default-esp-group 'ESP'
set vpn ipsec site-to-site peer <RTX830のアドレス> ike-group 'IKE'
set vpn ipsec site-to-site peer <RTX830のアドレス> authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer <RTX830のアドレス> authentication pre-shared-secret <シークレットキー>
set vpn ipsec site-to-site peer <RTX830のアドレス> authentication remote-id 192.168.10.1
set vpn ipsec site-to-site peer <RTX830のアドレス> connection-type initiate
set vpn ipsec site-to-site peer <RTX830のアドレス> local-address <VyOSのグローバルIP>
set vpn ipsec site-to-site peer <RTX830のアドレス> tunnel 1 local prefix '192.168.100.0/24'
set vpn ipsec site-to-site peer <RTX830のアドレス> tunnel 1 remote prefix '192.168.10.0/24'
set vpn ipsec nat-networks allowed-network 0.0.0.0/0
set vpn ipsec nat-traversal enable

VyOSとの接続におけるノウハウ

IPSec接続が確立しない

RTX830側のIPSec設定でGUIから設定すると以下の設定が追加されるが、この記述があるとIPSecの接続確立が失敗した。

 ppp ccp type none

VyOS側がRTX830側のグローバルIP変更に対応できない

RTX830側のPPPoEは固定グローバルIPではなく、動的グローバルIPのため、ヤマハのネットボランチのDDNSサービスを利用した。

VyOSとRTX830でIPSecVPN確立後にRTX830を再起動するとRTX830が持つグローバルIPが変わる。

DDNSが動作しているので、問題なく名前解決するIPアドレスは変わるが、VyOS側は一度セッション確立に使ったグローバルアドレスをずっと保持し続けるようだ。

このため、定期的にipsecプロセスを再起動させる必要があるため、以下をVyOSに追加した。

$ vpn ipsec auto-update 30

30秒おきにipsecプロセスを再起動する処理。

以上

Dockerでguacamoleを動かす(Let`s encrypt対応)

Guacamoleとは

GuacamoleはApaccheが開発するWebベースのリモートアクセスアプリケーションだ。

サポートするプロトコルは VNC, RDP, SSHでHTML5をサポートするブラウザで動作する。

AndroidやiPhoneからでもRDP経由でWindowsを動作させることができ、利便性が高い。

Dockerでguacamoleを動かす

docker-composeを用いて、guacamoleを動作させる。

データベースとしてpostgresを利用しており、この領域はvolumeでマウントする。

Guacamoleはテレワーク環境として使われることも想定され、独自ドメインでインターネット公開する用途もありそう。

Let's encryptでhttps化を対応したdocker-compose.ymlを下記にしめす。

let's encryptはhttps-portalコンテナで動作しており、nginxのリバースプロキシが動作している。

証明書の更新も自動で行ってくれるコンテナでメンテナンス不要だ。

version: "3"
services:

  postgres:
    image: postgres:13.0
    restart: unless-stopped
    environment:
      PGDATA: /var/lib/postgresql/data/guacamole
      POSTGRES_DB: guacamole_db
      POSTGRES_PASSWORD: guacamole1234567890
      POSTGRES_USER: guacamole_user
    volumes:
      - ./pginit:/docker-entrypoint-initdb.d:z
      - ./pgdata:/var/lib/postgresql/data:z

  guacd:
    image: guacamole/guacd:1.2.0
    restart: unless-stopped

  guacamole:
    image: guacamole/guacamole:1.2.0
    restart: unless-stopped
    environment:
      GUACD_HOSTNAME: guacd
      POSTGRES_DATABASE: guacamole_db
      POSTGRES_HOSTNAME: postgres
      POSTGRES_PASSWORD: guacamole1234567890
      POSTGRES_USER: guacamole_user
    depends_on:
      - postgres
      - guacd

  https-portal:
    image: steveltn/https-portal:1
    ports:
      - '80:80'
      - '443:443'
    links:
      - guacamole
    restart: always
    volumes:
      - ./nginx:/var/lib/https-portal:z
    environment:
      DOMAINS: '<独自ドメイン.com> -> http://guacamole:8080/guacamole/'
      STAGE: 'production'
      # FORCE_RENEW: 'true'

SoftetherVPNをDockerで動かす(docker-compose)

DockerでSoftetherを動かす

SoftetherVPNはOSSのVPNソフトウェアだ。

WindowsやLinuxにインストールして使うが、Dockerで動かす例が少なかった。

SoftetherはL2VPNを提供するアプリケーションであるが、Dockerは動作ホスト内で仮想ネットワークを形成する。

このため、Dockerコンテナでの動作と相性が良くない。

しかし、Dockerのネットワークドライバをhostsにすることで動いたので手順をまとめる。

Softetherが動作するdocker-compose.yml

SoftetherをDockerで動作させるために必要なこと

SoftetherでVPNサーバ機能を使うためには基本的にはローカルブリッジ機能が必要になる。

Dockerで標準状態でSoftetherコンテナを動作させるとDockerホストが持つIP帯ではなく、内部仮想ネットワークの172.17.0.0/24等がコンテナに割り当たるはずだ。

このLANをL2VPNの接続先として公開することはできるが、やりたいのはDockerホストのNICが所属するLANだ。

このためDockerホストのNICが所属するLANにコンテナが接続できる必要があり、Dockerのネットワークドライバのhostを利用する。

これにより、コンテナはDockerホストのNICを介してネットワーク接続が可能だ。

以下のdocker-compose.ymlを動作されればとりあえずSoftetherが動作する。

version: "3"

services:
  app:
    image: siomiz/softethervpn
    #environment:
      #- USERS=user1:password1;user2:password2
      #- PSK=test
      #- HPW=test
    volumes:
      - ./vpn_server.config:/usr/vpnserver/vpn_server.config:z
    cap_add:
      - NET_ADMIN
    network_mode: "host"
    privileged: true
    ports:
      - 500:500/udp
      - 4500:4500/udp
      - 1701:1701/tcp
      - 1194:1194/udp
      - 5555:5555/tcp

portsで各softetherのポートを指定しているが、hostネットワークに割り当てているので、不要かもしれない。

この設定で起動したSoftetherコンテナはDockerホストのローカルブリッジが動作する。

YAMAHAルータ RTX830 の基本コマンド

ヤマハルータの操作

ヤマハルータの操作にはコンソール接続が必要だ。

RTX830にはUSB-MiniBによるコンソール接続が可能となっており、RJ45またはUSBで接続ができる。

コンソール操作ソフトはTeraterm等を利用すると良いだろう

基本コマンド

show config(現設定の確認)

現状のルータのConfigを出力できる。

# show config
# RTX830 Rev.15.02.10 (Fri Jun  7 10:04:56 2019)
# MAC Address : xx:xx:xx:xxxx:xx, xx:xx:xx:xxxx:xx
# Memory 256Mbytes, 2LAN
# main:  RTX830 ver=00 serial=XXXXXXXXXX MAC-Address=xx:xx:xx:xxxx:xx MAC-Addre
ss=xx:xx:xx:xxxx:xx
# Reporting Date: Oct 18 23:20:50 2020
ip lan1 address 192.168.100.1/24
telnetd host lan
dhcp service server
dhcp server rfc2131 compliant except remain-silent
dhcp scope 1 192.168.100.2-192.168.100.191/24

cold start 工場出荷時リセット

ヤマハルータを初期化(工場出荷時)できる。

# show config
# cold start
Password:
RTFS formatting... Done.
Restarting ...

コンソールの文字化け対策

# console character ascii

show status ? (各種ステータスの表示)

show status に続いて、以下コマンドを入力することで、状況を表示することが可能

# show status ?
? backup bgp boot bridge1 cloud cooperation dhcp dhcpc ethernet external-memory
 heartbeat heartbeat2 ip ipip ipv6 l2tp lan1 lan2 lua mail mobile netvolante-dn
s ngn ospf packet-buffer pp pptp qos remote rtfs sd status-led switch switching
-hub tunnel upnp usbhost user vlan vrrp wan1 yno

ヤマハルータのトラブルシューティング

syslogのログレベルを上げる

syslog debug on

SoftetherVPN のSecureNATの動きが怪しい

SoftetherVPNのSecureNAT

SoftetherVPNのSecureNATは仮想HUB内に仮想のルータを配置する機能。

SecureNATはDHCPサーバ機能もあり、標準では192.168.30.0/24のネットワークを作成する。

SecureNATを有効にするとSoftetherが動作するホストを通じて外部への通信が可能。

気を付けないのがSecureNATを有効にしている仮想HUBとローカルブリッジは一切関係ない。

SecureNATが生成するゲートウェイはSoftetherホスト自体であり、ローカルブリッジのNICとは関係なく、Softetherホストの持つ経路情報によって通信が提供される。

つまり、Softetherホストがインターネット接続可能であればSecureNAT上のホストはインターネット接続が可能になるし、Softetherホストが複数NICを持ち、別のLANへのルーティング情報を持っていればそこへもつながる。

ネット上のブログや記事はSecureNATの本質を捉え間違えているものが多いので注意が必要だ。

SecureNATの動きが怪しい

さくらのVPS上のCentOS7にSoftetherをインストールして動作検証を行ったが、VPNを接続した後の数秒後(10秒程度)くらいに通信が途絶えてしまう。

要求がタイムアウトしました。
要求がタイムアウトしました。
要求がタイムアウトしました。  ←ここでSecureNATを有効に
192.168.100.21 からの応答: バイト数 =32 時間 =34ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =33ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =46ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =53ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =52ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =34ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =62ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =40ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =41ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =28ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =46ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =56ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =44ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =55ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =64ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =50ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =51ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =41ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =32ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =51ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =53ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =46ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =42ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =35ms TTL=63
192.168.100.21 からの応答: バイト数 =32 時間 =33ms TTL=63
要求がタイムアウトしました。    ← なぜか通信できなくなる。
要求がタイムアウトしました。
要求がタイムアウトしました。
要求がタイムアウトしました。
要求がタイムアウトしました。
要求がタイムアウトしました。

通信が途切れた際のSecureNATのステータスをモニタすると、カーネルモード NAT で動作中とRaw IPモードで動作中がはいになったとたんに接続が切れたことが分かった。

このSecureNATは動作モードがあり、「ユーザーモード」と「カーネルモード」と「Raw IP モード」があるらしい。

⇒ 公式 SecureNATカーネルモードについて

ユーザーモード NAT

ユーザーモードNATは特権を必要としない一般プロセスでNAT処理を実現するもの。

このため、Linuxカーネルの機能を使えないためオーバーヘッドが大きく、パフォーマンスが低い。

IPtablesも使わないため、影響範囲は狭くほぼ動作する。

カーネルモードNAT

以下公式より引用

一般的な NAT 処理と同様にパケットの内容の解釈を行わずにヘッダの書き換えのみで動作するため、ユーザーモード SecureNAT と比較して高速に動作します。

インターフェースレベルの低レベルAPI経由でヘッダのみの書き換えで動作するモード。これは上位の権限を要求する場合があるそうだ。

Raw IP モードNAT

最後はいわゆる普通のNATを行うモードで、iptables経由でLinuxのNetfilterのnat機能を使う。

Linux Kernel のモジュールで動作するので非常に高速に動作する。

問題は利用モードの自動選択

どうも利用可能かどうかを自動判定して、適切なモードを選択してくれる仕様のようだ。

イーサネットインターフェイスでの通信に成功した場合はカーネルモード SecureNAT が使用され、Raw IP ソケットでの通信に成功した場合は Raw IP モード SecureNAT が使用されます。いずれも成功しなかった場合はユーザモード SecureNAT が使用されます。

方式ドキュメントを読む限り、ユーザモードNATからスタートして、カーネルモードの可否、RawIPモードの可否を判定するようだ。

ユーザモードNAT ⇒ カーネルモードNAT ⇒ RawIPモードNAT

この方針はいいが、なぜかエラーとなるカーネルモードとRawIPモードが有効になってしまった。

原因はDocker?

今回はCentOS7上でDockerを用いてSoftetherを動作させていた。

低レベルのネットワークアクセスのため、network driverはhostで、privilegedな権限を付与して動作させている。

ここの設定はおそらく問題ないが、いけなかったのはDockerがiptables経由でnatテーブル等を書き換えていること。

softetherが設定したnatテーブルを不当に書き戻している可能性が高い。

ホストのiptablesを操作するプロセスが共存するのはあまり好ましくないだろう。

対策はユーザモードNAT固定

幸いにも NATの利用モードの明示的な指定が可能だ。

カーネルモードを禁止する場合は「DisableKernelModeSecureNAT」を、Raw IP モードを禁止する場合は「DisableRawIpModeSecureNAT」を、ユーザモードを禁止する場合は「DisableUserModeSecureNAT」を、それぞれ 「1」に設定して下さい。 公式: 利用モードの選択

※ 公式ページのDisableRawIpModeSecureNATはDisableIpRawModeSecureNATのタイポです。

以下を設定すればユーザモードで固定することが可能だ。

• DisableKernelModeSecureNAT: 1
• DisableIpRawModeSecureNAT: 1

上記を仮想HUBのプロパティから設定すれば問題なく動作するはずだ。