Ubuntu22.04 他のサーバーでWebサービスを提供する

ネットワーク構成

元々、example.netというWebサーバーを運営していた。
このサーバーには幾つかのサービスを導入していて、サブドメインでサービスを切り替えていた。

ある日、宅内のサービスの増加でユーザー管理が面倒になり、Samba ad dcでドメインコントローラーの運営をはじめた。
アクティブディレクトリがどんなものなのかを知りたい、という好奇心もあった。
管理するドメインをexample.netとしたので、結果としてこのURLをドメインコントローラーに取られてしまった。

とはいえ、ドメインコントローラーはできるだけ軽い状態にしておきたかったので、Webサーバーを新設して各サービスをそこに移動させた。

┌───────┐
│ルーター(1)   │
│192.168.110.1 │
└───┬───┘
　　　　├─────────────┬─────────────┐
┌───┴────┐　　┌─────┴─────┐　　┌────┴────┐
│  Webサーバー   │　　│ドメインコントローラー│　　│クライアント      │
│www.example.net │　　│example.net           │　　│other.example.net │
│192.168.110.80  │　　│192.168.110.200       │　　│192.168.110.7     │
└────────┘　　└───────────┘　　└─────────┘

このタイミングで、ユーザーの全員に「新しいWebサーバーに移行してね！」と依頼することも考えたが、以下の理由でちょっと厄介だった。

• 宅内サービスは家族＋親戚、LAN＋Internetで利用している。
  彼らはITに詳しくないので、設定変更がちゃんとできないかもしれない。フォローが大変。
• 運営しているサービスの中には、ドメイン変更がちょっと面倒なものがある(主にWordPress)。

仕方がないので、ドメインコントローラーにApacheを入れて、Webサーバーにリバースプロキシしている。

問題点

とりあえずは動いているけれど、LANから各サービスにアクセスするとき、必ずドメインコントローラーを通過するという、すっきりしない構成になっている。

• Webサーバーから見ると、LANからの要求はすべてドメインコントローラーからの要求に見える。
  • どのクライアントからの要求なのかを、IPアドレスで見分けることができない。
  • クライアント証明書のやりとりができない。
• LANからWebサーバーにアクセスすると、ドメインコントローラーに負荷が掛かる。
  同じ仮想ホストの上で動いてはいるものの、通信速度はだいぶ遅くなる。

設定をしっかり学習すれば、もっとできることがあるだろう。

NAT

NATの効果

ドメインコントローラーにくるHTTPとHTTPSの要求を、IptablesでそのままWebサーバーに流す。

Iptablesについては、こちらで日本語訳を公開してくれている。
Stray Penguin – Linux Memo – / Iptablesチュートリアル 日本語訳

ドメインコントローラーではUFWを使っているので、UFWで設定していく。

パケット転送を有効化。

/etc/ufw/sysctl.conf

# Uncomment this to allow this host to route packets between interfaces
net/ipv4/ip_forward=1

※この3行を有効行にする。

設定を反映して、結果を確認。

$ sudo ufw reload
$ cat /proc/sys/net/ipv4/ip_forward
1

転送を許可する。

/etc/default/ufw

#DEFAULT_FORWARD_POLICY="DROP"
DEFAULT_FORWARD_POLICY="ACCEPT"

設定を反映し、結果を確認。

$ sudo ufw reload
$ sudo iptables -t filter --list-rules
-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
...

NATを設定する。
ドメインコントローラーはルーターではないので、DNATとSNATをする。
SNATをしないと、Webサーバーから戻ってくるパケットが直接クライアントに飛んで行ってしまう。クライアントは、Webサーバーから突然送りつけられたパケットがなんなのか分からずに破棄するので、通信が成立しない。

/etc/ufw/before.rules

# NAT rules
*nat
:PREROUTING ACCEPT
:POSTROUTING ACCEPT
-F
-A PREROUTING -s 192.168.110.0/24 -p tcp -m multiport --dport 80,443 -j DNAT --to-destination 192.168.110.80
-A POSTROUTING -p tcp -d 192.168.110.80 -m multiport --dport 80,443 -j SNAT --to-source 192.168.110.200
COMMIT

