無料の外部から監視するサービスを使って見た!site24x7

前回、事前に調査した4つの監視サービスを検討してみました。この中では格段に操作と設定がしやすかった、site24x7 というサービスを紹介することにします。なぜ、このサービスなのかと言うと4つのサイトに同時にサインアップして実際に使ってみたのですが、説明書も何も見ずに最後まで設定できたからです。

site24x7の有料プランでできること

Site24x7 プラン比較

https://www.site24x7.jp/packs-comparison.html

詳細はこの表の通りですが、無料プランと有料プランの格差がありますよね?有料は7000円〜となっていますが、実は10ドルで出来そうな感じです。後ほど紹介しますね。

さて、無料プランではWEBの死活監視ができ、アラートはメールで可能。ステータスページは有料と違い、グラフが表示できるダッシュボードが公開できない。という内容です。有料と無料では、公開できる情報(グラフ)が違います。実際にこのサイトで公開している監視グラフのページを見てもらうほうが理解が速いかなと思います。

有料プランのグラフ

このサイトの監視状況 有料プラン(1ヶ月ほど無料)

https://hack.gpl.jp/status/

上記リンクは、有料プランが終わったときには見れないのでスクリーンショットをつけておきます。有料プランはカスタマイズしたグラフをダッシュボードに作り、それを共有することが可能です。

いろんなグラフが作れますが、上から「応答時間詳細」でこれは東京リージョンからのものです。その下が、「ページ読み込み時間詳細」です。どちらも、DNSや接続時間など詳細に出ています。

応答時間詳細は、各所にヒゲ状に突出している部分がありますね。また、ページ読込時間を見ると夜間帯は安定していますが、昼間はギザギザしていますね。

次は、「スループット」と「各ロケーションからのSSLハンドシェイク時間」です。200kb/secくらい最高で出ていますが、平均値は120kb/secくらいですね。WEBデータのような小さいデータの転送は速度があまり出ないのかな?

SSLハンドシェイクの時間は、各拠点からのものでこの拠点は世界中から8箇所まで選べます。国内だと東京・長野・大阪が選べました。

最後の図は、「ロケーションごとのページ読み込み時間」です。面白いことに東京よりも、シンガポールからのほうが速そうです。また、意外にもニューヨークやロサンゼルスからも遅くはありません。有料プランは、これ以外の数多くの機能があり全部は紹介しきれませんが、概ね有益だなと感じました。例えば、証明書期限チェックやドメイン更新期限チェックなどあります。面白いなと思ったのは、Tracerouteによるネットワークパス分析です。

ロスからと東京からのホップ数(ざっくり言えば、ルータ越えの数)はそう変わりないみたいw また、深センからはいろんな経路があるんだな! ということがわかりました。

site24x7の10ドルの有料プラン!

これだけ、いろいろな機能ができるなら検討してもいいかもしれません。このサービスの価格は、有料にするとお幾らなんでしょうね?

はい、最初に見てもらった価格表はPro〜7000円から有料とありましたが、なんとスターターという有料プランもあるようです。これは日本円だと毎月払いで2000円、ドル払いだと10ドルと記載されています。

可能かどうかは不明ですが、ドル建ての支払いのほうがお得な気がします。月払い10ドルならアリかもですね。この表中にある、詳細監視というのは、以下のことです。四角枠で囲った部分、これは欲しいですね。

ブラウザーと記載してあるものは、時系列でその時の読込にかかった状態が記録されています。例えば、2020/09/22 2:55 の東京からの読込が10秒ほどかかっている部分があります。

これは、ブラウザーからの読込は以下のようになっていました。

つまり、JSの読込が遅いのか? あるいは、画像の読込が遅いのか? あるいはジェットパックで画像置き換えられたCDNが悪いのか? などが各拠点から時系列でわかってしまいます。すごいですね!

site24x7の無料プランは・・・?

無料プランでは、有料プランでできるダッシュボードのグラフを共有することはできませんでした。グラフが見たければ、管理パネルにログインしていれば以下のように見えます。

