当サイトでリバースプロキシを導入したい理由
現在(2023年8月)、webサーバ一台でWordpress(2サイト)・Nextcloud・Matomoを運用している。これらは外部からアクセスするためにしかたなく一台構成としている。お金持ちならこんなことに悩まなくアドレスをいっぱいもらえば問題解決なのだが…
このままでもサーバの性能的には全然問題ないが、各種アップデートなどのメンテナンスに気を遣うことが多くなった。特にWordPressの一つのサイトで必要なphpなどのメンテナンスが他方に影響を与えることがある。また、例えば基本ソフトウェアのアップデートやセキュリティパッチを適用したりする場合にすべての機能を停止する必要がある。アップデート後一部の機能で不具合が出た場合もどうするか(切り戻すか不具合を解消するか)悩みどころである。
ということでこれらの問題を解決するため,リバースプロキシを導入し、Webサーバを分散することにした.
リバースプロキシどれを使う?
リバースプロキシは squidと比較して悩んだ結果、比較的事例が多かった nginxとする。
リバプロのインストールおよび設定
インストール方法や設定方法はWeb上に腐るほど事例があるのでそちらを参照するとして、動作させるうえで少しはまった点を記載しておく。
リバプロが動作しているサーバでSELinuxが有効になっている場合は、以下のコマンドを実行する。
setsebool -P httpd_can_network_connect 1
現在の構成
サービスを提供しているドメインをexample.comとする。
現在は、DDNSに*.example.comを登録し、境界ルータでポート80および443のアクセスを一台のWebサーバへ振り向けている。このWebサーバでapacheのバーチャルドメインの機能を用いて複数のサブドメインを運用している。
最終構成
最終構成は、境界ルータでポート80および443のアクセスをリバースプロキシに振り向けそこからサブドメインごとの複数のWebサーバへアクセスするようにする。
変更後の構成は次のようになる。
移行方法とテスト方法
内部アクセスの移行方法とテスト方法
移行方法
外部からのアクセスはそのままに(境界ルータをいじらずに)、内部アクセスのほうから移行を行う。
内部アクセスの場合のリバースプロキシの組み込み方法は、
- リバースプロキシの設定を行う。
- フォワードプロキシサーバを立てる。
- フォワードプロキシサーバの/etc/hostsに、サービスのFQDNとアドレスを設定する。アドレスには、リバースプロキシのアドレスを記載する。
テスト方法
テストは、ブラウザのプロキシ設定で上記のフォワードプロキシサーバアドレスを指定し、各サービスにアクセスする。
外部アクセスの移行方法
内部向けアクセスのリバースプロキシの設定およびテストが完了したらあとは簡単である。
境界ルータの80,443ポートの振り向け先をリバースプロキシサーバへ変更するだけだ。
これで、外部からもリバースプロキシ経由でアクセスできているはずである。
Webサーバの分散
分散方法は省略。気が向いたら書くかもしれない。
これで心置きなく システムのアップデート(dnf updateやapt update ; apt upgrade)ができる。
エラーと対処
Nextcloud エラーその1
エラー内容
リバースプロキシヘッダーの構成が正しくないか、信頼できるプロキシからNextcloudにアクセスしています。そうでない場合、これはセキュリティに問題があり、攻撃者がNextcloudを表示できるようにIPアドレスを偽装することができます。詳細については、ドキュメント↗をご覧ください。
対処
config/config.phpに以下の記載を行う。192.0.2.11はリバプロのアドレス。
'trusted_proxies' =>
array (
0 => '192.0.2.11',
),
Nextcloud エラーその2
エラー内容
“X-Content-Type-Options” HTTPヘッダーが “nosniff”に設定されていません。 これらは潜在的なセキュリティまたはプライバシーのリスクになります。この設定を調整することをお勧めします
“X-Frame-Options” HTTPヘッダーが “SAMEORIGIN”に設定されていません。 これらは潜在的なセキュリティまたはプライバシーのリスクになります。この設定を調整することをお勧めします
対処
nextcloudインストールディレクトリの.htaccessに以下の定義がある。
Header onsuccess unset X-Content-Type-Options
Header always set X-Content-Type-Options "nosniff"
Header onsuccess unset X-Frame-Options
Header always set X-Frame-Options "SAMEORIGIN"
また、nginxで以下の定義を行っていた。
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
重複して定義したことで、各ヘッダーの値がおかしくなっていたようだ。
.htaccessのこれらの行をコメントにすることでエラーは表示されなくなった。
Nextcloud エラーその3
エラー内容
外部からNextcloudにアクセスした際(内部からのアクセスでも出ている?)、417が帰ってきていた。
対処
nginxで以下の定義を実施することで解決。
client_max_body_size 0;
コメント