ラズパイに OpenWrt を入れて DS-lite ルーターを構築する

 

 

 Raspberry Pi3 B の役割変遷 

 

これまで Asterisk、OpenVPN、WireguardVPN として使ってきました。

Asterisk はひかり電話をやめてブラステルをイエデンにしてお役御免になりました。

 

 

いまは Rakuten Link があるのでブラステルも不要になりつつあります。

 

 

その後、外出中に家庭内の機器を操作できるようにと、OpenVPN 〜 WireguardVPN をインストールしていました。

 

 

IPv4 over IPv6 のポート制限回避のため PPPoE を併用したり、いっそのこと IPv6 したりと変わってきています。

 

 

いまは AP モードの GL-AXT1800 の Tailscale を使っており自前の VPN サーバーはお役御免、その結果ラズパイは使い道がなく、有休品になっていました。

 

 

以下の記述で Rpi3 は Raspberry Pi3 B のことです。

 

 

 

 

Rpi3 を DS-lite で動かす 

 

　〜〜 ことの発端 〜〜

 

今回、GL-AXT1800 や MT2500A で DS-lite を設定したところ、再起動の不具合が発生、これが OpenWrt 問題か GL.iNet 問題かを切り分けるためラズパイに OpenWrt を入れ、DS-lite を設定して検証してみたのです。

 

結果は GL.iNet 問題であると結論付けましたが、せっかく DS-lite をセットアップしましたので、具体的なやり方を記載してみます。

 

 

 

 

 

【その１】OpenWrt で 無線LANルーターにする 

 

まずは OpenWrt ルーターにするところから始めます。

 

参考にしたのは、にゃののん日記 というサイトです。

 

 

 

このサイトでは 無線LANルーター化 はしていますが、DS-lite は設定しておらず、IPv6 対応もされていません。

 

 

DS-lite ルーター化は OpenWrt による無線LANルーター化のあとで記載します。

 

ここに「OpenWrt公式サイト（日本語）からダウンロード→安定リリース ビルド→21.02.0（GL-AXT1800の最新版ファームウェアのOpenWrtバージョンと同じ）→targets→bcm27xx（Raspberry Piを含むカテゴリ）→bcm2710（Rpi3用）→rpi-3-ext4-factory.img.gzの順に選択してダウンロードしたものをbalenaEtcher等でmicroSDカードに書き込む」と記載されています。

 

 

この手順で OpenWrt は簡単にブートできます。

 

 

要は対象のブートイメージを SD カードに焼き、これを Rpi3 に差し込んで電源を入れれば OpenWrt の初期画面になります。

SD カードは手持ちの 2GB のものを使いましたが、1GB でも十分です。

最終的に DS-lite を動かすところまでに使用した SD メモリ領域は 0.9GB ほどです。

 Rpi3 OpenWrt Configuration 


Mac mini M1 で最初に SD カードを MS-DOS（FAT）で初期化します。

 

Windows でも OpenWrt にできます。

 

balenaEtcher を使い、ダウンロードした OpenWrt を書き込みます。

 

《Flash from file》をクリックしてダウンロードしたopenwrt-21.02.0-bcm27xx-bcm2710-rpi-3-ext4-factory.img.gz を指定します。

 

今回は GL-AXT1800 と同じバージョンにしましたが、もっと新しいバージョンがすでにリリースされています。

 



《Select target》をクリックして SD カードを指定し、《Flash!》をクリックすると、自動解凍して書き込みが始まります。

 

 

下図は書き込み中の状態です。

 

書き込み完了画面です。


OpenWrt のブートディスクが出来上がりです。

 

SD カードを取り出し、Rpi3 の SD カードスロットに差し込みます。

 

そして Mac と Rpi3 を LAN ケーブルで直結します。

 

 

このとき Mac のネットワーク設定は DHCP サーバーを使う設定にします。

 

OpenWrt から IP アドレス（192.168.1.0/24）が割り当てられるからです。

 

Rpi3 の電源導通で OpenWrt が起動します。

