네트워크 보안
Alpacon은 아웃바운드 연결만 사용하는 에이전트를 통해 서버를 플랫폼에 연결합니다. Alpacon이 서버로 들어오는 연결을 만들지 않으므로, Alpacon 접근을 위해 열어야 하는 인바운드 포트는 없습니다. 서버가 자체 서비스에 쓰는 포트는 그대로 유지하면 됩니다. 이 문서에서는 연결이 동작하는 방식과 네트워크, 방화벽, 프록시를 구성하는 방법을 설명합니다.
전송 구간 암호화, 인증서 관리, 플랫폼 측 보호에 대해서는 플랫폼 보안 및 가용성을 참고하세요.
연결 모델
아웃바운드 전용 에이전트
기존 SSH 접근은 포트 22를 들어오는 연결에 노출해야 합니다. Alpacon은 그 반대로 동작합니다. 각 서버의 Alpamon 에이전트가 플랫폼으로 아웃바운드 연결을 열고, 모든 접근이 그 채널을 통해 되돌아옵니다.
기존 SSH:
인터넷 → 방화벽(인바운드 포트 22) → 서버
Alpacon:
서버 → Alpamon 에이전트(아웃바운드 전용) → 방화벽 → 플랫폼이렇게 얻는 이점:
- Alpacon용 인바운드 포트 불필요: 에이전트가 밖으로만 연결하며, Alpacon이 서버로 접속해 들어오지 않습니다.
- 아웃바운드 전용: Alpamon 에이전트가 모든 연결을 시작합니다.
- 방화벽 친화적: 제한적인 방화벽 정책이나 네트워크 주소 변환(NAT) 환경에서도 인바운드 허용 없이 동작합니다.
- 위치와 무관한 접근: 네트워크 위치만으로는 접근 권한이 생기지 않으며, 모든 세션이 인증과 권한 확인을 거칩니다.
연결이 설정되는 과정
- 에이전트 시작: Alpamon 에이전트가 서버에서 시작되어 워크스페이스 엔드포인트로 아웃바운드 연결을 열고, 서버 토큰으로 인증한 뒤 하트비트로 연결을 유지합니다.
- 사용자 연결: 웹 콘솔이나 CLI로 Alpacon에 로그인합니다. 서버를 열면 플랫폼이 권한을 확인한 뒤 에이전트의 기존 아웃바운드 채널을 통해 세션을 연결합니다.
- 세션 실행: 사용자와 서버 사이에 직접 연결은 없습니다. 플랫폼이 세션을 중계하며, 세션은 전송 구간에서 암호화됩니다. 어느 한쪽을 닫으면 세션이 종료됩니다.
에이전트 네트워크 요구사항
Alpamon 에이전트는 워크스페이스 엔드포인트로 아웃바운드 HTTPS와 WebSocket(WSS) 접근이 필요합니다. 호스트에서 수신 대기 포트를 열지 않습니다.
엔드포인트:
<workspace>.<region>.alpacon.io로 아웃바운드 HTTPS(443)- 지속 채널을 위한
<workspace>.<region>.alpacon.io로 아웃바운드 WSS(443)
리소스 사용량: 에이전트는 경량이며 보통 메모리 약 128MB, 디스크 약 150MB를 사용합니다. 네트워크가 끊기면 지수 백오프로 자동 재연결하고, 자신이 실행했던 세션에 다시 연결합니다.
프록시 지원
Alpamon 2.8.5 이상은 에이전트의 HTTPS_PROXY 또는 HTTP_PROXY 환경 변수에 설정한 프록시를 거쳐 Alpacon에 연결하고, NO_PROXY에 적은 호스트에는 직접 연결합니다. 이전 버전의 에이전트는 이 변수를 무시하고 직접 연결합니다.
에이전트 서비스는 셸의 변수를 물려받지 않습니다. 그래서 셸에서 export로 설정한 변수는 에이전트에 적용되지 않으며, 변수는 서비스 자체의 환경에 설정해야 합니다. 에이전트가 systemd 서비스로 실행되는 Linux에서는 드롭인(drop-in) 파일을 추가하세요.
sudo systemctl edit alpamon편집기가 열리면 다음 내용을 추가합니다.
[Service]
Environment=HTTPS_PROXY=http://proxy.company.com:8080
Environment=NO_PROXY=files.company.com그런 다음 에이전트를 재시작해 변경 사항을 적용합니다.
sudo systemctl restart alpamonmacOS에서는 /Library/LaunchDaemons/com.alpacax.alpamon.plist의 EnvironmentVariables 키에 변수를 추가한 뒤, 이 파일을 대상으로 sudo launchctl unload와 sudo launchctl load를 실행합니다. Windows에서는 시스템 환경 변수로 설정한 뒤 컴퓨터를 다시 시작합니다. 에이전트 서비스는 Windows가 시작될 때만 시스템 환경 변수를 읽기 때문입니다.
- 변수: 에이전트는 Alpacon에 모두 HTTPS로 연결하므로, 이 연결에 적용되는 변수는
HTTPS_PROXY입니다.HTTP_PROXY는http://주소에만 적용됩니다. - 프록시 URL:
http://또는socks5://프록시 URL을 사용하세요.https://같은 다른 스킴을 쓰면 에이전트의 지속 채널과 세션은 프록시를 거치지 않고 직접 연결되며, 에이전트가 경고를 기록합니다. - 우회 목록: 프록시 없이 접속해야 하는 호스트는
NO_PROXY에 쉼표로 구분해 적습니다. 워크스페이스 엔드포인트(서버가 프록시 없이 직접 접속하는 경우)와 에이전트가 파일을 주고받는 내부 호스트가 여기에 해당합니다. - 항상 직접 연결: 클라우드 인스턴스 메타데이터 요청과 로컬 호스트로 보내는 요청은 프록시를 거치지 않습니다.
방화벽 구성
필수 아웃바운드 규칙(서버 측)
Alpamon 에이전트를 실행하는 서버의 경우:
| 프로토콜 | 포트 | 대상 | 목적 |
|---|---|---|---|
| HTTPS | 443 | <workspace>.<region>.alpacon.io | 에이전트 연결 |
| WSS | 443 | <workspace>.<region>.alpacon.io | 지속 채널 |
| HTTPS | 443 | api.github.com | 에이전트 버전 확인 |
| HTTPS | 443 | github.com, release-assets.githubusercontent.com | 에이전트 설치 및 자동 업데이트 |
| HTTPS | 443 | *.amazonaws.com (S3) | WebFTP 파일 전송(선택) |
일부 선택 기능은 추가 엔드포인트에 접근합니다. 브라우저 내장 코드 에디터는 처음 사용할 때 code-server.dev와 open-vsx.org에서 내려받고, Linux 패키지 설치는 packagecloud.io를 사용합니다. 이 기능을 쓰는 경우에만 허용하세요.
iptables 예시:
# 워크스페이스로 아웃바운드 HTTPS 허용
iptables -A OUTPUT -p tcp --dport 443 -d <workspace-ip> -j ACCEPT
# 설정된 연결의 응답 허용
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# 그 외 모든 인바운드 차단
iptables -A INPUT -j DROP필수 아웃바운드 규칙(클라이언트 측)
웹 브라우저나 CLI로 Alpacon에 접근하는 사용자의 경우:
| 프로토콜 | 포트 | 대상 | 목적 |
|---|---|---|---|
| HTTPS | 443 | alpacon.io | 메인 애플리케이션 |
| HTTPS | 443 | <workspace>.<region>.alpacon.io | 워크스페이스 접근 |
| HTTPS | 443 | auth.alpacon.io | 인증 |
| WSS | 443 | <workspace>.<region>.alpacon.io | 터미널 세션 |
기업 방화벽과 프록시
Alpacon은 기업 방화벽과 프록시 뒤에서도 동작합니다. 서버의 에이전트는 CONNECT 메서드를 지원하는 HTTP 프록시나 SOCKS5 프록시를 거쳐 연결하며, 사용자 이름과 비밀번호로 인증하는 프록시도 사용할 수 있습니다. 설정 방법은 프록시 지원을 참고하세요.
IP 허용 목록
출발지 IP 주소를 기준으로 접근을 제한해 통제를 강화할 수 있습니다.
서비스 토큰 IP 허용 목록 (지금 사용 가능):
- 서비스 토큰별로 특정 IP 주소나 CIDR 범위에서만 사용 허용
- 토큰을 사용할 수 있는 시간과 요일 지정
- 토큰별 요청 속도 제한 적용
- 자세한 내용은 서비스 토큰 문서를 참고하세요
워크스페이스 수준 IP 접근 정책 (Enterprise):
- 사무실 네트워크나 VPN 게이트웨이 같은 특정 IP 범위로 워크스페이스 접근 제한
- 도입이 필요하시면 support@alpacax.com으로 문의해 주세요
VPN에서 이전하기
접근 권한이 네트워크 수준이 아니라 사용자별, 서버별로 부여되기 때문에, 서버 접근만을 위해 두었던 VPN을 정리하는 팀이 많습니다. 단계적으로 전환하면 확신이 설 때까지 대체 수단을 유지할 수 있습니다.
- 병행 운영: 기존 VPN을 비상 접근용으로 유지하면서 서버에 Alpacon을 배포하고, 팀이 익숙해지도록 합니다.
- 점진적 이전: 중요도가 낮은 서버부터 옮기고, 이어서 팀을 하나씩 이전하면서 사용 현황과 피드백을 확인합니다.
- VPN 정리: 워크스테이션에서 VPN 클라이언트를 제거하고 방화벽 규칙을 닫습니다. 일정 기간 동안은 인프라를 대체 수단으로 남겨 둡니다.
- 전환 완료: VPN 인프라를 폐기하고 네트워크 문서를 갱신합니다.
모범 사례
네트워크 관리자용
- 공격 표면 최소화: 필수 서비스를 제외한 모든 인바운드 포트를 차단합니다.
- 네트워크 분리: 서버를 별도의 네트워크 세그먼트로 격리합니다.
- 트래픽 모니터링: 네트워크 모니터링으로 이상 징후를 감지합니다.
- 에이전트 최신 유지: Alpamon을 최신 버전으로 유지합니다.
- 방화벽 로그: 방화벽 규칙에 로깅을 활성화합니다.
서버 관리자용
- SSH 차단: Alpacon 배포 후 포트 22를 차단합니다.
- 에이전트 모니터링: 에이전트 상태와 연결을 확인합니다.
- 프록시 사용: 필요한 경우 기업 프록시를 구성합니다.
- 로그 집중화: 에이전트 로그를 중앙 로깅 시스템으로 전달합니다.
문제 해결
에이전트가 오프라인으로 표시됩니다
가능한 원인:
- 아웃바운드 HTTPS 또는 WSS를 차단하는 방화벽
- 잘못된 프록시 구성
- 네트워크 연결 문제
- 잘못된 에이전트 토큰
확인 방법:
# 에이전트 상태
sudo systemctl status alpamon
# 워크스페이스 연결 확인
curl -v https://<workspace>.<region>.alpacon.io/health
# 에이전트 로그
sudo journalctl -u alpamon -f
# 에이전트에 적용된 프록시 변수
systemctl show alpamon --property=Environment
# 프록시를 통한 테스트
curl -v -x http://proxy:8080 https://<workspace>.<region>.alpacon.io/health터미널 응답이 느립니다
가능한 원인:
- 워크스페이스 리전과의 지리적 거리
- 네트워크 혼잡
- 프록시 성능
시도해 볼 것:
- 워크스페이스를 만들 때 가장 가까운 리전을 선택합니다.
- 가능하면 Alpacon 엔드포인트에 대해 프록시를 우회합니다.
traceroute로 네트워크 경로를 확인합니다.- 서버 자체의 리소스 사용량을 점검합니다.
관련 문서
- 플랫폼 보안 및 가용성 - 전송 구간 암호화, 인증서, 플랫폼 보호
- 보안 개요 - 전반적인 보안 접근 방식
- 데이터 보안 - 데이터 보호 조치
- 연결 문제 해결 - 연결 끊김·세션 실패 진단
문의
네트워크 구성 관련 도움: