본문으로 건너뛰기

TCP/UDP 스트림 프록시

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

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

활성화 조건

사이드바에 프로토콜 매핑이 표시되려면 다음 조건을 모두 충족합니다.

  1. 시스템 설정 → 모드서브도메인 모드입니다.
  2. 시스템 설정 → 기능 → 프로토콜 매핑이 활성화되어 있습니다.

기능 스위치를 끄면 프로토콜 매핑 수신 포트가 중지되고 메뉴가 숨겨지지만 저장된 규칙은 유지됩니다. 다시 켜면 이전 설정으로 복원됩니다. 서브도메인 모드에서 다른 모드로 전환할 때도 기능과 수신 포트는 중지되지만 규칙은 유지됩니다.

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

라우팅 방식

text
TCP :2222 -> 192.168.1.20:22
TCP :3306 -> 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/tcp53/udp입니다. 같은 프로토콜과 포트 조합은 중복될 수 없습니다.

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

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

인증은 출발지 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 및 최소 권한은 계속 설정합니다.

local_exempt

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

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

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

저장, 동기화 및 방화벽

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

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

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

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

확인 및 문제 해결

  1. 현재 공인 IP 직접 연결 서브도메인 모드이고 기능 스위치가 계속 켜져 있는지 확인합니다.
  2. 프로토콜과 외부 포트가 클라이언트 설정과 일치하는지 확인합니다.
  3. fn-knock 실행 환경에서 대상(타깃)에 직접 연결합니다.
  4. 컨테이너 포트 공개, 호스트 방화벽, 라우터 포워딩 및 클라우드 보안 그룹을 확인합니다.
  5. 인증을 켰다면 브라우저 로그인과 프로토콜 클라이언트가 같은 공인 인터넷 출구 IP를 사용하는지, 로그인 후 IP 접근 허용을 끄지 않았는지, 사용자 지정 자격 증명에서 현재 프로토콜과 외부 포트를 선택했는지 확인합니다.
  6. 저장 후에도 수신 대기하지 않으면 게이트웨이 동기화를 클릭한 뒤 상태와 로그를 확인합니다.

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

QQ 커뮤니티: 1081609274