회사 프록시 환경 사용

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

이 페이지는 어플라이언스 호스트에 프록시 환경 변수가 설정되어 있지 않은 상태를 가정합니다 — 사용자가 프록시를 명시적으로 제공합니다. 설치가 자동으로 처리하는 부분과 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)

설치가 자동으로 처리하는 부분

설치 명령에 프록시를 제공하면, ironflock appliance install이 Docker 데몬과 호스트의 디바이스 에이전트를 구성해 줍니다 — 프록시 설정을 root만 읽을 수 있는 /etc/ironflock/proxy.env에 보관하고, Docker와 에이전트가 이 파일을 사용하도록 지정하며, Docker를 재시작하여 IronFlock 레지스트리에 도달할 수 있도록 합니다. 이 단계는 다음과 같습니다:

자동 처리 — 프록시를 한 번만 제공하면(아래 참조), 설치가 설정을 작성하고 Docker를 재시작합니다. 수동 데몬 설정이 필요 없습니다.
프록시를 제공하지 않으면 완전히 생략 — 인터넷에 직접 연결되는 설치는 영향을 받지 않습니다.

설치는 또한 어플라이언스 자체의 클라우드 연결 — 라이선스 검증 및 ironflock.com에서 인스턴스에 접근할 수 있게 해주는 원격 관리 업링크 — 도 프록시를 통해 라우팅합니다. 어플라이언스의 중앙 구성 파일인 /opt/ironflock/.env에 프록시를 기록하며 플랫폼이 이를 자동으로 사용합니다. 이후의 모든 업데이트도 이 설정을 유지합니다(나중에 프록시 변경 또는 제거하기 참조). 어플라이언스가 온라인 상태가 되는 데 별도의 설정은 필요 없습니다.

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

프록시는 두 곳에서 필요합니다: 설치 스크립트는 ironflock을 다운로드하는 데 프록시가 필요하고, ironflock appliance install은 Docker를 구성하는 데 프록시가 필요합니다. 프록시 URL을 한 번 설정하고, --proxy로 curl에, 환경 변수로 설치 스크립트에 전달한 다음, --http-proxy / --https-proxy로 ironflock appliance install에 전달하십시오:


# 회사 프록시 — 이 줄을 편집하십시오
PROXY="http://proxy.your-company.com:3128"
 
curl -fsSL --proxy "$PROXY" https://instance-registry.ironflock.com/dl/cli/install.sh \
  | sudo env HTTP_PROXY="$PROXY" HTTPS_PROXY="$PROXY" bash
 
sudo ironflock appliance install --license-file license.txt \
  --http-proxy "$PROXY" --https-proxy "$PROXY"

프록시 URL을 사용자의 값으로, license.txt를 Instance Key가 들어 있는 파일로 교체하십시오(설치 참조). 프록시에 로그인이 필요한 경우 프록시 인증을 참조하십시오. 비밀번호는 URL에 넣지 않습니다.

ironflock appliance install의 프록시 플래그:

플래그	용도
`--http-proxy <url>`	Docker, 에이전트, 어플라이언스의 일반 HTTP 트래픽용 프록시. `""`는 프록시를 제거합니다.
`--https-proxy <url>`	HTTPS 트래픽용 프록시 (이미지 가져오기에 중요한 항목). `""`는 프록시를 제거합니다.
`--no-proxy <list>`	프록시를 우회해야 하는 쉼표로 구분된 추가 호스트 목록.
`--proxy-password-file <file>`	프록시 URL에 있는 사용자의 비밀번호가 한 줄로 들어 있는 파일 또는 파이프(`/dev/stdin`).

sudo는 셸의 프록시 변수를 ironflock에 넘겨주지 않으므로, 프록시는 플래그로 지정하십시오. 명령의 다른 플래그는 ironflock appliance install에서 설명합니다.

로컬 트래픽은 항상 프록시를 우회합니다

