TCP/UDP 스트림 프록시

프로토콜 매핑은 SSH, 데이터베이스, DNS 같은 비 HTTP 서비스에 TCP / UDP 수신 포트를 추가합니다. 도메인 Host나 URL 경로를 읽지 않고 외부 포트의 바이트 스트림을 host:port로 전달합니다.

이 기능은 공인 IP 직접 연결 서브도메인 모드를 보완하는 용도로만 사용합니다. 웹 서비스에는 계속 서브도메인 매핑을 사용하고 경로 호환 규칙은 경로 매핑을 참고합니다.

매핑 관리의 프로토콜 탭에서 TCP / UDP 규칙을 관리합니다. 탭 표시는 현재 모드와 프로토콜 매핑 기능의 활성화 상태에 따라 달라집니다.

활성화 조건

프로토콜 매핑은 공인 IP 직접 연결 서브도메인 라우팅에서만 사용합니다. 다음 경우 사이드바에 표시됩니다.

1. 시스템 설정 → 모드가 서브도메인 모드입니다.
2. 시스템 설정 → 기능 → 프로토콜 매핑이 활성화되어 있거나 관리해야 할 저장된 규칙이 남아 있습니다.

기능 스위치를 끄면 모든 프로토콜 매핑 수신 포트가 중지되지만 규칙은 삭제되지 않습니다. 규칙이 남아 있는 동안 관리 메뉴와 비활성 안내가 유지되어 잘못된 설정을 수정하거나 삭제할 수 있습니다. 비활성 상태에서는 게이트웨이 동기화를 실행할 수 없습니다. 다시 켜면 남은 규칙의 수신 포트가 복원됩니다. 서브도메인 모드에서 다른 모드로 전환할 때도 기능과 수신 포트는 중지되지만 규칙은 유지됩니다.

리버스 프록시 모드 → 서브도메인 매핑도 Host 라우트를 사용하지만 프로토콜 매핑은 제공하지 않습니다. FRP나 Cloudflare에서 다른 프로토콜을 처리하려면 해당 플랫폼에 별도로 설정해야 하며 fn-knock의 HTTP Host 진입점을 재사용할 수 없습니다.

라우팅 방식

TCP :2222 -> 192.168.1.20:22
TCP :13306 -> 127.0.0.1:3306
UDP :53   -> 127.0.0.1:53

도메인은 진입점 주소를 가리키는 역할만 하며 프로토콜 분배에는 관여하지 않습니다. 클라이언트는 nas.example.com:2222에 연결할 수 있고, 최종적으로 일치하는 규칙은 전송 프로토콜과 포트만으로 결정됩니다.

규칙 필드

필드	설명
전송 프로토콜	TCP, UDP를 함께 선택할 수 있으며 저장 후 두 규칙으로 분리
외부 포트	클라이언트가 연결하는 포트로 범위는 1-65535
메모	용도가 비슷한 매핑을 구분하고 검색하기 위한 선택 설명
대상 주소	경로나 http:// 없이 순수한 host:port 형식
인증 필요	연결 전에 출발지 IP를 기준으로 fn-knock 접근 권한 상태 확인

같은 포트에 TCP와 UDP 규칙을 각각 하나씩 만들 수 있습니다. 예를 들면 53/tcp와 53/udp입니다. 같은 프로토콜과 포트 조합은 중복될 수 없습니다.

외부 포트를 로컬 기기의 같은 포트로 전달할 수 없습니다. 예를 들어 TCP :3306 -> 127.0.0.1:3306은 로컬 포워딩 루프를 만들기 때문에 저장 및 활성화 시 거부됩니다. localhost, 루프백, 미지정 주소 및 현재 로컬 인터페이스 주소를 검사합니다. 외부 포트나 대상 포트를 변경합니다.

서비스 시작 시 같은 포트 로컬 루프, 다른 프로세스가 사용 중인 외부 포트 또는 안전하게 적용할 수 없는 런타임 오류가 발견되면 프로토콜 매핑 전체를 자동으로 비활성화합니다. 잘못된 규칙 하나가 관리 화면과 다른 게이트웨이 기능을 막지 않도록 하며, 저장된 규칙과 사이드바 항목은 유지됩니다. 확인 가능한 프로토콜, 포트, Target 및 원본 오류가 페이지에 표시됩니다.

문제 규칙을 수정하거나 삭제한 뒤 시스템 설정 → 기능에서 다시 활성화하세요. 포트 충돌이면 수신 중인 프로세스를 찾고, 특정 규칙을 찾지 못하면 최근 변경한 매핑을 하나씩 확인합니다. 해결하지 않은 상태에서 동기화나 재시작을 반복해도 복구되지 않습니다.

