投稿

ラベル(ルーター)が付いた投稿を表示しています

OpenWrt で Let's Encrypt (with acme.sh)

イメージ
このブログ記事を最初にまとめた当時(2020-11-11)には気付かなかったが、現在(2023-12-06)ではいつの間にか、OpenWrt のパッケージモジュールとして acme が用意されており、さらには LuCI から使うための luci-app-acme までも存在している。以前の僕はこれらの OpenWrt パッケージについて知らなかったので、acme.sh の 公式サイト の説明に従って一般的な Linux マシンとしてインストールし、コマンドを実行して使用してと、愚直に自力の作業をしていたものである。今では OpenWrt の acme.sh についての 公式の説明 も存在するので、それに従って作業すれば、ほとんど苦もなく完了できる。 だが、acme.sh の実行による Let's Encrypt からの証明書の発行が半自動化されたとはいえ、DNS や NGINX などと連携させる必要があり、総合的な話としては一定の知識を要するので、ここにまとめておきたいと思う。 Web ルートの準備 acme.sh では証明書の発行時の身元確認の方式として、Web ルートに .well-known/acme-challenge という一時的な隠しフォルダを作成し、そこにユニークな文字列からなるファイル名を持ったファイルを設置して、インターネット側から http://(ドメイン名)/.well-known/acme-challenge/(ファイル名)にアクセスできるかどうかで、確認するという形になっている。 このため、いきなり、acme を使うのではなくて、先に DNS 側でドメインが OpenWrt ルーターの IP を指し示すように設定しておき、さらに OpenWrt ルーター側では、NGINX の設定で、そのドメイン名での http アクセスが /www 以下に対応付けられるようにしておかなければならない。 DNS の設定 A レコードでデフォルトドメインがルーターの IP アドレスを指し示すように設定している他、CNAME で www がデフォルトドメインの別名であるようにしている。CAA レコードは今回の趣旨とは全く関係がないオマケで、無関係の他者が勝手にこのドメイン名を使った証明書を作成することを防ぐためのものである( 参考 )

au ひかり用の HGW を HGW-BL1500HM に更新

イメージ
実家の au ひかり用の HGW を Aterm BL902HW から HGW-BL1500HM に更新した。条件(メッシュ Wi-Fi の有料オプション(おうちどこでも WiFi)への申し込みとの抱き合わせ)付きだが、キャンペーンで今なら手数料無料で更新できたからだ(有料オプションは、料金が発生する前に速攻で解約する予定)。 両者の違い: Wi-Fi が ax/ac 対応になった(BL902HW では an まで) NEC(日本)製から Askey(台湾)製になった VDSL モデム一体型から分離型になった 両者の共通点: 有線の WAN/LAN は 1Gbps でギガビットイーサなのは同じ 有料オプションの Wi-Fi は使っていなかったし、今後も使う予定はないので、かなりどうでもいい話(だが、au 側としてはそこが理由で今回のキャンペーンを行ったのだろうけど)。 NEC(日本)製から Askey(台湾)製になったことについては、ファイヤーウォールの初期設定(👉 au ひかり用の HGW のファイアーウォールの初期設定 )など、特に変った点は見られず、この辺りの一貫性はメーカー側よりは au 側にイニシアティブがあるのだろう。ただ、設定項目としては同じでも、かなり画面の外観が変っていて、レイアウトが無駄に大きく(NEC の時は 1 次元的に縦に長いレイアウトだったが、Askey では 2 次元的で横に段組されていて今さら古い時代のホームページみたいなセンス)、行きたい画面に辿り着くまでステップ数が無駄に多い印象。 Wi-Fi は使わないし、かといって使う方の有線の WAN/LAN は前の BL902HW と同じなのに、なぜ、わざわざ更新しようと思ったのか? それはまあ、Wi-Fi が高速化された分、スループット(CPU の処理速度も含めた総合的な性能)がより高速になっているであろうことが期待できるからである。 実は段違い? マンションタイプの VDSL なので、そこがボトルネックにはなってしまうのだが、実は、BL902HW の場合と BL1500HM で大きく違っている部分があり、それは、VDSL モデムと HGW 間の接続が、100Base-TX から 1000Base-T に上がった点である。

au ひかり用の HGW のファイアーウォールの初期設定

