공인 IP 없이 터널로 서브도메인 공개
공인 IP가 없어도 서브도메인 매핑을 사용할 수 있습니다. FRP 또는 cloudflared가 외부 요청을 fn-knock 게이트웨이 엔드포인트로 전달하면 게이트웨이가 Host에 따라 LAN의 서비스로 라우팅합니다.
기존 설정에는 경로 매핑을 계속 사용할 수 있지만 새로 배포할 때는 리버스 프록시 모드 → 서브도메인 매핑을 우선 선택합니다.
사전 요구 사항
- fn-knock가 배포되어 있고 로컬에서 게이트웨이 포트를 사용할 수 있습니다.
- FRP 서버 또는 Cloudflare Zero Trust 계정을 준비했습니다.
- 직접 관리할 수 있는 도메인이나 터널에서 제공하는 공개 호스트가 있습니다.
- 로그인 자격 증명과 실제 외부 네트워크 테스트 환경을 준비했습니다.
설정 절차
시스템 설정 → 모드에서리버스 프록시 모드를 선택한 뒤서브도메인 매핑을 선택합니다.서브도메인 매핑에서 루트 도메인, 인증 Host, 첫 번째 서비스 Host를 구성합니다. 서비스 Host의 대상(타깃)에는 fn-knock 실행 환경에서 접속할 수 있는 LAN 서비스 주소를 입력하고 기본적으로 ‘로그인 필요’를 켭니다. 인증 Host는 공개 상태로 유지합니다.리버스 프록시 모드에서 FRP 또는 cloudflared를 설치하고 구성하여 외부 트래픽을 fn-knock의 실제 게이트웨이 포트로 전달합니다.- 터널 제공자에서 인증 Host와 서비스 Host의 DNS 및 공개 호스트 이름(Public Hostname)을 구성하고 Host, WebSocket, 실제 클라이언트 IP가 올바르게 전달되는지 확인합니다.
- 외부 HTTPS를 구성합니다. 터널이나 앞단 리버스 프록시에서 TLS를 종료한다면 오리진 프로토콜과 인증서 검증 방식을 명확히 정합니다. 내부
localhost주소를 브라우저 접속 주소로 사용하면 안 됩니다. - 모바일 네트워크에서 인증 Host를 열고 로그인을 완료한 뒤 서비스 Host에 접속합니다.
FRP와 cloudflared의 차이
| 항목 | FRP | cloudflared |
|---|---|---|
| 인터넷 엔드포인트 | 직접 운영하는 frps 또는 서비스 제공자 노드 | Cloudflare Edge 및 Tunnel |
| DNS | 일반적으로 FRP 서버를 가리킴 | 공개 호스트 이름이 DNS를 생성하거나 연결하는 경우가 일반적 |
| 실제 출발지 IP | HTTP 헤더 또는 올바르게 구성한 PROXY Protocol | Cloudflare 요청 헤더. 엔드포인트에 맞는 설정 필요 |
| fn-knock에서의 관리 | 여러 frpc 인스턴스, 설정, 로그 관리 | 리소스, 터널 토큰, 프로세스, 로그 관리 |
FRP가 TCP 포워딩만 한다면 fn-knock에 터널 노드나 로컬 중계 주소가 연결 출발지로 보일 수 있습니다. FRP 경로에 맞춰 PROXY Protocol 또는 신뢰할 수 있는 실제 IP 헤더를 구성하고 요청 로그에서 결과를 확인합니다. 페이지가 열린다는 사실만으로 허용 목록, 지역, 스캔 차단 규칙이 실제 클라이언트 주소를 사용한다고 가정하면 안 됩니다.
cloudflared의 공개 호스트 이름은 서비스로 직접 연결하지 말고 http://127.0.0.1:7999 같은 게이트웨이 엔드포인트를 오리진으로 사용합니다. 서비스를 직접 오리진으로 지정하면 fn-knock의 Host 라우팅과 인증을 우회합니다.
대상(타깃) 주소
- fn-knock와 서비스가 같은 호스트에서 네이티브로 실행된다면 서비스가 실제로 수신하는
127.0.0.1:<포트>를 사용할 수 있습니다. - Docker에서
127.0.0.1은 fn-knock 컨테이너 자체입니다. 호스트 서비스에는 컨테이너에서 접속할 수 있는 주소를 입력하고, 다른 컨테이너에는 공유 Docker 네트워크의 서비스 이름을 사용합니다. - 서비스가 LAN의 다른 기기에 있다면 고정된 사설 IP 또는 내부 DNS 이름을 입력합니다.
- 대상(타깃)이 HTTPS라면 인증서 이름과 신뢰 체인을 확인합니다. LAN 인증서 오류도 게이트웨이에서는
502로 나타납니다.
DDNS가 필요하지 않은 이유
터널 환경에서 공개 도메인은 일반적으로 가정용 인터넷 주소가 아니라 FRP 서버 또는 Cloudflare Edge를 가리킵니다. 같은 Host에 가정 회선 주소를 업데이트하는 DDNS를 추가하면 DNS 충돌이 발생합니다. DNS가 최종적으로 주소가 바뀌는 자체 공인 엔드포인트를 가리켜야 할 때만 DDNS를 구성합니다.
연결 경로 검증
다음 순서로 확인합니다.
- fn-knock에 터널 리소스가 설치되어 있고 인스턴스 또는 터널이 실행 중이며 로그에 지속적인 재연결이 없습니다.
- 공개 DNS가 올바른 엔드포인트를 가리킵니다.
- 인증 Host를 열고 로그인할 수 있습니다.
- 요청 로그에 올바른 Host와 실제 클라이언트 IP가 표시됩니다.
- 서비스 Host가 올바른 업스트림과 일치합니다.
DNS는 해석되지만 요청 로그에 아무 기록이 없다면 터널이나 앞단 플랫폼을 확인합니다. 로그에 요청이 있지만 포워딩에 실패한다면 매핑과 업스트림 서비스를 확인합니다.
WebSocket, 업로드/다운로드, 로그아웃, 자격 증명의 서비스 범위도 계속 테스트합니다. LAN 요청에는 local_exempt가 적용될 수 있으므로 최종 결과는 반드시 실제 외부 네트워크에서 검증합니다.
롤백 및 마이그레이션
터널을 전환하기 전에 fn-knock 설정을 내보내고 기존 DNS, frpc 설정 또는 터널 공개 호스트 이름을 기록합니다. 롤백해야 한다면 기존 엔드포인트를 먼저 복원한 뒤 새 터널을 중지합니다. 서로 다른 실제 IP 또는 TLS 의미를 가진 두 엔드포인트가 같은 Host에 장기간 동시에 서비스를 제공하게 두지 않습니다.
경로 모드에서 서브도메인 매핑으로 마이그레이션할 때는 새 서비스 Host를 병렬로 만들고 검증한 뒤 기존 경로를 제거합니다. 업스트림 서비스에 절대 콜백 URL이 저장되어 있다면 해당 서비스 설정도 함께 변경합니다.