計測地点は、シアトル(US)からのみです。試験を行う間隔は10分となりそれ以下はできません。死活監視のみとなり、無料プランでグラフはこれ以外は登録できないようです。シアトルからの監視ですが、まぁ十分でしょうか。有料プランで出来たブラウザからの読込はサポートしていません。
 なお、グラフの共有(ダッシュボード)はできず、公開できるのは、ステータスページで、StatusIQ というサービスを使って行えるようです。これも実際に見てもらったほうが速いです。以下に、このサイトの状態を貼ってあります。

NetWork Status FreePlan

https://hack.gpl.jp/network-status-freeplan/

グラフは出すことができず、サービスが生きているか死んでいるかを表示するものみたいですね。

なお、WEBサイトを登録するときの画面は以下のようになります。

あとがき

最初、WEBを監視するだけだと思っていましたが関連するサービスがたくさんあって、このサービスは今後検討してみたいなと思いました。しかし、スマホサーバを外部から10ドル払って監視する価値がどのくらいあるのかまだ未知数です。

監視できる事は豊富で、コスパ的に見れば、類似サービスの中では突出しているようにも思えます。多少味付けは違いますが、マカレルよりいい機能があるかな!と感じています。でも、マカレルはLINE通知があるので好きなんです。

site24x7で、まだ試していないのはLinuxのリソースを監視するサービスです。これもエージェントがtermux で動作するのかどうかわかりません。Termuxネイティブ環境は何かと制約があるのです。もし、うまくいったら、また続報があるかもです。

このブログは、スマートフォンの中に引越ししました!

えっ? と思われた方もいるかもしれませんが、このジャンクハックブログは引越ししました。それもスマートフォンの中にいます!

なんで、引越しをしたの?

はい、結論から言いますと今まで使っていたWordPress.comのパーソナルプランの料金が上がったからです。月額400円から500円で年間一括6000円となります。まぁ、100円くらい良いんですがなんとなく、年間で6000円かーと思いましてね。

今から2年ほど前、 WordPress.com 上のパーソナルプランっていうところを使い始めていました。

Linuxエンジニアがサーバを作らず結局、WordPress.com の有料プランに入ることにしたよ

https://hack.gpl.jp/2018/10/17/20181017/

レンタルサーバはたくさんあるんですが、WordPressのオートマチック(Automattic Inc.)がやっているサービスです。ビジネスプランまで契約しようかと当初は思っていましたが、このブログがそんな人気が出るわけでもなくチマチマとパーソナルプラン(当初月額400円)でやっていました。

更新期限が10月中旬ということもあって、2、3ヵ月前から自宅サーバを検討していました。ご興味があるかたは、以下から検索してね。(検索システムも速くしてあります)

Termuxとか、自宅サーバ関連

https://hack.gpl.jp/?s=Termux+自宅サーバ

月に500円、年間6000円支払うなら電気代に払って自宅サーバでブログを楽しみたいな! と思ったのであります。

スマホの中に引越しとは?

 はい、このブログはスマホの中から今見ているみなさんに提供しているんです。信じられませんよね!w

これは、Termux というAndroidアプリがありまして、それがつまりは Linuxなんですよね。正確にいえば、Android自体がLinux Kernelを採用したOSなんで、その上でLinux環境を構築するアプリなんです。

で、その環境にWEBサーバやら、データベースサーバやらを作り、WordPressを動作させているんです。回線は、普通のNTTの光回線に InterLinkのIP固定サービスでやっております。いわゆる自宅サーバというやつですね。

あとがき

これで、Pluginもテーマファイルもやりたい放題です。

ぴー
ぴー

やっぱりWordPressはカスタマイズしたいよね!

とりあず、今日は引越ししたよ! というネタをあげたかったので以上にします。またねー。

WordPressのコマンドラインツール、wp-cliを使ってみたら便利だった!

存在は知っていましたが使ってみると便利でした。

WP-CLI は WordPress を管理するためのコマンドラインインターフェースです。

https://wp-cli.org/ja/

つまり、こんなことが出来ます。