au ひかり用の HGW である HGW-BL1500HM について、初期状態でのファイアーウォールの設定について調べてみた(ちなみに、前世代の Aterm BL902HW についても設定内容は同じである)。 WAN 側インターフェース 種別 方向 プロトコル 送信元 送信元ポート 宛先 宛先ポート 優先度 廃棄 out UDP any any any 137-139 1 廃棄 out TCP any any any 137-139 2 廃棄 out UDP any any any 445 3 廃棄 out TCP any any any 445 4 廃棄 out TCP any any any 2049 5 廃棄 out UDP any any any 2049 6 廃棄 out TCP any any any 1243 7 廃棄 out TCP any any any 12345 8 廃棄 out TCP any any any 27374 9 廃棄 out TCP any any any 31785 10 廃棄 out UDP any any any 31789 11 廃棄 out UDP any any any 31791 12 廃棄 in TCP any any any 1243 13 廃棄 in TCP any any any 12345 14 廃棄 in TCP any any any 27374 15 廃棄 in TCP any any any 31785 16 廃棄 in UDP any any any 31789 17 廃棄 in UDP any any any 31791 18 一見複雑なようだが、全て廃棄するルールで、送信元ポートは全て any であり、重複してエントリーされているものがあるので、宛先ポート毎にまとめて考えれば、かなり単純だと思う。独自に宛先ポート毎の表にしてみた: WAN 側インターフェース 宛先ポート 方向 プロトコル 備考 137-139 out TCP/UDP NetBIOS over TCP/IP (Windows) 445 out TCP/UDP Direct Hosting of SMB (Windows) 2049 out T

OpenWrt で uWSGI 環境を整える

イメージ
OpenWrt(23.05)に Web サーバーとして NGINX(SSL 版)を利用し、 uWSGI ミューウィズジー をアプリケーションサーバーとして連携する方法について記す。 前提状況:USB フラッシュドライブ WWW 用のデータを置く場所として USB フラッシュの外部ドライブを用意(👉 OpenWrt での USB フラッシュドライブ )し、さらに Extroot 化(👉 OpenWrt のストレージを Extroot 化する )していることを前提としている。 LuCI もろとも Web サーバー(HTTPd)を SSL 対応 NGINX 化する 以前の OpenWrt 18.x とは飛躍的に進歩して、19.07 以降では SSL 対応版の NGINX が opkg として用意されている(以前は SSL 対応にするためには自前で Linux ソースコードからモジュールをビルドする必要があった)のみならず、NGINX 版 LuCI がセットアップされている opkg すら用意されており、OpenWrt コミュニティの旺盛な活動を感じる(👉 LuCI on other web servers > LuCI on nginx )。 opkg update opkg install luci-ssl-nginx opkg remove luci-ssl luci reboot デフォルトでインストールされている LuCI/uHTTPd の方は不要になるのでアンインストールした。 OpenWrt ルーターで websocket サーバーを運用したいと思ったので、その下準備として、アプリケーションサーバーを整えておく必要がある。Python 系のアプリケーションサーバーとしては uWSGI が定番であり、最近のバージョンでは websocket にもデフォルトで対応しているようなので、まずここでは uWSGI 環境の構築について一通り行いたいと思う。 luci-ssl-nginx luci-ssl-nginx を導入するとデフォルトの uHTTPd 環境の LuCI に代えて、NGINX(かつ SSL)環境の LuCI が動くようになる。この環境において、Lua プログラムである LuCI に NGINX

OpenWrt の uWSGI での websocket は諦めた