※最後に追記

設定を反映し、結果を確認。

$ sudo ufw reload
$ sudo iptables -t nat --list-rules
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A PREROUTING -s 192.168.110.0/24 -p tcp -m multiport --dports 80,443 -j DNAT --to-destination 192.168.110.80
-A POSTROUTING -d 192.168.110.80/32 -p tcp -m multiport --dports 80,443 -j SNAT --to-source 192.168.110.200

これで、クライアントとWebサーバーは、ドメインコントローラーを通して通信することができる。
クライアント証明書を提示することもできるようになる。
ただし、Webサーバーからみると、すべての要求がドメインコントローラーから来るように見える(そのようなログが残る)。

試しに、Webサーバーのルーティングテーブルを変えてみたところ、SNATなしで通信が確立した。
もし、この方向で本格的に進めるならば、別のネットワークセグメントを作り、そこにWebサーバーを置いてルーティングするのが良さそうだ。

リバースプロキシ

リバースプロキシの効果

リバースプロキシを頑張るときには、きっと参照したくなるページをメモ。
Apache Module mod_ssl
Apache Module mod_authz_core
Expressions in Apache HTTP Server

さて、リバースプロキシ構成にした場合、デフォルトだと

• ドメインコントローラーのApacheは、要求したクライアントのIPアドレスをログに残す。
• サービス側のApacheは、ドメインコントローラーをログに残す。

という動作をする。

domain controller:/etc/apache2/sites-available/proxy.conf

SSLProxyEngine On
ProxyPreserveHost On
ProxyPass        / https://192.168.110.80/
ProxyPassReverse / https://192.168.110.80/

※実際にはもう少し複雑に書いているところもあるが、本題ではないので省略している。

クライアントのIPアドレス

WebサーバーのApacheで、要求したクライアントのIPアドレスを記録するためには、X-Forwarded-Forをログ出力すれば良かった。
stack overflow / ProxyPreserveHost seems to do little for me

web server:/etc/apache2/sites-available/service.conf

LogFormat "%h %{X-Forwarded-For}i %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined2
CustomLog ${APACHE_LOG_DIR}/service_access.log combined2

※<VirtualHost *:443>～</VirtualHost>の間にこれを入れておいた。

そうすると、このようなログが残る。

web server:/var/log/apache2/service_access.log

Reverse Proxy: 192.168.110.200 192.168.110.7 - - [29/Jul/2023:07:55:28 +0900] "GET...
Direct       : 192.168.110.7 - - - [28/Jul/2023:04:31:47 +0900] "GET...

直接アクセスされたときには、X-Forwarded-Forは付かないので、ホストとX-Forwarded-Forの両方をログに出力する。
出力量が増えるけれども、問題を調べる時には良いのではないだろうか。

クライアント証明書

リバースプロキシなので、ドメインコントローラーが2つの接続を使ってコンテンツを流通させている。

[クライアント]－(接続1)－[ドメインコントローラーのApache]－(接続2)－[WebサーバーのApache]

この場合、WebサーバーのApacheがクライアント証明書の提示を求めていても、それはドメインコントローラーに対して求めているのであって、クライアントにそれを求めることはできない。

Nginxには、それができる方法が用意されているようだ。
server fault / Add Client certificate when acting as reverse proxy (Apache/NGINX)

ApacheでもAJPであれば、クライアントからサーバーにクライアント証明書を渡すような通信ができるらしい。
しかし、AJPって過去にTOMCATのシステムに接続させるときに使った記憶があるけれど、どうやらそれ専用のようなので、今回のケースでは使えない。
server fault / Apache not Forwarding Client x509 Certificate to Tomcat via mod_proxy

そのため、Apacheでは以下の方法でWebサーバーに情報を渡すようだ。

• ドメインコントローラーは、クライアントに証明書の提示を求める。
  提示された証明書を、Webサーバーの代わりにしっかりと検証する。
• クライアント証明書に問題がなければ、提示されたクライアント証明書、あるいは、クライアント証明書の中の値をWebサーバーに渡す。
  情報を渡すためには、リクエストヘッダーを使う。