$ wp plugin list
+----------------------------------------+----------+--------+---------+
| name                                   | status   | update | version |
+----------------------------------------+----------+--------+---------+
| akismet                                | active   | none   | 4.1.6   |
| amp                                    | active   | none   | 2.0.1   |
| autoptimize                            | active   | none   | 2.7.7   |
| jetpack                                | active   | none   | 8.9     |
| jquery-manager                         | active   | none   | 1.10.6  |
| line-auto-post                         | active   | none   | 1.0.1   |
| litespeed-cache                        | inactive | none   | 3.4.2   |
| multiple-domain-mapping-on-single-site | active   | none   | 1.0.4   |
| ultimate-addons-for-gutenberg          | active   | none   | 1.17.0  |
| word-balloon                           | active   | none   | 4.12.0  |
| wordpress-importer                     | active   | none   | 0.7     |
| wpfront-scroll-top                     | active   | none   | 2.0.2   |
| duplicate-post                         | active   | none   | 3.2.5   |
+----------------------------------------+----------+--------+---------+

シェルが使える環境だったら使わないと、もったいないですね!

インストール抜粋

Termux環境でも使えるか試してみました。要件はさきほどのリンクに記載してありますがPHP5.4〜とUNIX系の環境だそうです。WordPressは、3.7〜。

ステップ1

適当なディレクトリを作っておきます。例では、home直下にtmpディレクトリを作りそこで作業します。まず、wp-cli.phar をダウンロードします。

cd
mkdir tmp
cd tmp
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

ステップ2

一応、確認です。

php wp-cli.phar --info

以下のような感じで出力されました。

OS:	Linux 4.14.141+ #1 SMP PREEMPT Wed May 6 10:13:36 CST 2020 aarch64
Shell:	/data/data/com.termux/files/usr/bin/bash
PHP binary:	/data/data/com.termux/files/usr/bin/php
PHP version:	7.4.10
php.ini used:	/data/data/com.termux/files/usr/lib/php.ini
WP-CLI root dir:	phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	/data/data/com.termux/files/home/tmp
WP-CLI packages dir:	
WP-CLI global config:	
WP-CLI project config:	
WP-CLI version:	2.4.0

ステップ3

実行権限をつけて、パスが見えるところに移動。

chmod +x wp-cli.phar
mv wp-cli.phar $PREFIX/bin/wp
::(ちゃんと見えるか確認)
$ which wp
/data/data/com.termux/files/usr/bin/wp

ステップ4

タブ補完できるようにしておきます。

cd
mkdir bin
cd bin
wget https://raw.githubusercontent.com/wp-cli/wp-cli/v2.4.0/utils/wp-completion.bash

vi ~/.bash_profile

以下を追記

source /data/data/com.termux/files/home/bin/wp-completion.bash

反映しておきます。

source ~/.bash_profile

確認

$ wp ※ここでタブキーを押してみると以下が表示されます。
cache              cron               help               menu               post-type          shell              theme 
cap                db                 i18n               network            rewrite            sidebar            transient 
cli                embed              import             option             role               site               user 
comment            eval               language           package            scaffold           super-admin        widget 
config             eval-file          maintenance-mode   plugin             search-replace     taxonomy           
core               export             media              post               server             term 

ステップ5

実際に使ってみましょう。WordPressのプラグインがあるディレクトリに移動します。以下は、プラグインの一覧を出すコマンドです。

$ wp plugin list
+----------------------------------------+----------+--------+---------+
| name                                   | status   | update | version |
+----------------------------------------+----------+--------+---------+
| akismet                                | active   | none   | 4.1.6   |
| amp                                    | active   | none   | 2.0.1   |
| autoptimize                            | active   | none   | 2.7.7   |
| jetpack                                | active   | none   | 8.9     |
| jquery-manager                         | active   | none   | 1.10.6  |
| line-auto-post                         | active   | none   | 1.0.1   |
| litespeed-cache                        | inactive | none   | 3.4.2   |
| multiple-domain-mapping-on-single-site | active   | none   | 1.0.4   |
| ultimate-addons-for-gutenberg          | active   | none   | 1.17.0  |
| word-balloon                           | active   | none   | 4.12.0  |
| wordpress-importer                     | active   | none   | 0.7     |
| wpfront-scroll-top                     | active   | none   | 2.0.2   |
| duplicate-post                         | active   | none   | 3.2.5   |
+----------------------------------------+----------+--------+---------+