Mac のネットワークに IP が割り当たったらブラウザで192.168.1.1 と入力すると OpenWrt の初期画面になります。

 

 

初期画面ではまだパスワード未設定なので何も入力せず、《Login》をクリックします。



 

次に時刻合わせをします。
 

【System】→ 【System】→【General Settings】→【Sync with Browser】でブラウザと時刻が同期します。

【Timezone】を「Asia/Tokyo」として《Save & Apply》で反映させます。



 

 

続いてパスワードを設定します。



 

パスワードと、確認用パスワードを入力して《Save》で設定完了になります。

 

設定したパスワード欄と確認欄はクリアされますが設定はできています。

 

再び《Save》してしまうと no password になりますから注意が必要です。



 

いったん《Logout》し、パスワードを入力してログインし直します。

 

次に WiFi-AP を設定します。

 

ドライバーと アクセスポイント化のパッケージは Rpi3 用がすでに組み込まれています。

 

 

【Network】→【Wireless】と進み《Enable》となっているインタフェースの《Edit》をクリックします。

 

Power を10dBm/10mW にします。

国内は 10mW 以上の高周波出力は電波法違反になります。

 

10dBm で十分に届きます。

 

Wireless Security は WPA2-PSK にし、Cypher は Force CCMP（AES）として、Key（接続時パスワード）を設定します。


 

 

Advanced Settings で、Country Code を JP - Japan にし、Force 40MHz モードにチェックを入れます。

 

 

 

General Setup に戻り Wireless network is disabled 欄の《Enable》をクリックして有効化します。

 

 

 

Mac と Rpi3 を直結していた LAN ケーブルを外し、Mac をいま設定した WiFi-AP に接続します。

 

Mac の LAN ポートは現在のルーターにつないでいても構いません。

 

つまり LAN：192.168.xxx.0/24、WiFi-AP：192.168.1.0/24 となります。

 

 

 

にゃののん日記 では Rpi3 の LAN 端子を WAN端子にする、として下記手順が示されていますが 2 項のあと、3 項の該当箇所がなく、しばらく悪戦苦闘しました。

1. Network→Interfaces
2. InterfacesのLANから、Edit
3. Physical Settings→Common ConfigurationのInterfaceからeth0→Ethernet Adapter: "eth0"のチェックをはずす
4. Save & Apply
5. Interfacesから、Add new interface
6. Name of the new interfaceにwanを入力
7. Protocol of the new interfaceからDHCP clientを選択
8. Submit
9. Save & Apply

 

 

1 〜 4 項は次のようにします。

 

【Network】→【Interface】→【Devices】→ Type 欄が「Bridge device」の《Configure...》をクリックします。



「Bridge ports」の「eth0」のチェックを外し《Save》で戻って《Save & Apply》します。



 

続いて 5 〜 9 項になります。

 

 

【Interfaces】から、《Add new interface》をクリックし、
「Name of the new interface」に「wan」を入力します。

 

「Protocol of the new interface」から「DHCP client」を選択し「Device」は「”eth0” (wan) 」を選択して、《Save》→《Save & Apply》で反映させます。

 

つまりこういうことです。

 

LAN インタフェースのデバイス設定を eth0 から br-lan にし、WAN インタフェースを新規追加して、こちらを eth0 にする、ということです。

 

これによって Rpi3 の LAN ポートが WAN になるというわけです。

さて、この WAN ポートをメインルーターの LAN ポートに繋ぐのですが、このあとの設定に備えて、メインルーターが 192.168.1.0/24 の場合は、Rpi3 側の LAN インタフェースを 192.168.1.0/24 以外にする必要があります。

メインルーターが 192.168.1.0/24 以外の場合は、変更する必要はありません。

 

変更する場合は LAN インタフェースの IPv4 アドレスを変更します。

 

 

ここではメインルーターが 192.168.1.0/24 以外を前提にこのあとの設定をします。

 

 

Rpi3 の LAN ポートは WAN ポートになっているので、メインルーターの LAN につなぎます。

 

以上で WAN がメインルーターからアドレス付与されて、Rpi3 に接続したクライアントは、インターネットアクセスができる状態になっています。

 

 

