数日間、nginxを使用してリバースプロキシを実行するようにUbiquiti ErPoe-5(ファームウェア1.9.1)をセットアップしようとしていますが、問題のほとんどは、取得できないという事実が原因であるようです。デバイス上のnginxの最新バージョン。
tutorials nginxをインストールするために見たのは、WebSocketまたはHTTP2をサポートしていないnginx1.2までしか取得できません。 HTTP2は必須ではありませんが、リバースプロキシを介して公開したい内部リソースにはWebSocketのサポートが必須です。実際のところ、ルーター自体が独自のWeb管理インターフェイスでそれらを使用しており、 ユビキティフォーラムのこの投稿 からもHTTP2が必要になる可能性があります。
注:ファームウェア2.x以降にアップグレードすると、 にリンクされているチュートリアル)に記載されている新しいStretchリポジトリを使用できるようになります。質問 。 Stretchリポジトリは、nginxパッケージをWebSocketとHTTP2をサポートする1.10に更新します。ただし、以下の手順とスクリプトは2.xでも引き続き適用できるため、2.xファームウェア(初期リリース)にアップグレードしたくない人の混乱を避けるために、新しいファームウェア/パッケージバージョンを反映するように回答が更新されていません。ファームウェアの使用により、アーリーアダプターにいくつかの問題が発生し、2.xファームウェアバージョンではパフォーマンスの低下の問題がまだ知られています。
注2:この回答は、一般的なLinuxコマンドについて十分な知識があるか、少なくともSSH経由でルーターにログインできることを前提としています。そうでない場合は、回答または後続のコメントでLinuxスクリプトまたはコマンドの基本をカバーする予定がないため、続行する前に、これらの前提条件を満たすためにスキルを磨く必要があります。
ファームウェア2.xリリースより前は、UbiquitiルーターはDebian7.11をベースにしています。 wheezy-したがって、標準を破ることなく得られる最善の方法は、nginx 1.6です(wheezy
ではなく_wheezy-backports
_リポジトリを使用することによって)。これはWebSocketのサポートでは機能しますが、http2などの新しいオプションはまだありません。
1.14のような新しいバージョンを入手するには、コンフォートゾーンから少し離れて、新しいDebian 9.5リポジトリ(つまり、stretch
と_stretch-backports
_)の使用を開始する必要があります。私は「快適ゾーンを脱出する」と言いますが、これは悪い経験によるものではありませんが、ロジックにより、Ubiquitiが2.xより前のファームウェアバージョンのルーターでwheezy
を使用している理由があると考えられるためです。したがって、ルーターが使用している可能性のある他のパッケージ(libc6など)のアップグレードに依存している場合、stretch
パッケージの使用にはリスクが伴います。
したがって、以下の解決策がルーターの機能を壊さないとは言えませんが、ルーターの機能(openvpnサーバー/クライアント、負荷分散、VLANなど)をかなり使用していると言えます。問題はありませんでした。
また、Ubiquiti EdgeMax OS /ファームウェア(2.0.8)の現在のバージョンを問題なく再フラッシュして、すべてのパッケージをストック/デフォルトバージョンに戻すことができました。 (ただし、ファームウェアを再フラッシュすると、_/config
_ディレクトリに保存しなかった微調整やカスタマイズも消去されることに注意してください。常に_/config
_の下に保存してから、起動スクリプトを追加してください。必要に応じて他の場所でそれらへのリンクを維持する_/config/scripts/post-config.d
_へ)
したがって、将来のUbiquitiアップデートは、このインストール後に正常にインストールされる可能性が高いと言ってかなり安心しています-ただし、nginxを再インストールする必要があります(おそらく以下のスクリプトを使用して)。
通常の免責事項が邪魔にならないので、これが私のために働いていることです。
構成をバックアップします。
すでにnginxをインストールしようとしている場合は、先に進んで最新のファームウェアを再インストールすることもお勧めします。すべてを適切なベースポイントに戻します(通常のCLI構成またはWebインターフェイスオプションの外に微調整/カスタマイズを配置した場合は注意してください-それらを失う可能性があります)。
Webインターフェイスを駆動するサービスをいじくり回すので、SSHからファームウェアアップデートをフラッシュするために必要なコマンドをよく理解するのが賢明でしょう同様に(ヒント:_add system image https://dl.ui.com/firmwares/edgemax/v1.10.x/ER-e100.v1.10.10.5210345.tar
_)。
SSH *をルーターに接続し、次のスクリプト(または同等のステートメント)を実行します。
stretch
および_stretch-backports
_)stretch-backports
_を優先するように設定します(nginx 1.10.3を使用する場合は、以下のスクリプトを変更して、優先度から削除することにより、_stretch-backports
_ではなくstretch
を優先します-910)* Webインターフェイスが一時的に操作不能になる可能性があるため、SSHの代わりにWebインターフェイスのCLI機能を使用しないでください[〜#〜]しないでください[〜#〜]このプロセスの一部です。
_#! /bin/bash
vcfg=/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper
echo Updating package repositories ...
echo
$vcfg begin
$vcfg delete system package
$vcfg set system package repository stretch url http://http.us.debian.org/debian
$vcfg set system package repository stretch components "main contrib non-free"
$vcfg set system package repository stretch distribution stretch
$vcfg set system package repository stretch-backports url http://http.us.debian.org/debian
$vcfg set system package repository stretch-backports components "main contrib non-free"
$vcfg set system package repository stretch-backports distribution stretch-backports
$vcfg commit
$vcfg end
apt-get update
echo
echo Setting repository priorities ...
echo
echo "Package: *
Pin: release a=stretch
Pin-Priority: 900
Package: *
Pin: release a=stretch-backports
Pin-Priority: 910">/etc/apt/preferences.d/stretch
echo
echo Temporarily stopping the current web interface ...
echo
kill -SIGTERM $(cat /var/run/lighttpd.pid)
echo
echo Installing nginx-light ...
echo
echo "#! /bin/bash
[ -d /var/log/nginx ] || mkdir /var/log/nginx">/config/scripts/post-config.d/create_nginx_log_dir
chmod a+x /config/scripts/post-config.d/create_nginx_log_dir
[ -d /var/log/nginx ] || mkdir /var/log/nginx
apt-get install nginx-light -V -y
echo
echo Restarting the old web interface ...
echo
service nginx stop
/usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
echo
echo Updating the nginx default site listen on non-standard ports ...
echo
sed -i -E 's/^(\s*)(listen\s+(:|\[|\])*)([0-9]+)(;|\s)/\1\2\4\4\5/g' /etc/nginx/sites-enabled/default
echo
echo Starting the nginx service ...
echo
service nginx start
echo
echo Installation complete.
_
[回答 "yEnter「サービスの再起動に関するプロンプトへ]
これで、nginxが正常にインストールされ、Webブラウザで_http://<router IP address>:8080
_に移動してテストできるようになります。 _8080
_の使用ポートは、デフォルトのルーターWebインターフェースと競合する可能性が高いデフォルトのポート_80
_ではなく、上記のスクリプトのsed
コマンドで構成する必要があることに注意してください。 。
私は個人的に、ルーターでデフォルトで提供されるlighttpd
service/GUIに非標準ポート(以下の構成例では553)を使用し、次にnginx(標準ポート80/443でリッスン)を次のように使用することを好みます。 lighttpd
のリバースプロキシ。これにより、ルーターを含むすべてのローカルネットワークWebサイト(つまり、router.myhouse.com、nas.myhouse.comなど)に1つのドメイン名を使用できます。同じことを行う場合は、を使用してGUIポートを変更できます。 configure -> set service gui http(s)-port ###
ステートメント、またはWebインターフェイス/ GUIの_Config Tree
_セクションで同じ変更を加える。
次に、いくつかのリソースのリバースプロキシとして機能するようにnginxを構成する必要があります。通常、これは、ルーターのnginxリスニングポートに解決されるURL内の特定のホスト/ドメイン名を使用してアクセスできるローカルネットワークリソースになります。
これを行うには、_/etc/nginx/sites-enabled
_ディレクトリにnginx構成ファイルを作成します(または、_/config/user-data
_の下に作成してから、_/etc/nginx/sites-enabled
_ディレクトリの下にリンクを作成します-これにより、簡単になります_/etc
_ディレクトリの内容をリセットするアップグレードから回復するため)。
オンラインのnginx構成ファイルの例はたくさんありますが、ルーターインターフェイス(またはWebSocketを使用する他のWebサイト)をnginxリバースプロキシの背後に配置する場合は、以下の例が役立つ場合があります。または、Synology NASを背後に配置することを特に検討している場合(特にフォトステーションは少し注意が必要です)。
_upstream edgemax {
server 192.168.1.1:553;
keepalive 32;
}
upstream nas {
server 192.168.1.7:5001;
keepalive 32;
}
upstream nasphoto {
server 192.168.1.5:443;
keepalive 32;
}
upstream nasfile {
server 192.168.1.7:7001;
keepalive 32;
}
server {
listen 443 ssl http2;
server_name router.*;
ssl_certificate /config/user-data/ssl_chain_key.pem;
ssl_certificate_key /config/user-data/ssl_chain_key.pem;
client_max_body_size 0;
proxy_http_version 1.1;
proxy_buffering off;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $Host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
location / {
proxy_pass https://edgemax;
}
}
server {
listen 443 ssl http2;
server_name nas.*;
ssl_certificate /config/user-data/ssl_chain_key.pem;
ssl_certificate_key /config/user-data/ssl_chain_key.pem;
client_max_body_size 0;
proxy_http_version 1.1;
proxy_buffering off;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $Host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
location / {
proxy_pass https://nas;
}
location /photo {
proxy_pass https://nasphoto/photo;
}
}
server {
listen 443 ssl http2;
server_name files.*;
ssl_certificate /config/user-data/ssl_chain_key.pem;
ssl_certificate_key /config/user-data/ssl_chain_key.pem;
client_max_body_size 0;
proxy_http_version 1.1;
proxy_buffering off;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $Host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
location / {
proxy_pass https://nasfile;
}
}
server {
listen 443 ssl http2;
server_name photos.*;
ssl_certificate /config/user-data/ssl_chain_key.pem;
ssl_certificate_key /config/user-data/ssl_chain_key.pem;
client_max_body_size 0;
proxy_http_version 1.1;
proxy_buffering off;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $Host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
rewrite ^/photo/(.*)$ /$1;
location / {
proxy_pass https://nasphoto/photo/;
}
}
_
リバースプロキシ設定ファイルを配置したら、_Sudo service nginx restart
_を実行して有効にすることができます。問題がある場合は、_/var/log/nginx/error.log
_を参照してください。
ヒント#1:nginxリバースプロキシに非標準ポートを使用する予定の場合(つまり、リバースプロキシの設定で_listen 80
_および/または_listen 443
_)の場合、上記の構成の_proxy_set_header Host $Host;
_を_proxy_set_header Host $http_Host;
_に置き換えるとよいでしょう。これは、Webクライアントにデフォルトのポートからのトラフィックを常に要求させたいと思われるWebSocketにとって特に重要です。そうしないと、コンポーネントやライブデータが欠落しているインターフェイスになります。 (_proxy_set_header Host $Host:$server_port;
_を試すこともできますが、元のリクエストで使用されていなくても常にヘッダーにポートが追加されるため、これは明らかに異なることに注意してください)
ヒント#2:_server_name router.*
_の使用にも注意してください。これは、URL _router.<anything>.<anything>
_を使用してnginxリバースプロキシを参照することを意味します。設定のそのセクションが適用されます。 (ほとんどの例では、_router.domain.com
_のような完全/明示的なドメイン名を使用しています)
これは、ドメイン名/ DNS名を変更する可能性がある場合(つまり、構成を変更せずに_router.home.com
_および_router.home.net
_で機能する)だけでなく、_server_name
_を維持するのにも役立ちます。エントリが短い。 nginxを起動すると、名前が長いと「バケットサイズを大きくする」などのエラーが発生することが多いため、これは重要です。長い名前が必要な場合は、構成内で server_names_hash_max_size および/または server_names_hash_bucket_size の値を微調整する必要があります。
UPDATE:ルーターをEdgeOSバージョン1.9.1から2.0.8までのすべてのバージョンに正常に更新しましたが、基本的に問題はありません。更新後、ルーターにはnginxがありませんでしたが(予想どおり)、スクリプト(この回答の最初のコードブロック)を実行でき、すぐに戻ってきました。カスタマイズを_/config
_で維持し、スクリプトを_/config/scripts/post-config.d
_で使用して、再起動/アップグレード後も存続しない変更を維持することが、ここでのスムーズな航海の鍵となります。
UPDATE#2:このプロセスは、ER-Xなどの小型ルーターでも機能します。ただし、デバイスで使用できるストレージが限られているため、nginx用のスペースを確保するために非アクティブなファームウェアイメージを削除する必要があります。これは、各更新後にも実行する必要があります。非アクティブなファームウェアイメージを削除するには、_delete system image
_を実行し、プロンプトに「はい」と答えます。
-私のER-X更新プロセス-
delete system image
_コマンドを使用して古いファームウェア(現在は非アクティブなイメージ)を削除します(_show system storage
_は、削除前に76%が使用され、後で37%が使用されていると報告します)show system storage
_はインストール後に71%が使用されていると報告します)Sudo apt-get clean
_を実行して、一時ファイルなどで使用されているスペースを解放します(_show system storage
_は、クリーンアップ後に56%が使用されていると報告します)