DevOps /管理者の作業では、誰かがどこかへのアクセスを緊急に許可する必要がある場合がしばしばあります。 Dockerインスタンス、多数のコンテナの1つ、または何らかの内部サービスです。
トラフィックプロキシ、サーバー間の負荷分散、および異種サービスの統合に役立つその他の便利な機能に関するnginxの機能については、誰もが知っています。 ただし、開発プロセスで発生する問題を解決するタスクははるかに広範囲です。
この記事の主なメッセージは、閉じたセグメント内で一時的なアクセスを提供するなど、一見単純なものに対する非標準的なアプローチを示すことです。
簡単なものから始めましょう。
閉じたゾーンがあり、その内部でデータベース、Webサービス、その他のさまざまなインスタンスが回転しています。 通常、nginxはこれらすべての前に立ち、トラフィックを「駆動」します。
たとえば、MySQLまたはMariaDB用のGalera Clusterを検討してください。
Galera Clusterは、複数のMySQLまたはMariaDBインスタンス用のオンラインブロックレプリケーションシステムです。
クラスターをセットアップするための多くの指示があり、それぞれにストリームモジュールとnginxがあります。 構成ファイルのクラシックバージョンは、このようなものです。
stream { error_log /var/log/nginx/mariadb-balancer-error.log info; upstream db { server 172.16.100.21:3306; server 172.16.100.22:3306; server 172.16.100.23:3306; server 172.16.100.24:3306 backup; server 172.16.100.25:3306 down; } server { listen 3306; proxy_pass db; proxy_connect_timeout 1s; # detect failure quickly } }
nginxがインストールされているホストでは、待機ソケットが開かれ、このソケットへの着信接続は組み込みのnginxバランサーによって処理されます。 dockerまたはkubernetesが使用されているシステムでは誰もが理解しているように、このコンテナまたはそのコンテナが実行されているホストへのサービスの厳密なバインドはありません。 次に、DNS解決が作用し、バランサーをバイパスして特定のノードと特定のMySQLインスタンス（MariaDB）に接続する必要があるまで、これはすべて正常に機能します。 そして、この場合、静的構成は非常にボトルネックです。
私は何につながっていますか。
回路内にさまざまなサービスがある場合のオプションを検討してください。ただし、ファイアウォールとnginxで開いている同じポートでアクセスできる必要があります。 Prod、Dev、および独自のssh、mysql、nginx、Apacheバンドルなどの3つの独立したインスタンスが回転する3つのノードがあるとします。
HTTP / HTTPSの観点からは問題はありません。 仮想サーバーのパックを作成し、必要な各ドメイン名にバインドします-要求が来ました-サーバー名は要求から決定されました-接続は必要なインスタンスに行きました。 利益！
ssh、mysql、postgresqlなどのサービスは仮想化の方法を知らないため、多くの場合、インスタンス内で接続を整理するには、タンバリンとダンスを手配してファイアウォールのポートを開き、転送パッケージを整理し、マルチホームソースルーティングなどを行う必要があります。
ソリューション自体は表面にありますが。 フォワードパッケージは良いことですが、アクティブな開発モードで着信トラフィックを処理するノードでファイアウォールのルールを編集することはあまり便利ではありません。
ほとんどのnginxメカニズムは場所で機能し、ストリームでは機能しません。
ただし、最小限の労力でリソースへの動的接続のプロセスを最適化できる小さな抜け穴がありました。 これを行うには、memcachedまたはredisデータベースをデータベースバックエンドとして持つローカルDNSリゾルバーが必要です。
一番下の行は次のとおりです。 クライアントからサーバーへの接続を開始すると、nginxは、ポート5353でリッスンしているローカルリゾルバー127.0.0.1のssh.localまたはmysql.localゾーンのクライアントIPアドレスを解決しようとします。サーバーdns応答は、接続が転送されるループ内のサーバーアドレスである必要があります。 Nginxは残りの作業自体を行います。
stream { error_log /var/log/nginx/ssh-forward-error.log debug; resolver 127.0.0.1:5353 valid=10s; map $remote_addr $sshtarget { default $remote_addr.ssh.local:22; } map $remote_addr $mysqltarget { default $remote_addr.mysql.local:3306; } server { listen 2223; proxy_pass $sshtarget; proxy_connect_timeout 1s; # detect failure quickly } server { listen 33306; proxy_pass $mysqltarget; proxy_connect_timeout 1s; # detect failure quickly } }
クライアントのアドレスが対応テーブルに見つからない場合、デフォルトで何を与えるかは、システム管理者次第です。 存在しないアドレス127.0.0.2などを返すことができます。
存在しないアドレスへの接続がnginxに代わって行われるという事実に注意を喚起したいので、この接続スキームを使用するときは注意が必要です。 DNSサーバーを作成するか、既製のサーバーを使用するかについては、誰もが自分で決定します。 サーバーをPythonで取得し、数行でデータベースにクエリを追加するか、この構成がテストされた真珠で古いプロジェクトを取得できます。
データベースコンテンツ管理は、あらゆるものに実装できます。 主なことは、誰がいつどこに行くべきかを理解することです。
実際、「フォースのダークサイド」はなぜですか？ 本質的に、このスキームは、単一のエントリポイントでこの情報を提供するさまざまな輪郭からさまざまな時間間隔でさまざまな情報を表示することを可能にします。 特定の瞬間にどの回路のどの情報ブロックが表示されるかはわかりません。
確立されたキープアライブSSLトンネルは継続的な接続を提供し、dnsデータベースから自動クリーニングモードのエントリが欠落すると、同じIPを持つ別のホストがリソースに接続できなくなります。
会社の内部リソースの管理システムまたは管理システムに以前にログインし、ポートを内部サーバーに転送したことがある人のための閉じた企業ポータルを考えてみましょう。 このスキームを使用して、RDGatewayを使用せずに、ユーザーの承認に従って、ネットワーク上の特定のコンピューターにrdp接続を一時的に転送します。 顧客は、閉じたゾーン内の特定の回線にアクセスする必要がある場合があり、この一時的なアクセススキームはうまく機能します。
次のように、このスキームを継続的に使用することをだれにも勧めません。 まだ十分に安全ではありませんが、重要な瞬間にnginxの背後にある回路内の状況に影響を与える機会があります。
©Aborche 2017
