Skip to Content
デプロイオプション企業プロキシの背後で

企業プロキシの背後で

多くの工場ネットワークや企業ネットワークでは、企業の HTTP プロキシ（例：ポート 3128 の Squid プロキシ）経由でしかインターネットに到達できません。IronFlock アプライアンスはこの構成でも問題なくインストール・動作します — インストールコマンドでプロキシを指定すれば、それ以外の設定はすべてインストーラが行います。

このページでは、アプライアンスホストにプロキシ環境変数が一切設定されていないことを前提とします — プロキシは明示的に指定してください。インストーラが自動的に処理する内容と、TLS を傍受するプロキシで必要となる 1 つの追加手順について説明します。

これは、アプライアンスガイドの ファイアウォールの設定 セクションのプロキシ版コンパニオンです。到達可能でなければならない IronFlock エンドポイントは同じです — 違いは、ここではそれらにプロキシ経由で到達するという点です。

プロキシに注意が必要な理由

IronFlock プラットフォームのイメージは Docker デーモンによってプルされます — これはシェルとは別の、独自のネットワーク設定を持つバックグラウンドサービスです。プロキシ経由でインターネットに到達できるホスト上であっても、明示的に伝えない限り、デーモンはプロキシの存在を知りません。設定しないままだと、デーモンは直接接続を試み、ネットワークがそれをブロックし、インストールはタイムアウトとともにログインのステップで停止します。

Error response from daemon: Get "https://instance-registry.ironflock.com/v2/":
net/http: request canceled while waiting for connection (Client.Timeout exceeded)

インストーラが自動的に処理する内容

インストールコマンドでプロキシを指定すると、インストーラが Docker デーモンを設定します — /etc/systemd/system/docker.service.d/http-proxy.conf にプロキシのドロップインを書き込み、IronFlock レジストリに到達できるよう Docker を一度再起動します。このステップは以下の特徴を持ちます。

  • 手間いらず — プロキシを一度指定するだけで（下記参照）、インストーラが設定を書き込み、Docker を再起動してくれます。手動でのデーモン設定は不要です。
  • 冪等 — 以降の更新時には、プロキシが実際に変更された場合にのみ Docker を再起動するため、稼働中のアプリが妨げられることはありません。
  • 完全にスキップ — プロキシが指定されない場合は何も行いません。インターネットに直接接続するインストールには影響しません。

インストーラはさらに、アプライアンス自身のクラウドへの接続もプロキシ経由にルーティングします — ライセンス検証と、ironflock.com からインスタンスに到達できるようにするリモート管理アップリンクです。インストーラはプロキシをアプライアンスの設定に記録し、プラットフォームはそれを自動的に使用します。アプライアンスをオンラインにするために別途の設定は必要ありません。

プロキシの背後でインストーラを実行する

プロキシは 2 か所で必要になります：curl がインストーラをダウンロードするために必要であり、インストーラが Docker を設定するために必要です。1 つのコマンドで両方に渡してください — プロキシ URL を一度設定し、curl には --proxy で、インストーラには --http-proxy / --https-proxy で渡します。

# 御社の企業プロキシ — この行を編集してください
PROXY="http://proxy.your-company.com:3128"
 
curl -fsSL --proxy "$PROXY" \
  https://instance-registry.ironflock.com/dl/appliance/install_ironflock.sh \
  | sudo bash -s -- <your-instance-key> --http-proxy "$PROXY" --https-proxy "$PROXY"

プロキシ URL と <your-instance-key> をご自身の値に置き換えてください。プロキシが認証を必要とする場合は、URL に認証情報を含めてください：http://user:password@proxy.your-company.com:3128。

インストーラのプロキシフラグ：

フラグ用途
--http-proxy <url>Docker デーモンからのプレーン HTTP トラフィック用プロキシ。
--https-proxy <url>HTTPS トラフィック用プロキシ（イメージのプルで重要となるのはこちら）。
--no-proxy <list>プロキシをバイパスすべき追加のホスト（カンマ区切り）。