お〜! これは便利ですね。いろんな使い方があるので、以下をみてみてくださいね。

WP-CLI Quick Start

https://make.wordpress.org/cli/handbook/guides/quick-start/

いろいろ便利な使い方があると思うので、備忘録:〜 で紹介していきたいと思います。

あとがき

やっぱり自宅サーバでWordPressをLinuxにホスティングしてみると、面白い発見がいろいろありますね。今まで、使わなかったいろんな方法があると夢が膨らみます。例えば、テスト環境なんかも簡単に作れそうですね。あるいは、差分を取って slack に投稿しておけば自動アップデートで何がどうなったかもわかると思います。アイデア次第ですね。

Termuxネイティブ環境でacme-nginxを使いワイルドカード証明書を自動取得!

前回、別記事にすると言っていた件です。

Termux環境で動作するLet’s Encryptのワイルドカードドメインに対応した自動化ツールを探せ!

https://hack.gpl.jp/2020/09/11/wildcard-domain-acme/

今日のネタは、Termuxネイティブ環境で acme-nginx というPythonで、作られた自動化ツールで Let’s Encrypt のワイルドカードドメイン証明書を取得します。さぁうまく出来るでしょうか? ちなみに、ワイルドカード証明書とは、以下のようなことを言います。

ワイルドカード証明書とは

「*.example.jp」のように、コモンネームの一番左のラベルにアスタリスク(*)を指定したサーバー証明書です。

ワイルドカード証明書は「www.example.jp」「login.example.jp」「member.example.jp」のように、アスタリスクと同一階層のサブドメインのみが異なるすべてのサーバーにインストールできます。
また、JPRSの提供するワイルドカード証明書なら、「*.example.jp」の証明書を「example.jp」のようにアスタリスク(*)を除いたホスト名のサーバーでも利用できます。

https://jprs.jp/pubcert/about/wildcard/

では作ってみましょう。acme-nginx はもう入れてあるものとします。DNSはデジタルオーシャンに変更して、APIトークンを取得してあります。

ステップ1

適当な証明証を入れておくディレクトリを作っておきます。例では、example.jp というドメインで説明しています。

cd
mkdir -p ssl/example.jp
cd ssl/example.jp

ステップ2

アカウントキーと、ドメインキーを作成します。

openssl genrsa 4096 > account.key
openssl genrsa 4096 > example.jp.key

ステップ3

digitaloceanのトークンを環境変数に入れておきます。

export API_TOKEN=digitaloceanのトークン

ステップ4

証明書を発行します。WEBの認証はないので便利ですね。パスは、Termuxxの環境変数 $PREFIX に置き換えたほうが見やすいかもですね。

acme-nginx \
	--no-reload-nginx \
	-k /data/data/com.termux/files/home/ssl/example.jp/account.key \
	--dns-provider digitalocean \
	--domain-private-key /data/data/com.termux/files/home/ssl/example.jp/example.jp.key \
	-o /data/data/com.termux/files/home/ssl/example.jp/example.jp.crt \
	-d '*.example.jp' -d 'example.jp'

ドメインの指定は、*.example.jp と example.jp を指定します。そうしないと、example.jp でのドメインだけのアクセスで証明書が無効となります。
 実際のログは(ドメイン名は置き換えていますが)以下のようになります。

