Proxmox環境のOpenWrtでミニPC本体のWi-Fiデバイスを利用する

昨日の日記で「Proxmox環境のOpenWrtで、ミニPC本体のWi-Fiデバイスが直接利用できないから別の方法で無理やりWi-Fi対応した」みたいなことを書いたけれど、ひょんなことでOpenWrtから直接ミニPC本体のWi-Fiデバイスを使う方法を発見してしまいました。

ミニPCはGMKtec NucBox G2 Plusです。

Proxmox環境のOpenWrtでミニPC本体のWi-Fiデバイスを認識させる

★Proxmox上の操作

(Proxmox上ですでにhostapdを使ってアクセスポイント化していた場合は、この作業前に止めておきます。)

Proxmox > OpenWrtの仮想マシン > ハードウェア > 追加 > PCIデバイス
Raw デバイス: 0000:02:00.0

★OpenWrt上の操作

LuCI > Software

kmod-rtw89-8852be
rtl8852be-firmware
wpad-basic-mbedtls

この3つをインストール。

これでLuCI > Network配下にWirelessが現れてWi-Fiの設定ができるようになりました!途中再起動とか必要だったかも。

このWi-Fi環境でできることとできないこと

2.4GHz帯と5GHz帯の両対応で、WPA3にも対応しています。

アクセスポイントにすることはできますが、2つ同時に起動することはできません。

クライアントとして上位のアクセスポイントに接続することと、自分がアクセスポイントになることは同時にできます。

ただその際、周波数帯・チャンネルは上位側と同じでないとアクセスポイントが起動しません。
(ただ、5GHz帯の場合、36・40・44・48chのどれかで設定していれば、仮に上位とずれてても上位に合わせたチャンネルで起動してくれます。謎の親切設計。)

そしてアクセスポイント側でやっぱりChannel: autoが機能しません。Proxmox本体側でアクセスポイントにしようとしたときと同じ症状です。

上位が2.4GHz帯で下位を5GHz帯にしたいときとかは、

昨日作ったUSB-WiFi専用仮想OSを使えばいいかな。

OpenWrtに追加するデバイスなどの割り出し方

今回なんでやり方がわかったかというと、

root@NucBoxG2Plus:~# lspci -vnn | grep -i net
01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)
02:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8852BE PCIe 802.11ax Wireless Network Controller [10ec:b852]
        Subsystem: Realtek Semiconductor Co., Ltd. RTL8852BE PCIe 802.11ax Wireless Network Controller [10ec:b852]
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)

Proxmoxコンソール上で打ったこのコマンドの結果から。

Wireless Network ControllerがRealtekのRTL8852BEだと出ているので、デバイスドライバはこれで探しました。「PCI」や「02:00.0」あたりに、仮想OSに追加するハードウェアのヒントも見えます。

Proxmox環境のミニPCを無線ルータ化する

中国での旅行用ルータとして改造中のミニPC(GMKtec NucBox G2 Plus)ですが、Proxmoxでの仮想環境にしてからWi-Fiが使えなくなっていました。

IMG20250219193608

それでも前回の旅行のときのように、スマホのテザリングを駆使すればなんとかはなるんですが、毎日結線するのはたいへん。

Proxmox環境でもWi-Fiが使えないかいろいろとがんばってみました。

ミニPCを無線アクセスポイントにする

追記 2025-04-16

以下のやり方よりこちらの方がおすすめです。

こちらを参考にしてやってみると、ミニPCを無線アクセスポイントにできました!

でもいくつか注意点が。

(1) OpenWrtではなく、Proxmox本体で無線の管理をする構成になってしまう。

物理ルータ上のOpenWrtだと、SSIDとかパスフレーズの設定がLuCIで設定できたりしますが、それができません。設定はProxmoxのCUIで。ネットワーク構成としては、Proxmox本体が受けた無線からOpenWrtにLANケーブルを1本引いてきてつないでるような構成になります。

OpenWrt側でWi-Fi管理ができると、メッシュネットワークとかが組めたりするみたいなんですが、そういうのも無理。

(2) チャンネルの自動設定ができない。

hostapd.confchannel=0と設定するとチャンネルの自動設定ができるみたいなんですが、これだとなぜか立ち上がりません。

ログを見ると、「自動設定のために周囲の電波のスキャンしようとしたけどできなくてあきらめる」みたいな挙動になってます。

(3) 5GHz帯の電波が使えない。