NO_PROXY를 수동으로 관리할 필요가 없습니다. 설치는 항상 localhost, 127.0.0.1, 그리고 어플라이언스 자체의 호스트 주소를 프록시에서 제외합니다(--no-proxy로 전달한 항목은 유지되며 병합됩니다). 이를 통해 어플라이언스의 로컬 앱 스토어와 레지스트리에 직접 도달하며, 회사 프록시를 통해 외부로 라우팅되지 않도록 보장합니다.

프록시 인증

프록시에 로그인이 필요한 경우, 개인 계정이 아니라 어플라이언스 전용 서비스 계정을 부여하십시오. 그러면 어플라이언스의 트래픽이 프록시 로그에 네트워크 팀이 관리하는 이름으로 표시됩니다. 네트워크 팀은 이 계정이 접근할 수 있는 대상을 제한할 수 있고, 누구의 개인 로그인에도 영향을 주지 않고 계정을 비활성화하거나 자격 증명을 교체할 수 있습니다. 이는 IronFlock 호스트의 네트워크 ID의 프록시 측면에 해당합니다.

지원됨: Basic 인증. 프록시 URL에 사용자를 지정하고, 비밀번호는 비밀번호가 한 줄로 들어 있는 파일(또는 /dev/stdin)을 --proxy-password-file로 지정하십시오. 호스트의 모든 사용자가 명령줄을 읽을 수 있으므로, ironflock은 비밀번호가 들어 있는 프록시 URL을 거부합니다. 어플라이언스는 root만 읽을 수 있는 파일에 비밀번호를 보관하므로, 이후 그 파일은 삭제해도 됩니다:
```
sudo ironflock appliance install --license-file license.txt \
  --https-proxy "http://[email protected]:3128" \
  --proxy-password-file proxy-password.txt
```
아직 지원되지 않음: Windows 통합 인증(Kerberos, NTLM). 프록시가 이 방식만 허용한다면, 네트워크 팀에 서비스 계정에 대해 Basic 인증을 허용하거나, 어플라이언스의 주소를 이름이 지정된 호스트로 등록해 인증 없이 허용하도록 요청하십시오.

트래픽에 관해 네트워크 팀에 전달할 내용:

트래픽은 방화벽 구성 목록의 엔드포인트로만, 포트 443의 HTTPS로 전송됩니다. 포트 2525의 이메일 릴레이는 프록시를 사용하지 않습니다.
cbw.ironflock.com으로의 원격 관리 연결은 몇 초마다 keep-alive 트래픽이 오가는 장시간 유지되는 WebSocket입니다. 프록시가 장시간 유지되는 연결을 일정 시간 후에 끊으면 어플라이언스는 몇 초 안에 스스로 다시 연결하지만, 원격 사용자는 그때마다 잠깐의 중단을 느낄 수 있습니다 — 가능하다면 이 연결을 연결 유지 시간 제한에서 제외하십시오.

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

프록시는 어플라이언스의 중앙 구성 파일인 /opt/ironflock/.env에 기록되며, 모든 업데이트가 이를 유지합니다. 설치된 어플라이언스에서 프록시를 변경하려면 ironflock appliance configure를 사용하십시오. 이 명령은 설정을 Docker 데몬, 플랫폼 서비스, 디바이스 에이전트에 적용하며, 변경된 것이 있을 때만 어플라이언스를 재시작합니다:


# 다른 프록시로 전환
sudo ironflock appliance configure --https-proxy "http://proxy2.your-company.com:3128"
 
# 프록시를 우회하는 호스트 변경
sudo ironflock appliance configure --no-proxy "buildserver.corp.example.com"

각 설정은 독립적입니다: 지정하지 않은 설정은 어플라이언스의 기존 값을 유지하므로, --https-proxy만 전달하면 기존 NO_PROXY 목록은 그대로 유지됩니다.

프록시를 제거하려면 — 예를 들어 어플라이언스를 인터넷에 직접 연결되는 네트워크로 옮긴 후 — 빈 프록시를 전달하십시오:


sudo ironflock appliance configure --http-proxy "" --https-proxy ""

