회사 프록시 환경 사용

많은 공장 및 기업 네트워크는 회사 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에서 인스턴스에 접근할 수 있게 해주는 원격 관리 업링크 — 도 프록시를 통해 라우팅합니다. 어플라이언스의 중앙 구성 파일인 /opt/ironflock/.env에 프록시를 기록하며 플랫폼이 이를 자동으로 사용합니다 — 이 파일은 이후의 모든 업데이트에서도 기준이 되는 원본으로 유지됩니다(나중에 프록시 변경 또는 제거하기 참조). 어플라이언스가 온라인 상태가 되는 데 별도의 설정은 필요 없습니다.

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

프록시는 두 곳에서 필요합니다: 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:[email protected]: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 호스트의 네트워크 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으로의 원격 관리 연결은 몇 초마다 keep-alive 트래픽이 오가는 장시간 유지되는 WebSocket입니다. 프록시가 장시간 유지되는 연결을 일정 시간 후에 끊으면 어플라이언스는 몇 초 안에 스스로 다시 연결하지만, 원격 사용자는 그때마다 잠깐의 중단을 느낄 수 있습니다 — 가능하다면 이 연결을 연결 유지 시간 제한에서 제외하십시오.

나중에 프록시 변경 또는 제거하기

프록시는 어플라이언스의 중앙 구성 파일인 /opt/ironflock/.env에 기록됩니다. 이 파일이 기준이 되는 원본입니다: 이 파일에 담긴 값이 모든 업데이트에서 적용됩니다. 따라서 설치된 어플라이언스에서 프록시를 재구성하는 데는 두 단계가 필요합니다:

/opt/ironflock/.env의 HTTP_PROXY, HTTPS_PROXY, NO_PROXY 항목을 편집하십시오.
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하십시오:


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 없이 접속하는 레지스트리 호스트를 추가합니다. 클라우드 장치는 루프백 두 항목 외에는 아무것도 받지 않습니다. 엔드포인트가 공개되어 있어 프록시가 실제로 필요하기 때문입니다.

사이트에 필요한 그 밖의 항목은 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를 설치하십시오. 흔히 저지르는 실수는 하나의 호스트명(예: 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 구성 요소가 회사 프록시를 통해 다운로드되도록 허용되어야 합니다. 네트워크/보안 팀에 다음 두 가지를 구체적으로 요청하십시오:

instance-registry.ironflock.com에서 내려받는 이미지에 대한 스캔 예외 — 일반적인 위험 소프트웨어(riskware) 판정이 터널 구성 요소를 차단하지 않도록 하기 위함입니다. 이는 모든 IronFlock 트래픽을 TLS 검사에서 제외하는 것보다 범위가 좁습니다 — 어플라이언스의 나머지 트래픽은 계속 검사 대상으로 둘 수 있습니다.
탐지를 알려진 오탐(false positive)으로 기록. 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

문제 해결

설치가 “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을 전달하십시오.

업데이트

어플라이언스가 프록시 뒤에서 설치되면 프록시 설정이 /opt/ironflock/.env에 기억되며 모든 업데이트에서 다시 적용됩니다. 수동 업데이트와 자동 백그라운드 업데이트 모두 추가 작업 없이 프록시를 통해 계속 작동합니다 — Appliance 가이드의 유지 관리를 참조하십시오. 어플라이언스가 다른 프록시를 사용하도록 하려면 — 또는 프록시를 완전히 제거하려면 — 나중에 프록시 변경 또는 제거하기를 참조하십시오.

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