메인 콘텐츠로 건너뛰기

NAT 뒤 내부 Linux 서버에 원격 SSH 접속하기

완성 결과: VPN으로 내부 네트워크 전체를 연결하지 않고, 외부 엔지니어가 DRLink Server의 지정된 포트를 통해 내부 Linux 호스트의 SSH에 접속합니다. 구성 예: 외부 PC → 공인 DRLink Server → Agent의 아웃바운드 터널 → 내부 10.10.20.15:22.

준비

  • 서버 설치 완료, Server 설치 프로그램와 외부 방화벽 경로 확보
  • 내부 호스트에서 DRLink Server로 아웃바운드 통신 가능
  • 내부 호스트에 이미 동작하는 sshd와 SSH 사용자 계정/키 존재. DRLink는 계정이나 sshd를 생성하지 않습니다.
  • 원격 접속을 외부에 공개하기 전에 필요하면 접근 허용 IP 제한을 먼저 설정하세요. Remote Access의 초기 No Policy 상태는 ALLOW입니다.

1단계 — 서버 상태 확인

실제 Data Relay Link CLI 캡처 — 제품 버전 조회: 설치 버전과 DRLink Server 역할을 확인합니다. 그림 1. 제품 버전 조회: 설치 버전과 DRLink Server 역할을 확인합니다. 제품 CLI 출력 예시; 일부 주소·호스트는 가렸습니다. DRLink Server 셸:
확인: Role이 DRLink Server이고 서비스 상태가 정상인지 확인합니다.

2단계 — SSH용 Zero-Touch 등록 발급

Server REPL:
마법사에서 Linux → 호스트 이름·설명 → SSH only → 실제 SSH 포트(기본 22)를 선택합니다. SSH 사용자명은 접속 예시용이며 비워도 SSH는 게시됩니다. Zero-Touch에서 SSH only, RDP only 또는 Choose Remote Services로 선택한 서비스는 등록 시 Service Object·Remote Service·공인 포트 예약까지 자동 구성됩니다. 같은 서비스를 수동으로 다시 생성하지 않습니다. Agent에서 show remote-services로 실제 이름을 확인하세요. 화면에 출력된 실제 일회용 설치 명령어 전체를 복사하여 내부 Linux 호스트의 관리자 터미널에서 실행합니다. 예시 URL을 임의로 만들지 마세요. 등록 URL/티켓은 비밀 인증정보이므로 공개 문서·이슈·로그에 복사하면 안 됩니다.

3단계 — Agent와 자동 생성된 서비스 확인

실제 Data Relay Link CLI 캡처 — 실제 Agent Host 상태: Agent 역할, Healthy 런타임 및 Server Connected를 확인합니다. 그림 2. 실제 Agent Host 상태: Agent 역할, Healthy 런타임 및 Server Connected를 확인합니다. 제품 CLI 출력 예시; 일부 주소·호스트는 가렸습니다. 내부 Agent Host 셸:
확인: Role Agent Host, 정상 등록 및 제어 채널 연결. 내부 호스트에서 sudo drlink를 열고 조회합니다. <actual-service-name>은 목록의 실제 이름으로 바꾸세요:
확인: DRLink Server에서 할당한 공인 포트/주소가 보이고 대상 및 런타임이 검증되면 HEALTHY입니다. DEGRADED/Pending allocation은 성공 판정이 아닙니다.

4단계 — 외부 PC에서 실제 SSH 접속

실제 Data Relay Link CLI 캡처 — 실제 SSH Remote Service 검증 결과: HEALTHY 상태와 예약 엔드포인트를 확인합니다. 실제 공인 주소는 가렸습니다. 그림 3. 실제 SSH Remote Service 검증 결과: HEALTHY 상태와 예약 엔드포인트를 확인합니다. 실제 공인 주소는 가렸습니다. 제품 CLI 출력 예시; 일부 주소·호스트는 가렸습니다. 외부 PC 셸: 위에서 조회한 예약 포트·공인 주소·실제 SSH 계정을 사용합니다.
성공 기준: 대상 SSH 서버의 호스트 키를 별도로 확인하고 인증을 통과하여 내부 호스트에서 명령을 실행할 수 있어야 합니다. SSH 계정/키 오류는 DRLink 등록 오류와 다릅니다.

5단계 — 서버 목록·정책 확인

실제 Data Relay Link CLI 캡처 — 실제 Remote Access 정책 테스트: No Policy 상태의 ALLOW 결과입니다. WHITELIST 적용 성공 결과는 아닙니다. 그림 4. 실제 Remote Access 정책 테스트: No Policy 상태의 ALLOW 결과입니다. WHITELIST 적용 성공 결과는 아닙니다. 제품 CLI 출력 예시; 일부 주소·호스트는 가렸습니다. Server REPL:
필요한 SSH 서비스 하나만 노출되었는지, 실제 외부 접속과 감사 기록이 대응하는지 확인합니다. 접속 허용을 제한하려면 사무실 IP 허용 시나리오를 완료하세요.

실패 시/철회

  • DEGRADED: Agent에서 system diagnostics → system synchronize → show remote-service <actual-service-name> 순서로 확인
  • 시간 초과: 공인 포트 방화벽/NAT, Agent 터널, 서버 정책, 대상 22번 포트 검사
  • Permission denied: 대상 SSH 사용자·키·sshd 권한 검사
  • 서비스 제거: 소유 Agent에서 unset remote-service <actual-service-name> 실행 전 포트 예약과 연결 중단 영향을 확인합니다. 단일 서비스 때문에 전체 Managed Host를 삭제하지 마세요.

최신 동작 확인 — 2026-10-28

재연결 후 소유 Agent에서 system synchronize와 show remote-service <actual-service-name>를 확인합니다. HEALTHY는 현재 런타임 검증이 필요하며 저장된 플래그/heartbeat만으로 판단하지 않습니다. 복구 후 실제 SSH를 다시 연결하고 DEGRADED를 지우려는 목적으로 재등록하지 마세요. 현재 CLI 전체 목록 · MCP 호환성
마지막 수정일 2026년 10월 29일