SSLを使用するサイトのリバースプロキシとしてのNginx

はじめに



nginxをApacheのフロントエンドとして設定する方法と、それが必要な理由は、Habréを含めて繰り返し書かれています。 私のケースはクラシックとは少し異なります。 それはすべて通常どおり開始され、Apacheのプロジェクト、訪問者数の増加、それに関連してサーバーリソースが不十分でした。 しかし、プロジェクトはクライアントとの通信を保護するためにSSLを使用しました。 私が遭遇したことと、カットの下で伝える問題をどのように解決したか。



問題



クライアントリクエストの直接受信はnginxに渡されるため、SSLでの作業はそこに転送する必要があります。 ハングしましたがループバック127.0.0.1:8080のApacheは、SSLサポートを必要としませんでした。 最初の問題は、証明書がThawteからのものであり、中間証明書を使用する必要があることでした。 Nginxには、このような証明書を使用するための特別なディレクティブはありません。 Apacheの設定では、次のようになりました。



<VirtualHost 1.2.3.4:443> ... SSLEngine on SSLCertificateFile /usr/local/ssl/www.blabla.ru/public.crt SSLCertificateKeyFile /usr/local/ssl/www.blabla.ru/private.key SSLCACertificateFile /usr/local/ssl/www.blabla.ru/intermediate.crt ... </VirtualHost>
      
      





nginxでSSLCACertificateFileをどうするか? 2つのファイルの内容を1つ(公開証明書に続いて中間)に配置することで、2つのファイルを「マージ」するだけでよいことがわかりました。



 cd /usr/local/ssl/www.blabla.ru cp public.crt public_concat.crt cat intermediate.crt >> public_concat.crt
      
      





これで終わりです。nginxでは次のように記述します。



  server { listen 1.2.3.4:443; server_name www.blabla.ru; ssl on; ssl_certificate /usr/local/ssl/www.blabla.ru/public_concat.crt; ssl_certificate_key /usr/local/ssl/www.blabla.ru/private.key; ... }
      
      





保護されていないサイトから保護されたサイトへのリダイレクトは、セットアップに問題を引き起こしませんでした。



  server { listen 1.2.3.4:80; server_name www.blabla.ru blabla.ru; # rewrite ^(.*) https://www.blabla.ru$1 permanent; return 301 https://www.blabla.ru$request_uri; }
      
      





困難はajaxから始まりました。 サーバーへの非同期リクエストはhttp://プレフィックスを使用して実行されたため、ajaxに有害なリダイレクト301が発生しました。環境変数、特にプロトコル名をnginxからapacheに転送する必要がありました。

nginxの場合:



  server { ... location / { ... proxy_set_header X-Forwarded-Proto $scheme; ... } ... }
      
      





Apacheで最も重要なことは、仮想ホストの定義で指定することです。



 <VirtualHost 127.0.0.1:8080> ServerName www.blabla.ru ... SetEnvIf X-Forwarded-Proto https HTTPS=on ... </VirtualHost>
      
      





これで、すべてのajaxリクエストはhttps://必要に応じて送信されます。 このトリックのために、Apache setenvif_moduleモジュールをインストールし、設定で有効にする必要があります。



 LoadModule setenvif_module libexec/apache22/mod_setenvif.so
      
      





一部のアプリケーションは、環境変数を使用して自分でパスを決定できることも覚えておく必要があります。 たとえば、リソースの開発者が必要とするphpMyAdminは、設定でフルパスが指定されていない場合、ポートとともにそれ自体を形成します。 だから私は次のようなものを得ました:



 https://www.blabla.ru:80/myadmin
      
      





80がすべてを台無しにしましたが、phpMyAdminはSSL保護エラーがあったというscりで開きませんでした。 上記のように、phpMyAdmin configでパスを直接指定することで修正されました。



 $cfg['PmaAbsoluteUri'] = 'https://www.blabla.ru/myadmin';
      
      







既存のロギングスキームを保存するために、Apacheで訪問者の実際のIPアドレスを転送することを忘れないでください。 これは繰り返しペイントされ、apache rpaf_moduleモジュールに向かって掘り下げられます。



PS:すべてがFreeBSD 8.2、Apache 2.2.22_5、nginx-1.0.14.1で行われました。 メモを膨らませないように、構成の全文をアップロードしませんでした。 同じ理由で、実際のIPクライアントとrpaf_moduleモジュールの転送に焦点を当てました。 必要に応じて-レイアウト。



All Articles