周波数帯の設定がhostapd.confにはあるんですが、それで5GHz帯に設定してみても「許可されていない」とか出て立ち上がりません。

5Ghz 帯で AP モードを起動できない
特定の国コード 00(グローバル)を使用している場合、5GHz 帯のすべての使用可能な周波数に no-ir(no-initiating-radiation) フラグが設定され、hostapd での使用が禁止されます。これを回避するには、wireless-regdb をインストールし、適切な国コードを設定して、使用可能な周波数を有効にする必要があります。

なお、最近の Intel 製デバイスには “Location-Aware Regulatory(LAR)” 機能が搭載されており、ユーザー空間の規制データベースを無視し、代わりに近隣のアクセスポイントを検出して規制地域を推測します。このため、5GHz 帯のアクセスポイントを検出するまで、5GHz 帯での送信ができません。その結果、多くの場合、5GHz 帯での送信が完全に禁止されます

以前のカーネルでは LAR を無効化するオプションがありましたが、ファームウェアのクラッシュを引き起こすため 2019年に削除されました。この削除以降、LAR 対応の Intel 製 Wi-Fi カードは 5GHz帯でアクセスポイントとして使用できなくなっています。

いろいろややこしそうではあります。

しかたがないので、2.4GHz帯でチャンネル固定で使うことにしました。宿のWi-Fiとかぶって安定しないようなことがあれば、手修正するしかないかな。

あと、セキュリティを少しでも高めるために、

wpa_key_mgmt=WPA-PSK-SHA256
wpa_pairwise=CCMP

このへんの設定だけデフォルトより心もち強めに。ちなみに

wpa=3

では起動しませんでした。

上位ネットワークにWi-Fiで接続する

ここまでは、端末をミニPCにWi-Fiでつなぐ話でした。

今度はミニPCを、宿とかの無線アクセスポイントにWi-Fiでつなげられるようにできるかな?

仮想のゲストOSからはミニPC本体のWi-Fiは扱えないんですが、ミニPCのUSBポートに差した機器はそのままパススルーでゲストOSから使えます。マウスとかキーボードとか。

それができるんだったら、USBのWi-FiアダプタをゲストOSで認識させればなんとかなるんじゃない?

たとえば・・・

インターネット

宿の無線アクセスポイント
|(Wi-Fi)
USBのWi-Fiアダプタ
ゲストOS(Windows)
|(仮想ネットワーク)
ゲストOS(OpenWrt)

端末

最悪こういう構成はできそう。Windowsに対応したUSBのWi-Fiアダプタなんて星の数ほどあるわけやし。

でもこれだと(ウイルスに感染しやすい)Windowsがフロントに立つ構成なので避けたいです。せめてWindowsでなくLinuxにしたいなあ。

調べてみると、TP-Link Archer T2U Nano AC600というWi-FiアダプタならUbuntuで使えた実績があるみたいです。ということでぽちっと購入。

そしてこのWi-Fi専用Linuxは、できるだけ軽量なものがいいので、

Ubuntu系列で最軽量っぽいLubuntuをさらにミニマム設定でインストールしてみました。ちなみに仮想ハード構成は、ディスク8GB・メモリ1GBにしました。これがぎりぎりかな。

そしてこのREADMEのPrerequisitesとBasic Installation for All Distrosに従ってドライバを入れて再起動するとWi-Fiを認識しました。

あとはisc-dhcp-serverとUFWでちゃちゃっとDHCP&NAPTルータ化して完成!

こちらもちょっと注意点が。

なぜかうちのBUFFALOのアクセスポイントが見えてるのにつながらないなあと思ったら、このWi-Fiアダプタ、WPA3に対応していませんでした。一般の人を受け入れる宿のWi-FiとかだとWPA3オンリーの設定にはしないはずなので、旅先で問題になることはないと思うけれど。

追記 2025-06-29

HDMI切替器を更新する

家のテレビ用プロジェクタには、いくつかの機器から出力できるようにHDMI切替器で分岐させています。

HDDレコーダーからの映像をプロジェクタに出すとき、ときどき「No Signal」になるのが微妙に不便だったんですが、その原因がどうもこのHDMI切替器にありそうな気がしていました。切替器を通すことで信号の減衰が起こっているんじゃないかと。

それだったら、電源から給電できるタイプの切替器にしたらいいのかも?