대상에는 fn-knock 실행 환경에서 접근 가능한 주소를 입력합니다. Docker에서 127.0.0.1은 컨테이너 자체를 가리키므로 호스트나 LAN 대상에는 컨테이너에서 접근할 수 있는 주소를 사용합니다.

목록 검색은 프로토콜, 외부 포트, 메모, 대상 주소, 서비스 식별 결과 및 인증 상태를 대상으로 합니다. 메모는 목록에서 바로 수정할 수 있고 프로토콜, 포트, 대상 또는 인증 상태는 매핑 편집 화면에서 변경합니다.

서비스 식별 및 엄격한 프로토콜 검증

새 프로토콜 매핑은 저장 후에도 활성 상태로 유지되며 처음에는 엄격한 검증 꺼짐으로 표시됩니다. 저장한 뒤 규칙의 추가 작업에서 감지를 실행합니다. 시스템이 대상에 능동적으로 연결하고, 엄격한 검증을 지원하는 서비스를 높은 신뢰도로 식별하면 서비스 프로필을 기록하고 엄격한 프로토콜 검증을 켭니다. 서비스 유형만 식별할 수 있으면 프로필은 기록하지만 엄격한 검증은 끈 상태로 둡니다. 감지에 실패하거나 결과가 불명확해도 매핑은 활성 상태를 유지하며 엄격한 검증만 꺼집니다.

업스트림 인증 때문에 HTTP 감지에서 401만 확인되어 일반 HTTP와 WebDAV 같은 구체적인 서비스를 안정적으로 구분하지 못할 수 있습니다. 이때 추가 작업에서 서비스 유형 지정을 선택하고 대상에서 실제로 실행 중인 서비스를 확인합니다. 엄격한 검증을 지원하는 서비스라면 확인 및 검증 활성화를 실행할 수 있고, 식별만 가능한 유형도 엄격한 검증을 끈 채 저장할 수 있습니다. 엄격히 검증 가능한 유형을 잘못 선택하면 정상 연결도 프로토콜 불일치로 거부됩니다. 수동으로 지정한 서비스 유형을 지우면 엄격한 검증은 꺼지지만 매핑은 비활성화되지 않습니다.

규칙의 전송 프로토콜, 외부 포트 또는 대상을 바꾸면 이전 서비스 식별 결과가 지워지고 엄격한 검증이 꺼지지만 매핑은 활성 상태를 유지합니다. 엄격한 프로토콜 필터링에 의존하려면 새 대상을 다시 감지하거나 서비스 유형을 지정합니다. 이 세 필드를 그대로 두고 메모나 로그인 요구 사항만 편집할 때에만 검증된 서비스 정보가 유지됩니다.

기존에 만들어져 서비스 식별 정보가 없는 규칙은 레거시 또는 엄격한 검증 미사용 상태로 표시될 수 있습니다. 앱을 업데이트해도 서비스 유형이 자동 지정되지는 않습니다. 각 대상을 확인한 뒤 감지를 실행합니다. 그 전까지는 엄격한 검증을 끈 채 매핑을 계속 전달할 수 있습니다.

트래픽 세부 정보와 활성 IP

목록의 트래픽 열은 각 TCP/UDP + 외부 포트별로 따로 집계됩니다. 세부 정보를 열면 실시간 수신·송신 속도, 현재 연결 수, 누적 트래픽과 최근 15분, 1시간, 6시간, 1일 또는 7일의 기록을 확인할 수 있습니다.

같은 패널에는 최근 활성 상태였던 출발지 IP도 표시됩니다. 매핑 페이지를 벗어나지 않고 IP를 차단 목록에 추가하거나 제거하거나 로컬 IP로 표시할 수 있습니다. 이 작업은 전역 차단 목록과 로컬 IP 규칙을 변경하므로 공유 규칙을 수정하기 전에 일반 차단 목록을 확인합니다.

트래픽 기록은 프로토콜 게이트웨이가 실제로 관측한 바이트를 기준으로 하며 운영 및 문제 해결용이지 과금용이 아닙니다. UDP에는 연결 상태가 없으므로 출발지는 짧은 시간 동안만 활성 상태로 처리됩니다. 프로세스 재시작이나 정리 정책으로 사용 가능한 기록 범위가 줄어들 수도 있습니다.

인증은 출발지 IP와 자격 증명 범위를 확인

SSH, MySQL, Redis 같은 클라이언트는 fn-knock 로그인 페이지를 열지 않습니다. 인증 필요를 켠 뒤에는 다음 순서로 사용합니다.

1. 브라우저에서 fn-knock 웹 진입점을 열고 로그인을 마칩니다.
2. 시스템 설정 → 세션 → 로그인 후 IP 접근 허용을 끄지 않았다면 로그인 절차가 현재 인터넷 출구의 공인 IP에 프로토콜 접근 권한을 만듭니다. 그렇지 않으면 해당 IP / CIDR을 직접 추가합니다.
3. 프로토콜 클라이언트에서 같은 인터넷 출구 IP를 통해 외부 포트에 연결합니다.