프록시 구성이 Docker 데몬과 디바이스 에이전트에서 다시 제거되고, 어플라이언스는 직접 연결로 돌아갑니다. NO_PROXY 목록은 나중에 다시 활성화할 때를 위해 유지됩니다.

로그인이 필요한 프록시는 현재 configure로 설정할 수 없습니다: ironflock appliance configure는 프록시 비밀번호를 받지 않습니다. --proxy-password-file은 ironflock appliance install만 받습니다. 설치된 어플라이언스에서 appliance install을 실행하면 지정한 옵션을 적용하고 시크릿과 설정은 유지하므로(다시 실행하기), 비밀번호와 함께 새 프록시를 설정할 수 있습니다:


sudo ironflock appliance install --version <version> \
  --https-proxy "http://[email protected]:3128" \
  --proxy-password-file proxy-password.txt

--version에는 어플라이언스가 실행 중인 버전(ironflock status가 보여 줌)을 지정하십시오. 지정하지 않으면 이 실행은 어플라이언스를 채널의 최신 릴리스로 업데이트하기도 합니다. 설치된 어플라이언스는 Instance Key를 유지하므로 이 실행에는 --license-file이 필요 없습니다.

엣지 디바이스

위의 모든 내용은 ironflock agent install로 연결한 엣지 디바이스에도 동일하게 적용됩니다. 이 명령은 동일한 프록시 플래그를 사용합니다. 실행할 때 프록시를 전달하면, 다운로드(패키지 관리자, Docker 설치, 에이전트 다운로드), Docker 데몬, 디바이스 에이전트를 프록시를 통해 라우팅해 줍니다:


sudo ironflock agent install -c mydevice.flock \
  --http-proxy "$PROXY" --https-proxy "$PROXY"

ironflock을 다운로드하는 설치 스크립트는 그보다 먼저 실행되므로, 이 단계에도 프록시를 전달하세요. sudo는 기본적으로 셸의 프록시 변수를 넘겨주지 않으므로 명시적으로 전달하고, 프록시 플래그도 ironflock agent install에 넘기세요:


curl -fsSL --proxy "$PROXY" https://instance-registry.ironflock.com/dl/cli/install.sh \
  | sudo env HTTP_PROXY="$PROXY" HTTPS_PROXY="$PROXY" bash -s -- agent install -c mydevice.flock \
      --http-proxy "$PROXY" --https-proxy "$PROXY"

디바이스가 클라우드가 아닌 로컬 어플라이언스 앱 스토어에서 앱 이미지를 가져오는 경우, 해당 레지스트리의 호스트를 --no-proxy로 추가하여 그러한 가져오기가 로컬 네트워크에 머물도록 하십시오.

프록시에 로그인이 필요한 경우, 디바이스에서는 비밀번호를 프록시 URL에 넣지 않습니다. 디바이스의 모든 사용자가 명령줄을 읽을 수 있으므로, ironflock은 URL에 비밀번호가 들어 있는 프록시 플래그를 거부합니다. URL에는 사용자를 지정하고, 비밀번호는 한 줄로 파일에 넣으세요:


sudo ironflock agent install -c mydevice.flock \
  --https-proxy "http://[email protected]:3128" \
  --proxy-password-file proxy-password.txt

디바이스는 비밀번호를 root만 읽을 수 있는 /etc/ironflock/proxy.env에 보관하므로, 이후 비밀번호 파일은 삭제해도 됩니다.

Windows 장치에서는 에이전트가 Windows 서비스로 실행됩니다. 프록시를 서비스 설치 프로그램에 전달하세요 — 플랫폼 연결과 에이전트 자동 업데이트에 모두 적용됩니다:


.\device-agent.exe service install -config .\myaccount_myproject_mydevice.flock -proxy "http://proxy.example.com:3128"

어떤 호스트가 프록시를 우회하는가