と思って、だめもとでこちらに替えてみたところ、「No Signal」がまったく出なくなりました!

Proxmoxの遠隔メンテナンス経路を冗長化する

実家に置いてきたProxmox環境のミニPCですが、

何種類ものVPNでOpenWrt区画につなげられるようにしてあるので、遠隔メンテナンスは一応できます。

でも今後こまりそうなのが、OpenWrt区画が遠隔から一時的に使えなくなるようなメンテナンスをするとき。

たとえばファームウェアのメジャーバージョンアップがあった場合、最初に設定がいったん初期化されてしまうので、遠隔からは何も操作ができなくなってしまいます。

そうでなくても、うっかりWAN側の接続が切れるような操作をしてしまうこともあるし、今のOpenWrtとは別のメンテナンス経路を確立しといた方がよさそうやなあ。

要件

(1) 今あるOpenWrtに頼らず、遠隔から実家のProxmoxに接続できるようにする。
(2) 実家の無線ルータが買い替えとかでサブネットが変わってしまっても、影響を受けないようにする。
(3) このバックアップ経路自体、短時間で構築できるような手法を選ぶ。

手法

実家ミニPC–実家無線ルータ–インターネット

実家ミニPCはこんな感じで実家無線ルータの配下にいて、DDNSとポートフォワードでOpenConnectやSoftEtherの接続を受けるようにしています。

要件(1)(3)だけなら、Proxmoxの管理ポートをただインターネットにさらすという手もあるんですが、セキュリティ的にこわいのと、要件(2)で実家の無線ルータが交換されたときにポートフォワード設定を入れ直さないといけなくなるので不採用。トラブル時の応急対応とかではやるかもしれないけれど。

ということで、こちらを参考にProxmoxのLXCでTailscale専用コンテナを作って対応することにしました。

ハードウェアリソース的には、OpenWrtをもう1つ立てる方が小さくすむんですが、コンテナの方が手間が少なくてよかったです。構築だけなら10分ぐらい?

仮想ハードウェア構成

参考にしたブログでは、

テンプレート:AlmaLinux 9
ディスク:32GB
CPU:2コア
メモリ:2048MB

という構成で構築されていましたが、今回は

テンプレート:Debian 12
ディスク:1GB
CPU:1コア
メモリ:128MB

こんなふうにしました。ディスク使用率は76%で、メモリ使用率はMAXでも50%を少し超えるぐらいです。これがミニマム構成かな。

そしてネットワークインタフェースは、ミニPCのLAN側・WAN側両方に足を出していて、LAN側は固定IPで、WAN側はDHCPで割り当てるようにしてあります。
(ミニPCのWAN側というのは、セグメント的には実家無線ルータのLAN側です。)

WAN側に足を出したのは、OpenWrtに頼らずインターネットに接続するため。DHCPにしてあるのは要件(2)で実家のサブネットが変わっても追従できるように。LAN側に足を出したのは、Proxmoxに接続する宛先IPアドレスを固定するためです。

Tailscaleの設定

Tailscaleで外部から接続すると、–advertise-routesに含まれないプライベートIPアドレス空間には接続端末から直接通信ができなくなってしまいます。たとえExit Nodeになっていたとしても。

ふつうなら今あるサブネットをぽちぽち登録していけばいいんですが、実家の無線ルータの交換やOpenWrtの設定変更で未知のサブネットができても設定変更せずに通信できるようにしたいです。

ということで、思い切って

–advertise-routes=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16

こういう設定でいくことにしました。プライベートIPアドレス空間全領域。

端末のTailscaleクライアントで接続して使うだけなので問題ないけど、このtailnetにほかのルータから–accept-routesするのは危険かも。

将来的なメンテナンス

このバックアップ経路があれば、遠隔からOpenWrtを1から再セットアップすることもできそうです。

もしこのTailscaleコンテナ自体を、OS部分(Debian 12)含めてアップデートをしたくなるようなことがあっても、最新のテンプレートから作り直せばいいだけなので楽です。

あと、実家の無線ルータが交換された場合も、管理者パスワードさえ教えてもらえれば、ポートフォワード設定はこちらからできるので問題なさげ。

金盾対応のPBR

金盾のアクセス制限を回避するのにVPNが使われますが、

中国から中国のサイト(高德地图とか)にアクセスするときは、VPNで日本経由のアクセスにするとあからさまに応答が遅くなるので、接続先サイトのドメインによってVPNを通すか通さないかを変えたいです。