同じ値を IRONFLOCK_HTTP_PROXY、IRONFLOCK_HTTPS_PROXY、IRONFLOCK_NO_PROXY 環境変数として指定することもできます。

ホストがすでに HTTP_PROXY / HTTPS_PROXY をエクスポートしている場合は、（フラグなしで）sudo -E bash を実行すれば、インストーラがそれらを自動検出します — ただし新規のアプライアンスではこれらは通常設定されていないため、上記のように明示的に渡すのが確実な方法です。

ローカルトラフィックは常にプロキシをバイパスします

NO_PROXY を手動で管理する必要はありません。インストーラは常に localhost、127.0.0.1、およびアプライアンス自身のホストアドレスをプロキシ対象外に保ちます（--no-proxy で渡したものは保持され、マージされます）。これにより、アプライアンスのローカルアプリストアとレジストリには企業プロキシ経由でルーティングされることなく、直接到達されます。

エッジデバイス

上記の内容はすべて、デバイスセットアップツール（ironflock-init）でセットアップするエッジデバイスにも同様に当てはまります。このツールは同じプロキシフラグを受け取り、同じ方法で自身を設定します — 実行時にプロキシを渡せば、ダウンロード（パッケージマネージャ、Docker のインストール、エージェントのダウンロード）と Docker デーモンをプロキシ経由でルーティングしてくれます。

sudo ./ironflock-init -c mydevice.flock \
  --http-proxy "$PROXY" --https-proxy "$PROXY"

セットアップツールをダウンロードするブートストラップスクリプトは、その前に実行されるため、そのステップにもプロキシを渡してください — ダウンロードが成功するよう、まずシェルでエクスポートします。

export HTTP_PROXY="$PROXY"
export HTTPS_PROXY="$PROXY"
curl -sSL --proxy "$PROXY" https://instance-registry.ironflock.com/dl/reswarmify/install.sh | bash

デバイスがクラウドではなくローカルのアプライアンスアプリストアからアプリイメージをプルする場合は、そのレジストリのホストを --no-proxy で追加し、それらのプルがローカルネットワーク上にとどまるようにしてください。

Windows デバイスではエージェントは Windows サービスとして動作します。プロキシはサービスのインストーラーに渡してください — サービス環境に保存され、プラットフォームへの接続とエージェントの自動更新に適用されます：

reagent.exe service install -config path\to\config.flock -proxy "http://proxy.example.com:3128"

Docker Desktop はこの設定を読み取りません。イメージの取得も機能するよう、Settings → Resources → Proxies で別途プロキシを設定してください。

TLS 傍受型プロキシ（企業 CA）

一部の企業プロキシは、会社の認証局（CA）で再署名することで HTTPS トラフィックを検査します。これらの場合、プロキシの設定は必要ですが十分ではありません — アプライアンスホストもその CA を信頼していなければならず、そうでないとすべてのクラウド接続（イメージのプル、ライセンス検証、管理アップリンク）が拒否されます。

CA はホストのシステム信頼ストアに一度だけインストールしてください。アプライアンスはその信頼ストアをすべてのコンテナにマウントするため、Docker とすべての IronFlock サービスが CA を取得します — コンテナごと・サービスごとに設定するものは何もありません。コンテナは起動時にこれを読み込むため、CA を追加または変更した後はスタックを再起動してください（下記のステップ 3）。

1. 企業 CA を入手する

ネットワークチームに、プロキシの**「SSL 検査」/「TLS 傍受」ルート CA**（管理対象の社内マシンにすでに配布されているものと同じ証明書）を .crt ファイルとして依頼してください。これが最もクリーンな入手元です。

単一ホストの証明書ではなく、発行元の CA をインストールしてください。 よくある間違いは、1 つのホスト名（例：instance-registry.ironflock.com のみ）に対してプロキシが再署名した証明書を保存してしまうことです。これではそのホストだけが動作し、それ以外のすべてのクラウドホストは失敗したままになります。必要なのは、それらの証明書に署名する CA です。

