HTTPSをリバースプロキシ

会社のほうのサイトがあまりに閑散としているので、ロボットさん達だけは大勢来てくれる delegate9.org サイトから誘致しようと考えました。既にリンクは貼ってありましたが、ロボットはほとんどそれを辿ってくれません。別のサイトはターゲットじゃないからでしょうか。

それで、会社のサイトのコンテンツを http://delegate9.org の一部であるように見せればどうだろう?ということで、リバースプロキシしてみることにしました。

会社のサイトは、設立時や銀行の審査などもあり、今後公告にも使う予定なので、HTTPSにしてあります。なのでこれをマウントするのは、HTTPよりは、ちょっと難しいのでは。そう思ったので、まず実験的に会社のサイトのSSLを外してみることにしました。

やろうとすると、XSOnamaeの管理コンソールが、それをやると何が起きても知らんぞみたいな警告してくるのですが、だってSSLを外すだけじゃん。だったらHTTPからHTTPSに切り替える時だって警告しろよな。余計なお世話だわいと、やってしまいまいたところ… こんな事になっちゃいました↓

重大インシデント発生 / 業務継続性・レビュテーションの危機

こ、これはまずい。会社の信用に関わる(笑)。会社のサイトで遊んだ、いや実験したのはまずかったと反省しつつ、急いでSSLに戻す処置をしたのですが、これがまた反映されるのに数分以上かかるわけです。一体何をやっているのやらXSOnamae… 遅延でもかませてるんでしょうか?

それで心を改め、DeleGateでHTTPSサーバをマウントする方法を思い出そうとしたり、マニュアルを読んだりしたのですが、どうもよくわかりません。マウントポイントごとに設定できたような記憶があるのですが… 単なる MOUNT="/xxx/* https://xxx/*" という設定だけではダメなのです(そう出来てしかるべきなのに…)

そういえば、ターゲットがhttpsの時はSSLフィルターを噛ませる、という明示的な設定が必要でした。ですが、やり方を思い出せません(確かCMAPとかなんとか…)。仕方なく、ローカルに HTTP → HTTPS 変換をやるプロキシを立てて一段噛ませることにしました。

さてどうかな、と思ってブラウザから見てみたところ、つながらない。なんでだと思ってログを見ると、SSLプロトコルのレベルで却下されているようです。そういやこいつが使ってるOpenSSLライブラリは古いしなと思い、わざわざ足下に置いておいた古いライブラリを消し、もともとUbuntuに備え付けのデフォのライブラリを探し当てるようにしたら… つながりました↓

httpsサーバ(WordPress/nginx)のリバースプロキシ(マウント)成功

おー、なんだかシュール(笑)。ブログやら検索やらのリンクもつついて見ましたが、問題ないようです。まあ、スクリプトでURLを合成されたりしなければ、URLの変換は難しいことではないですからね。少なくとも私の使っているWordPressのテーマやウィジェットはすごく素朴なので、そんな芸当をしそうにないです。

ということもあり、サーバのSSLの有り無しで影響をうけるような話では無いと思うので、XSOnamaeのサーバで何を問題にしているのかピンと来ません。まあアンカーにフル表記のURLを使っているからということなのかなとは思いますが。

delegate.org では長い間、HTTPSサーバをHTTPクライアントにリバースプロキシする事はずっとやってて問題なかったと思います。まあ、オレオレ証明書で怒られてはいますが。最近はhttpsでないとブラウザにひどいレッテルを貼られるのにも気付きました。ほぼ万能証明書は買ってあるので、活用しないと…

2020-0502 sato@izmoh


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です