NAT 통과: 서브도메인 라우팅
인터넷에서 직접 들어오는 경로가 없거나 포트 포워딩을 구성할 수 없거나, FRP 또는 Cloudflared를 외부 엔드포인트로 사용하려는 환경에 적합합니다. 인터넷 트래픽은 먼저 터널을 거쳐 fn-knock 게이트웨이에 도착한 다음 요청 도메인에 따라 서비스로 전달됩니다.
- 네트워크 토폴로지: NAT 통과/터널링
- 라우팅 방식:
Host로 서비스 구분 - 권장 정책: 로그인 우선
- 관리 패널 위치:
시스템 설정 → 모드 → 리버스 프록시 모드 → 서브도메인 매핑
리버스 프록시 모드에서는 서브도메인 매핑을 기본으로 사용합니다. 경로 모드는 기존 설정을 호환하거나 반드시 특정 경로 접두사 아래에 배포해야 하는 애플리케이션에만 사용합니다.
시작 전 준비
다음 항목이 필요합니다.
- DNS를 관리할 수 있는 도메인(예:
example.com) - FRP 서버 또는 사용 가능한 Cloudflare Tunnel
- 사용할 수 있는 로그인 방식 하나 이상
- fn-knock가 실행되는 기기에서 서비스에 접속할 수 있는 네트워크 경로
fnOS FPK, Docker, OpenWrt, Linux, Synology DSM 7 SPK는 모두 내장 터널을 사용할 수 있습니다. Windows x86_64는 내장 FRP/Cloudflared를 제공하지 않습니다. 같은 Windows 호스트에서 터널 클라이언트를 별도로 실행한다면 로컬 127.0.0.1:7999를 오리진으로 사용하는 것을 권장하지만, 설치와 운영은 fn-knock가 관리하지 않습니다. Docker에서 127.0.0.1은 컨테이너 자체를 뜻합니다. 업스트림이 호스트나 LAN의 다른 기기에 있다면 컨테이너에서 접속할 수 있는 주소를 입력합니다.
요청 경로
외부 요청은 다음 순서로 이동합니다.
auth.example.com또는nas.example.com의 인터넷 엔드포인트- FRP 또는 Cloudflared 터널
- fn-knock의 실제 게이트웨이 포트. fnOS 네이티브 FPK, Docker Compose, OpenWrt, Linux, Synology DSM 7 SPK, Windows는 기본적으로
7999를 사용합니다. Windows에서 직접 관리하는 터널은 같은 호스트의 루프백 주소를 오리진으로 사용하는 것이 좋습니다. - 인증 서비스 또는 해당 서비스의 업스트림
터널은 원래 Host 헤더를 fn-knock에 전달합니다. 모든 도메인은 동일한 로컬 게이트웨이를 가리키고 fn-knock가 이후 라우팅을 처리합니다.
1. 리버스 프록시 모드와 서브도메인 매핑 선택
시스템 설정 → 모드로 이동합니다.
리버스 프록시 모드를 선택합니다.- 라우팅 방식에서
서브도메인 매핑을 선택합니다. - 설정을 저장합니다.
저장 후 사이드바에 서브도메인 매핑과 터널 관련 메뉴가 표시되는지 확인합니다.
다른 모드에서 전환했다면 기존 라우팅, 인증서, 인증 주소를 확인합니다. 경로 모드의 매핑을 서브도메인 매핑으로 바로 사용할 수는 없습니다.
2. 루트 도메인과 인증 서비스 설정
서브도메인 매핑에서 서브도메인 모드 설정을 펼친 뒤 도메인에 example.com을 입력하고 저장합니다. 인증 서비스의 외부 HTTPS 포트에는 사용자가 실제로 접속하는 인터넷 포트를 입력합니다. 그런 다음 인증 서비스 추가를 눌러 auth.example.com을 추가합니다.
인증 서비스는 다음 조건을 충족합니다.
- 공개 접근을 허용합니다.
- 이전 매핑에 엄격한 허용 목록 규칙이 남아 있다면 그대로 인증 서비스로 사용할 수 없습니다. 기존 설정을 기록한 뒤 인증 서비스를 다시 만듭니다.
- 인증 엔드포인트는 하나만 구성합니다.
- 터널에서 로컬 fn-knock 게이트웨이에 도달 가능한 구성이 필요합니다.
서비스 매핑을 만들기 전에 먼저 외부 네트워크에서 인증 주소가 열리는지 확인합니다.
3. 서비스 매핑 추가
서브도메인 매핑에서 서비스를 추가합니다. 예시는 다음과 같습니다.
| 설정 항목 | 예시 |
|---|---|
| 서브도메인 | nas |
| 대상 | http://192.168.1.20:5666 |
| 로그인 필요 | 켬 |
저장 후 인터넷 엔드포인트는 https://nas.example.com입니다.
업스트림에서 HTTP Basic Auth를 요구한다면 매핑의 고급 설정에서 Basic Auth 건너뛰기를 켜고 업스트림 자격 증명을 입력합니다. 이 자격 증명은 fn-knock가 업스트림에 연결할 때만 사용하며 사용자 로그인을 대신하지 않습니다.
4. 접근 정책 설정
현재 Host 편집 페이지에서는 로그인 필요 스위치를 제공합니다.
| 설정 | 동작 |
|---|---|
해당 Host 매핑의 로그인 필요를 끔 | 공개 접근. fn-knock 로그인과 허용 목록을 확인하지 않음 |
로그인 필요를 켬 | 유효한 출발지 접근 권한이 없으면 세션과 자격 증명의 서비스 범위를 차례로 확인 |
| 기존의 엄격한 허용 목록 규칙 | 로그인 필요를 꺼도 공개되지 않을 수 있습니다. 유효한 출발지 접근 허용 기록(수동 또는 로그인 후 자동 생성)만 확인하며, 세션 쿠키 자체로는 출발지 조건을 대신할 수 없습니다. |
대부분의 터널 환경에서는 로그인 필요를 켭니다. 현재 UI에서 엄격한 허용 목록 규칙을 새로 선택할 수는 없습니다. 이전의 엄격한 규칙에서 벗어나려면 현재 UI에서 매핑을 다시 만듭니다. 로그인 필요만 끄는 것으로는 공개되지 않습니다. Cloudflare, FRP 또는 다른 프록시 노드의 출발지 IP를 사용자의 고정 IP로 허용 목록에 추가하지 않습니다. 모든 요청이 같은 출발지로 간주될 수 있습니다.
5. 터널 설정
먼저 시스템 설정에서 FRP 또는 Cloudflared 리소스를 준비한 다음 리버스 프록시 모드 페이지에서 터널을 만들고 시작합니다.
Cloudflared 사용
Cloudflare Zero Trust에서 엔드포인트마다 Public Hostname을 구성합니다.
| 공개 도메인 | 로컬 서비스 |
|---|---|
auth.example.com | http://127.0.0.1:<실제 게이트웨이 포트> |
nas.example.com | http://127.0.0.1:<실제 게이트웨이 포트> |
fn-knock가 관리하는 Cloudflared와 게이트웨이가 같은 런타임 환경에 있다면 127.0.0.1과 실제 게이트웨이 포트를 사용합니다. Cloudflared를 별도 컨테이너로 실행하고 fn-knock와 같은 Docker 네트워크에 연결했을 때만 fn-knock의 컨테이너 서비스 이름과 포트를 사용합니다. 서로 다른 네트워크에 있다면 Cloudflared에서 도달할 수 있는 주소를 사용합니다.
인터넷 TLS는 Cloudflare에서 종료할 수 있습니다. 로컬 오리진에 HTTPS를 사용한다면 오리진 주소가 포함되고 Cloudflared에서 신뢰할 수 있는 인증서를 사용합니다. 그렇지 않다면 통제된 내부 네트워크에서 HTTP로 오리진에 연결합니다.
FRP 사용
FRP 서버는 외부 HTTP/HTTPS 트래픽을 fn-knock의 실제 게이트웨이 포트로 전달하고 원래 Host를 보존합니다. 인증 도메인과 서비스 도메인은 같은 게이트웨이 엔드포인트를 공유할 수 있습니다.
외부 포트, 인증서, DNS는 FRP 서버 배포 방식에 따라 구성합니다. fn-knock 관리 엔드포인트를 FRP의 서비스 오리진으로 공개하지 않습니다.
6. HTTPS와 공개 인증 주소 확인
엣지 플랫폼에서 TLS를 종료한다면 브라우저에 보이는 공개 주소에 HTTPS를 사용하고 fn-knock의 인증 리디렉션 주소도 이와 일치시킵니다. 공개 주소와 로컬 오리진의 프로토콜이 다를 때 로컬 HTTP 주소를 사용자에게 보이는 인증 URL에 넣지 않습니다.
FRP에서 HTTPS를 직접 제공한다면 FRP 서버 또는 fn-knock 게이트웨이에 모든 서브도메인을 포함하는 인증서를 구성합니다. 자세한 내용은 SSL 인증서를 참고합니다.
7. 외부 네트워크에서 검증
모바일 데이터에서 다음 순서로 테스트합니다.
auth.example.com을 열어 로그인 페이지에 접속할 수 있는지 확인합니다.nas.example.com을 열어 인증 절차로 들어가는지 확인합니다.- 로그인 후 서비스 페이지로 돌아오는지 확인합니다.
- 터널 상태와 fn-knock
요청 로그를 열어 요청이 올바른 Host 및 업스트림과 일치하는지 확인합니다.
경로 모드는 호환용으로만 사용
현재 UI에서 리버스 프록시 모드 → 경로 모드는 권장하지 않는 방식으로 표시됩니다. 다음 상황에서만 사용합니다.
- 기존 경로 매핑을 유지해야 하며 아직 마이그레이션할 수 없습니다.
- 인터넷에서 사용할 수 있는 도메인이 하나뿐입니다.
- 업스트림 서비스가 경로 접두사 아래의 배포를 명시적으로 지원합니다.
예를 들어 https://example.com/nas/를 NAS로 전달할 수 있습니다. 경로 접두사, 리디렉션, 쿠키, WebSocket을 처리할 수 있는 업스트림 서비스에만 적용합니다. 그렇지 않으면 리소스 404, 로그인 리디렉션 루프, 루트 경로 복귀 문제가 쉽게 발생합니다.
새 설정에서는 서비스마다 별도의 서브도메인을 할당합니다. 이전 구성을 마이그레이션하는 방법은 NAT 통과 및 경로 매핑을 참고합니다.
문제 해결
| 증상 | 우선 확인할 항목 |
|---|---|
| 터널은 온라인이지만 도메인이 타임아웃됨 | Public Hostname, FRP 엔드포인트, DNS, 터널 대상 포트 |
| 모든 서브도메인이 같은 서비스로 연결됨 | 터널 또는 앞단 프록시가 Host를 보존하는지 확인 |
| 502 응답 | 터널에서 게이트웨이에 접속할 수 없거나 게이트웨이에서 서비스 업스트림에 접속할 수 없음 |
| 로그인 후 리디렉션 반복 | 공개 프로토콜, 인증 도메인, 루트 도메인, 쿠키 범위, 앞단 프록시의 Host/X-Forwarded-*가 일치하는지 확인한 뒤 원래 서비스 Host에서 다시 접속 |
| Cloudflared TLS 오류 | 오리진 프로토콜 또는 인증서 신뢰 설정 오류 |
| 경로 모드에서 리소스 404 | 업스트림이 경로 접두사를 지원하지 않으므로 서브도메인 매핑으로 마이그레이션 권장 |
전체 문제 해결 안내는 FAQ를 참고합니다.