なぜリバースプロキシが必要か
現在(2023年8月)、webサーバ一台でWordpress(2サイト)・Nextcloud・Matomoを運用している。これらは外部からアクセスするためにしかたなく一台構成としている。お金持ちならこんなことに悩まなくアドレスをいっぱいもらえば問題解決なのだが…
このままでもサーバの性能的には全然問題ないが、各種アップデートなどのメンテナンスに気を遣うことが多くなった。特にWordPressの一つのサイトで必要なphpなどのメンテナンスが他方に影響を与えることがある。また、例えば基本ソフトウェアのアップデートやセキュリティパッチを適用したりする場合にすべての機能を停止する必要がある。アップデート後一部の機能で不具合が出た場合もどうするか(切り戻すか不具合を解消するか)悩みどころである。
ということでこれらの問題を解決するため，リバースプロキシを導入する．
リバースプロキシどれを使う?
リバースプロキシは nginxとする。
リバプロが動作しているサーバでSELinuxが有効になっている場合は、以下のコマンドを実行する。
setsebool -P httpd_can_network_connect 1最終構成
サービスを提供しているドメインをexample.comとする。
現在は、DDNSに*.example.comを登録し、境界ルータでポート80および443のアクセスをWebサーバへ振り向けている。
これを、境界ルータでリバースプロキシに振り向けそこからWebサーバへアクセスするようにする。
移行方法とテスト方法
内部アクセスの移行方法とテスト方法
移行方法
外部からのアクセスはそのままに(境界ルータをいじらずに)、内部アクセスのほうから移行を行う。
内部アクセスの場合のリバースプロキシの組み込み方法は、
- リバースプロキシの設定を行う。
- フォワードプロキシサーバを立てる。
- フォワードプロキシサーバの/etc/hostsに、サービスのFQDNとアドレスを設定する。アドレスには、リバースプロキシのアドレスを記載する。
テスト方法
テストは、ブラウザのプロキシ設定で上記のフォワードプロキシサーバアドレスを指定し、各サービスにアクセスする。
外部アクセスの移行方法
境界ルータの80,443ポートの振り向け先をリバースプロキシサーバへ変更する。
エラーと対処
Nextcloud エラーその１
エラー内容
リバースプロキシヘッダーの構成が正しくないか、信頼できるプロキシからNextcloudにアクセスしています。そうでない場合、これはセキュリティに問題があり、攻撃者がNextcloudを表示できるようにIPアドレスを偽装することができます。詳細については、ドキュメント↗をご覧ください。
対処
config/config.phpに以下の記載を行う。
'trusted_proxies' =>
array (
0 => '192.168.110.12',
),Nextcloud エラーその２
エラー内容
“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 エラーその３
外部からNextcloudにアクセスした際(内部からのアクセスでも出ている?)、417が帰ってきていた。
nginxで以下の定義を実施することで解決。
client_max_body_size 0;
コメント