NO_PROXY는 클라이언트가 접속하는 호스트 이름을 기준으로 일치시키며, 그 이름이 확인된 주소로는 결코 일치시키지 않습니다. 장치가 이름으로 접근하는 어플라이언스 — 즉 도메인 모드의 모든 어플라이언스, 앱 UI 및 HTTPS 참조 — 는 따라서 명시적으로 지정해야 합니다. 그렇지 않으면 에이전트가 로컬 어플라이언스로 가는 연결을 회사 프록시를 거쳐 보내고, 대부분의 프록시는 내부 네트워크로 되돌아가는 라우팅을 거부하므로 장치는 결코 온라인이 되지 않습니다.

설치 프로그램은 이를 장치 자신의 .flock에서 판단합니다. localhost와 127.0.0.1 외에 어플라이언스 도메인을 — 점 없는 형태와 앞에 점이 붙은 형태 모두로 — 그리고 TLS 없이 접속하는 레지스트리 호스트를 추가합니다. 클라우드 장치는 루프백 두 항목 외에는 아무것도 받지 않습니다. 엔드포인트가 공개되어 있어 프록시가 실제로 필요하기 때문입니다.

사이트에 필요한 그 밖의 항목은 ironflock agent install의 --no-proxy 플래그에 대응하는 -no-proxy에 넣습니다:


.\device-agent.exe service install -config .\myaccount_myproject_mydevice.flock `
  -proxy "http://proxy.example.com:3128" `
  -no-proxy "buildserver.corp.example,10.0.0.0/8"

나중에 설정 변경하기

결과는 **%ProgramData%\IronFlock\DeviceAgent\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

파일을 편집한 뒤 .\device-agent.exe service install을 다시 실행하면 변경 사항이 적용됩니다. 이후의 설치가 이 파일을 덮어쓰는 일은 절대 없으며, service uninstall은 에이전트 디렉터리를 보존합니다 — 따라서 서비스를 다시 설치할 때 필요한 제거/설치 주기를 거쳐도 설정이 유지됩니다. 플래그 값으로 파일을 의도적으로 교체하려면 -force-proxy를 사용하세요.

에이전트 1.4.0 이전에 설치된 Windows 디바이스에서는 에이전트가 디바이스를 새 구조로 옮길 때까지 폴더가 계속 %ProgramData%\IronFlock\Reagent입니다.

이 사이트가 어플라이언스에 프록시를 거쳐 접근한다면 해당 항목을 삭제하세요. 두 구성 모두 실재합니다. 같은 공장 LAN의 어플라이언스에는 직접 접근하지만, 중앙에서 호스팅되는 어플라이언스는 회사 프록시를 통해서만 접근할 수 있는 경우가 있습니다. 설치 프로그램은 둘을 구분할 수 없으므로 호스트를 그대로 기록합니다 — 네트워크에 해당하지 않는 항목은 제거하세요.

Docker는 별도로 설정합니다

Docker Desktop은 proxy.env도 서비스 환경도 읽지 않습니다. 이미지를 내려받는 것은 Docker 데몬이며, Settings → Resources → Proxies에 자체 설정과 자체 우회 목록을 가지고 있습니다 — 그 목록에도 어플라이언스 호스트가 필요합니다. 에이전트 쪽에서 프록시를 고쳐도 docker pull은 해결되지 않습니다.

Linux 장치

ironflock agent install은 --no-proxy를 직접 받으므로 설치 시점에 어플라이언스를 지정할 수 있습니다:


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

localhost, 127.0.0.1, ::1은 항상 프록시를 우회합니다. 디바이스의 .flock 파일에 지정된 업데이트 서버도 IronFlock 클라우드의 호스트가 아니면 프록시를 우회하며, 어플라이언스의 디바이스가 이 경우에 해당합니다.

설정은 root만 읽을 수 있는 /etc/ironflock/proxy.env에 보관됩니다. Docker와 디바이스 에이전트 모두 여기서 설정을 가져옵니다. 나중에 설정을 조정하려면 ironflock agent configure를 사용하세요. 지정한 플래그는 해당 설정을 대체하며, 나머지 설정은 그대로 유지됩니다:


