リバース プロキシと WordPress

昨日Apache 上で PHP を動かすのに苦労したという記事を書いた。まぁ普段から Linux を使ってる人間にとってはなんてことない設定だ。Windows Server 側のボクからしても、振り返れば大したことではない。
さて、次は Windows Server でも Linux でもない、別の問題だ。

この仕事は WordPress を使う仕事だった。といってもボクはそちらには踏み入れない。ボクの仕事はフロント部分で、デザイナーさんがあげてきたウェブ デザインを CSS + HTML + JavaScript + PHP で WordPress のテーマに落とし込む仕事である。
とはいえサーバを用意するようには言われたので、昨日用意した仮想サーバに WordPress をインストールして動くようになるまではやらなければならない。

昨日も説明したが、仮想サーバはこの amatsukami.jp サーバ上にある。
インターネットからこの仮想サーバにアクセスするには、グローバル IP アドレス(インターネットの世界で重複しないユニークなアドレス)を最低でも一つ割り当てなければならないのだが、amatsukami.jp にはグローバル IP アドレスが一つしかないので、仮想サーバに割り当てることは出来ない。
そこでリバース プロキシApplication Request Routing)という仕組みを使って、仮想サーバにアクセスしに来たデータは amatsukami.jp サーバが素通しして仮想サーバに通すようにする。こうすることによって、外からはあたかも仮想サーバがインターネット上にいるかのように見えるわけである。

これ自体の設定は、とても簡単で、素通しの設定をすればいいのである。

問題は HTTPS だ。とはいえ、実はこれ自体も設定は簡単である。リバース プロキシが暗号化の処理をしてあげればいいのだ。リバース プロキシの向こう側にいる仮想サーバは別に暗号化の処理をしなくても良いのだ。
ところがここで大きな問題が生じる。それは「リンク」だ。

仮想サーバは暗号化の処理をしない。ということはどういうことになるかというと、WordPress は、自身のリンクにすべて「http://」という暗号化なしのアドレスを貼ってしまうのだ。

暗号化してある場合、ここは「https://」で始まらなければならない。でも WordPress 自身というか、仮想サーバそのものが暗号化の処理を必要としていないわけだから、https のリンクを張るわけがない。

さーて、こまった……これはどうすればいいんだ??

で、いろいろ試行錯誤した結果、WordPress が実行される一番最初のところで、ムリヤリ、HTTPS だという嘘の情報を書き込むと動くことが判明したwwww

$_SERVER['HTTPS'] = 'on';

