企業プロキシの背後で

多くの工場ネットワークや企業ネットワークでは、企業の 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 からインスタンスに到達できるようにするリモート管理アップリンクです。インストーラはプロキシをアプライアンスの中央設定ファイル /opt/ironflock/.env に記録し、プラットフォームはそれを自動的に使用します — 以降のすべてのアップデートでも、このファイルが引き続き正式な設定元となります（後からプロキシを変更または削除する を参照）。アプライアンスをオンラインにするために別途の設定は必要ありません。

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

プロキシは 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:[email protected]:3128 — どのアカウントを使用すべきかについては、プロキシ認証 を参照してください。

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

同じ値を 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 ホストのネットワーク ID のプロキシ側にあたる設定です。

• サポート対象：Basic 認証。 アカウントをプロキシ URL — http://user:[email protected]:3128 — に含め、インストールコマンドで指定するか、/opt/ironflock/.env に記載したうえで sudo ironflock-update を実行します。パスワード内の特殊文字は URL エンコードしてください（例：@ → %40）。
• 現時点では未サポート：Windows 統合認証（Kerberos、NTLM）。プロキシがそれ以外の方式を受け付けない場合は、サービスアカウントに Basic 認証を許可するか、アプライアンスのアドレスを名前付きホストとして認証なしで許可するよう、ネットワークチームに依頼してください。

トラフィックについては、ネットワークチームに次のように伝えてください。

• 通信先は ファイアウォールの設定 に列挙されたエンドポイントのみで、ポート 443 の HTTPS を使用します。ポート 2525 のメールリレーがプロキシを経由することはありません。
• cbw.ironflock.com へのリモート管理接続は、数秒ごとにキープアライブ通信を行う長時間維持される WebSocket です。プロキシが一定時間後に長時間接続を切断する場合、アプライアンスは数秒以内に自動的に再接続しますが、リモートユーザーはそのたびに短い中断に気づくことがあります — 可能であれば、この接続を接続時間の制限対象から除外してください。

後からプロキシを変更または削除する

プロキシはアプライアンスの中央設定ファイル /opt/ironflock/.env に記録されています。このファイルが正式な設定元です：ここに記載されている内容が、すべてのアップデートで適用されます。したがって、インストール済みのアプライアンスでプロキシを再設定する手順は次の 2 ステップです。

1. /opt/ironflock/.env の HTTP_PROXY、HTTPS_PROXY、NO_PROXY エントリを編集します。
2. sudo ironflock-update を実行します。

アップデートは設定をあらゆる場所に一括で再適用します — Docker デーモン、プラットフォームサービス、デバイスエージェント、リモートアクセストンネル — そして、実際に変更があったものだけを再起動します。

あるいは、新しい値をフラグとして渡すこともできます — フラグはファイルより優先され、ファイルに書き戻されます。

sudo ironflock-update --https-proxy "http://user:[email protected]:3128"

各設定は独立しています：--https-proxy だけを渡しても、既存の NO_PROXY リストはそのまま保持されます（指定しなかった HTTP スキームには自動的に同じ値がミラーされます）。

プロキシを削除するには — たとえばアプライアンスをインターネットに直接接続できるネットワークへ移設した後など — /opt/ironflock/.env のエントリを空にする（HTTP_PROXY=、HTTPS_PROXY=）か、明示的に空のフラグを渡したうえで、アップデートを実行します。

sudo ironflock-update --http-proxy "" --https-proxy ""

プロキシ設定は Docker デーモンとデバイスエージェントから再び取り除かれ、アプライアンスは直接接続に戻ります。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"

どのホストがプロキシを迂回するか

NO_PROXY が照合するのはクライアントが接続しようとするホスト名であり、その名前が解決されるアドレスではありません。デバイスが名前で到達するアプライアンス — つまりドメインモードのすべてのアプライアンス、アプリ UI と HTTPS を参照 — は、明示的に指定する必要があります。そうしないとエージェントはローカルのアプライアンスへの接続を社内プロキシ経由で送ってしまい、多くのプロキシは社内ネットワークへ折り返すルーティングを拒否するため、デバイスは決してオンラインになりません。

