Android12搭載のスマートフォンから自宅ネットワークへVPN接続できる環境を作るその２: blogの辺境　～目指せblogの一市民～

2023年10月10日 (火)

Android12搭載のスマートフォンから自宅ネットワークへVPN接続できる環境を作るその２

NanoPi＋OpenVPNで作成した環境がNanoPiの動作不良により稼働しなくなった為、急遽別構成で構築しなおすことになった。

今回はお安く仕上げるためLANポートは1Gbps対応ではなく100Mbpsの機器を選定。
購入した機材は以下の通り。

現在25％オフの1,000円引き中で3,999円の所が2,999円となっている。
このGL.iNet USB GL-MT300N-V2 (Mango)はバックグラウンドでOpenWRTが動作しており、フロントエンドに独自のWEBコンソールを追加したルーターで、OpenVPNとWireguardが初期ですぐに導入可能な状態で起動する。
またフロントエンドのWEBコンソールから通常のOpenWRTのWEBコンソール(luci)へもアクセス可能である。

正直スマホからのスループットが100Mbpsも出ることはないのでLANポートが1Gbpsである必要性が無かった為、今回は100Mbpsのタイプにした。
但し公称のVPNスループットは10Mbps前後の為、不満が出る様なら上位グレードの物に交換するかも。
注：私が見たカタログスペック表ではOpenVPNが10Mbps程度、WireGuardが12Mbps程度の表記となっていたが、実測した人の記事だとWireGuardで50Mbps程度出ているらしいのでそれだけ出るならスループット的には問題なさそう。

あとアクセス環境の新規構築に伴って今回はOpenVPNより簡単なWireGuardへ乗り換えることにした。
デフォルトのルータLAN IPは192.168.8.1となっており、WEBコンソールへアクセスすると言語の設定・パスワードの設定を求められる。

パスワードを設定すると機器の設定画面に移動する。

ここでVPNをクリックしWireGuardサーバーを選択。

”WireGuardサーバを初期化します”をクリックするとWireGuardサーバーが自動で設定される。

ローカルネットワークにリモートからアクセスできるように”ローカルネットワークへのアクセスを許可します”を有効にする。

これで”起動”をクリックするとWireGuardサーバーが起動する。
次いで”管理タブ”をクリックしサーバーに接続してくるクライアントの設定を作成。

”新しいユーザーを追加します”をクリック。

接続名を設定、今回は”test”と入力し”追加”をクリック。

これでクライアント設定が完了。
”設定”の下のアイコンをクリックするとクライアント側のWireGuardに設定する内容が表示されれる。

クライアント側のWireGuardで上記QRコードを読み込めば設定は完了する。
若しくはテキストで表示してコピペした内容をファイルに保存してクライアント側のWireGuardで読み込んでもOK。

androidスマホ側ではWireGuardクライアントをインストールする。
GooglePlayで”WireGuard”と検索すれば出てくる。

WireGuardを起動すると右下の”＋”のボタンをクリックする。

ここで先ほどのQRコードをスキャンするか設定ファイルを読み込めば設定完了。

以上、やることは非常に少ないがこれで基本的にクライアントからサーバー側LANへのアクセスは可能となる。
OpenVPNの設定は敷居が高い方なので単にスマホで自宅ネットワークにアクセスしたいだけならWireGuardも良い選択肢だと思う。

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
ここからはもうちょっとマニアックな設定解説。

・上記で作成したクライアントの設定

[Interface]

Address = 10.0.0.2/32
ListenPort = 35382
PrivateKey = 省略
DNS = 64.6.64.6

[Peer]
AllowedIPs = 0.0.0.0/0,::/0
Endpoint = 106.138.19.3:51820
PersistentKeepalive = 25
PublicKey = 省略

私の環境ではWireGuardサーバーはメインのルータの配下に接続するのでちょっと設定変更が必要。

上記設定から
AllowedIPs = 192.168.0.0/24,::/0
Endpoint = DDNS登録のURL:51820

へ変更。
AllowedIPsを自宅ネットワークアドレスに変更するとクライアントはインターネットアクセスと自宅ネットワークアクセスが同時にできる。
元のままだとVPN接続中はクライアントからインターネットへのアクセスが出来なくなる。
EndpointをDDNS登録のURLに変更したのはIPが動的に変更する際の対応。
メインルータ側での待ち受けポートを変更している場合は後ろのポート番号も変更する。

もうちょっと設定を修正してクライアントネットワークとサーバーネットワークのLAN間接続を行うことも可能。
その場合はクライアント側にも今回使用したルータを用意する必要がある。
またGL.iNetの独自WEBコンソールからWireGuardを設定すると独自の設定ファイルから起動に必要な設定ファイルを都度生成して起動している為、一般的なWireGuardの設定ファイルが作成されない。
その為、独自作成される設定ファイルでの修正が必要。

WireGuardサーバーの設定後、WinSCP等でWireGuardサーバーのルータへアクセスし、"/etc/config/”配下にある"wireguard_server"ファイルを修正する。

修正内容は以下の通り。
ファイル内のpeer設定にLAN側のネットワークアドレスを追加する。