イメージ
websocket サーバを運用するために OpenWrt(v23.05.2)の uWSGI をあれこれと強引にカスタムしてみたが、結局、諦めざるをえなかった……。 自分の力量不足だっただけかもしれないし、今後のバージョンアップによる情勢の変化もあるかもしれないので、参考までに何を試して駄目だったのかを記録のために記しておくことにする。 OpenWrt の uWSGI パッケージは SSL 非対応なので websocket が不可 最近の uWSGI 自体は、デフォルトで websocket 対応している(“ The uWSGI websockets implementation is compiled in by default. ”)ようなのだが、OpenWrt で用意された uWSGI のバイナリーイメージは、websocket 非対応でコンパイルされている。この StackOverFlow の回答 にもあるように、OpenWrt 上では uwsgi コマンドの help 表示のオプション一覧に、https 関係のオプションが表示されないので、https 対応状態でコンパイルされていないことが確認できる。 uwsgi --help | grep https websocket プロトコルの規格では、非セキュア通信(ws://)の場合でも、ハンドシェイク確立時にはセキュア通信(https://)を必須としているので、https 対応状態でコンパイルされていることが必要となる。実際に、上述の uWSGI の公式ドキュメントのテスト用のシンプルな エコーサーバーの WSGI プログラム を実行してみると、uWSGI のログに次のようなエラーが記録されていた: you need to build uWSGI with SSL support to use the websocket handshake api function !!! Traceback (most recent call last): File "echo.wsgi", line 5, in application uwsgi.websocket_handshake(env['HTTP_SEC_WEBSOCKET_KEY'],

OpenWrt on WZR-HP-AG300H: Python

イメージ
32MB フラッシュの WZR-HP-AG300H では、Python のフルパッケージ(python3)も問題なくインストールできた。 ただ、結局のところ、フルパッケージは「python3-light + 他の全ての追加パッケージ」に過ぎないので、必要になったら都度該当する追加パッケージを入れればいいだけだと思い、python3-light で入れ直した。 python3 後日、結局、 Extroot 化 でフラッシュ容量を気にする必要がなくなったので、何も気にせずにフルパッケージ(python3)を入れた: opkg update opkg install python3 OpenWrt 23.05.2 での Python のバージョン: python -V Python 3.11.6 python3-pip フルパッケージとはいえ、pip は含まれていないので、さらに python3-pip もインストールする: opkg install python3-pip OpenWrt 22.05.2 での pip のバージョン: pip -V pip 23.2.1 from /usr/lib/python3.11/site-packages/pip (python 3.11) pip 自体の更新: pip install --upgrade pip Requirement already satisfied: pip in /usr/lib/python3.11/site-packages (23.2.1) Collecting pip Obtaining dependency information for pip from https://files.pythonhosted.org/packages/47/6a/453160888fab7c6a432a6e25f8afe6256d0d9f2cbd25971021da6491d899/pip-23.3.1-py3-none-any.whl.metadata Downloading pip-23.3.1-py3-none-any.whl.metadata (3.5 kB) Downloading pip-23.3.1-py3-none-any.whl (2.

OpenWrt のストレージを Extroot 化する

イメージ
(公式ガイド:👉 Extroot configuration ) 今、例として使用している Buffalo WZR-HP-AG300H は、フラッシュストレージのサイズが 32MB であり、Python や gcc などの開発ツールを使おうとするとすぐに容量不足でアプリがインストールできなくなってくる。また、後に判明したことだが、RAM 容量は 128MB で OpenWrt の文書では特に少ないと扱われてはいないものの、pip で Python のモジュールをインストールする処理の中で gcc でのコンパイル作業を伴うような大掛かりな処理が発生すると、128MB では不足して OpenWrt 自体が落ちて(リブートして)しまったことがあるので、Swap メモリーも必要になる。 まず、フラッシュストレージのサイズは、外部 USB ストレージを使い(参考: OpenWrt で外部 USB ストレージを使う )、Extroot 化することで限界を突破できる。そして Swap メモリーについては、Extroot 化したのち、Swap ファイルによって行えばよい。 原理 OpenWrt のファイルシステムは、overlay ファイルシステムという方式が採られている( 参考 )。パーティションが内部的には rootfs (/rom, compressed, not writable) rootfs_data (/overlay, uncompressed, writable) から構成されており、論理的には overlay (/, 未修正のファイルは compressed, writable) システム内に存在する各ファイルを扱うようになっている。 Extroot の場合、上のような元々の overlay パーティションとは別に、もう一つの overlay パーティションを外部ストレージに用意して使う形にする。Extroot 化前の元々の overlay パーティションにあった内容を全部コピーして使うことで、緊急時には Extroot 化前の状態に戻してフォールバックできる余地を残すためである。 必要なツール等の準備等 公式ガイドによると、ツールのインストールに一定の容量が必要なので、フラッシュ容量が 8MB 未

OpenWrt で外部 USB ストレージを使う

イメージ
(公式ガイド:👉 Using storage devices ) 外部 USB ストレージ用のドライバーのインストール opkg update opkg install kmod-usb-storage opkg install usbutils ドライバーは kmod-usb-storage のみ usbutils はコマンド lsusb -t を使って USB メモリーが接続されているかどうかを調べるためのもの(オプショナル) lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/2p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/2p, 480M |__ Port 1: Dev 2, If 0, Class=, Driver=usb-storage, 480M 「Port 1: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 480M」の行が表示されていることにより、外部 USB ストレージ(USB メモリースティック)が挿されているのが確認できる。 外部ドライブとして認識されていることの確認 lsusb コマンドによる確認は、USB デバイスが認識されているかどうかのものである。最終的に、OpenWrt の Linux OS 側が、外部ドライブとして認識しているかどうかは、/dev/sd* としてアタッチされているかで確認できる: ls -l /dev/sd* brw------- 1 root root 8, 0 Nov 16 16:42 /dev/sda brw------- 1 root root 8, 1 Nov 16 16:42 /dev/sda1 今回の例では、/dev/sda が存在することにより、認識されていることが確認できていることになる。 外部ドライブのパーティションが適切に認識されているかの確認 上で外部ドライブが認識されていることが確認できたが、さらに、/dev/sda の論理

OpenWrt での NTP 設定

イメージ
System > System 基本設定 Timezone は Asia/Tokyo にした(Save & Apply)。 時計の同期 NTP サーバー候補 ntp.nict.jp ntp.jst.mfeed.ad.jp 0.openwrt.pool.ntp.org 1.openwrt.pool.ntp.org 2.openwrt.pool.ntp.org 3.openwrt.pool.ntp.org 最後に Save & Apply する。

OpenWrt での SSH 設定

イメージ
Wi-Fi の有効化作業 に次いで、この SSH の有効化作業もインストール後に最優先となる作業だ。 OpenWrt の設定・管理は LuCI だけでは作業が完結させることができず、SSH でログインして CUI 環境で作業しなければならないこともある。そのままでもパスワード認証で SSH にログインできるが、面倒なので、認証用の公開鍵を登録しておいた。 ルーターのパスワード System > Administration で、まだパスワードを設定していない場合にはルーターのパスワードを設定して Save する。 SSH 用の鍵 次に、SSH 用の公開鍵を登録しておく。 クライアントの PC 側で SSH アプリが使うために予め作成して用意してある、公開署名ファイル(*.pub)をドラッグ&ドロップすればいい(コピー&ペーストで入力することも可能)。 鍵は複数登録できる。先程、ドラッグ&ドロップした鍵が表示されていれば設定は ok。 SSH のアクセス制限 また、WAN に直接繋がっておらず LAN 内部からしかアクセスできないルーターならば気にしなくてもいいかもしれないが、(DMZ に設置したり、公開用の WWW サーバーを兼ねている等の)WAN 側からアクセス可能なルーターの場合は、Dropbear の設定で Interface を LAN のものに絞っておくことによって、SSH が LAN 内部からしかアクセスできないようにした方がいいだろう。 一方、公開鍵を登録した場合、パスワード認証の方を無効化することも可能だが、上記設定により LAN 内部からしかアクセスできない状態にしているため、それほどセキュリティを心配する必要がないと考え、(Dropbear の設定で)パスワード認証を無効化するようなことはしていない。むしろ現状では、設定を色々といじっていて公開鍵認証でログインができなくなったりした場合に、パスワードで SSH ログインできないと面倒なことになるというリスクの方が大きいと考えた。 Save & Apply で設定を保存・反映すれば完了。 備考 OpenWrt のルーターを再インストールしたりしてルーター側の SSH のハッシュが変ってしまうと、クライアント PC 側でハ

OpenWrt での Wi-Fi 設定

イメージ
OpenWrt をインストールしたら、まず最初に手を付ける作業が Wi-Fi(Network > Wireless で該当デバイスの設定を Edit)。初期状態では Wi-Fi が無効化されているため、Wi-Fi を有効化しておかないと、有線 LAN で直結していないノート PC(Macbook)から作業できない、というのが個人的には決定的な理由。 設定自体は特に難しくはなく、大まかには 2.4G 帯と 5G 帯それぞれについて、暗号化キーを決め、SSID や周波数チャンネル、出力強度をカスタムしたりする程度。最後に Enable して Save & Apply する流れとなる。 以下では、最初に、作業用の古いノート PC(Linux)から有線 LAN でルーターに接続して設定を行い、5G 帯をアクセスポイント・モードで有効化し、Wi-Fi 経由で MacBook が接続できるようにしてから、(Linux マシンと LAN ケーブルを片付けて)残りの作業を行っている。 5G 帯のアクセスポイント設定 WZR-HP-AG300H の場合では radio1 が 5G 帯(802.11an)となっているので、この Wireless 設定を Edit する。 Device 設定(Advanced Settings) 上半分の Device 設定についてはまず Advanced Settings タブの国設定で「JP - Japan」を選ぶ。 Interface 設定(基本設定) 下半分の Interface 設定については上のスクリーンショットのように Mode を「Access Point」、ESSID を適当に設定する(ここでは「OpenWrt」としている)。 Device 設定(基本設定) 国設定を選んだので、基本設定のタブに戻る(下のスクリーンショット)。 チャンネルは auto にすると、PC(受信端末)側のアクセス可能範囲外のチャンネルが選ばれてしまう場合があるので、確実に接続できるであろうチャンネルを手動で選んでおいた方が無難だろう。出力パワーは最強にしておいた。帯域幅はデフォルトの 20 MHz 幅のまま(40 MHz にすると倍化するが、その分、他の Wi-Fi との干渉もし易くなるため)。