インストーラーはこれをデバイス自身の .flock から判断します。localhost と 127.0.0.1 に加えて、アプライアンスのドメインを — 先頭にドットのない形と付いた形の両方で — さらに TLS なしで接続するレジストリホストを追加します。クラウドデバイスにはループバックの 2 エントリ以外は追加されません。エンドポイントが公開されており、プロキシが実際に必要だからです。

サイト固有のその他のホストは、ironflock-init の同名フラグに対応する -no-proxy で指定します：

reagent.exe service install -config path\to\config.flock `
  -proxy "http://proxy.example.com:3128" `
  -no-proxy "buildserver.corp.example,10.0.0.0/8"

後から設定を変更する

結果は %ProgramData%\IronFlock\Reagent\proxy.env に書き込まれ、それ以降はこのファイルが正となります：

HTTP_PROXY=http://proxy.example.com:3128
HTTPS_PROXY=http://proxy.example.com:3128
NO_PROXY=localhost,127.0.0.1,appliance.corp.example,.appliance.corp.example

編集したうえで reagent.exe service install を再実行すると反映されます。以後のインストールがこのファイルを上書きすることはありません。また service uninstall はエージェントディレクトリを残すため、サービスの再インストールに必要なアンインストール／インストールのサイクルを経ても設定は保持されます。フラグの値でファイルを意図的に置き換えるには -force-proxy を使ってください。

このサイトがアプライアンスへプロキシ経由で到達する場合は、該当エントリを削除してください。 どちらの構成も実在します。同じ工場 LAN 上のアプライアンスには直接到達しますが、中央でホストされたアプライアンスには社内プロキシ経由でしか到達できないことがあります。インストーラーは両者を区別できないため、ホストをそのまま書き出します — ご自身のネットワークに当てはまらないものは削除してください。

Docker は別途設定します

Docker Desktop は proxy.env もサービス環境も読みません。イメージを取得するのは Docker デーモンで、Settings → Resources → Proxies に独自の設定と独自の除外リストを持ちます — そのリストにもアプライアンスのホストが必要です。エージェント側でプロキシを直しても docker pull は直りません。

Linux デバイス

ironflock-init は --no-proxy を直接受け付けるため、セットアップ時にアプライアンスを指定できます：

sudo ./ironflock-init -c mydevice.flock \
  --http-proxy "$PROXY" --https-proxy "$PROXY" \
  --no-proxy "appliance.corp.example.com"

これにより /etc/systemd/system/reagent.service.d/http-proxy.conf に systemd のドロップインが作成されます。後から設定を変更する目的でこのファイルを編集しないでください — セットアップツールが書き換えます。代わりに systemctl edit reagent を使います。これはインストーラーのドロップインの後に systemd が適用する override.conf を作成し、IronFlock が触れることはありません：

sudo systemctl edit reagent

[Service]
Environment="NO_PROXY=localhost,127.0.0.1,appliance.corp.example.com"

sudo systemctl restart reagent

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 コンポーネントが企業プロキシ経由でダウンロードできるよう許可する必要があります。ネットワーク／セキュリティチームには、具体的に次の 2 点を依頼してください。

• instance-registry.ironflock.com からのイメージダウンロードに対するスキャンの例外設定 — 一律のリスクウェア判定によってトンネルコンポーネントがブロックされないようにするためです。これは IronFlock のすべてのトラフィックを TLS 検査から除外するよりも範囲の狭い対応であり、アプライアンスのそれ以外のトラフィックは引き続き検査の対象にしておけます。
• 検出を既知の誤検知として記録すること。 frp は広く使われているオープンソースのリバースプロキシであり、IronFlock はこれを、上記で説明したアクセス制御付きのリモートアクセス機能のためだけに使用しています。

アプライアンス向けにすでに列挙されているものと同じ 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 を渡してください。

アップデート

アプライアンスがプロキシの背後でインストールされると、そのプロキシ設定は /opt/ironflock/.env に記憶され、アップデートのたびに再適用されます。手動アップデートとバックグラウンドの自動アップデートのいずれも、追加の操作なしにプロキシ経由で引き続き動作します — アプライアンスガイドの メンテナンス を参照してください。アプライアンスを別のプロキシに向ける場合 — あるいはプロキシを完全に外す場合 — は、後からプロキシを変更または削除する を参照してください。

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