このガイドでは、NGINXのインストールと構成について説明し、単一の公開IPアドレスの背後で複数の物理サーバー、仮想マシン、または両方の組み合わせを実行できるようにします。仮想マシン上で多数のWebサーバーを実行してローカルで管理することを選択することも、各ホストへのSSHなどのリモートアクセスツールを使用する必要がある場合もあります。たとえば、通常の営業時間外にローカルアクセスが利用できない場合です。このガイドは、両方のシナリオを容易にすることができます。
ここに示す構成は、使用可能なパブリックIPアドレスに制限があるホームラボまたはスモールビジネスネットワークに最適です。ホスティングサービスから複数のサーバーまたは仮想マシンをレンタルしている場合、このような構成を実行する理由はほとんどありません。いずれにせよ、サーバーまたはホストごとに公開IPアドレスが割り当てられます。
NGINXをインストールし、サーバーがHTTP（S）、SSH、FTP、およびMySQL/MariaDBのリバースプロキシとして機能できるようにする構成を作成する方法を説明します。 NGINXホストサーバーの場合、ローカルアクセス、Ubuntu 18.04の新規インストール、およびUbuntuサーバーのインストール手順中にSSHサーバーをインストールすることを選択したと思います。
この構成は私にとってはうまく機能しますが、これがあなたのために機能することを保証することはできませんのでご了承ください。もちろん、何かおかしいと思ったら、訂正できるように知らせてください。始める前に、ガイド全体を必ずお読みください。ガイドを管理する2つの方法を示す1つの部分（ストリーム）があります。
このガイドでは、次のホスト名とIPアドレスを使用します。
rproxy.example.com 192.168.1.1 web1.example.com 192.168.1.2 db1.exmple.com 192.168.1.3
インストール中に作成した標準のUbuntu18.04サーバーのインストールでは、サーバーにroot以外のユーザーアカウントが必要です。そのユーザーと一緒にNGINXをインストールするサーバーにログインすることから始めます。これはローカルサーバーである可能性が高いため、SSHサーバーを構成するには、最初にサーバーに直接ログインする必要がある場合があります。もちろん、これを行うには、サーバーに接続されたキーボードとモニターが必要です。
注：私のように、ブラウザインターフェイスを含むVMWareなどの仮想化ソフトウェアを使用している場合は、そのシステム内にコンソールが必要であり、「直接」アクセスせずにこの手順を実行できます。そのコンソール内でこの構成全体を実行しようとすることもできますが、コピーアンドペーストなどの一部の機能はブラウザーベースのコンソールでは機能しませんでしたが、これはブラウザー固有である可能性があるため、試してみる価値があるかもしれません。できます。
コンソールシェル（ブラウザまたは直接接続）
sudo nano /etc/ssh/sshd_config
行のコメントを解除します。ポートは、ポート番号を23456、ListenAddressなどに変更し、0.0.0.0に変更します。 nanoに慣れていない場合は、CTRL + Xを押し、yと入力して、Enterキーを押します。これにより、ファイルが保存されて閉じられます。ファイルに変更が加えられていない場合、CTRL + xは、保存を求めるプロンプトを表示せずにファイルを閉じます。コマンドプロンプトに戻ります。
これはすでにかなり長いガイドであり、SSHキーの使用やルートSSHの許可など、さまざまな目的で変更する必要のある設定を示すガイドが多数あるため、このファイル内の残りの設定については詳しく説明しません。ログインする。これらのガイドは、HowtoForgeのWebサイトでも見つけることができます。
変更が完了したら、変更を有効にするためにsshサーバーを再起動する必要があります。現在のログインは、この再起動の影響を受けません。
systemctl restart ssh
ローカルネットワーク内の別のコンピューター上の端末からSSHを使用してログインできることを確認します。
ssh [email protected] -p23456
SSHを使用して正常にログインし、コンソール/サーバーからログアウトした後は、このターミナルを開いたままにします。このガイドの残りの部分では、これを使用する必要はありません。
この時点から、ターミナルからルートレベルのコマンドを実行するようになります。次のコマンドを使用すると、後続のコマンドの前にsudoを付ける必要がなくなります。
sudo -s
Aptパッケージデータベースを更新し、Ubuntuをアップグレードして、最新のパッケージがインストールされていることを確認します。
apt update && apt -y upgrade
アップグレード中に新しいカーネルがインストールされていることを報告するものが表示された場合は、aptのアップグレードが完了したら再起動して、完全に更新されたシステムで作業していることを確認する必要があります。
hostnamectl set-hostname rproxy.example.com
仮想サーバーを実行している場合は、ここで設定されているホスト名を保持するために変更が必要なcloud.cfgという名前のファイルがある可能性があります。次のコマンドは、コンテンツを含むファイルまたは空のページを表示します。空のページが表示された場合は、CTRL + xを押すだけで、何もすることがないため、この手順をスキップできます。
nano /etc/cloud/cloud.cfg
ホスト名の保持行をtrueに変更し、ファイルを閉じる/保存します。
If your system is currently local only you will need to show this server where your other servers/virtual hosts are.
nano /etc/hosts
変更を加えると、hostsファイルは次のようになります。IPアドレスとホストは独自のインフラストラクチャと一致する必要があります。
127.0.0.1 localhost 127.0.1.1 rproxy.example.com 192.168.1.2 web1.example.com 192.168.1.3 db1.example.com # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters
NGINXのインストール
apt install -y nginx
インストール後、NGINXのバージョンを確認する必要があります。SSHおよびMySQL / MariaDBのリバースプロキシを使用できるようにするには、バージョン1.9以降を使用することが最も重要です。
nginx -v
ご覧のとおり、Ubuntu 18.04（2019年10月10日）のデフォルトであるNGINXバージョン1.14がインストールされています
nginx version: nginx/1.14.0 (Ubuntu)
NGINXをリバースプロキシとして機能させるための準備
この構成では、リバースプロキシホストサーバーから直接Webサイトにサービスを提供することはありません。 / etc /nginx/の下に新しいディレクトリ構造を作成します。これにより、後でこれらの変更を元に戻したい場合や、実際にこのホストから直接Webサイトにサービスを提供したい場合に、デフォルトのNGINX構成が保持されます。これらのリバースプロキシ構成と一緒にデフォルト構成を実行することは可能ですが、Apache2が同じサーバー上にある場合は、リッスンするための代替ポートが必要であり、Apache2のこのインスタンスがサービスを提供するWebサイトをリバースプロキシする必要があります。
cd /etc/nginx && mkdir rproxy && cd rproxy && mkdir http http/available http/enabled stream stream/available stream/enabled
構造が整ったので、構成ファイルの作成に進むことができます。私はnanoを使用していますが、使い慣れたエディターを使用できます。 Nanoは、保存時にファイルを作成/更新します。
Before you proceed, open an empty document on your computer or get a pen and paper to note down the ports you configure.
Webサーバーのリバースプロキシ（http）の構成
それに応じて調整するWebサイトのhttp構成ファイルを作成します
nano http/available/example.com.conf
サーバーブロックをターミナルで開いたページにコピーし、それに応じてnanoを調整します。
# Note down ports 80 and 443
server {
server_name example.com www.example.com;
listen 80;
set $upstream 192.168.1.2;
location / {
proxy_pass_header Authorization;
proxy_pass http://$upstream;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_buffering off;
client_max_body_size 0;
proxy_read_timeout 10000s;
proxy_redirect off;
}
} SSH、MySQL / MariaDBリバースプロキシ（ストリーム）の構成
先に進む前に、ホストごとまたはサービスごとに、どちらを利用するかを決定します。ホストごとに、ホストごとに構成を作成します。これは、単一のホストの設定をすばやく変更するのに役立つ場合があります。サービスごとに、SSH、MySQL / MariaDB、FTPの各サーバーのファイルにすべてのサーバーのサービスポートがあります。
SSH構成を追加します。
nano stream/available/ssh.conf
# Note down the listen ports
upstream web1-ssh {
server 192.168.1.2:22;
}
server {
listen 22002;
proxy_pass web1-ssh;
}
upstream db1-ssh {
server 192.168.1.3:22;
}
server {
listen 22003;
proxy_pass db1-ssh;
}
# Add as many upstream and server block pairs as you will need for your remote accessed SSH servers.
MySQL/MariaDB構成を追加します。
nano stream/available/db.conf
# Note down the listen ports
upsteam db1-mysql {
server 192.168.1.3:3306;
}
server {
listen 33063;
proxy_pass db1-mysql;
}
# Add as many upstream/server block pairs as you will need for your remote accessed MySQL/MariaDB servers to this file.
次に、FTPリバースプロキシ構成を作成します。
nano stream/available/ftp.conf
upstream web1-ftp {
server 192.168.1.3:21
}
server {
listen 21002;
proxy_pass web1-ftp;
}
# Add as many upstream/server block pairs as you will need for your remote accessed FTP servers.
nano /etc/nginx/rproxy/stream/available/web1.example.com.conf
# Note down the listen ports
upstream web1-ssh {
server 192.168.1.3:22;
}
server {
listen 22002;
proxy_pass web-ssh;
}
db1.example.comのホストファイルを作成する
nano /etc/nginx/rproxy/stream/available/db1.example.com.conf
# Note down the listen ports
upsteam db1-mysql {
server 192.168.1.3:3306;
}
server {
listen 33063;
proxy_pass db1-mysql;
}
upstream db1-ssh {
server 192.168.1.3:22;
}
server {
listen 22003;
proxy_pass db1-ssh;
}
ご覧のとおり、少し変わっています。非標準的な方法でパブリックポートを使用しており、必要なポートを選択してからNGINXをポイントしています。これは、リモートでアクセスするサーバーごとにサービスごとに異なるポートを使用していることを除いて、正常です。つまり、SSHを例として使用すると、SSH対応ホストごとに異なるポート番号22 222 2222 22222は、たとえば、4つの異なるサーバーまたは仮想マシンのポート22を指します。
これは、NGINXがWebサイトのリバースプロキシに当てはまらない場合です。ただし、NGINXにWebサイト用に定義されたサーバー構成がある限り、ポート80と443が転送されるだけで正しく機能します。
この時点で、HTTPステップを使用してストリームステップをスキップし、代わりに複数のサービスの複数のポートを適切なサーバー/IPアドレスに転送できることに気付いたと思います。確かに、これは行うことができます。ただし、ssh、mysql、およびftpの各サーバーのデフォルトのポートを変更する必要がある場合があるため、サーバーの数が増えると、さらに複雑になり、保守が困難になります。この構成はすでに複雑ですが、必要に応じて行うこともできます。
私が示した方法でこれらのサービスにリバースプロキシを使用すると、これらの構成を変更するための単一の場所を提供することで複雑さが大幅に軽減され、インフラストラクチャ全体のポートを変更する必要がなくなります。
この構成への追加のボーナスとして、インフラストラクチャ内の他のサーバーは、必要に応じてローカルインターフェイスとデフォルトポートでリッスンする必要があります。ローカルで管理している場合は、ローカルIPアドレスとデフォルトのサービスポートを使用して必要なサービスにアクセスできるため、メモを参照して正しいポートを覚える必要はなく、IPアドレスとログイン資格情報を知っているだけで済みます。
NGINXリバースプロキシ構成の使用を開始するには、メイン構成ファイルを編集する必要があります。 httpブロックの現在のインクルード行をコメントアウトします（NGINXから直接Webサイトを提供していない場合も）。
cd /etc/nginx && nano nginx.conf
以下の強調表示された部分に注意して、何を変更する必要があるかを判断してください。
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
events {
worker_connections 768;
# multi_accept on;
}
http {
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# SSL Settings
##
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;
##
# Logging Settings
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
##
# Gzip Settings
##
gzip on;
gzip on;
# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascri$
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
# include /etc/nginx/sites-enabled/*;
# Reverse proxy http configuration files.
include /etc/nginx/rproxy/http/enabled/*.conf;
}
stream {
# Reverse proxy stream configuration files.
include /etc/nginx/rproxy/streams/enabled/*.conf;
}
#mail {
# # See sample authentication script at:
# # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
#
# # auth_http localhost/auth.php;
# # pop3_capabilities "TOP" "USER";
# # imap_capabilities "IMAP4rev1" "UIDPLUS";
#
# server {
# listen localhost:110;
# protocol pop3;
# proxy on;
# }
#
# server {
# listen localhost:143;
# protocol imap;
# proxy on;
# }
#}
まず、すべてのhttp構成を有効にします
ln -s /etc/nginx/rproxy/http/available/*.conf /etc/nginx/rproxy/http/enabled
すべてのストリーム構成を有効にする
ln -s /etc/nginx/rproxy/stream/available/*.conf /etc/nginx/rproxy/stream/enabled
テストを実行して、リバースプロキシとしてのNGINXの構成が正しいことを確認します。
nginx -T
出力には、以前に作成したすべてのカスタム構成とともに成功メッセージが表示されます。
NGINXを再起動して、リバースプロキシ構成を実行します。
systemctl restart nginx
NGINXが構成されたすべてのポートでリッスンしていることを確認してください。すべてのポートが結果に表示されていることをメモと照合してください。
netstat -tulpn | grep nginx
出力は次のようになります
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:22002 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:22003 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:33062 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:33063 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 4964/nginx: master
NGINXがリッスンし、トラフィックを許可するすべての接続のリバースプロキシとして機能する準備ができたので、次の手順を実行する間、UFWを一時的に無効にします。正常に機能していない場合のトラブルシューティングが容易になります。
ufw disable
残念ながら、ここではご案内できません。これを行う方法については、ルーターのマニュアルを参照するか、ルーターをオンラインで検索する必要があります。ただし、要約すると、NGINXがリッスンしている各ポートをNGINXホストマシンに転送する必要があります。特定のルーターで、カスタムの「アプリケーション」を設定できます。
これにより、割り当てられていないポートまたはポート範囲をカスタムアプリケーションにいくつでも割り当てることができ、LANIPアドレスまたはホスト名で識別される特定の接続デバイスに割り当てられます。いずれにせよ、これは、すべてのポートを削除して再割り当てすることなく、そのカスタムアプリケーションに割り当てられたすべてのポートをネットワーク上の任意のホストに切り替えることができることを意味します。これは優れたオプションであり、これをサポートするルーターを選択することを強くお勧めします。
ルーターのファイアウォールにあるこの小さいながらも非常に便利な機能により、アクティブなリバースプロキシの構成をミラーリングする2番目のリバースプロキシをインストールするように促されました。電源をオフにして、起動してから3分以内にポートを切り替えることができます。災害復旧のためのそのターンアラウンドタイムを満たすのに苦労するプロのホスティング会社があると思いますが、これはすべて、ホームネットワーク上で複数のサーバーを実行したいという願望のために起こりました。
リバースプロキシサーバー用の無料のLetsencryptSSL
CertbotおよびCertbotNGINXプラグインをインストールします。証明書にリストされているすべての（サブ）ドメイン名に対して機能するDNSがあり、HTTPを介してドメインに接続できるようになるまで、証明書を作成できないため、この手順はここで実行されます。ポートをリバースプロキシに転送した後にこれを完了すると、構成に対する追加のテストとしても機能します。ドメインに到達できないために証明書が失敗した場合は、出力に意味のあるエラー通知が表示されます。
最新のcertbotバージョンを取得していることを確認するには、インストールする前にcertbotリポジトリを追加します。 Ubuntuリポジトリは、多くの場合、ソフトウェアバージョンよりも1バージョン以上遅れているため、入手できる場合は、すべてのソフトウェアの最新のステーブルバージョンが本当に必要です。
add-apt-repository ppa:certbot/certbot
apt install -y certbot python-certbot-plugin
certbotとcertbotnginxプラグインをインストールすると、NGINXの証明書を作成できるようになります。
このコマンドは、SSLを提供するすべてのドメインとサブドメインに対して繰り返す必要があります。 certbotを初めて実行する場合は、利用規約に同意する必要があります。
certbot --nginx -d example.com -d www.example.com
アップストリームホストでSSLを使用してサーバーをセットアップしている場合は、ここで選択したオプションがホストサーバーのオプションと一致していることを確認する必要があります。具体的には、アップストリームサーバーでhttpsにリダイレクトする場合は、ここでもそうする必要があります。 。
わかりやすくするために、example.comは別のサーバーに存在し、ISPConfig内でhttpをhttpsにリダイレクトすることを選択したので、そのため、ここでそれを行うことを選択します。構成ファイルが更新され、Certbotが独自の構成をいくつか追加したことがわかります。
トラフィックがリバースプロキシに流れることができるようになったので、すべてが意図したとおりに機能していることを確認する必要があります。 Webサイトが正しく機能していることを確認し、SSH、FTP、およびMySQL/MariaDBの接続とタスクを実行します。すべてが正常に動作していることを確認したら、UFWを有効にし、各ポートを許可するルールを追加します。
ufw enable
どこからでも80と443を許可する必要があります。 SSH、FTP、MySQL/MariaDBをIPアドレスまたはホスト名に制限する可能性があります。ルールにコメントを付けると、ポートを割り当てたサービス/サーバーをすばやく特定できます。
ufw allow 80
ufw allow 443
ufw allow from 1.2.3.4 to any port 22002 comment 'web1 SSH'
ufw allow from somehost.domain.com to any port 33061 comment 'db1 MySQL/MariaDB'
ufw reload
ufw status numbered
リバースプロキシの背後で実行している場合、Apache2ログファイルは、Webサイト訪問者のIPアドレスではなく、リバースプロキシサーバーのIPアドレスを記録します。通常のIPアドレスログをApache2に戻すために、この動作を修正するモジュールを利用できます。
Apache2インスタンスがインストールされている各Webサーバーで次の手順を実行します。
sudo apt install -y libapache2-mod-rpaf
Apache2が正しいIPアドレスを記録するようにするには、rpaf.confファイルに小さな変更を加えます。 Ubuntu 18.04はすでにファイルを作成しているので、ファイルを編集して、強調表示されたIPアドレスをNGINXリバースプロキシホストのIPアドレスに変更するだけです。
nano /etc/apache2/mods-available/rpaf.conf
<ifmodule rpaf_module="">
RPAFenable On
# When enabled, take the incoming X-Host header and
# update the virtualhost settings accordingly:
RPAFsethostname On
# Define which IP's are your frontend proxies that sends
# the correct X-Forwarded-For headers:
RPAFproxy_ips 127.0.0.1 ::1
# Change the header name to parse from the default
# X-Forwarded-For to something of your choice:
# RPAFheader X-Real-IP
</ifmodule> サーバーまたは仮想マシン内の同じポートで2つのサービスがリッスンすることはできません。 NGINXがApache2Webサーバーと同じサーバーまたは仮想マシンにインストールされている場合は、Apache2がリッスンするポートを変更する必要があります。 NGINXは、HTTP（S）機能を実行するためにポート80と443を必要とします。これらはHTTPとHTTPSのデフォルトポートであるためです。
このガイドのhttpセクションに戻って参照し、ネットワーク内の他のサーバーと同じ方法で、このApache2インスタンスによって提供されるWebサイトのリバースプロキシ構成を追加します。
Apache2リッスンポートの変更
ISPConfigなどのサーバー管理システムがインストールされている場合、このシステムはApache2 vhostファイルを処理するため、Apache2がリッスンしているポートを変更する方法を調査する必要があります。 ISPConfigフォーラムを検索し、必要に応じてそれらの調整を行います。それ以外の場合は、これらの変更を実行する方法について、UbuntuフォーラムまたはApache2Webサイトを参照する必要があります。
Note: Apache2 ports do not need to be altered when it is the only web server installed on server or virtual machine.