インターネットアクセスできないときは、DNS 未設定のケースと思われます。

 

ターミナルから CLI で vim /etc/resolv.conf とし、
nameserver 1.1.1.1 を最終行に追加して公的 DNS を有効にします。

 

 

 

 

これで Rpi3 が OpenWrt による 無線LAN ルーター になり、インターネットアクセスができるはずです。



インターネット接続できているので DS-lite 設定やその他に備え、いくつかのパッケージをインストールします。

 

【System】→【Software】→《Update lists...》をクリックし、パッケージリストを最新化します。

 

 

そして、「Filter：」欄に下記のパッケージ名を入力して一つずつ《Install》します。

・luci-i18n-base-ja（日本語化）
・usbutils（USBポートの検査）
・ds-lite（DS-lite のパッケージ）
・kmod-usb-net-asix-ax88179

　（Buffalo LUA4-U3-AGT・USB-LAN アダプター用のドライバー）

 

DS-lite パッケージは再起動しないと有効になりませんので、ここでいったん再起動しておきます。

 

luci-i18n-base-ja のインストールにより、以降は日本語メニューになります。

 

 

以上で Rpi3 が無線LAN 付きのトラベルルーターになります。

 

 

 

 

【その２】OpenWrt で DS-lite による 無線LANルーターにする  

 

DS-lite を設定して IPv4 over IPv6 対応の 無線 LAN ルーター にしていきます。

 

 

 

まずは IPv6 対応のために WAN6 インタフェースを作成します。

 

【ネットワーク】→【インタフェース】で《インタフェースを新規作成》をクリックします。
 

　・名前　　　：wan6

　・プロトコル：DHCPv6クライアント

　・デバイス　：”eth0” (wan)

 

 

  

を設定し《インタフェース作成》とします。

 

 

 DHCPサーバータブをクリックしリレーモードにします。

 

 

詳細設定のカスタムDNS に 2606:4700:4700:1111 または 2001:4860:4860::8888 を設定します。

 

これは IPv6 の公的 DNS 設定になります。

 

ファイアウォールの設定を確認します。

xpass と wan6 がファイアウォールゾーン設定されているか？

《保存》→《保存＆適用》します。

 

次に【ネットワーク】→【インタフェース】で《インタフェースを新規作成》をクリックし、xpass インタフェースを追加します。

　・名前　　　：xpass

　・プロトコル：Dual-Stack Lite (RFC6333)

 

として《インタフェースを作成》をクリックします。

 その他の設定と確認 

LAN インタフェースの【詳細設定】でカスタムDNS として IPv4 公的DNS を設定します。

DHCPサーバータブに移り、IPv6設定をリレーモードにします。

 

 

《保存》→《保存＆適用》します。

 

xpass インタフェースの詳細設定で、トンネルインターフェースでMTUを使用欄を 1280 から 1460 に変更します。

ファイアウォール設定で、ファイアウォールゾーンの割り当てを確認します。

xpass と wan6 がファイアウォールゾーンに設定されているか？

 

 

 

次に WAN インタフェースの無効化設定をします。

 

　・プロトコル：アンマネージド

　・デバイス　：未設定

 

 

とし《保存》します。
 

 

 

 

最後にファイアウォールの設定を確認・修正します。

 

あと一息で DS-lite 設定が終了します。

 

 

 

【ネットワーク】→【ファイアウォール】と進みます。

 

[LAN] → [WAN] の《編集》をクリックし、次の内容になっているかを確認します。

 

 

《保存》で戻ります。

 

 

[WAN] → [REJECT] の《編集》をクリックし、次の内容になっているかを確認します。

 

《保存》で戻ります。

 

 

 

《追加》をクリックし、xpass のファイアウォール設定をします。

 

 

 《保存》で戻ると最終的に次のようになっているはずです。

 

 

 

 

Software flow offloading と Hardware flow offloading にチェックを入れます。

ネットワークアクセスが多少速くなるらしいです。


 

 

以上で DS-lite の設定ができているはずです。

 