# 프록시를 우회하는 호스트 변경
sudo ironflock agent configure --no-proxy "appliance.corp.example.com,buildserver.corp.example"
 
# 다른 프록시로 전환
sudo ironflock agent configure --https-proxy "http://proxy2.your-company.com:3128"
 
# 디바이스에서 프록시 설정 제거
sudo ironflock agent configure --remove-proxy

이 명령은 변경 전후의 설정을 보여 줍니다. 설정을 적용하려면 Docker를 재시작해야 하고 그동안 디바이스의 앱이 잠시 멈추므로, 명령이 먼저 묻습니다. 직접 만든 systemd 드롭인(systemctl edit)의 프록시 변수는 설정 파일이 같은 변수를 설정하면 더 이상 적용되지 않으며, 명령은 이런 드롭인이 있으면 경고합니다. 자세한 내용은 ironflock agent configure를 참조하세요.

ironflock 이전에 설정된 디바이스는 프록시를 http-proxy.conf라는 systemd 드롭인에 보관하며, 디바이스의 모든 사용자가 비밀번호를 포함해 이 내용을 읽을 수 있습니다. ironflock agent configure를 처음 실행하면 설정이 /etc/ironflock/proxy.env로 옮겨집니다.

2026년 10월 이전에 설치된 디바이스에서는 에이전트가 디바이스를 새 구성으로 옮길 때까지 유닛 이름이 여전히 reagent.service입니다(드롭인 디렉터리는 reagent.service.d).

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 ironflock appliance restart

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

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가 허용되고 나면, 다음 업데이트가 다운로드를 다시 시도하며 다운로드가 성공하는 즉시 다른 변경 없이 기능이 켜집니다. 바로 시도하려면 어플라이언스가 실행 중인 버전(ironflock status가 보여 줌)으로 설치를 다시 실행하십시오. 어플라이언스의 시크릿과 설정은 유지됩니다:


sudo ironflock appliance install --version <version>

원격 접근 없이 실행하기

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


# 설치 시
sudo ironflock appliance install --license-file license.txt --no-tunnel
 
# 또는 이미 설치된 어플라이언스에서
sudo ironflock appliance configure --no-tunnel

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


sudo ironflock appliance configure --tunnel

문제 해결

설치가 instance-registry.ironflock.com에 로그인하는 단계에서 Client.Timeout 오류와 함께 멈춥니다. Docker 데몬이 레지스트리에 도달할 수 없습니다. ironflock appliance install을 다시 실행하고 위에 표시된 대로 --http-proxy / --https-proxy로 프록시를 전달하십시오.

프록시를 구성한 후에도 로그인이 계속 실패합니다. 프록시가 TLS를 가로챌 가능성이 높습니다. TLS 가로채기 프록시에 설명된 대로 회사 CA를 설치한 다음 설치 명령을 다시 실행하십시오.

Docker 데몬이 프록시를 인식하는지 확인하십시오:


sudo docker info | grep -i proxy
sudo docker login instance-registry.ironflock.com

docker info는 Docker가 사용하는 프록시를 보여 주며, 비밀번호는 가려서 표시합니다. docker login이 단독으로 성공하면 어플라이언스 설치도 실패하던 단계를 통과할 것입니다.

모든 것이 정상적으로 설치되는데 단일 구성 요소만 다운로드에 실패합니다. 이는 대개 frp 기반 원격 접근 구성 요소가 프록시나 백신에 의해 위험 소프트웨어로 차단되는 경우입니다. 설치는 여전히 완료되며 — 디바이스 인터페이스 접근만 사용할 수 없습니다. 이를 활성화하려면 디바이스 사용자 인터페이스 원격 접근에 설명된 대로 프록시 팀에 해당 트래픽을 허용하도록 요청한 다음, 어플라이언스가 실행 중인 버전으로 sudo ironflock appliance install --version <version>을 실행하십시오. 의도적으로 이 기능 없이 설치하려면 --no-tunnel을 전달하십시오.

업데이트

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

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