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

さて、昨日は古い 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
結局、この日は解決することができなかった
(正解はリバースプロキシ側に、ユーザがアクセスしてきた時のホスト名のままでアクセスするという設定があるのだった)

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