ということで、なんでもかんでもVPNを通すとこまることがあります。

そこでPBRを使って、通信の振り分けをすることにしました。

ドメイン名で振り分ける準備

旅先用ルータのOpenWrtにpbr・luci-app-pbr・dnsmasq-fullをインストール。そして

LuCI > Services > Policy Routing > Basic Configuration

Use resolver set support for domains: Dnsmasq nft set

とセットします。

ふつうのルーティング設定は、宛先IPアドレスを使って経路の振り分けをするものですが、PBRを使うと宛先ドメインでの振り分けができるようになります。

それはルータが「名前解決する都度そのIPアドレスをルーティングテーブルに載せる」というしくみで実現しているので、名前解決はルータ自身でやらないと機能しません。つまり、端末側でDNS設定を8.8.8.8などにしていた場合には振り分けが発動しないんです。

なので端末のChromebook側では、「サイトのルックアップに安全な接続を使用する」をOFFにするだけでなく、DNSをDHCPで自動設定されるままにするなどする必要があります。

しばらくこれに気づかずはまりました。

VPN回線を経路の選択肢に追加する

PBRの経路Interfaceの選択肢には、デフォルト設定ではwanなど限られたものしか表示されないので、ここにVPN回線を追加しておきます。

LuCI > Services > Policy Routing > Advanced Configuration > Supported Interfaces

ここにVPNのデバイス名を追記します。ちなみに「デバイス名」というのは、

LuCI > Network > Interfaces > Devices

ここに一覧表示されるものです。

LuCI > Network > Interfaces > Interfaces

の方ではないので注意。

これもしばらく気づかずはまりました。

PBR振り分けの注意点

ただ単純に、Googleなどの金盾ブロック対象ドメイン宛の通信だけをVPNに通せばいいかというと、そう簡単にはいきません。

金盾は、DNS応答の改ざんでブロックを実現しているケースもあるので、こちらも対応しないと、改ざんされた接続先にVPNを通して接続しようしてしまって回避できません。

かといって、全部のDNS通信をVPNに通す設定にしてしまうと、最初にVPNトンネルを張るためのDNS問い合わせができなくなったりしてこまります。

端末からのDNS問い合わせは、ルータ自身を指さないとPBRが機能しないのでここはいじれない。なのでルータが名前解決する経路だけを制御したい。

そこでまず、特定ドメインの問い合わせだけふだんと別のDNSを指すようにします。

LuCI > Network > DHCP and DNS > Forwards > Additional servers file

/etc/dnsmasq.servers

と入力。そして旅先用ルータ上の/etc/dnsmasq.serversを以下のように編集します。

server=/google.com/1.1.1.2
server=/google.co.jp/1.1.1.2

(などなど、対象ドメインを列挙。このようにルートドメインだけ書いておけばサブドメインにも効きます。)

ちなみに1.1.1.2は1.1.1.1のマルウェアブロック版です。ふだんとちがう設定であれば何でもいいです。

そしてPBRで1.1.1.2宛の通信をVPN経由となるように経路制御します。

LuCI > Services > Policy Routing > Policies

Remote addresses / domains: 1.1.1.2
Chain: output
Interface: (通したいVPNのインタフェース)

というようなルールを追加します。「Chain: output」はフォワードなどでないルータ自身の送信パケットの制御を指します。

追記 2025-07-15
西宁では宿のWi-Fiとモバイル回線ともにCloudflare DNS(1.1.1.1〜3)と疎通ができなかったので、Quad9の9.9.9.10に変更しました。
(9.9.9.9だと、このブログで画像埋め込みに使っているpCloudの公開用ドメインfiledn.euがなぜかブロックされてしまうので、セキュリティ制御のない9.9.9.10の方に。)

その他細かな注意点

今回旅先用ルータ-実家ルータ間に複数経路がある構成ですが、旅先用ルータ側でこのつなぎのVPNセグメントにIPマスカレードをかけておきます。

LuCI > Network > Firewall > Zones

で、VPNセグメントの属するゾーンすべてで

Masquerading

にチェック。

なにかとトラブルの元になる、行きと帰りで別ルートを通ってしまう非対称ルーティングを防ぐ目的です。OpenConnectでは旅先用ルータ側のIPアドレスがランダムに決まってしまうので、そもそも実家ルータ側に戻りのルーティング設定が固定で入れられないという事情もあります。