자격 증명이 전체 범위를 사용하면 프로토콜 접근 권한을 인증이 켜진 모든 프로토콜 매핑에 사용할 수 있습니다. 사용자 지정 범위를 사용하면 인증 설정 → 권한에서 정확한 TCP/UDP + 외부 포트를 선택해야 합니다. 시스템은 선택한 매핑에만 현재 출발지 IP를 허용하며 선택하지 않은 프로토콜이나 포트는 계속 거부합니다. 자격 증명 범위를 바꾸면 기존 세션의 프로토콜 접근 권한도 함께 조정됩니다.

인터넷 출구 IP가 바뀌거나 접근 권한이 만료되거나 로그인 후 IP 접근 허용을 껐거나 클라이언트가 다른 네트워크를 사용하면 연결이 즉시 거부됩니다. 이때는 다시 로그인하거나 수동 접근 권한을 업데이트합니다. 브라우저 쿠키는 TCP / UDP 연결과 함께 전송되지 않으며 프로토콜 진입점은 출발지 IP, 프로토콜 및 외부 포트에 의존합니다. 수동 IP / CIDR 접근 권한은 여전히 독립된 허용 경로입니다. 세션과 IP 변경은 세션 관리 및 IP 변경 이력을, 인증 방식과 사용자 지정 범위는 인증 체계 개요를 참고합니다.

프로토콜 클라이언트에는 브라우저 쿠키가 없으므로 게이트웨이는 현재 세션에서 확인한 출발지 IP를 프로토콜 접근 권한과 연결합니다. 세션이 유효한 동안 현재 출발지 IP는 해당 프로토콜 접근 권한의 전체 유효 기간 동안 계속 사용할 수 있습니다. 모바일 네트워크 변경으로 추가된 IP는 설정한 이동 허용 시간 동안만 유효합니다. 세션 또는 프로토콜 접근 권한이 만료되면 연결이 거부되며 이전에 로그인했다는 이유만으로 과거 IP를 영구 보존하지 않습니다.

인증 필요를 끄면 해당 수신 포트가 공개적으로 전달됩니다. 대상 서비스 자체의 SSH 키, 데이터베이스 비밀번호, TLS 및 최소 권한은 계속 설정합니다.

지정한 출발지의 로그인 우회

인증 필요가 켜진 매핑에서는 추가 작업의 로그인 우회 설정을 통해 지정한 출발지가 먼저 웹 로그인하지 않고 연결하도록 할 수 있습니다. 조건은 정확한 출발지 IP, CIDR 또는 출발지 지역을 사용할 수 있습니다. 같은 규칙 그룹 안의 조건은 AND, 서로 다른 그룹은 OR로 평가됩니다. 일치하지 않는 출발지는 기존 로그인 인증 절차를 계속 따릅니다.

지역 조건은 저장할 때 고정 CIDR 집합으로 컴파일되며 지역 데이터베이스가 업데이트되어도 자동으로 바뀌지 않습니다. 데이터베이스 변경 후 정책을 다시 저장합니다. 지나치게 넓은 CIDR이나 부정 조건으로만 구성된 광범위한 규칙은 저장할 때 한 번 더 확인해야 합니다. 매핑 하나에는 최대 16개 그룹, 그룹마다 최대 16개 조건을 저장할 수 있습니다.

로그인 우회는 fn-knock 로그인 검사만 건너뜁니다. 서비스 식별과 엄격한 프로토콜 검증은 계속 실행되며 대상 자체의 계정, 키 또는 TLS를 대체하지 않습니다. 인증 필요를 끄면 모든 출발지가 이미 직접 연결할 수 있으므로 활성화된 우회 정책은 비활성화되고 규칙은 초안으로 남을 수 있습니다. 인증을 다시 켤 때 정책 상태도 다시 확인합니다.

전역 개방 시간

프로토콜 매핑 페이지에서 매핑 추가 옆의 추가 작업을 열고 활성화 또는 비활성화 예약을 선택하면 모든 TCP / UDP 규칙에 공통으로 적용할 일일 개방 시간을 설정할 수 있습니다. 시간은 HH:mm 형식이며 서버 로컬 시간에 따라 매일 반복됩니다. 활성화 시간과 비활성화 시간은 같을 수 없습니다. 22:00-06:00 같은 설정은 자동으로 자정을 넘어 다음 날까지 이어집니다.

예약 닫힘과 기능 비활성화는 서로 다른 상태입니다.

