Web サーバを暗号化する #2 WordPress を SLB で SSL offload する

Server Load Balancer (SLB) を導入し、SSL offload を設定する話となります。

このブログは Alibaba Cloud の ECS インスタンスで提供しています。　Ubuntu が動作する ECS インスタンの管理は自分自身で行っていますが、たまにやらかして停止させてしまうことが年に 1,2 回あります。　個人のブログサイトなので停止しても特に問題はないのですが、Sorry Page（只今メンテナンス中です、とかアナウンスする画面）を導入することにしました。　Sorry Page というと普通の Load Balancer にはその機能を備えています。　ということで Alibaba Cloud Server Load Balancer を導入することにします。　あわせて SSL offload も構成していきます。

また、Sorry Page の機能が SLB (Server Load Balancer) にあるのか調べようと Alibaba Cloud Document Center を久々に見てみるといつの間にか SLB は Classic 扱いとなっており、Application Load Balancer (ALB)が主になっていることもわかります。　ということで Applicatoin Load Balancer がどんなものか調べつつ、使えるなら使い、SSL offload を設定し、Sorry Page の表示まで進めていきます。

Application Load Balancer とは？

Classic SLB と Application Load Balancer （ALB）の違いは Document Center に説明があります。

Classic Load Balancer (CLB): formerly known as SLB. CLB instances support TCP, UDP, HTTP, and HTTPS. CLB instances also provide powerful processing capabilities for Layer 4 load balancing and basic processing capabilities for Layer 7 load balancing.
Application Load Balancer (ALB): ALB instances provide ultra-high performance to process network traffic at Layer 7. For example, you can use HTTPS offloading with ALB instances. Each ALB instance supports up to one million QPS. An ALB instance serves as a cloud-native gateway of Alibaba Cloud and also provides advanced routing features. ALB instances can forward, redirect, and rewrite messages based on user-defined HTTP headers, cookies, and query strings.

ALB の一番の特徴は Layer 7 のトラフィック処理について高い処理能力を発揮できることのようです。　SSL offloading について100万 QPS に対応するとのこと。　昔は SSL offloading は重い処理に分類されるもので汎用CPU（x86などの）では効率が悪く、専用の ASIC や Hardware を利用することが当たり前でしが今はパブリッククラウドでもあっさり 100万 QPS を出せるということです。

また、Layer 7 のロードバランサー機能、特に Application Load Balancer というだけであり rewrire 系の機能が Classic より拡充されているようです。

Document Center では簡単な比較表も提供されていました。

上の表を見ていくと、性能面で向上（50,000 QPS から 1,000,000 QPS へ）、ドメイン名とURLベースのルーティングからコンテントベースのルーティングに対応し、Forwards/redirects/rewritesなどに対応していることもわかります。Cloud-native support では Canary release や blue-green deployments に対応できる分散ないし同期型のトラフィック処理も出来るようになったとのこと。　私のこのブログサイトには使い手が無い機能ばかりですが、ある程度の規模のサイトの運営する場合には嬉しい機能ばかりです。

ただ、上記の Document Center のページの更新日は 2021/2/18 となっており、本当に最近登場したようです。

そして、Sorry Page の機能があるのか、設定方法など確認しようと思ったのですが Document Center にはまだ ALB に関するドキュメントは整っていません（2021/2/27現在）。

とりあえず実際に設定しながら試しいってみます。

Server Load Balancer の購入

まずは Alibaba Cloud のコンソールにログインします。

メニューから Server Load Balancer にアクセスします。　Applicatoin Load Balancer の選択肢はありません。

Region に Japan (Tokyo) を選択し、Create Instance をクリックします。

インスタンスの購入画面から Region やスペックを指定していきます。　この画面からは Classic SLB と ALB を選んだりする項目は無いように見えます。

Zone Type は Multi-zone しか選べません。　Primary Zone は選択可能です。　今回、対象となるサーバは 1台しかなくその ECS インスタンスは Zone B に配置しているので、今回 SLB の Primary は Zone B にします。同じ Zone の方が Latency が良いためです。

Instance Spec の選択ですが、見る限り Classic のようです。　ALB はまだ使えない気がしてきました。　が、とりあえず進めていきます。

他の選択肢も以下の通りですが、見る限りは Classic のようです。

今回、Instance Spec として Small I を選択しました。　下から2番目のものです。　一番下の Shared Performance Instance を選択すると、このリージョンでは使えないとの案内がありました。

購入内容を確認し、 Term も確認し、Activate Now をクリックします。

インスタンスは数分（2分もかからず）、Status は Active になります。　Azure は結構時間がかかり待たされるのですが、Alibaba Cloud の SLB はこの点はかなり良いです。

ただ、見る限りは新登場の Application Load Balancer というよりは昔からある Classic SLB のようです。　とりあえず、設定まで進めていきます。

Server Load Balancer の基本設定

設定は以下の流れで実施してきます。

証明書のアップロード
リスナー設定
状態の確認

証明書のアップロード

Certificates > Create Certificate をクリックします。

ここから https://bigriver.jp で利用している証明書をアップロードします。

途中は省略しますが、以下登録が完了したスクリーンショットです。　設定で迷うような所はあまりありませんが、Public Key Certificate: に中間証明書も忘れずに登録しましょう。

Listener の設定

Add Listener をクリックします。

Listener Protocol には HTTPS を選択します。　あとは Listener Name に任意の名前をつけても良いですし、つけなければ自動的に protocol_port 形式の名前が付与されます。

Advanced はとりあえず既定値で進めます。

SSL Certificates では先程登録した証明書を指定します。