クライアント－ドメインコントローラー接続

クライアントが提示してくるクライアント証明書は、ドメインコントローラーでしっかり検証する必要がある。

domain controller:/etc/apache2/sites-available/proxy.conf

SSLProtocol all -SSLv2 -SSLv3 -TLSv1.3
SSLCACertificateFile    /etc/ssl/private/ca.crt
SSLCARevocationFile     /etc/ssl/private/ca.crl
SSLCARevocationCheck    leaf
SSLVerifyClient require
SSLVerifyDepth 1

ここでは、クライアントに証明書の提示を求め、渡されたクライアント証明書がca.crtで署名したものであるか検証している。
検証してOKであれば処理が継続するので、要求はWebサーバーにリバースプロキシされる。

ドメインコントロラー－Webサーバー接続

Webサーバーで、以下のようにクライアント証明書を求めているとして…

web server:/etc/apache/sites-available/service.conf

SSLCACertificateFile    /etc/ssl/private/ca.crt
SSLCARevocationFile     /etc/ssl/private/ca.crl
SSLCARevocationCheck    leaf
SSLVerifyClient require
SSLVerifyDepth 1

ドメインコントローラーでは、アクセス用のクライアント証明書を用意しておいて、それを渡してセッションを確立する。
server fault / Add Client Certificate when acting as a reverse proxy

Webサーバーにアクセスするためのクライアント証明書を用意する。
ApacheはPEM形式を求めているので、P12の秘密鍵のパスフレーズを外しつつ、PEM形式に変換。

$ openssl pkcs12 -nodes -in proxy.pfx -out proxy.pem
Enter Import Password: <クライアント証明書のパスフレーズ>[Enter]

※できあがるproxy.pemには、クライアント証明書と秘密鍵が含まれる。
※-nodesで秘密鍵が暗号化されなくなる(＝パスフレーズがなくなる)。

できあがったPEM形式のファイルを安全な場所に置いて、Apacheに渡す。

domain controller:/etc/apache2/sites-available/proxy.conf

SSLProxyMachineCertificateFile /etc/ssl/private/proxy.pem

これで、ドメインコントローラーとWebサーバーの間の接続ができる。

クライアント証明書情報の伝達

ドメインコントローラーがクライアントから受け取った証明書の情報は、リクエストヘッダーにのせてWebサーバーに伝える。
Server Fault / Apache load balancer with https real servers and client certificates

Webサーバーはクライアント証明書自体を検証しておらず、それが信頼できるものなのかどうかが分からないのだから、クライアントが勝手にこういったヘッダーを付けないように(いわゆる偽造をしないように)注意する必要があるそうだ。
X-hogeのところは、説明のためにわかりやすい文字を付けているが、これを普段見かけないような、想像もできないような文字列にしておけ、ってことと理解した。

domain controller:/etc/apache2/sites-available/proxy.conf

RequestHeader set X-Client-Cert %{SSL_CLIENT_CERT}s
RequestHeader set X-Client-S-DN %{SSL_CLIENT_S_DN}s
RequestHeader set X-Client-M-SERIAL %{SSL_CLIENT_M_SERIAL}s

取り扱うことができる値は、このページに書かれている。
Apache Module mod_ssl

こうして渡された値を、Webサーバーではどう取り扱うかというと、例えば…

web server:/etc/apache/sites-available/service.conf

# ドメインコントローラーからリバースプロキシされてきたアクセス
<If "%{REMOTE_ADDR} == '192.168.110.200'">
        Require expr (%{HTTP:X-Client-M-SERIAL} == "EXXXXXXXXXXXXXXB") \
                  or (%{HTTP:X-Client-M-SERIAL} == "EXXXXXXXXXXXXXXC")
</If>
# ルーターを経由したアクセス
<Else>
        Require expr (%{SSL_CLIENT_M_SERIAL} == "EXXXXXXXXXXXXXXB") \
                  or (%{SSL_CLIENT_M_SERIAL} == "EXXXXXXXXXXXXXXC")
</Else>

といったやり方でアクセスを制御していく。