この一行を書き加えるだけですべて解決(汗)。え、ほんとにいいのかなぁ??
たぶん解決方法としては正しくないとは思うんだけど、とりあえず動いているし、特に問題も起きてないのでよしとしよう(ぁ
プラグインとかの更新もちゃんとできるし……(^^;

2020 年最初の台風が発生した。去年より 3 ヶ月以上遅れての発生だ。というのも去年は 2/20 の段階ですでに二号が生まれているからだ。とはいえツイートで一月に発生していたというのは調査不足だ。じっさい 2029 年の台風一号がいつ発生したかは調べてない(汗

さてこの 2019 年との台風発生の違いは現れるだろうか? 去年は妙に台風の数が多かったが……今年は果たして?

リバースプロキシの秘密は preserveHostHeader にあり

ボクは aipo というグループウェアを一人で使っているのだが(笑)、一人で使うので、割と URL がテキトーだった。例に挙げれば、https://amatsukam.jp:3333/ って感じ。なんだよこの 3333 って数字は! みたいなw
https は本来 443 で動くのだが(なので何も指定しないと 443 番で通信しようとする)、そちらは色んな人がアクセスするための別のサービスが動いているため、ボクしか使わないグループウェアの方はテキトーなポート番号を割り当てていたのだ。

が、先日リバース プロキシというものを知ったボクはこの aipo も https://amatsukami.jp/aipo/ にできるのではないかといろいろ悪戦苦闘していた。

それがついに解決して、3333 を付けなくてもアクセスできるようになった。
Microsoft 製リバースプロキシである Application Request Routing の preserveHostHeader という設定を True にすることにより、インターネット網からアクセスしてきたホスト名でリバースプロキシ下にあるサーバ群にアクセスするようになった。
というわけでホスト名に関しては、まずは解決。

しかし問題はこれだけではない。aipo はルートディレクトリに配されている。どういうことかというと、https://amatsukami.jp:3333/ が aipo のホームページ(ホームディレクトリ)である。しかしこれを、https://amatsukam.jp/aipo/ にしたい。リバースプロキシだけでは、コレを解決できない(たぶん)。aipo 本体も https://amatsukami.jp:3333/aipo/ にしなければならないわけである。

んでなんとなーく aipo のドキュメントを眺めていると、昔 aipo ディレクトリで運用されていた名残があるような感じで、んじゃー、aipo フォルダってのを作ったら動くんじゃないかと思ってやってみたら動いたwwww
具体的には、aipo のインストール先である「dpl8110\tomcat\webapps」っていうディレクトリに、ROOT というディレクトリがあるので、それをそっくりそのまま aipo というディレクトリ名に変えるだけである(万全を期すなら、ROOT は残しておき、ROOT ディレクトリを aipo というディレクトリ名でコピーする)。こうすることによって、aipo は https://amatsukami.jp:3333/aipo/ で動くようになった。
次に aipo のプラグインなどを提供している container ディレクトリだが、こいつは単純にリバースプロキシで、https://amatsukami.jp/container/ ってアクセスが来たら、aipo のサーバにそのまま飛ばすようにすればよい。ただコレの欠点は、amatsukam.jp では container というディレクトリが使えなくなることだが、別に問題はないだろう(理想を言えば、aipo/container/ にするべき)。

また、3333 という数字をつけなくてすむようになったので、iPhone のカレンダーに aipo のカレンダーが取り込めるようになった。aipo に入力した予定表がそのまま iPhone でも見られる。イイ感じ!

下の写真はお昼に食べに行った「アカス」のランチ。タンドリーチキン付き。真ん中のはタンドリーチキンだよ! 見間違えないでよ!(何

気温とか 4K とかカレーのシミとかミルクとか

またまた Twitter から拾った、いろいろくだらない&どうでもいいネタ。

暑い! ってただそれだけである。残暑は長し。

まぁメモ程度に。1080p と較べるとファイルサイズはほぼ倍。電池は 10 ポイント多く使用した。さすがに 4K クラスとなると HEVC で録画したいんだけど、Premiere で読み込めないので未だに互換フォーマット。というか、PhotoshopHEIF に対応してくれないと移行でできない……orz
すぐ対応すると思ったのになかなか対応しないなぁ……。

そう!こういうのないの? ボクは白が好きなので、割と白を着るんだけど……時々食事の時失敗しちゃうんだよねぇ。そしたらもうそれは選択肢なくちゃいけなくなる。上のようなウェットティッシュがあれば、ちょいちょいってその部分に薬品(?)を浸透させて、そのあとウェットティッシュ側に吸い取るみたいな……そういうのないのかなぁ。

先日 TAMA Networks の旧コンテンツを別サーバに移した。そしたら、訪問者カウンタがおかしくなった。理由は簡単で、リバースプロキシ(Application Request Routing)経由でアクセスするため、旧コンテンツから見たらリバースプロキシしかアクセスしてこないためだ(笑)。
旧コンテンツに何千人、何万人来ようが、全部リバースプロキシが間に入るので、旧コンテンツからしたら一人がすげー勢いでアクセスしてくるな、って事にしかならないのだw

と言うわけで、リバースプロキシ側で HTTP ヘッダに HTTP_X_FORWARDED_FOR という名前で、アクセスしてきた人の IP アドレスを入れて、それを旧コンテンツに渡し、また旧コンテンツでは REMOTE_ADDR でカウントするのではなく、先ほどの HTTP_X_FORWARDED_FOR でカウントするように書き換えた。これで解決。

シティハンターだったっけなぁ? キャッツアイだったかなぁ。女子高生とかを「ミルク臭い」と呼んでいたのを思い出した。確かに 10 代の女の子って代謝が早いせいなのか、ミルクのような臭いがしてた。でも最近、JC も JK も大人びちゃって化粧やら香水やらするから、あの臭いはしなくなったよなぁなんてことをふと思う(ぁ
脱いだら解るけど。

そしてエロゲを作ってるからかもしれないけど、アレだよね、すっかりミルク臭いなんて表現は使わなくなったって言うか、もう女子高校生や女子中学生くらいが恋愛のターゲットになっても驚かれなくなったよなぁ……。エロゲだと容姿的にそれくらいが普通だもんなぁ。

リバースプロキシの基本がわかってない(ぁ

さて、昨日は古い PHP で動く旧コンテンツを、リバースプロキシApplication Request Routing)を使って別のサーバに追い出すことに成功した。ということはだ、今別サーバで色々動いているものが、少なくとも見た目上は一つに集約できるのではないかということに気づく。

今、Redmine(プロジェクト管理)やグループウェア(Aipo)なんかが動いてはいるんだけど、それらは全部 HTTP でやりとりするのね。しかも Windows で動かすと全部独立したサービスで動くため、これらを一つの HTTP で動かすわけにはいかないという状況だ。

そこでどうしているかというと、不特定多数の人がアクセスするサービスはデフォルトに割り当て、ボク一人で使っている Redmine やグループウェアは TCP ポート番号を分けることによって使い分けていた。
たとえば、https://amatsukami.jp:9999/ なんて感じだ。でもこれはデフォルトの動作じゃないし、見た目もよろしくない。

リバースプロキシを使えば、https://amatsukami.jp/redmine/ ってやると https://amatsukami.jp:9999/ にアクセスするように設定できる。こうすることによって、全て https://amatsukami.jp/ で完結できる。

というわけでさっそく一番使用頻度が高いグループウェアで設定してみようとするんだが、これがうまくいかない。ホスト名が一致しないのだ。
どういうことかというと、リバースプロキシ経由になるということは、グループウェアにアクセスしに来るのはリバースプロキシと言うことになる(アクセス経路は以下の通り)。

ユーザ → リバースプロキシ → グループウェア

リバースプロキシとグループウェアは LAN 内で結ばれていて、お互い LAN 内の名前(ホスト名という)で呼び合っている。この LAN 内のホスト名はインターネットの世界では通用しない。でもグループウェアは呼ばれたホスト名で応答するように作られており、リバースプロキシは LAN 内でしか有効でないホスト名をそのままユーザに返してしまうため、インターネット網にいるユーザは結局アクセス出来ないのだ。

じゃぁ旧コンテンツはどうしているのかというと、旧コンテンツのエンジンである Pukiwiki Plus ! は返すホスト名を固定できるのだ。このホスト名をインターネットで通じる名前にしておけば問題ないというわけである。
ところがボクが使っているグループウェアにはこの機能が無い。
ただこの時、ボクはグループウェアの方に着目してしまったのよね……これが遠回りの原因になってしまった。グループウェアはオープンソースなもんだから、ソースとかを見始めちゃったのよね……orz
結局、この日は解決することができなかった
(正解はリバースプロキシ側に、ユーザがアクセスしてきた時のホスト名のままでアクセスするという設定があるのだった)

下の写真は浅草橋で一番美味しい(とボクが思い込んでいる)、ろく月の豚白湯麺とチャーシュー丼。うまいー!

リバースプロキシって便利!

TAMA Networks の旧コンテンツは Pukiwiki Plus ! というシステムで動いている。コイツは PHP 5.2 じゃないと動かない。5.3 以降では動かないのだ(どうも動くらしいのだが、IIS ではセキュリティ関連の機能がまったく働かない)。そのおかげで、amatsukami.jp サーバはずっと PHP を更新できないでいる。そうこうしているうちに PHP は 7 になってしまった。

一方、現在の TAMA Networks は WordPress というシステムで動いていて、これは現役のシステムであり、バージョンアップもされている。
そしていつかは WordPress が PHP5.2 では動かなくなるはずだ。現に WordPress のプラグインなどは 5.2 で動かないものもチラホラ出始めている。
しかし、先の Pukiwiki Plus ! のおかげで、こちらは PHP のバージョンを上げられない。
何かいい方法はないものか? と、色々考えたあげく、二つの方法を思いついた。

  1. amatsukami.jp サーバで複数のバージョンの PHP が動くようにする
  2. リバースプロキシを使って、Pukiwiki Plus ! を amatsukami.jp サーバから追い出す

と言うわけで①を試そうとしたんだが、IIS7.5 ではこれがどうもうまくいかない。
いや、7.5 でもできると思うんだけどなぁ……。結果的に旧コンテンツが動かなくなるw
そこでやる気を失って放置してたら、ウェブサーバが落ちたwww
どうやら旧コンテンツの実行にものすごく時間がかかるようになってしまったためで、旧コンテンツそのものにアクセス出来ないようにしたら、復活した。

これが 9/11 頃である。

その後も①に色々挑戦するも、何故かうまく動かない。まぁ amatsukami.jp サーバは 6 年も稼働し続けているし、その間、いろんな設定ミスだのなんだのをしてきたから内部がけっこうヤバいことになっているのかもしれない。
さっさと新しいサーバに移行しなければ……という結論には達するものの、技術的な勉強も兼ねて仮想サーバ(こちらは IIS8.0)に PHP を 2 バージョン(5.2 と 7)をセットアップした。するとすんなり両バージョンで PHP が動くではないか。なのでこの設定をそっくりそのまま amatsukami.jp サーバに持ってくると……やっぱり動かないorz
う~む、やはり amatsukami.jp サーバが怪しいんだなぁ……(実は PHP の設定が不味かった)。

そこで amatsukami.jp サーバにリバースプロキシを設定する。そして https://amatsukami.jp/scripts/pukiwiki/ 及び https://amatsukami.jp/pukiwiki/ にアクセスしに来たら、それは仮想サーバの Pukiwiki を呼び出すように設定した。
と言うわけで上のメニューにある「今は昔」のリンク先は amatsukami.jp サーバではなく、仮想サーバで動いているコンテンツだったりする。

将来的にサーバを新調したら、どっちの方法でやるかは悩むな。サーバを新しくしたら当然そっちでは複数のバージョンの PHP が動かせるはずだ。となれば別にリバース プロキシに頼らなくてもよい。
ただ将来的な設計で、ロードバランサなどを置く場合は、そもそも全てのサイトがリバース プロキシでの運用になるだろうし……。まぁそれはその時になったら考えよう。

下の写真はシャンブラとボクが勝手に呼んでいる『上海ブラッセリー』の塩やきそばと半チャーハン。ここのチャーハンは紅生姜が入っているのが特徴だ。半チャーハンの写真がフタルあるのは、ここ、半チャーハンはお代わり自由だったんだけど、それがなくなり、「普通」「大盛り」「特盛り」が選べるようになった。その大盛りと特盛りの比較写真が、チャーハンが二つ並んでる写真だw
あくまでも半チャーハンの大盛りと特盛りなので、大盛りが普通のチャーハンくらいの量だと思ってもらえれば間違いないと思われる。ただし、残っているチャーハンの量に影響されるのか解らないが、けっこう日によって量は違ったりするw