確認のため、いくつかのサイトをアクセスしてみます。 

 

https://test-ipv6.com/index.html.ja_JP をアクセスします。

IPv6 が 10/10 になるかを確認します。

 

https://www.yahoo.co.jp/ をアクセスします。
yahoo は IPv4 オンリーサイトなので IPIP カプセル化の確認ができます。

 

http://check.xpass.jp/ をアクセスして《確認》ボタンを押し、xpass の状態を確認します

 

 

 

 

以上で DS-lite の設定が完了です。

 

 

 

 

最後に・・・

 

ネットワークアクセス速度は DL/UP ともに約 90 Mbps です。

 

 

 

Rpi3 は USB2.0 ですし、WiFi も 2.4GHz/802.11bgn で、LAN ポートも最大 100 Mbps ですから、これ以上はでません。

 

 

ですので VDSL 方式ならば性能的にはつり合いますが、1Gbps 以上の回線では性能不足を感じます。

 

 

また GL-MT300N の方が 3,000 円程度で手に入りますので、格段にコスパが優れています。

 

 

 

Rpi 3 b+ または Rpi4 ならば USB3.0 ポートがありますし、WiFi も 5GHz/802.11ac ですからもっと速度性能はよくなると思いますがどうでしょうか。

OpenWrt ルーターとしてならば GL.iNet（AXT1800 やMT2500 が性能的におすすめ）の方をおすすめします。

Raspberry Pi は小型 Linux マシンとして使う分にはよいと思いますが、OpenWrt にするともったいない気がします。

 

 

 

 

 

GL.iNet ルーターが再起動で DS-lite が正常に戻らない件にハマった【2023-11-22 一部修正、11-23 追記】

 

 

【2023-11-22 一部修正】青字で記載部分が修正箇所

【2023-11-23 追記　　】橙字が追記箇所

 　Raspberry pi3 B に OpenWrt を入れて Xpass で検証しました（記事末に追加）

 

 

 

GL-AXT1800 または MT2500A を xpass（DS-lite）ルーターにした場合、再起動で DS-lite が外れる問題に悩まされてきました。

 

 

ルーターはすでに RTX830 に戻していますが、この問題は刺さった棘みたいにズーッと気になっていたのです。

 

 

ブリッジモード（AP モード）にした AXT1800 を一時的にルーターモードに変え、刺さった棘を取ることにハマったのです。

 

 

試してみてはダメで AP モードに戻し、時間があれば再びルーターモードにして棘取りを試みる、ということを繰り返していました。

 

 

ルーターモードに戻した場合、管理画面で IPv6 は「Passthrough」にします。

 

なので LAN と WAN6 の【DHCP サーバー：IPv6設定】は「リレーモード」になります。

 

 

 

 

今回再起動問題がやっと処置できましたのでその顛末を記載します。

 

 

同事象に見舞われている方への処置になれば幸いです。

 

 

 

 

 発生現象 

再起動すると【ネットワーク】→【インタフェース】で LAN インタフェースの IPv4 アドレスの下に IPv6: fd70:a23c:cd9a::1/64 が表示され、LAN に割り当たっていることがわかります。

 

 

IPv6: fd70:a23c:cd9a::1/64 は「グローバルアドレス」になっていますが、何のアドレスか出どころが不明です。

 

リンクローカルならば fd80:~~/64 になるはずですが、そうでもありません。

 

アルテリアの Xpass のグローバルアドレスはウチの場合は、2001:f71:a0e0:5600:~~/128 ですから、これではありません。

 

この不明な「グローバルアドレス」が悪さをしているのか？

 

 

この IPv6: fd70:a23c:cd9a::1/64 が割り当たることが原因と思われる、「DS-lite が外れて IPv6 が正しく機能しない」という状況に陥っていました。

 

 

 

 

 当初の処置 

【ネットワーク】→【インタフェース】→【LAN】→【詳細設定】と進みます。

 

 

この中の「IPv6割り当て長」を「64」から「無効」にして【保存】で戻り【保存＆適用】で反映させると IPv6: fd70:a23c:cd9a::1/64 が割り当たらなくなり、DS-lite が正しく処理されるようになるのです。

 

 