この例について、Ifで場合分けしている。
これは、ドメインコントローラーとWebサーバーを接続する際に、ドメインコントローラーがクライアント証明書を提示しているからで、

• ドメインコントローラーが保持しているクライアント証明書。
• クライアントが提示したクライアント証明書の中身。

の両方が見える状態だと、判定を間違えるかもしれないと思ったから。
条件によっては分けなくても良いかもしれないので、よく整理しなければ。

以上の通り、役割分担と情報伝達を上手く整理すれば、クライアント証明書を使ったやりとりができることが分かった。

サブドメイン新設

サブドメイン新設の効果

サブドメインwww.example.netを新設し、example.net(ドメインコントローラー)にアクセスされたらリダイレクトする。
ユーザーにURL変更を告知して変更を依頼しつつ、変更前のドメインでもサービスを使えるなら、まろやかに移行できる。

domain controller:/etc/apache2/sites-available/proxy.conf

<VirtualHost *:443>
        ServerName example.net
        ServerAdmin webmaster@example.net

        ErrorLog  ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        SSLEngine On
        SSLCertificateFile    /etc/ssl/private/fullchain.pem
        SSLCertificateKeyFile /etc/ssl/private/privkey.pem

        Redirect 301 / https://www.example.net/
</VirtualHost>

結果からすると、3パターンがあった。

1. URL変更への対応で、設定やデーターベースの修正が必要になる。
   記載する事例はWordPress。
   このタイプは変更前のURLで使うことができないが、幸いブラウザで使うサービスなので、リダイレクトしてしまえばサービスを提供できる。
2. URL変更しても問題なく動作するが、クライアント側がリダイレクトに対応していない。
   記載する事例はZ-Push。
   でもこれは、クライアント側が対応しないのは仕方がないように思った(それ、別のサーバーだから)。
3. URL変更しても問題なく動作し、クライアント側も新旧どちらのURLでも問題なく動く。
   記載する事例はLibreSpeed。
   この他、Zabbixなんかも問題なく動いているように思う。

ではまず、リダイレクトの設定。
後ほど、2の対応でリバースプロキシの設定を加えている。

WordPress

WordPressはしっかりとURLを変更する必要がある。
WordPress.org / サイト URL の変更

変更の説明の中で、wp-cliというツールが紹介されている。これは、データーベースを更新してくれるようで、一番きれいにしてくれそうな気配。
WP-CLI / The command line interface for WordPress

ウチではこれから本番稼働させるために、DockerのWordPress FPMを準備しているので、そこでドメイン移行ができるか試してみる。

wp-cliをインストールする。

$ sudo docker exec -it wordpress bash --login

# cd /usr/local/bin/
# curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
# chmod +x wp-cli.phar
# mv wp-cli.phar wp
# exit

wp-cliコマンドは、色々な操作ができて、データーベースの修正なんかもできるらしい。
WordPress Developer Resources / WP-CLI Commands / wp search-replace

マルチサイト(–network)なので、2行目も実施した。

$ sudo docker exec -it -u www-data wordpress bash --login

$ wp search-replace 'https://example.net' 'https://www.example.net' --skip-columns=guid
$ wp search-replace 'https://example.net' 'https://www.example.net' --recurse-objects --network --skip-columns=guid --skip-tables=wp_users
$ exit

マルチサイトを設定したときに追加した定義値があったけれど、これを変更するとサイトネットワーク管理が動かなくなる。
なので、設定しない。

/var/www/html/wp-config.php

define( 'DOMAIN_CURRENT_SITE', 'www.example.net' );

サイトにアクセスしてみると、どうやら、だいたい問題なく動いているようだった。
wp-config.phpに手を入れるアレは、データーベースとの不整合が発生しているような気がするので、この方法はきれいなのかな、と思われる。

(先日、まっさらできれいな環境を作ったばっかりなのになぁ…)

Z-Push

Z-Push自体は、ドメインの変更があっても問題なく動作している。

クライアント側のテストにThunderbirdのTbSyncを使わせていただいたが、さすがにURL違いのリダイレクトには追従してくれない(探してみると、http→httpsは追従するようだった)。
他の対応アプリもきっとそうだろう、ちょっと無理があるんだよね、違うサーバーなのに追従するってこと自体が。