ファイルを直接入手できないものの、プロキシがフルチェーンを提示する場合は、通信経路から CA を抽出できます — <PROXY_HOST>:<PROXY_PORT> をご自身のプロキシに置き換えてください。

# チェーンを取得します（証明書ごとに 1 つの PEM）。c1 はホストごとのリーフ証明書です（スキップしてください）。
# c2..cN が信頼すべき企業 CA チェーンです。
echo quit | openssl s_client -connect instance-registry.ironflock.com:443 \
  -proxy <PROXY_HOST>:<PROXY_PORT> -showcerts 2>/dev/null \
  | awk '/BEGIN CERTIFICATE/{n++; c=1} c{print > ("/tmp/proxy-c" n ".pem")} /END CERTIFICATE/{c=0}'
 
# 任意 — 返ってきた内容を確認します：
for f in /tmp/proxy-c*.pem; do echo "== $f =="; openssl x509 -in "$f" -noout -subject -issuer; done

2. インストールして信頼ストアを再構築する

IT チームから .crt を直接受け取った場合：

sudo cp corporate-root-ca.crt /usr/local/share/ca-certificates/corporate-proxy-ca.crt
sudo update-ca-certificates

上記のチェーンから抽出した場合は、リーフ証明書（c1）を除くすべての証明書を信頼します：

i=0; for f in $(ls -v /tmp/proxy-c*.pem | tail -n +2); do
  i=$((i+1)); sudo cp "$f" "/usr/local/share/ca-certificates/corporate-proxy-ca-$i.crt"
done
sudo update-ca-certificates

3. 検証する

これで、すべての IronFlock クラウドホストがプロキシ経由で検証できるはずです — TLS エラーではなく、HTTP ステータスが返ります。

for H in instance-registry.ironflock.com web.ironflock.com cbw.ironflock.com \
         registry.ironflock.com regauth.ironflock.com; do
  curl -x http://<PROXY_HOST>:<PROXY_PORT> -sS -o /dev/null -w "$H -> %{http_code}\n" "https://$H/"
done

5 つすべてで 200、401、404 のようなコードが返れば、CA は正しいです。その後、サービスが反映できるようスタックを再起動します（またはインストーラを再実行します）。

sudo systemctl restart ironflock.service

デバイスユーザーインターフェースへのリモートアクセス

IronFlock では、エッジデバイスやマシン上で動作するユーザーインターフェース — マシンの HMI、PLC ページ、デバイス上の設定画面やダッシュボード画面 — を、どこからでも IronFlock 内で直接開くことができます。これはリモートサービスおよびサポートを可能にする重要な機能です：エンジニアは現地に赴くことも、ローカルネットワークに接続することもなく、マシンのインターフェースに到達できます。アクセスは常に IronFlock の権限システムによって仲介・保護されるため、認可されたユーザーのみが特定のデバイスに到達できます。

このリモートアクセストンネルは、成熟し広く使われているオープンソース技術である **frp（Fast Reverse Proxy）**の上に構築されています。IronFlock はこれを、上記のデバイスインターフェースアクセスを提供する目的のみに使用します。

企業プロキシが妨げになり得る理由

frp は強力なネットワークトラバーサル機能を備えており、そのためアンチウイルスやプロキシのセキュリティ製品は、しばしばこれを一律にリスクウェアとしてフラグします — 長い実績を持つオープンソースコンポーネントとして安全であり、ここでは認可されたリモートアクセス機能のためだけに使われているにもかかわらず、です。これが起こると、プロキシは frp を含む IronFlock コンポーネントのダウンロードをブロックします。

これはアプライアンスを壊すものではありません：リモートアクセストンネルは任意の機能であるため、そのコンポーネントがブロックされても、プラットフォームは通常どおりインストール・動作し、単にデバイスインターフェースアクセスなしで稼働します。ダッシュボードでは、デバイスのリモートアクセス制御が、このアプライアンスではリモートアクセスが利用できない旨を表示します。