不思議なことにいったん「無効」にしたあとで「64」に戻して IPv6: fd70:a23c:cd9a::1/64 が割り当たるようになっても DS-lite は正しく処理されるのです。

 

 

わけがわかりません。

 

 

 

 

 再起動で再発 

ところが再起動すると元の木阿弥で、IPv6: fd70:a23c:cd9a::1/64 が割り当たってしまい、「DS-lite が外れて IPv6 が正しく機能しない」状態に戻ってしまうのです。

 

このとき「IPv6割り当て長」が「64」に戻っています。

 

 

DS-lite を正しく処理させるには再度「64」を「無効」にしなくてはならず、どうしても手動で再設定という手間がかかるのです。

 

 

 

 

 抜本処置までの道のり 

いろいろ試行錯誤の末に最終的に次のような措置をしてやっと、再起動しても DS-lite が正しく処理されるようになりました。

 

 

 

まず ifconfig で IP アドレスの割り当て状況を見てみます。

(マゼンタ色部分は隠蔽化しています)

 

root@GL-MT2500:~# ifconfig
br-lan    Link encap:Ethernet  HWaddr aa:bb:cc:dd:ee:ff 
          inet addr:192.168.xxx.1  Bcast:192.168.xxx.255  Mask:255.255.255.0
          inet6 addr: fe80::~~/64 Scope:Link
          inet6 addr: fd70:a23c:cd9a::1/64 Scope:Global → このアドレスが問題
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:65601 errors:0 dropped:3003 overruns:0 frame:0
          TX packets:61494 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:10899131 (10.3 MiB)  TX bytes:38764310 (36.9 MiB)

ds-wan    Link encap:UNSPEC  HWaddr 20-01-0F-71-A0-E0-56-00-00-00-00-00-00-00-00-00  
          inet addr:192.0.0.2  P-t-P:192.0.0.1  Mask:255.255.255.255
          inet6 addr: fe80::~~/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP  MTU:1460  Metric:1
          RX packets:12675 errors:0 dropped:0 overruns:0 frame:0
          TX packets:17468 errors:11 dropped:11 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5970263 (5.6 MiB)  TX bytes:2851135 (2.7 MiB)

eth0      Link encap:Ethernet  HWaddr aa:bb:cc:dd:ee:ff 
          inet6 addr: 2001:f71:a0e0:5600:~~/64 Scope:Global
          inet6 addr: fe80::~~/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:59982 errors:0 dropped:0 overruns:0 frame:0
          TX packets:43547 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:43265468 (41.2 MiB)  TX bytes:9732380 (9.2 MiB)
          Interrupt:75
︙ 

︙
root@GL-MT2500:~#

GL.iNet のフォーラムに gl-mt300n でのこの問題が提起され、/etc/config/network の LAN の項目に【 option ipv6 '0' 】を追加してみたがうまくいかなかった、とあったのをみつけ、これがヒントになりました。

 

 

中身を確認してみます。

root@GL-MT2500:~# cat /etc/config/network

config interface 'loopback'
    option device 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config globals 'globals'
    option ula_prefix 'fd70:a23c:cd9a::/48' → これはなんでしょう？

config device
    option name 'br-lan'
    option type 'bridge'
    list ports 'eth1'

config device
    option name 'eth1'
    option macaddr 'aa:bb:cc:dd:ee:ff'

config interface 'lan'
    option device 'br-lan'
    option proto 'static'
    option netmask '255.255.255.0'
    option isolate '0'
    option ipaddr '192.168.xxx.1’
    option delegate '0'
    option ip6ifaceid '::1'

config device
    option name 'eth0'
    option macaddr 'aa:bb:cc:dd:ee:ff'
︙
︙
root@GL-MT2500:~#
 


【 'option ipv6 0' 】を追加して、再起動するとまたまた fd70:a23c:cd9a::1/64 が割り当たっており、相変わらず DS-lite が正常処理されなくなっています。

 

 