2020-09-13 02:45:40,777 - INFO - trying to create account key /data/data/com.termux/files/home/ssl/example.jp/account.key
2020-09-13 02:45:41,727 - INFO - trying to register acmev2 account
2020-09-13 02:45:43,612 - INFO - already registered
2020-09-13 02:45:43,613 - INFO - trying to create domain key
2020-09-13 02:45:43,615 - INFO - acmev2 dns challenge
2020-09-13 02:45:43,615 - INFO - preparing new order
2020-09-13 02:45:46,648 - INFO - order created
2020-09-13 02:45:47,644 - INFO - verifying domain example.jp
2020-09-13 02:45:47,670 - INFO - creating TXT dns record _acme-challenge.example.jp IN TXT uWmLyGGgK1Jyj(省略)RHo-A5TUKBAac
2020-09-13 02:45:50,642 - INFO - asking acme server to verify challenge
2020-09-13 02:45:52,486 - INFO - waiting for example.jp challenge verification
2020-09-13 02:45:53,239 - INFO - example.jp verified!
2020-09-13 02:45:53,240 - INFO - delete dns record
2020-09-13 02:45:56,793 - INFO - verifying domain example.jp
2020-09-13 02:45:56,817 - INFO - creating TXT dns record _acme-challenge.example.jp IN TXT hP2bwoYASAQYL(省略)VkiKGDupZxfw0
2020-09-13 02:45:59,551 - INFO - asking acme server to verify challenge
2020-09-13 02:46:02,005 - INFO - waiting for example.jp challenge verification
2020-09-13 02:46:02,884 - INFO - example.jp verified!
2020-09-13 02:46:02,885 - INFO - delete dns record
2020-09-13 02:46:05,385 - INFO - signing certificate
2020-09-13 02:46:08,480 - INFO - certificate signed!
2020-09-13 02:46:08,480 - INFO - downloading certificate
2020-09-13 02:46:09,472 - INFO - writing result file in /data/data/com.termux/files/home/ssl/example.jp/example.jp.crt

30秒くらいで、完了していますね。dnsにテキストレコードを書いている部分が2回あります。ちゃんと認証が通ればテキストレコードは削除していますね。これは便利!作者に感謝です!

ステップ4

あとは、キーと証明書をnginxに設定して再起動しておきます。

・Key
 /data/data/com.termux/files/home/ssl/example.jp/example.jp.key

・CRT
 /data/data/com.termux/files/home/ssl/example.jp/example.jp.crt

あとは、実際のクライアントから確認してみます。

おー、鍵マークがかかっていますね。うまくできているようです! 今度は、curlで https://gpl.jp にアクセスできるか確認してみます。WordPressには、このドメインはマッピングしていないので、静的ファイルが置いてあるURLに対してアクセスしてみます。curlクライアントはリモートのMacからです。

$ curl -Iv https://gpl.jp/license.txt
*   Trying 116.58.181.140...
* TCP_NODELAY set
* Connected to gpl.jp (116.58.181.140) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.gpl.jp
*  start date: Sep 12 16:46:12 2020 GMT
*  expire date: Dec 11 16:46:12 2020 GMT
*  subjectAltName: host "gpl.jp" matched cert's "gpl.jp"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fd360002000)
> HEAD /license.txt HTTP/2
> Host: gpl.jp
> User-Agent: curl/7.54.0
> Accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200 
HTTP/2 200 
< server: nginx
server: nginx
< date: Sat, 12 Sep 2020 18:09:29 GMT
date: Sat, 12 Sep 2020 18:09:29 GMT
< content-type: text/plain; charset=utf-8
content-type: text/plain; charset=utf-8
< content-length: 19915
content-length: 19915
< last-modified: Wed, 12 Feb 2020 11:54:05 GMT
last-modified: Wed, 12 Feb 2020 11:54:05 GMT
< vary: Accept-Encoding
vary: Accept-Encoding
< etag: "5e43e75d-4dcb"
etag: "5e43e75d-4dcb"
< strict-transport-security: max-age=15552000
strict-transport-security: max-age=15552000
< x-xss-protection: 1; mode=block
x-xss-protection: 1; mode=block
< x-frame-options: DENY
x-frame-options: DENY
< x-frame-options: SAMEORIGIN
x-frame-options: SAMEORIGIN
< x-frame-options: ALLOW-FROM https://www.youtube.com https://www.wordpress.com
x-frame-options: ALLOW-FROM https://www.youtube.com https://www.wordpress.com
< x-content-type-options: nosniff
x-content-type-options: nosniff
< content-security-policy: default-src * 'self' data: 'unsafe-inline' 'unsafe-eval' ;
content-security-policy: default-src * 'self' data: 'unsafe-inline' 'unsafe-eval' ;
< referrer-policy: strict-origin
referrer-policy: strict-origin
< permissions-policy: fullscreen=() geolocation=()
permissions-policy: fullscreen=() geolocation=()
< x-hacker: Hello. :-)
x-hacker: Hello. :-)
< accept-ranges: bytes
accept-ranges: bytes