• 기능 스위치를 끄면 모든 프로토콜 리스너가 중지됩니다.
• 예약 닫힘 시간에도 포트는 계속 수신 대기하지만 새 TCP 연결은 거부되고 UDP 패킷은 버려집니다.
• 닫힘 시간 전에 만들어진 TCP 세션은 강제로 끊기지 않습니다.
• 다음 개방 시간이 되면 게이트웨이를 다시 동기화하지 않아도 새 연결을 받습니다.

이 실행 시간 규칙은 모든 프로토콜 매핑에 적용되며 포트별로 다른 시간을 설정할 수 없습니다. 관리 페이지는 서버 시간을 기준으로 예약 개방 중 또는 예약 닫힘을 표시합니다. 브라우저나 서버 시간대가 잘못되면 표시와 실제 접근 시간이 예상과 다를 수 있으므로 서버 시계와 시간대를 먼저 수정합니다.

local_exempt

인증 서비스는 게이트웨이가 인식한 루프백, 사설망 및 링크 로컬 출발지를 local_exempt로 분류합니다. 이러한 출발지가 인증이 활성화된 프로토콜 매핑에 연결하면 로컬 네트워크 접근으로 처리되어 웹 로그인을 먼저 요구하지 않습니다.

따라서 다음 사항에 유의합니다.

• LAN 연결 성공만으로 인터넷 인증이 적용되었다고 판단할 수 없습니다.
• 포트 앞에 NAT나 프록시가 있다면 게이트웨이가 프록시의 사설 주소를 보고 있지 않은지 확인합니다.
• 인터넷 테스트에는 실제 외부 네트워크를 사용하고 세션의 출발지 IP를 대조합니다.

저장, 동기화 및 방화벽

생성, 편집, 삭제 및 메모 변경은 순서대로 저장되므로 연속 작업이 서로 덮어쓰지 않습니다. 수신 포트에 영향을 주는 규칙 변경은 게이트웨이를 새로 고치고 지원되는 배포에서는 포트 허용 규칙도 동기화합니다. 메모는 관리와 검색에만 사용되며 전달에는 영향을 주지 않습니다. 게이트웨이 동기화는 전체 설정을 명시적으로 다시 적용할 때 사용하며 일반적으로 매번 클릭할 필요는 없습니다.

플랫폼별 지원 범위는 다음과 같습니다.

• fnOS 네이티브 FPK는 자동 방화벽 관리를 활성화했을 때 프로토콜 포트를 동기화할 수 있습니다.
• fn-knock는 OpenWrt 호스트 방화벽을 관리하지 않습니다. 프로토콜 매핑은 계속 수신할 수 있지만 관리자가 OpenWrt 방화벽에서 해당 포트를 직접 허용해야 합니다.
• Docker는 새 호스트 포트를 공개하거나 호스트 방화벽을 수정하지 않습니다. 컨테이너 시작 설정에서 고정 포트를 명시적으로 공개하고 호스트와 라우터 규칙을 직접 처리합니다. 실행 중인 Compose에서는 관리자 페이지에서 포트만 추가해 인터넷에 공개할 수 없습니다.
• 게이트웨이 실행 환경을 직접 관리하는 경우에도 포트 허용은 시스템 관리자의 책임입니다. fn-knock가 호스트 방화벽을 수정한다고 가정하지 않습니다.

플랫폼에서 포트를 자동으로 허용하는지와 관계없이 라우터 포트 포워딩, 클라우드 보안 그룹 및 상위 네트워크 정책에서도 해당 포트를 허용합니다.

확인 및 문제 해결

1. 현재 공인 IP 직접 연결 서브도메인 모드이고 기능 스위치가 계속 켜져 있는지 확인합니다.
2. 프로토콜과 외부 포트가 클라이언트 설정과 일치하는지 확인합니다.
3. fn-knock 실행 환경에서 대상(타깃)에 직접 연결합니다.
4. 컨테이너 포트 공개, 호스트 방화벽, 라우터 포워딩 및 클라우드 보안 그룹을 확인합니다.
5. 인증을 켰다면 브라우저 로그인과 프로토콜 클라이언트가 같은 공인 인터넷 출구 IP를 사용하는지, 로그인 후 IP 접근 허용을 끄지 않았는지, 사용자 지정 자격 증명에서 현재 프로토콜과 외부 포트를 선택했는지 확인합니다.
6. 서버의 현재 시간이 전역 개방 구간 안에 있는지 확인합니다. 예약 닫힘 시간에는 포트가 검색되더라도 새 트래픽을 전달하지 않습니다.
7. 시작 실패로 자동 비활성화되었다면 규칙을 수정하거나 사용 중인 포트를 해제한 뒤 다시 켭니다. 시작 오류가 기록되지 않았는데 저장 후에도 수신하지 않을 때만 게이트웨이 동기화를 실행하고 상태와 로그를 확인합니다.

관련 기능 스위치는 시스템 설정을 참고합니다.