/etc/config/network 中の朱字部分が問題の根源に思えます。

 

そこで朱字部分の修正をしました。

 

併せて IPv6割り当て長が '64' にならないように ''（null値）にします。

（この部分は null値にしても再起動で元に戻ってしまいますが結果に影響ありませんでした）

 

root@GL-MT2500:~# cat /etc/config/network

config interface 'loopback'
    option device 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config globals 'globals' → この行と次の行を削除する
    option ula_prefix 'fd70:a23c:cd9a::/48'

config device
    option name 'br-lan'
    option type 'bridge'
    list ports 'eth1'

config device
    option name 'eth1'
    option macaddr 'aa:bb:cc:dd:ee:ff'

config interface 'lan'
    option device 'br-lan'
    option proto 'static'
    option netmask '255.255.255.0'
    option isolate '0'
    option ipaddr '192.168.xxx.1’
    option delegate '0'
    option ip6ifaceid '::1'
    option ipv6 '0'
    option ip6assign '64' → この行は option ip6assign '' と、null 設定にする
    option ip6hint '0000' → この行は option ip6hint '' と、null 設定にする

config device
    option name 'eth0'
    option macaddr 'aa:bb:cc:dd:ee:ff'
︙ 

︙
root@GL-MT2500:~#


 

これによって再起動しても LAN に fd70:a23c:cd9a::1/64 が割り当たらなくなり DS-lite が正しく処理されるようになりました。
 

 

 

IPv6 を Passthrough ではなく NAT6 にした場合については試していませんが、おそらく今回のような事象にはならないだろうと推察しています。

 

なぜなら、NAT6 はリンクローカルが割り当たって、NAT6 変換してグローバル空間にでていく仕組みだから、だと考えています。

 

 

本件は２週間ほど試行錯誤の連続で、最終的に /etc/config/network の設定見直しに行き着くまで悩みました。

 

 

 

本件は OpenWrt の問題なのか、GL.iNet の問題なのかはわかりませんが、どうも後者のような気がします。

 

 

ラズパイにでも OpenWrt を入れて検証すればどちらの問題かがハッキリするかも知れませんので、後日検証してみますか。

 

 

 

 

2023-11-23 に Raspberry Pi3 B に OpenWrt をインストールし、Xpass 設定して検証しました。

 

結論からいいますと、GL.iNet 機器のように、再起動で問題になることはなく、Xpass は正しく処理されています。

 

 

なので本事象は GL.iNet 機器の問題と思われます。

 

 

ただ、/etc/config/network には下記の２行が含まれています。

 

config globals 'globals'
    option ula_prefix 'fd75:fe32:815a::/48' 

 

なぜ、Raspberry Pi3 B の OpenWrt（Xpass）ではこれが問題とならないのかはわかりません。

 

ギガビット対応の USB-LAN アダプターを LAN に、元からある LAN ポートを WAN にして検証しました。

 

 

 

Raspberry Pi3 B は USB2.0 なのでギガビット対応の LAN アダプター（Buffalo LUA4-U3-AGT：USB3.0）でも最大 100 Mbps です。

 

Xpass での性能は DL/UP ともに 92 Mbps でした。

 

Pi4 ならば USB3.0 ポートがありますからもっと速度が出ると思います。

 

 

 

Xpass ルーターのほか、トラベルルーターとしても使えますが、GL-MT300N の方がコスパはいいですね。

 

 

 

 

 

 

 

 

ルーターを GL-AXT1800 から RTX830 に戻しました【2023-10-15 修正】

 

 

【2023-10-15 修正】ブリッジモードでの tailscale の動作確認をしました

ルーターモードで有効にしておいた tailscale は、ブリッジモード（AXT1800 は APモード）にすると管理画面からメニューが消えますが、動作自体は問題ないことを確認しました。

ただしブリッジモードに切り替えると、そのままでは動作せず、CLI で service tailscale restart して動作するようになりました。

tailscale 管理画面では Connected になっています。

また、Subnets & Exit Node もそのまま機能しています。

 

 