< 
* Connection #0 to host gpl.jp left intact

ちょっと長いですが、途中「SSL certificate verify ok.」が出ていますね。接続は、TLS2 でHTTP/2 プロトコルになっていますね。これで当初の目的は達成できました! チェックサイトでは、A+判定出ていました。問題なさそうですね。

SSL Server Test (Qualys SSL Labs)

https://www.ssllabs.com/ssltest/

あとは、自動実行すればいいんですが termux の限られたリソースの中で cronjobを回して、ログを出し、何かあったらメールするっていうのをやるべきか、その他の方法を採用するかで迷っています。

 そもそも、termux でcronjobはちゃんと動くか確認しておかないとです。なんたって、androidシステム上で動いているわけですから。Dozeモードの影響とかそういうのは大丈夫なのか確認しないとです。

定期実行しておく

手動で実行していましたが、Site24x7 の監視サービスからアラートが飛んでくるので(これはありがたい機能ですが)cronに登録しておきました。しばらく様子を見てみます。

# update SSL . Run at 5:30 on the 1st and 15th of every month
30 5 1,15 * * /data/data/com.termux/files/home/ssl/gpl.jp/renew-cert.sh | $PREFIX/bin/msmtp junkhack@gpl.jp

あとがき

気になることはいろいろありますが、そろそろデータの引っ越しをやりますかね。 WordPress.com から速めに引っ越しして、新環境で記事を書いて行きたいです。

Termuxでのスマホサーバ、SSLアクセスでも耐えれそうかな?

TermuxでのLet’s Encrypt SSL化がやっとできたのでメモっておきます!

まず心配だったのは、SSLアクセスしたときのレスポンスですが、まぁ我慢どころといった感じでしょうか。

非SSLと比べると、接続には少し時間がかかっています。実際にスマホからSIM通信してみると、若干ワンテンポ送れる感じです。

証明書は、Let’s Encrypt でこれは3ヶ月ごとに更新しないといけないので自動化が必須となってきます。手動でやってもいいのですが、絶対面倒になって証明書を切らしてしまうので。で、自動化には certbot のスクリプトが有名なんですが、これは依存関係などがあったり、root (スクリプト中で su したり)が必須とかで、Termux では動きません。動かす方法もあるのでしょうが、世の中にはもっと小さな自動化ツールがありました!

acme-tiny っていうPython製の自動化PGです。pythonとopenssl があれば動くそうです。pip で入れて見ます。

ステップ1 pythonを入れる

pythonが必要なので、なければ入れます。今回は、もう入れてあるので次です。

$ dpkg-query -l | grep python
ii  python             3.8.5             aarch64      Python 3 programming language intended to enable clear programs

$ pkg install python -y

ステップ2 PIPで acme-tiny を入れる

$ pip install acme-tiny

pip が古いとか言われたら、以下で。

$ python3 -m pip install --upgrade pip

以下に入るようです。

$ which acme-tiny
/data/data/com.termux/files/usr/bin/acme-tiny

$ find $PREFIX -name *acme*
/data/data/com.termux/files/usr/bin/acme-tiny
/data/data/com.termux/files/usr/lib/python3.8/site-packages/acme_tiny.py
/data/data/com.termux/files/usr/lib/python3.8/site-packages/__pycache__/acme_tiny.cpython-38.pyc
/data/data/com.termux/files/usr/lib/python3.8/site-packages/acme_tiny-4.1.0.dist-info

ステップ3 Let’s Encryptアカウントの秘密鍵

どこか適当な場所にディレクトリを作って、そこで作業します。

$ cd
$ mkdir ssl
$ cd ssl
$ openssl genrsa 4096 > account.key

ステップ4 ドメイン用の秘密鍵を作成

ドメイン名は、読み替えてみてください。

$ openssl genrsa 4096 > www.example.jp.key

ステップ5 ドメインの証明書署名要求(CSR)を作成