企業 IT が許可すべきこと

御社が IronFlock のリモートサービス機能を活用したい場合は、frp を含む IronFlock コンポーネントが企業プロキシ経由でダウンロードできるよう許可する必要があります。ネットワーク／セキュリティチームに以下を依頼してください。

  • frp コンポーネントについて、IronFlock のダウンロードトラフィックをアンチウイルス／マルウェアのコンテンツスキャンおよびファイルダウンロードのブロック対象から除外してください — 最もクリーンな方法は、IronFlock のエンドポイントをプロキシの復号しない（TLS 検査バイパス）リストに追加することです。
  • frp の検出を承認済みの例外として扱ってください：これは、このオープンソースライブラリの正当な利用に対する、よく知られた誤検知です。

アプライアンス向けにすでに列挙されているものと同じ IronFlock エンドポイントが適用されます — ファイアウォールの設定 を参照してください。ここでの話は、そのトラフィックを単にルーティングすることに加えて、それをスキャン／ブロックしないようにするという点です。

frp の通過が許可されたら、あとはアップデートを再実行するだけです — ダウンロードが成功次第、他に何の変更もなく機能が自動的に有効になります。

sudo ironflock-update

リモートアクセスなしで実行する

デバイスインターフェースアクセスが不要な場合 — あるいはプロキシの例外設定を手配する間、クリーンなインストールを行いたい場合 — は、トンネルを明示的に無効化できます。それ以外はすべて通常どおりインストールされます。

# インストール時に、インストールコマンドへ追記します
... | sudo bash -s -- <your-instance-key> --no-tunnel
 
# または、すでにインストール済みのアプライアンスで
sudo ironflock-update --no-tunnel

この選択はアップデートをまたいで記憶されます。あとで（frp が許可されたら）--tunnel で再度有効化できます。

sudo ironflock-update --tunnel

トラブルシューティング

インストールが Client.Timeout エラーとともに「Logging in to instance-registry.ironflock.com」で停止する。 Docker デーモンがレジストリに到達できていません。インストーラを再実行し、上記のように --http-proxy / --https-proxy でプロキシを渡してください。

プロキシを設定してもログインが依然として失敗する。 プロキシが TLS を傍受している可能性が高いです。TLS 傍受型プロキシ で説明したように企業 CA をインストールし、その後再実行してください。

Docker デーモンがプロキシを認識しているか確認します：

sudo systemctl show --property=Environment docker
sudo docker login instance-registry.ironflock.com

docker login 単体で成功すれば、アプライアンスのインストールは失敗していたステップを通過できます。

他はすべて問題なくインストールされるのに、単一のコンポーネントだけダウンロードに失敗する。 これは通常、frp ベースのリモートアクセスコンポーネントが、プロキシやアンチウイルスによってリスクウェアとしてブロックされているためです。インストール自体は完了します — デバイスインターフェースアクセスだけが利用できません。これを有効にするには、デバイスユーザーインターフェースへのリモートアクセス で説明したように、プロキシチームにそのトラフィックを許可してもらったうえで、ironflock-update を再実行してください。意図的にこれなしでインストールするには、--no-tunnel を渡してください。

アップデート

アプライアンスがプロキシの背後でインストールされると、そのプロキシ設定は記憶されます。手動アップデートとバックグラウンドの自動アップデートのいずれも、追加の操作なしにプロキシ経由で引き続き動作します — アプライアンスガイドの メンテナンス を参照してください。

デバイスインターフェースへのリモートアクセス がインストール時にブロックされていた場合、すべてのアップデートで自動的に再試行されます — そのため、プロキシが frp を許可すれば、次回のアップデートで追加の手順なしにこの機能が有効になります。

Last updated on
IronFlock プライベートクラウドHTTPS と証明書