となると、Z-Pushで使われるURLについてはリダイレクトせずにProxyして、当面は並行運用していかなければならない。

/Microsoft-Server-ActiveSyncへのアクセスはexample.netにProxyして、それ以外は、www.example.netにリダイレクトする。
そんな都合の良い設定ってできるの？と思ったが、以下の設定で一応動作している。

domain controller:/etc/apache2/sites-available/proxy.conf

<VirtualHost *:443>
        ServerName example.net
        ServerAdmin webmaster@example.net

        ErrorLog  ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        SSLEngine On
        SSLCertificateFile    /etc/ssl/private/fullchain.pem
        SSLCertificateKeyFile /etc/ssl/private/privkey.pem

        SSLProxyEngine On
        ProxyPreserveHost On
        ProxyPass        /Microsoft-Server-ActiveSync https://192.168.110.80:443/Microsoft-Server-ActiveSync
        ProxyPassReverse /Microsoft-Server-ActiveSync https://192.168.110.80:443/Microsoft-Server-ActiveSync

        Redirect 301 / https://www.example.net/
</VirtualHost>

※赤文字を追加。

ProxyPassの指定同士は、書かれた順序で処理されるけれども、Redirectは上に書いても下に書いても動作は変わらなかった。

今回の要件であれば、上手く動きそうだ。

LibreSpeed

ネットワーク速度の計測をするのに、まずは宅内の状態がどうだか確かめないと。
ということで、過去に作っていたスピードテストサイトがある。

適当なディレクトリに置いて、Apacheからアクセスすれば動くタイプのPHPのプログラムなので、全く問題なく動作した。

ただ…

ApacheをHTTP/2で動かそうとしていて、うっかりPHP-FPMを導入していることを忘れていた。
ログを見ると、Uploadテストでエラーが25回ほど出力されていた。

[Sat Jul 29 21:40:54.157731 2023] [proxy_fcgi:error] [pid 2691061:tid 139980510766656] [client 192.168.110.7:57358] AH01071: Got error 'PHP message: PHP Warning:  Unknown: POST Content-Length of 20971520 bytes exceeds the limit of 8388608 bytes in Unknown on line 0', referer: https://www.example.net/speedtest/speedtest_worker.js?r=0.7769084026053297

アップロードサイズが足らないようなので少し大きくする。

/etc/php/8.1/fpm/php.ini

post_max_size = 16M
upload_max_filesize = 16M

設定を反映。

$ sudo systemctl reload php8.1-fpm

その他、以下のエラーが出ていたが、ファイルのアップロードを途中でキャンセルすると出るらしい。
Server Fault / Apache PHP-FPM “Software caused connection abort”

[Sat Jul 29 21:41:28.425780 2023] [proxy_fcgi:error] [pid 2691061:tid 139980493981248] (103)Software caused connection abort: [client 192.168.110.7:39104] AH01075: Error dispatching request to : (reading input brigade), referer: https://www.example.net/speedtest/speedtest_worker.js?r=0.20889857192768413

このエラーは毎回発生するんだろうな、ということで、割り切りとした。

特定のクライアントからの要求だけを別のサーバーにProxyする

仮想PCを立ち上げて、その仮想PCからの接続だけをProxyであれこれ処理するテストしたいと考えた。
ドメインコントロラーのApacheだけでどうにかできないかと思ったが、<If>の中にProxyPassを設置することはできなかった。

$ sudo apachectl configtest
AH00526: Syntax error on line 41 of /etc/apache2/sites-enabled/proxy.conf:
ProxyPass cannot occur within <If> section
Action 'configtest' failed.
The Apache error log may have more information.

そこで、特定のクライアントからの接続を別のポート(8443)にリダイレクトし、8443/tcpへのアクセスをWebサーバーにリバースプロキシすることにした。
UFWを使っているので、UFWで設定する。

/etc/ufw/before.rules

*nat
:PREROUTING ACCEPT
-F
-A PREROUTING -s 192.168.110.7 -p tcp --dport 443 -j REDIRECT --to-ports 8443
COMMIT