シングルドメイン
$ openssl req -new -sha256 -key www.example.jp.key -subj "/CN=www.example.jp" > www.example.jp.csr

サブドメインのワイルドカード証明書はどうやって作るのかまだ知りません。課題です。

ステップ6 証明書に署名してもらう

$ mkdir -p /data/data/com.termux/files/home/【WEBROOT】/.well-known/acme-challenge/

$ acme-tiny --disable-check --account-key ./account.key --csr ./www.example.jp.csr --acme-dir /data/data/com.termux/files/home/【WEBROOT】/.well-known/acme-challenge/ > ./www.example.jp.crt

ここで、–disable-check を入れていますがこれは先日記載したUターンNAT(ヘアピンNAT)ができないため、自分自身のWEBにアクセスできないからです。そういう問題がない場合は、削除してください。

こんな感じで出来ると思います。crtができない場合は何かが悪いです。ログにヒントがありますので慌てず、探りましょう!

.
├── account.key
├── www.example.jp.crt 署名された証明書
├── www.example.jp.csr
└──  www.example.jp.key 鍵

.WEBROOT
    └── .well-known
        └── acme-challenge
           └──xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

ステップ7 nginxの設定

設定ファイル抜粋。ルータとtermuxはポート転送しています。

http {
::(略)
    ssl_session_timeout 30m;
    ssl_session_cache   shared:SSL:10m;
    ssl_session_tickets off;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256;
::(略)
server {
     listen      8443;
::(略)
     ssl_certificate     /data/data/com.termux/files/home/ssl/www.example.jp.crt;
     ssl_certificate_key /data/data/com.termux/files/home/ssl/www.example.jp.key;
::(略)

なぜか、location で、.well-known/acme-challenge/ の場所が以下のように指定したら、アクセスできませんでした。なので、これは消して、実際のWEBROOTに/.well-known/acme-challenge/を作りました。

location ^~ /.well-known/acme-challenge/ {
    root /data/data/com.termux/files/home/【acme-challengeがあるパス】;
}
location = /.well-known/acme-challenge/ {
    return 404;
}

以下の評価が先にマッチしてしまって、これも一時的に消しました。

location ~ /\. {
    return 404;
}

nginxの設定、不慣れなんでどこかおかしいんでしょうね。

ワイルドカード証明書が取得できるようにしたら、cronに定期実行してもらおうと思いますが、もう少しいろいろ試してみてからにします。

SSLのチェックも良さそうです。

PageSpeed Insightsのモバイルのスコアも良さそうです。

PC版は100点出ました!

ということで、Termux のnginxとphp-fpmで無料の証明書を入れて速度的にも問題なさそうかなという感じです。

あとは、今回出たもろもろの問題をクリアにしてマクロを定期実行できればOKです。ぼちぼちやっていきます。でも、10月はじめまでには、移行完了しないといけませんので、それまでにはCDN問題もクリアして試してみたいです。

良くわからんこと!

・nginxのlocationのマッチはどうなってるのか?

・ワイルドカード証明書はどうやって作るのか?CSRの作り方っぽいが?

・リバースプロキシーでSSLアクセスするにはどうしたら?

ポートフォワードの経路で、Uターン NATとかヘアピンNATが使えないルータの場合のあれこれ

先日、以下のように困っていました。

Termuxのapache2+php+mariadbのチューニング前のwordpressの速度とか
::
まぁ、速度的なことより困っていることがあります。それは、ローカルのマシンから、termux上で動作しているwordpressにグローバルIPでアクセスできないことです。この場合、ルータの管理画面にアクセスしちゃうんで、どうしようかなと。こういうのなんていうんでしたっけか? とにかく、今の拠点のルータ(PR-400KI)は、内側ネットワークから外側のグローバルアドレスにアクセスしたものを、変換(最終的にサーバのプライベートアドレスに変換)してくれないのです。

これ、言葉で書くとよくわかりませんが、どんな問題かというと以下のようになります。

こういう表現として、UターンNATとか、ヘアピンNATとか呼ぶようです。これが出来るルータとできないルータがあり、NTTから借りているルータではできませんでした。いろいろ解決方法があるとは思いますが、一番簡単なのは、クライアントPCをVPNで外部のネットワークからアクセスさせる方法です。つくば大学のVPN Gateを使えば簡単に解決できますが、インターネット経路となりいまいちです。プレイベート間の通信なのでリバースプロキシを経由する方法が良さそうです。ポート変換がなければ、hosts を書き換えるか、内部DNSを立ち上げればいいのですが、今回の場合は、スマホサーバで提供しているポートは8080です。80と8080を対応付ける必要があり、hosts だけでは無理なので、リバースプロキシを通して、アクセスしてみることにします。

 ブログの更新は、クライアントPCからしか行わないのでこのPC中に設置してみました。もちろんリバースプロキシを分離して、内部DNSを立ち上げれば、理論上は何台でも違うポートとIPを使って好きなドメインでアクセスできます。そのうち、IoTデバイスとか、スマホサーバでクラスタリングとかロードバランサーとか使い出したら内部DNSやリバースプロキシは欲しくなってくるのですが、それはその時にまた考えることにします。

 ということで、クライアントにリバースプロキシを作って、スマホサーバの8080ポートで提供されているWordPress にアクセスしてみることにします。幸い、クライアントはMacなので nginx とかで簡単に作れます。

Macでリバースプロキシをnginxで作る

経路のイメージはこんな感じでしょうか。まずは、nginx を入れます。

$ brew install nginx

起動と再起動、停止は以下のようにします。

・起動
$ sudo nginx
・再起動
$ sudo nginx -s reload
・停止
$ sudo nginx -s stop

設定を以下のように書き換えます。server_nameや、proxy_passのIPやポートなど読み替えて書き換えてみてください。

/usr/local/etc/nginx/nginx.conf
::
worker_processes 1;
error_log /usr/local/var/log/nginx/error.log;

events {
  worker_connections  1024;
}

http {
  # This should be in the same directory as this conf
  # e.g. /usr/local/etc/nginx
  include       mime.types;
  default_type  application/octet-stream;
  
  # Note this log_format is named 'main', and is used with the access log below
  log_format   main '$remote_addr - $remote_user [$time_local]  $status '
    '"$request" $body_bytes_sent "$http_referer" '
    '"$http_user_agent" "$http_x_forwarded_for"';

  sendfile        on;
  keepalive_timeout  65;

  # Without this I got this error: 'upstream sent too big header
  # while reading response header from upstream'
  proxy_buffer_size   128k;
  proxy_buffers   4 256k;
  proxy_busy_buffers_size   256k;

  server {
      listen 80;
      server_name jh.gpl.jp;
      proxy_set_header    Host    $host;
      proxy_set_header    X-Real-IP    $remote_addr;
      proxy_set_header    X-Forwarded-Host       $host;
      proxy_set_header    X-Forwarded-Server    $http_host;
      proxy_set_header    X-Forwarded-For    $proxy_add_x_forwarded_for;
      access_log /usr/local/var/log/nginx/reverse-proxy.access.log  main;

      location / {
          proxy_pass         http://192.168.1.38:8080;
      }
  }
}

hosts を書き換えます。

$ cat /etc/hosts
::
127.0.0.1 jh.gpl.jp

nginx を再起動して、ブラウザでドメインに対してアクセスすればOKです。

ちなみに、wp-config.php に以下を追記すると、接続元が192.168.1.26 の時だけWordPress のドメイン名が www.gpl.jp に書き換わります。もちろん、アクセスするクライアントのhosts は書き換える必要があります。

if( $_SERVER['REMOTE_ADDR'] == '192.168.1.26' ){
    define('WP_HOME','http://www.gpl.jp');
    define('WP_SITEURL','http://www.gpl.jp');
}

ということで、macos で簡単にリバースプロキシーを立ち上げて、内部ネットワークの違うポートで提供されているWordPress にアクセスする方法でした。

Lan内部のスマホからもアクセスしたい場合は、内部DNSをDHCPで配布して、リバースプロキシーと対応付けしないとだめですので、完璧を求めるならそれらが必要です。そのうち、作る機会があれば紹介したいなと思います。