次は Backend Server を登録していきます。今回は複雑なことはしない（ Backend Server がそもそも1台しかいない）ので Default Server Group をクリックします。

Add More をクリックし、サーバーを追加します。

Backend に登録できる ECS インスタンスがリストされますので、選択して追加します。

Backend として ECS インスタンスが登録されました。　Port 番号は手動で指定する必要があります。　今回は SLB で SSL offloading するので SSL を利用しない port 80 を Port 似指定します。

次は Health Check の設定です。　こちらもまずは既定値で進めます。

最後に構成内容を確認し、問題がなければ作成します。

処理の過程は以下のようにリアルタイムで表示され、作成は30秒かからずに完了しました。

状態の確認

前の手順で実施した Listener の登録の直後にですが、 Health Check Status が Unavailable になっています。　おそらく、Health Check がまだ始まったばかりからでしょう。

1−2分後に更新すると以下の通り Normal になりました。

これで Load Balancer 自体の基本設定は完了です。

この状態で IP アドレスでアクセスしてみます。　画面は崩れていますがアクセスは出来ました。画面が崩れるのは WordPress 側でリダイレクトなりURLとして https://bigriver.jp を指定している部分があるからでしょう。このあと DNS を切り変えれば解消するはずです。

証明書も参照できます。　Alibaba Cloud Server Load Balancer に SSL offloading している証明書です。まあ、この画面だけでは SLB が処理しているのか ECS インスタンス上の Apache が処理しているかは判別できませんが。

DNS の切り替え

bigriver.jp の RR の IP アドレスを変更します。

以下は Alibaba Cloud DNS の設定画面ですが、もともとは ECS インスタンスのパブリック IP アドレスとなる 47.245.57.91 を設定しています。

これを SLB のパブリック IP アドレスに変更します。

ここで問題が発生します。　この記事のWordpress の編集画面にアクセスできません。

サイトの表示も崩れています。

一旦、DNS の RR をもとに戻し、トラブルシューティングすることにします。

トラブルシューティング

今回、SLB で SSL offloading する構成に変更しました。　結果、画面表示のレイアウトが崩れる、Wordpress の管理画面にアクセス出来ない状態となりました。　考えられる原因は3つです。　1つは、Wordpress で Static に以前のパブリック IP アドレスを設定しているまたはキャッシュしている可能性です。　2つ目は Server Load Balancer で SSL offloading する中でコンテンツを Rewrite している可能性です。コンテンツの URL について https を http に書き換えたりという処理です。3つ目は、Wordpress が http で届く要求を https にリダイレクトしている可能性です。　今回は3番目が原因となる可能性が高いです。 WordPress 側は https で受け付けるつもりでコンテンツ内の URL を https で統一しています。　ただ、実際に到達するリクエストは http となり、その結果、https へのリダイレクト処理を走らせ、要求が繰り返され、結果正常動作しません。　以下のブラウザの応答とも合致します。

まずは Alibaba Cloud Server Load Balancer で X-Forwrderd-Proto の HTTP ヘッダーを有効化します。」

次に wordpress の wp-config.php ファイルに以下の太字部分を追加します。

<?php
if ( ! empty( $_SERVER[‘HTTP_X_FORWARDED_PROTO’] ) && $_SERVER[‘HTTP_X_FORWARDED_PROTO’] == ‘https’ ) { $_SERVER[‘HTTPS’]=’on’; }

上記の設定についての詳しい情報は以下の WordPress の公開情報に説明があります。

管理画面での SSL 通信

DNS の RR を変更する前に、まずはパブリック IP アドレスでアクセスしてみます。　レイアウト崩れは解消されました。

DNS の RR を変更します。　以下は変更後のスクリーンショットですが、47.74.30.123 に変更しました。

TTL は 1秒なのでクライアント側での反映時間は基本的に1秒です。　ブラウザから https://bigriver.jp にアクセスします。

正常にアクセス出来ました。　先程アクセスできなかった wordpress の編集画面にも問題なくアクセスできました。

SLB 経由の通信となっているかの確認

本当に SLB 経由となっているのか、ECS インスタンス上で確認していきます。ここでまたちょっとした問題が発生します。　ssh で ECS インスタンスに接続することが出来なくなりました。

理由は明白です。　bigriver.jp の DNS の A レコードを SLB のパブリックIPに変更する中で Listener は https での受付しか設定していません。　この状態で bigriver.jp に ssh 接続しようとしても SLB で接続で受け付けてもらえません。　回避方法は以下の3つです。

SLB に SSH 受付のための Listener を作成する
直接 ECS インスタンスの IP アドレスで SSH 接続する
DNS に A レコードを追加するか、です。

1つ目方法は、今回のように Backend が1台しかない場合は可能な構成ですが、複数ある場合を考えると適切ではありません。　2番目の方法は何も追加の設定が不要ですが、IPアドレスを記憶しておく必要がありイマイチです。　ということで3番目の方法、DNSのレコードを追加、で進めます。

Alibaba Cloud DNS から以下のレコードを追加します。

ssh の接続先として、追加した DNS レコードの ssh.bigriver.jp で接続します。　無事、ログイン出来ました。

もともとやりたかったことは、SLB 経由に変更後、本当に SLB を経由して通信しているかの確認です。 Apache のアクセスログで判別可能です。　以下の通り、SLB に切り替え後は Source IP Address に 100.122.17.42 や 100.122.17.43 や 100.122.17.44 などの Alibaba Cloud の IP アドレスからの接続に変わったことが確認出来ます。　なお、Apache 側では X-Forwarded-For のヘッダをクライアントの IP アドレスとしてログ取得する設定はまだ実施していません。別途、設定します。