회사 프록시 환경 사용

많은 공장 및 기업 네트워크는 회사 HTTP 프록시(예: 포트 3128의 Squid 프록시)를 통해서만 인터넷에 도달합니다. IronFlock Appliance는 이러한 환경에서도 깔끔하게 설치되고 실행됩니다 — 설치 명령에 프록시를 제공하면 나머지는 설치 프로그램이 모두 구성해 줍니다.

이 페이지는 어플라이언스 호스트에 프록시 환경 변수가 설정되어 있지 않은 상태를 가정합니다 — 사용자가 프록시를 명시적으로 제공합니다. 설치 프로그램이 자동으로 처리하는 부분과 TLS를 가로채는 프록시에 필요한 추가 단계 하나를 설명합니다.

이 문서는 Appliance 가이드의 방화벽 구성 섹션을 보완하는 프록시 안내서입니다. 동일한 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에 프록시 드롭인을 작성하고 Docker를 한 번 재시작하여 IronFlock 레지스트리에 도달할 수 있도록 합니다. 이 단계는 다음과 같습니다:

자동 처리 — 프록시를 한 번만 제공하면(아래 참조), 설치 프로그램이 설정을 작성하고 Docker를 재시작합니다. 수동 데몬 설정이 필요 없습니다.
멱등성 — 이후 업데이트 시에는 프록시가 실제로 변경된 경우에만 Docker를 재시작하므로, 실행 중인 앱이 방해받지 않습니다.
프록시를 제공하지 않으면 완전히 생략 — 인터넷에 직접 연결되는 설치는 영향을 받지 않습니다.

설치 프로그램은 또한 어플라이언스 자체의 클라우드 연결 — 라이선스 검증 및 ironflock.com에서 인스턴스에 접근할 수 있게 해주는 원격 관리 업링크 — 도 프록시를 통해 라우팅합니다. 어플라이언스 구성에 프록시를 기록하며 플랫폼이 이를 자동으로 사용합니다. 어플라이언스가 온라인 상태가 되는 데 별도의 설정은 필요 없습니다.

프록시 뒤에서 설치 프로그램 실행하기

프록시는 두 곳에서 필요합니다: curl은 설치 프로그램을 다운로드하는 데 프록시가 필요하고, 설치 프로그램은 Docker를 구성하는 데 프록시가 필요합니다. 하나의 명령으로 두 곳 모두에 제공하십시오 — 프록시 URL을 한 번 설정하고, --proxy로 curl에 전달하며, --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를 export하고 있다면, 대신 (플래그 없이) 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하십시오:


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를 설치하십시오. 흔히 저지르는 실수는 하나의 호스트명(예: instance-registry.ironflock.com만)에 대해 프록시가 다시 서명한 인증서를 저장하는 것입니다. 그렇게 하면 해당 호스트만 작동하고 다른 모든 클라우드 호스트는 실패한 채로 남습니다. 그러한 인증서들을 서명하는 CA가 필요합니다.

파일을 직접 얻을 수 없지만 프록시가 전체 체인을 제시하는 경우, 와이어에서 CA를 추출할 수 있습니다 — <PROXY_HOST>:<PROXY_PORT>를 사용자의 프록시로 교체하십시오:


# 체인을 캡처하여 인증서당 하나의 PEM으로 저장합니다. c1은 호스트별 리프(leaf)이므로 건너뛰고,
# 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

다섯 호스트 모두에 대해 200, 401, 404 같은 코드가 반환되면 CA가 올바른 것입니다. 그런 다음 서비스가 이를 반영하도록 스택을 재시작하십시오(또는 설치 프로그램을 다시 실행하십시오):


sudo systemctl restart ironflock.service

디바이스 사용자 인터페이스 원격 접근

IronFlock을 사용하면 엣지 디바이스나 기계에서 실행되는 사용자 인터페이스 — 기계 HMI, PLC 페이지, 디바이스 내 구성 또는 대시보드 화면 — 를 어디서든 IronFlock 내부에서 직접 열 수 있습니다. 이는 원격 서비스 및 지원을 가능하게 하는 핵심 기능입니다: 엔지니어가 현장에 있거나 로컬 네트워크에 접속하지 않고도 기계의 인터페이스에 도달할 수 있습니다. 접근은 항상 IronFlock 권한 시스템에 의해 중재되고 보호되므로, 승인된 사용자만 특정 디바이스에 도달할 수 있습니다.