メニューから消えたほかのアプリケーションや VPN については未検証ですが、tailscale の動作状況をみると同様に動作すると思われます。

 

 

なので、GL.iNet 社には早い段階でファームウェアを改善して、メニューを復活していただきたいものです。

 

 

 

とりあえず、ウチでは AXT1800 も MT2500 同様にブリッジモードにしましたので、家庭内は 2重ルーター構成がなくなり、ドメインも 192.168.xxx.0/24 のみになります。

 

 

 

 

 

 

ルーターをほぼ１ヶ月ぶりに RTX830 に戻しました。

 

GL-AXT1800 は WiFi ルーターとして安定動作しており、問題はありませんでしたが、RTX830 を遊ばせておくのももったいないので、戻すことにしました。

 

 

Xpass における速度性能は IPv4 が、

 

　・RTX830  ：750 ~ 800 Mbps

　・AXT1800：400 Mbps 前後

 

で AXT1800 は RTX830 の約 50% の性能値です。

 

 

IPv6 は 

 

　・RTX830  ：880 ~ 900 Mbps 強

　・AXT1800：770 ~ 830 Mbps 

 

で AXT1800 が RTX830 よりも 10% 程度遅いのですがほぼ同等とみていいでしょう。

 

 

AXT1800 は Xpass における IPv4 パケットのカプセル化・アンカプセル化が結構重い、ということでしょう。

 

 

ただ AXT1800 も 400 Mbps 前後はでていますので、実質的に速度が問題にはなりません。

 

 

 

ですから RTX830 のような高級機を保有しないなら GL.iNet ルーターはおすすめできます。

 

 

 

 

 

さて、ルーターを RTX830 に戻すに際して、AXT1800 と MT2500A はいずれも WiFi-AP にすることとしました。

 

 

コンパクトなので設置もスッキリします。

 

 

ルーターは居間に置かざるを得ないので、居間の WiFi-AP はより小さい MT2500A にすることとし、AXT1800 を書斎用にすることにします。

 

 

左の黒い箱は電源収納ボックスで、MT2500A 本体はこの中に収めてあります（電話子機の下にちらりと見えています）。

 

電話子機の後ろが WiFi ドングルの Netgear A6210 です。

 

右前が ONU、右後ろが RTX830 です。

 

 

 

 

これまで MT2500A は tailscale：Subnets & Exit Node にしていて、WiFi-AP にもしていました。

 

WiFi-AP 用のドングルは WI-U2-300D から高性能な Netgear A6210 ドングルに変えましたが。。。

 

 

MT2500 の WiFi‐AP に接続の機器は、家庭内のローカルドメイン 192.168.xxx.0/24 で動作させたいのでブリッジモードにすることとします。

 

 

 

 

ところが GL.iNet 製のルーターはブリッジモードにするとアプリケーションの Adguard / ペアレンタルコントロール / ZeroTier / tailscale と、VPN が管理画面のメニューから消えます。

 

 

ルーターモード時に設定しておいたこれらの機能がブリッジモードで有効かどうかは未検証ですが、起動時に関連パッケージが読み込まれていますので、動作しているのではないかと考えています。

 

 

これらの機能をあえてメニューから削除する必要性はないと思いますし、ブリッジモードでも動作させればよいと思うのですが。。。

 

 

ブリッジモード／ルーターモード切替えは管理画面での設定なので GL.iNet 機器の問題のように思えます。

 

 

 

本件に関して GL.iNet フォーラムで 2023-05-01 に、あるユーザーが次の書き込みをしています。

r3mi    May 1

Hello,
I purchased a GL-AX1800 (Flint) and am very glad for the tailscale support in the latest firmware. It works fine, but after I put the router in Access Point mode, the tailscale App disappears from the admin menu. But tailscale is still working, e.g. I can access the router through tailscale network. Is is possible to make the App and its UI present in AP mode ? Even if not all options are relevant (eg subnet router for WAN), most are still useful (eg subnet router for LAN, access through tailscale IP, or exit node when it will be implemented).
Thanks,

 

このユーザーはメニューから消えても tailscale は機能している、といっています。

 

