공인 IP와 서브도메인으로 서비스 공개

외부에서 직접 접속할 수 있는 공인 IPv4 또는 IPv6와 도메인이 있고, 웹 서비스마다 별도의 서브도메인을 사용하려는 환경에 적합합니다. 최종 접속 주소의 예시는 다음과 같습니다.

text

auth.example.com     로그인 진입점
nas.example.com      fnOS 또는 NAS 서비스
files.example.com    파일 서비스

이 방식은 공인 IP 직접 연결과 Host 라우팅을 조합한 서브도메인 모드이며 리버스 프록시 모드 → 서브도메인 매핑이 아닙니다. 인터넷 인바운드 경로가 없다면 공인 IP 없이 터널로 서브도메인 공개를 참고합니다.

사전 요구 사항

인터넷에서 fn-knock 게이트웨이 포트에 접속할 수 있습니다. fnOS FPK, Docker, OpenWrt, Linux, Synology DSM 7 SPK, Windows에서 모두 이 방식을 사용할 수 있습니다. Docker는 게이트웨이 포트를 호스트에 공개해야 하고, Synology와 Windows는 각각 DSM/Windows 방화벽, 라우터 또는 앞단 프록시가 인터넷 트래픽을 게이트웨이로 전달하는지 확인합니다.
라우터, 클라우드 보안 그룹, 호스트에서 서비스의 원본 포트를 별도로 인터넷에 공개하지 않습니다.
DNS를 수정할 수 있는 example.com 도메인을 준비했습니다.
TOTP 또는 사용자 이름과 비밀번호를 복구할 수 있는 기기가 하나 이상 있습니다.
모바일 데이터 같은 실제 외부 네트워크에서 검증할 수 있습니다.

설정 절차

시스템 설정 → 모드에서 서브도메인 모드를 선택하고 저장합니다.
서브도메인 매핑을 열어 루트 도메인과 인증 서비스가 사용하는 실제 공인 포트를 입력합니다. 예를 들어 루트 도메인이 example.com, 인증 Host가 auth.example.com이고 공인 443을 내부 게이트웨이 7999로 전달한다면 공개 포트에 443을 입력합니다.
인증 서비스 매핑을 만듭니다. 인증 서비스는 공개 상태를 유지해야 하며 자체적으로 ‘로그인 필요’, 기존의 엄격한 허용 목록 또는 업스트림 Basic Auth 삽입을 적용하면 안 됩니다.
첫 번째 서비스 Host(예: files.example.com)를 만듭니다. 대상(타깃)에는 서비스의 LAN HTTP 주소를 입력하고 ‘로그인 필요’를 켭니다.
DNS에서 인증 Host와 서비스 Host가 같은 인터넷 엔드포인트를 가리키도록 합니다. 서비스가 많다면 와일드카드 레코드를 사용할 수 있습니다. 라우터가 게이트웨이 포트를 fn-knock로 전달하는지도 확인합니다.
SSL 인증서에서 인증 Host와 서비스 Host를 포함하는 인증서를 구성합니다.
공인 주소가 바뀐다면 DDNS를 구성합니다. 고정 공인 주소라면 건너뛸 수 있습니다.

DNS 및 포트 예시

text

auth.example.com  A/AAAA -> 인터넷 진입점
files.example.com A/AAAA -> 인터넷 진입점
인터넷 443/TCP -> fn-knock 7999/TCP

이 구성에서는 브라우저로 https://files.example.com에 접속하며 루트 도메인 설정의 인증 서비스 포트에 443을 입력합니다. 외부 주소가 https://files.example.com:8443이라면 공인 8443을 실제 게이트웨이 포트로 전달하고 관련 공개 포트 설정에도 8443을 입력합니다.

A와 AAAA를 함께 게시하기 전에 IPv4와 IPv6 모두 게이트웨이에 도달하는지 각각 확인합니다. AAAA가 접속할 수 없는 주소를 가리키면 IPv6를 지원하는 클라이언트가 실패하는 경로를 먼저 선택할 수 있습니다. 안정적인 IPv6 인바운드 경로가 없다면 A 레코드만 게시합니다.