이 원격 접근 터널은 성숙하고 널리 사용되는 오픈소스 기술인 frp (Fast Reverse Proxy) 위에 구축되어 있습니다. IronFlock은 이를 오직 위에서 설명한 디바이스 인터페이스 접근을 제공하는 데에만 사용합니다.

회사 프록시가 방해가 될 수 있는 이유

frp는 강력한 네트워크 통과 기능을 갖추고 있으며, 그 때문에 백신 및 프록시 보안 제품이 종종 이를 일반적으로 위험 소프트웨어(riskware)로 표시합니다 — 오랜 검증 이력을 가진 오픈소스 구성 요소로서 안전하며 여기서는 오직 승인된 원격 접근 기능에만 사용됨에도 불구하고 그렇습니다. 이런 일이 발생하면, 프록시는 frp를 포함하는 IronFlock 구성 요소의 다운로드를 차단합니다.

이는 어플라이언스를 손상시키지 않습니다: 원격 접근 터널은 선택적 기능이므로, 해당 구성 요소가 차단되면 플랫폼은 정상적으로 설치되고 실행되며 단지 디바이스 인터페이스 접근 없이 동작합니다. 대시보드에서는 디바이스의 원격 접근 컨트롤이 이 어플라이언스에서 원격 접근을 사용할 수 없음을 표시합니다.

회사 IT가 허용해야 하는 것

조직에서 IronFlock의 원격 서비스 기능을 활용하고자 한다면, frp를 포함하는 IronFlock 구성 요소가 회사 프록시를 통해 다운로드되도록 허용되어야 합니다. 네트워크/보안 팀에 다음을 요청하십시오:

frp 구성 요소에 대해 IronFlock의 다운로드 트래픽을 백신 / 멀웨어 콘텐츠 스캔 및 파일 다운로드 차단에서 제외 — 가장 깔끔한 방법은 IronFlock의 엔드포인트를 프록시의 복호화 제외(TLS 검사 우회) 목록에 추가하는 것입니다.
frp 탐지를 승인된 예외로 처리하십시오: 이는 이 오픈소스 라이브러리의 정당한 사용에 대한 잘 알려진 **오탐(false positive)**입니다.

어플라이언스에 대해 이미 나열된 동일한 IronFlock 엔드포인트가 적용됩니다 — 방화벽 구성을 참조하십시오. 이는 해당 트래픽을 단지 라우팅하는 것에 더해 스캔/차단하지 않도록 하는 것에 관한 내용입니다.

frp가 허용되고 나면, 업데이트를 다시 실행하기만 하면 됩니다 — 다운로드가 성공하는 즉시 다른 변경 없이 기능이 자동으로 켜집니다:


sudo ironflock-update

원격 접근 없이 실행하기

디바이스 인터페이스 접근이 필요하지 않거나 — 프록시 예외가 마련되는 동안 깔끔하게 설치하고 싶다면 — 터널을 명시적으로 비활성화할 수 있습니다. 나머지는 모두 정상적으로 설치됩니다:


# 설치 시, 설치 명령에 추가
... | sudo bash -s -- <your-instance-key> --no-tunnel
 
# 또는 이미 설치된 어플라이언스에서
sudo ironflock-update --no-tunnel

이 선택은 업데이트 전반에 걸쳐 기억됩니다. 나중에 (frp가 허용되면) --tunnel로 다시 활성화하십시오:


sudo ironflock-update --tunnel

문제 해결

설치가 “Logging in to instance-registry.ironflock.com”에서 Client.Timeout 오류와 함께 멈춥니다. 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을 전달하십시오.

업데이트

어플라이언스가 프록시 뒤에서 설치되면 프록시 설정이 기억됩니다. 수동 업데이트와 자동 백그라운드 업데이트 모두 추가 작업 없이 프록시를 통해 계속 작동합니다 — Appliance 가이드의 유지 관리를 참조하십시오.

디바이스 인터페이스 원격 접근이 설치 시점에 차단되었던 경우, 모든 업데이트가 이를 자동으로 재시도합니다 — 따라서 프록시가 frp를 허용하고 나면 다음 업데이트에서 별도의 단계 없이 기능이 켜집니다.