これに対して GL.iNet のスタッフが次のように答えています。

uochongjun    GL.iNet Staff    
May 4

There don’t seem to be any other issues, and improvements will be considered in subsequent releases.

 

メニューから消えるのは GL.iNet ルーターの問題のようで、改善が検討されるだろう、とあります。

 

 

ユーザーは、4ヶ月後の 2023-09-11 に 4.2.3 ではまだ改善されていませんねぇ、とスタッフに問いかけていますが、これに対する返答はありません。

4 months later    r3mi
luochongjun    Sep 11

Hello,
are you still considering the improvement ?
I upgraded my GL-AX1800 to the latest firmware (4.2.3), and tailscale is still not visible from the Application menu in Access Point mode (even though it has been enabled when in Router mode).
Thanks,
 

 

ちなみに最新版ファームウェア 4.4.6 でも本事象は改善されていません。

 

 

ブリッジモード時に tailscale が有効に動作するかどうかを AXT1800 で検証してみますか？

→ 検証して動作を確認済です。

 

 

 

またブリッジモードに変更後、プラグインパッケージのインストールができなくなっています。

 

 

すでにインストールしたパッケージは有効です。

 

例えば日本語化パッケージである luci-i18n-base-ja は、ルーターモードでインストールしておけばブリッジモードでも有効ですが、ブリッジモードにしたあとではインストールできません。

 

 

 

なぜインストールできないのか、状況把握のために CLI で ping google.com を打つと無応答です。

 

ping 8.8.8.8 は応答があります。

 

 

どうも dns が外れているようです。

 

 

route コマンドで、デフォルトゲートウェイは設定されているのがわかりますからデフォルトゲートウェイ問題ではなさそうです。

root@GL-MT2500:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.xxx.1    0.0.0.0         UG    0      0        0 br-lan
192.168.xxx.0    *               255.255.255.0   U     0      0        0 br-lan
root@GL-MT2500:~#

/etc/resolv.conf を見ると dns がローカルだけになっていて、公的 dns が未設定になっています。

root@GL-MT2500:~# cat /etc/resolv.conf
search lan
nameserver 127.0.0.1
nameserver ::1
root@GL-MT2500:~#

そこで /etc/resolv.conf に nameserver 1.1.1.1 を追加したところ、ping google.com が応答するようになりました。

 

 

この時点で opkg update はエラーにならずに正常に処理され、パッケージインストールができるようになりました。

 

 

 

ということで、MT2500A をブリッジモードで WiFi-AP とし、AXT1800 をルーターモードで WiFi-AP 兼 tailscale：Subnets & Exit Node とします。

 

 

 

その結果、家庭内のネットワークは次図のようになります。

 

 

 

家庭内 LAN のローカルドメインは 192.168.xxx.0/24 ですから、GL.iNet 機器 の WiFi-AP に接続のスマホ等は、同じドメイン 192.168.xxx.0/24 のアドレスになります。

 

 

 

ルーターモードの AXT1800 の WiFi-AP に接続されるスマホ等は、192.168.yyy.0/24 ドメインのアドレスになりますが、上位ドメイン 192.168.xxx.0/24 は自由にアクセスできます。

 

 

 

逆に上位ドメインから下位ドメインはポート開放やポート転送などを設定する必要がありますが、WiFi 接続はスマホとタブレットだけですから、下位ドメイン機器にアクセスすることはまずありません。

 

 

ただし、AXT1800 自体にログインや ssh 接続することがありますので、ポート 22（ssh）と 80（http）は開放していて、WAN 側からログインできます。

 

 

 

 

AXT1800（左側）とMT2500A（右側）の速度測定結果です。

測定に使ったのは OPPO Reno9 A です。

ともに 802.11ac で 867 Mbps の WiFi 定格ですが、リンク速度は 433 Mbps になっていて、これはスマホの能力で抑えられていると思います。

 

 

スマホは多分１ストリームと思われ、リンク速度は最大 433 Mbps なのでしょう。 

 

ちなみに家庭内のどの場所でも WiFi はこのような速度です。