서비스 매핑 필드

필드	권장 설정
Host	전체 도메인을 입력하거나 페이지에서 루트 도메인과 조합합니다. 경로를 포함할 수 없습니다.
대상(타깃)	fn-knock 실행 환경에서 접속할 수 있는 `http://` 또는 `https://` 주소 사용
로그인 필요	개인 서비스에서는 켜고 인증 서비스에서는 반드시 끔
호스트 응답	기본적으로 사용자의 Host를 유지. 업스트림이 자체 Host만 허용할 때 끔
Basic Auth 건너뛰기	업스트림 자체 Basic Auth 자격 증명을 삽입할 때만 사용하며 fn-knock 로그인을 대신할 수 없음
WAF	서비스 호환성을 확인하여 Host별로 활성화하거나 우회

Docker에서 127.0.0.1은 컨테이너 자체만 뜻합니다. 호스트 또는 다른 컨테이너의 서비스에는 fn-knock 컨테이너에서 접속할 수 있는 주소를 사용합니다. 여러 Host가 같은 대상(타깃)을 재사용하면 호스트 응답 설정도 공유합니다. 서로 다른 정책이 필요하면 별도의 대상(타깃)을 사용합니다.

검증

가정 Wi-Fi 연결을 끊고 모바일 네트워크에서 다음 순서로 테스트합니다.

인증 Host를 열고 로그인을 완료합니다.
서비스 Host를 열어 올바른 업스트림에 들어가는지 확인합니다.
요청 로그에서 Host, 클라이언트 IP, 인증 상태, 업스트림 대상을 확인합니다.
서비스의 원본 공인 포트로 접속을 시도하여 게이트웨이를 우회할 수 없는지 확인합니다.

LAN에서 로그인 없이 접속된다는 사실은 인터넷 정책이 정상이라는 뜻이 아닙니다. fn-knock는 사설망과 로컬 출발지를 로컬 예외로 처리합니다.

다음 오류 상황도 테스트합니다.

구성하지 않은 Host에 접속하면 다른 서비스가 아니라 게이트웨이 기본 응답을 반환합니다.
서비스 범위가 제한된 Host에 해당 범위를 갖지 않은 자격 증명으로 접속하면 거부되는 것이 정상입니다.
로그아웃한 뒤 서비스 Host를 다시 열면 현재 출발지에 유효한 IP 접근 권한이 남아 있지 않은 한 인증 절차가 다시 시작되는지 확인합니다.
WebSocket, 업로드, 다운로드, 서비스 콜백이 정상 작동합니다.

롤백

여러 서비스를 한꺼번에 마이그레이션하기 전에 서비스 Host 하나만 먼저 연결합니다. 롤백해야 한다면 기존 DNS와 포트 포워딩을 복원한 뒤 새 매핑을 삭제하거나 비활성화합니다. 인증서와 DDNS 작업은 다른 Host가 더 이상 사용하지 않는다는 사실을 확인한 뒤 정리합니다. 유일한 인증 Host를 먼저 삭제하면 로그인이 필요한 모든 서비스 Host가 정상적인 로그인 경로를 잃게 됩니다.

문제 해결

증상	확인 항목
인증 Host가 열리지 않음	DNS, 게이트웨이 포트, 라우터 포워딩, 인증서, 인증 서비스 매핑
로그인 후에도 서비스 Host가 거부됨	매핑 접근 정책, 자격 증명 서비스 범위, 쿠키 도메인, 실제 클라이언트 IP
잘못된 서비스가 열림	Host 이름, DNS 레코드, 업스트림 대상
브라우저에 인증서 오류가 표시됨	인증서가 해당 Host를 포함하는지, CDN/오리진 연결이 올바른 TLS 이름을 사용하는지 확인

공인 IP와 서브도메인으로 서비스 공개 ​

사전 요구 사항 ​

설정 절차 ​

DNS 및 포트 예시 ​

서비스 매핑 필드 ​

검증 ​

롤백 ​

문제 해결 ​