config peers 'wg_peer_3718'
　　option name 'test'
　　option client_key '省略'
　　option private_key '省略'
　　option client_ip '10.0.0.2/32'
　　option subnet '192.168.200.0/24'　<-追加

option subnetは以下の様に複数記載することも可能。
例：
　　option subnet '192.168.200.0/24'　
　　option subnet '192.168.300.0/24'　

これによりWireGuardサーバールータのルーティングテーブルに上記サブネット宛ルーティングが追加される・
TTYコンソールから確認すると以下の様なルーティングテーブルが確認できる。

root@GL-MT300N-V2_VPN-Sever:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.xxx.xxx 0.0.0.0 UG 10 0 0 eth0.2
192.168.100.0 * 255.255.255.0 U 0 0 0 wg0
192.168.200.0 * 255.255.255.0 U 0 0 0 wg0
root@GL-MT300N-V2_VPN-Sever:~#

サーバー側LANのゲートウェイルータに192.168.100.0/24と192.168.200.0/24をWireGuardサーバーのルータへ転送するルーティングテーブルを追加するとサーバー側LAN上の端末からクライアント側LANへのアクセスが可能となる。

この際はWireGuardクライアントの設定ファイルの
AllowedIPs = 192.168.0.0/24,::/0
は
AllowedIPs = 0.0.0.0/0,::/0
に戻しておく必要がある。

本来はここにサーバー側LANネットワークアドレスとWireGuardのVPNネットワークアドレスを追記しておけばよいはずなのだが

AllowedIPs = 192.168.0.0/24,10.0.0.0/24,::/0

と記載しても”,”で区切った追記分が反映されていない様子。
TTYコンソールから手動で追加すると正常にLAN間接続が出来たのでこれはGL.iNetのスクリプトの問題と思われる。
その為デフォルトで追記されているIPv6の”::/0”も機能していない様な気がする。
但しIPv6での検証はしていないので間違っているかも。
スクリプトは"/etc/init.d/wireguard_server"になるのでこれを修正して対応可能かも？

OpenWRT上でのWireGuardによる拠点間接続の例はあったがGL.iNetのルータを用いた拠点間接続の情報が見つけられなかったので結構苦労したが最終的には接続可能となったので苦労した甲斐はあった。

但し現状ではクライアントネットワーク側はWireGuardによるVPN接続を行うとインターネットへアクセスできなくなる為、インターネットアクセス用ルータとWireGuard VPN接続ルータを分ける必要がある。
若しくはWireGuard VPN接続ルータのルーティングテーブルを別途修正する必要がある。

メインルータにスタティックルートが定義できるならルータを分けるのが一番楽かと思う。

231014追記：
起動不能となったNanoPi R2Sを調査するためにttyコンソールへ接続して起動情報を見ようとした。
2310141002

コンソール接続用に使用したUSBデバイスはこれ。

RS-232CのUSBシリアルコンソールケーブルが使用できないので購入した。

R2Sのコンソールスピードは1.5Mbpsなのだが、Windowsのドライバは128Kbpsの速度までしか設定が出来ないのでこの記事で作成したlubuntu上のターミナルから接続して確認を実施。
その結果起動ログが何も見れなかった。
USBコンソールデバイスが正常に稼働しているかMT300N-V2のttyコンソールに接続して確認したらちゃんと起動ログが表示された。
MT300N-V2は115.2Ｋbpsの為、R2Sのコンソール速度と異なるがこのUSBデバイスのCH340チップは仕様上は2Mbpsまで対応しているのでログが表示されないという事は起動シーケンスに移行していないという事なので完全に壊れていると思われる。
通電ランプは点灯するのでファームウェアが飛んだかチップセットか周辺部品が死んだかしているのだろうと推測される。
直すための機材も部品もないので完全終了ですな。

一応このUSBデバイスのチップCH340はWindows11でも動くのでついでに動作確認。
ドライバはWindowsUpdateを実施すると自動でインストールされる。
一応チップメーカーHPにもドライバがあるがどちらも同じバージョンだったので気にする必要はなさそう。

Windowsのターミナルソフトで確認した結果は以下の通り。

ログでは大体61秒で起動している。
それとどこかのBlogにも書かれていたがOpenWRTの19.07.8と古いバージョンが使用されている。
私の構成ではこのルータが直接インターネットに接続される訳では無いので余りセキュリティの心配をしていないのだが、気になる人はもっと新しいOpenWRTの22.03.4を使用したファームウェア Version4.3.7もリリースされている。
但しOSファイルが大きくなった為かデフォルトでサポートしていた機能が色々制限されているので注意が必要。
まあ手動でパッケージを構成することはできるみたい。
ファームウェアを4.3.7へ更新後に再び3.216へダウングレードできたので試しに変更してみるのも有りかも。

しかしR2Sは思ったより持たなかった。
結構発熱がきつかったのでその影響もあった気がする。
基板上に5V供給用のコネクタもあるので自然空冷のケースよりFANで強制的に冷やすケースの方が安定するのかもしれない。
MT300N-V2は今の所R2Sほど発熱している感じは無いので冷却面では大丈夫と思われる。
まあスペックも低いからね。