Skip to main content

​
방화벽 & NAT

원격 Client에는 일반적으로 inbound port forwarding이 필요하지 않습니다. 반대로 Data Relay Link Server 측 public entry point는 control, enrollment, published service를 받을 수 있어야 합니다. 기존 실사용 가이드의 Direct, NAT, Enterprise single-443 배포 방식 이 그림을 보면 Server가 어디에 있는가와 어떤 제품 모드를 쓰는가를 분리해서 이해하기 쉽습니다. Private IP Server를 DNAT 뒤에 두어도 Direct 모드를 사용할 수 있고, Enterprise single-443은 제약된 Client Network를 위한 별도 transport 구조입니다.

​
구성 A — Server가 공인 IP를 직접 가짐

Direct 기본:

​
구성 B — Server가 Firewall/NAT 뒤 private IP

예시 DNAT:
Client에는 내부 IP가 아니라 외부에서 보이는 public control/enrollment endpoint를 사용해야 합니다.

​
Enterprise single-443를 Firewall/NAT 뒤에 둘 때

single-443에서는 외부 Firewall이 TCP 443 frontend만 전달하고, 내부 backend는 Data Relay Link Server의 loopback에 남겨둡니다.
Enterprise single-443에서는 Public TCP 7000이나 6099를 DNAT하지 마세요. 이 둘은 해당 topology에서 내부 backend listener입니다. 외부에 직접 노출하면 single-443의 보안/운영 경계를 우회하게 됩니다.
Server가 NAT 뒤에 있을 때는 Public Port와 Local Listen/Backend Port를 구분해야 합니다. Client에는 반드시 외부에서 실제로 보이는 public endpoint를 사용하고, Firewall에서는 그 endpoint를 의도한 내부 listener로 전달합니다.

​
Published service port는 가능하면 1:1

Registry의 persistent port reservation과 실제 사용자가 접속하는 Internet port를 일치시키면 운영과 troubleshooting이 훨씬 단순해집니다.

​
누가 무엇을 설정하나요?

​
Hairpin NAT / Split DNS

내부 사용자가 fw.example.com을 조회했을 때 public IP로 돌아가면 firewall이 hairpin NAT를 지원해야 내부 Data Relay Link server로 다시 들어올 수 있습니다. 지원하지 않는다면 split DNS 같은 내부 DNS 설계를 고려하세요.

​
NAT 문제 확인 순서

  1. Public DNS/IP가 올바른 firewall을 가리키는지
  2. Public control port가 내부 Data Relay Link control listen port로 DNAT되는지
  3. Public enrollment HTTPS가 allocator/listen port로 DNAT되는지
  4. Published service port가 열려 있고 가능하면 1:1인지
  5. Client가 자기 네트워크에서 public endpoint에 도달 가능한지
  6. Server drlink doctor가 topology 문제를 보고하는지
마지막 수정일 2026년 9월 10일