ロードバランサを使った場合のGITlabのサーバ設定(httpsとhttp)

Question

社用でGitLab+nginx(オム二版)をRedHutLinuxに入れて使おうと思っています。
しかし、ロードバランサ(LB)を介しているせいかうまく通信できません。
ブラウザ(Chrome、Firefox、IE)から
https://hogehoge.jp:8443/ にアクセスすると、一度目はリダイレクトされたようで
http://hogehoge.jp:8443/users/sign_in となりアクセスできません。
手動でhttps://hogehoge.jp:8443/users/sign_in と修正して、
やっとログイン画面にたどりつきます。
ログイン後も遷移によってhttpに変更され、何度も手で打ち直しています。
来週から社外パートナーに使用してもらう予定で、なんとかFIXしたいところです。
社内からのLBを介さないhttpでの直接通信は全く問題ありません。

下記構成で常にhttps通信させたいのですが、今できていません。
サーバへの何らかの設定で勝手にhttpに変わらずhttps固定にさせられないでしょうか？
よろしくお願いします。

###NW構成
外部インターネット----(https)---->LB----(http)---->GitLabサーバ
0. LBが入りますがサーバは1台です。
0. 外部からはSSL通信をさせます。
0. LBにサーバ証明書を入れて復号化しています。後段はhttp通信です。
0. 外部からLBまではポート8443、LBからGitLabサーバまではポート80の平文通信です。
0. LBにはVIPを割付て、DNS登録しています。(123.456.7.8=hogehoge.jp)
0. サーバは実IPでDNS登録していませんがホスト名gitlab01をつけています。(123.456.7.50=gitlab01)

###サーバ設定
0. HTTP、80ポート使用
0. 専らhttp通信の設定を入れています。
0. gitlab.rbの設定
external_url 'http://hogehoge.jp' としています
(このせいでリダイレクトされていると思い、httpsにしてみましたが、通信自体ができなくなります)

###サーババージョン

• GitLab 7.9.4
• GitLab Shell 2.6.2
• GitLab API v3
• Ruby 2.1.5p273
• Rails 4.1.9

###補足

• 社内規定によりLBの証明書をはずして、直接サーバに入れることは極めて難しいです。
• 外部からサーバに直接アクセスさせるのも困難です。

Answer 1

ありがとうございました。

Apacheをあげて、リバースプロキシを使いました。

Answer 2

LB が Nginx ですか？ それともバックエンドWebサーバーが Nginx ですか？

バックエンドWebサーバーからの応答の Location ヘッダにリダイレクト先(http://〜)がありますので、LB で変換する必要があります。Apache httpd なら ProxyPassReverse、Nginx なら proxy_redirect です。

(LB が Nginx の場合の設定例)
proxy_pass      http://backend.example.com/;
proxy_redirect  http://backend.example.com/ /;

バックエンドWebサーバーからの応答が「Location: http://backend.example.com/users/sign_in」ならば、「/users/sign_in」に変換し、プロトコル、ホスト名を補完して「Location: https://hogehoge.jp:8443/users/sign_in」でブラウザに返します。

LB が Nginx でない場合、LB に同等の機能はありませんでしょうか。

Comments

[DJR]

TaichiYanagiyaさま
ご回答ありがとうございます。　LBは当方の管理下になく、OS等の情報はわかりません。
バックエンドのWebサーバはnginxです。GitLabにバンドルされてインストールしたものです。完全ではありませんが、おっしゃった意味は少し理解できました。プロトコル、ホスト名を補完するのは、LBなんですよね。
やっぱりLBに手を入れる必要があるんですかね…。

Answer 3

試していないのですが、
ここで議論されている内容からすると、以下の設定で実現できそうです。

1. external_urlでhttpsを指定する。
2. nginx['listen_https']をfalseに設定する。
3. "X-Forwarded-Proto: https"と"X-Forwarded-Ssl: on"をリクエストヘッダに入れる様にロードバランサを設定する。

英語を誤読していたらすみません。

Comments

[DJR]

eripong様
ご回答ありがとうございます。こちらも詳細英語見てみます。
ただ、LBはこちらの管理下になく結構な手続きを要します。検証も難しくなんとかLBに手を入れず実現したいところです・・・。

[eripong]

なるほど。
"X-Forwarded-Ssl: on"がリクエストヘッダに入れば良いので、
小細工になりますが、LBとGitLabサーバの間にプロキシを挟んで、
"X-Forwarded-Ssl: on"を追加してやれば、動くかもしれません。

[eripong]

"X-Forwarded-Ssl: on"は、既にLBで追加されているかも知れないため、
手順としては不要かも知れません。

1.と2.だけ設定して、試してみても良いかと思います。
余裕があれば、tcpdumpなどでリクエストヘッダを確認して見ると良いかと。

[eripong]

"X-Forwarded-Proto: https"も必要そうなので追記しました。

[DJR]

eripong様
追記ありがとうございました。1をhttpsにするとつなげなくなります。2はgitlab.rbに項目がなかったので追記しましたが、以前と状態変わらずでした。
GIT+nginxを積んでいるサーバのtcpdumpをとって、外部からLB経由でアクセスしたときの今のヘッダを確認してみました。
"X-Forwarded-Ssl: on"、"X-Forwarded-Proto: https"は入っていないようです。
LBにアクセスしたIPアドレスを示す"X-Client: 123.456.78.90"は入っていました。
引き続きサーバ側で何かできないか探って見ます。

[eripong]

ヘッダが入っていませんか。

https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/nginx.md
を見ても、ヘッダは必要そうです。
プロキシを挟むことも難しいでしょうか？

また、「通信自体ができなくなります。」や「つなげなくなります」と言うのは、
ポートは開いているのでしょうか？それとも、エラー画面になる、
エラーログが出るなどでしょうか？

[TaichiYanagiya]

AWS で用意されている AMI をさわってみました。

Nginx が gitlab unicorn のリバースプロキシーで、https を有効にすると、80番、443番で Listen し、443番で受けたときに "X-Forwarded-Ssl: on" ヘッダを付けてバックエンドに渡すよう設定されます(/var/opt/gitlab/nginx/conf/gitlab-http.conf)。

https を有効にしない場合、Nginx は 80番のみで Listen し、"X-Forwarded-Ssl: on" ヘッダは付きませんが、無理やり設定ファイルを修正してヘッダを付けるようにするとどうでしょうか。

server {
listen *:80;
(略)

location /uploads/ {
(略)
proxy_set_header X-Forwarded-Ssl on; ★追加

proxy_pass http://gitlab;
}

location @gitlab {
(略)
proxy_set_header X-Forwarded-Ssl on; ★追加

proxy_pass http://gitlab;
}
}

※先頭の空白が消えてしまうかもしれません。

ただし、"gitlab-ctl reconfigure" を実行すると、設定がリセットされてしまうようです。