設定を反映する。

$ sudo ufw reload

8443への接続を処理するためのVirtualHostを追加する。

domain controller:/etc/apache2/sites-available/proxy.conf

...(今までの設定はそのまま残しつつ)
</VirtualHost>

Listen 8443
<VirtualHost *:8443>
        ServerName example.net
        DocumentRoot /var/www/html

        ErrorLog  ${APACHE_LOG_DIR}/test8443-proxy-error.log
        CustomLog ${APACHE_LOG_DIR}/test8443-proxy-access.log combined

        SSLEngine On
        SSLProxyEngine On
        SSLCertificateFile    /etc/ssl/private/service.crt
        SSLCertificateKeyFile /etc/ssl/private/service.key

        ProxyPreserveHost On
        ProxyPass        / https://192.168.110.80:443/
        ProxyPassReverse / https://192.168.110.80:443/
</VirtualHost>

設定を反映する。

$ sudo systemctl reload apache2

この設定によって、特定のクライアントからの要求は8443/tcpに届く形になる。
このポートは塞がっているので、以下で接続を許可する。

$ sudo ufw allow to any port 8443 proto tcp from any comment "for test"

これで思う存分テストができる…ハズ。

クライアント証明書を提示できない

ドメインコントローラーのApacheでクライアント証明書の提示を求めるように設定を変更した。
そこへブラウザーでアクセスしたら、以下のエラーが表示された。

Forbidden

You don’t have permission to access this resource.Reason: Cannot perform Post-Handshake Authentication.

ログにも同じメッセージが表示されている。

domain controller:/var/log/apache2/error.log

[Sat Jul 29 11:11:26.927128 2023] [ssl:error] [pid 1596834:tid 139737652004416] [client 192.168.110.7:44446] AH10158: cannot perform post-handshake authentication
[Sat Jul 29 11:11:26.927287 2023] [ssl:error] [pid 1596834:tid 139737652004416] SSL Library Error: error:0A000117:SSL routines::extension not received

この問題への対処方法を教えてくれた。
あぱーブログ / クライアント証明書認証の設定メモ（Apache2.4 + CentOS）

もうちょっと調べてみると、TLS1.3ではTLSハンドシェイクが行われた後でクライアント証明書を要求するために、ポストハンドシェイク・クライアント認証という別のメカニズムが導入されたけれども、それにはクライアントが対応していなければならない。
さらに、HTTP/2ではポストハンドシェイク認証が明示的に禁止されているとも書かれていて、ちょっと手詰まりな感じだった。
Stack Overflow / Delayed certificate in TLS 1.3
Stack Overflow / openssl clientcertificate not workign for me (TLS1.3)

そうすると、TLS1.2以下でやりとりするのが現実的なようだったので、デフォルト値を踏まえつつ、以下の設定にした。
Apache Module mod_ssl

domain controller:/etc/apache/sites-available/proxy.conf

SSLProtocol all -SSLv2 -SSLv3 -TLSv1.3

この設定を追加して、Apacheに反映させたところ、クライアント証明書を提示できるようになった。

Proxyの学習

リバースプロキシでできることをちゃんと確認しよう！と、モジュールが入ったディレクトリを見ると、ajp, balancer, connect, express, fcgi, fdpass, ftp, hcheck, html, http2, http, scgi, uwsgi, wstunnel等のモジュールが並んでいる。

Apacheでは、それぞれにしっかりした説明を更改しているけれど、それでもサンプルを見ないと使い方が分からない。
理解がすすまない自分に少しイライラするけれど、動かして試して意味が分かると、しょっちゅう見に行くことになりそうなページ達だったので、リンクを張ってみている。

色々探しているときに、リモートアドレスの比較方法が目を引いた。
マニュアル斜め読みでは見落としていたが、かなり便利に使えそうなのでメモしておく。
Server Fault / Apache 2.4 Proxy for External, Redirect for Internal

<If "%{REMOTE_ADDR} !-ipmatch 'xxx.xxx.xxx.xxx/24'">

このことは、こちらで書かれていた。
Apache / Expressions in Apache HTTP Server