Gately v0.6.5.5 출시
2026년 11월 11일
v0.6.5.5 다운로드 · GitHub Release
포트 노킹 (#80)
「네트워크」 그룹에 「포트 노킹」 모듈을 추가했습니다. fwknop 클라이언트와 호환되는 단일 패킷 인가(SPA)로, 보호 대상 포트는 평소 외부에서 연결할 수 없고, 클라이언트가 암호화·인증된 노크 패킷을 먼저 보내 인증을 통과하면 그 출처 주소만 정해진 시간 동안 허용합니다. SSH 직접 연결 보호에 적합하며, scp나 IDE 원격 개발처럼 웹 터미널로 해결되지 않는 용도도 인터넷에서 안전하게 연결할 수 있습니다.
- 보안: 패킷은 AES로 암호화하고 HMAC으로 인증하며, HMAC을 먼저 검증한 뒤 복호화합니다. 패킷은 한 번만 사용할 수 있고(재전송 방지), 타임스탬프가 유효 기간(기본 120초)을 벗어나면 거부합니다. 사용자 이름을 제한하거나 허용할 주소를 패킷에 명시하도록 요구할 수 있습니다;
- 방화벽 차단: 노크 패킷은 기본적으로 UDP 62201에서 받습니다. 규칙은 보호 대상 포트를 시스템 방화벽(nftables, 커널에 nf_tables가 없으면 iptables + ipset)에 기록하고, 노크에 성공한 주소는 허용 시간(기본 30초) 안에 새 연결을 만들 수 있습니다. 이미 맺어진 연결에는 영향이 없습니다;
- 잠김 방지: 「내부망 노크 면제」가 기본으로 켜져 있어 사설 주소와 이 장치 인터페이스의 공인 IPv6 대역은 노크가 필요 없습니다(통신사급 NAT 대역 100.64.0.0/10은 포함되지 않음). 노크 면제 허용 목록을 추가할 수도 있습니다;
- Gately 진입점의 노크 허용: 포트 포워딩, 프로토콜 라우팅, STUN 내장 전달의 IP 접근 제어에서 「노크 필요」를 선택할 수 있습니다. Gately가 직접 판단하므로 방화벽 권한이 필요 없고 Windows, macOS,
NET_ADMIN이 없는 컨테이너에서도 쓸 수 있습니다; - 포트 하나만 개방: 프로토콜 라우팅이 라우트별로 노크를 요구할 수 있고, TCP로 노크 패킷을 받는 「포트 노킹」 라우트(프로토콜
spa,fwknop -P tcp)가 추가되었습니다. 같은 포트에서 노크를 받고 결과에 따라 SSH 등의 라우트를 허용합니다; - 침입 방지 연동: 거부된 노크를 침입 방지의 이벤트 소스로 쓸 수 있으며, 내장 「포트 노킹 실패」 템플릿은 기본적으로 10분에 5회면 1일 차단합니다. UDP로 와서 HMAC 인증에 실패한 패킷은 출처를 위조할 수 있으므로 집계만 하고 이벤트에는 쓰지 않습니다. 노크 성공과 거부는 알림 센터에서 구독할 수 있습니다;
- 클라이언트 설정: 규칙 카드의 「클라이언트」에서 fwknop 명령줄과
~/.fwknoprc설정 블록을 생성합니다. 키 형식은fwknop -k와 같습니다.
자세한 내용은 포트 노킹을 참고하세요.
Wake-on-LAN: 에이전트 원격 종료
원격 종료에 「에이전트」 방식이 추가되었습니다. Windows, Linux, macOS, OpenWrt에 에이전트를 설치하면(각각 예약 작업, 또는 systemd / OpenRC, launchd, procd 서비스로 등록) 에이전트가 Gately를 롱 폴링해 명령을 받습니다. 장치에서 포트를 열 필요가 없고, Gately는 장치의 로그인 정보를 저장하지 않습니다.
- 에이전트는 종료, 재시작, 절전 세 가지 고정 동작만 실행합니다. API
POST /api/wol/devices/{key}/shutdown에서{"action": "reboot"},{"action": "sleep"}으로 재시작, 절전을 지정할 수 있습니다; - 명령은 보낸 뒤 10초 동안만 유효합니다. 에이전트가 먼저 확인하고 Gately가 응답한 뒤에 실행합니다. 에이전트가 오프라인이면 바로 오류가 나며, 다음 연결 때까지 대기열에 남지 않습니다;
- 설치 명령은 먼저 스크립트의 SHA-256을 검증하고 일치하지 않으면 중단합니다. 자격 증명은 요청 본문과 환경 변수로 전달되며 URL이나 명령줄 인수에 나타나지 않습니다;
- 장치 카드에 에이전트의 온라인 여부와 보고된 호스트 이름, 시스템, 출처 주소가 표시됩니다. 자격 증명을 「재생성」하면 이전 에이전트는 즉시 끊어집니다.
Home Assistant, 스마트 플러그처럼 HTTP API를 제공하는 서비스를 위한 「HTTP 요청」 방식도 추가했습니다. URL, 메서드, 헤더, 본문을 입력하며 상태 코드 2xx를 성공으로 봅니다. 자세한 내용은 Wake-on-LAN · 에이전트를 참고하세요.
웹 서비스: 로그인한 사용자 신뢰 (#81)
사이트에 「로그인한 사용자 신뢰」 옵션이 추가되었습니다. 이 사이트의 Gately 인증을 통과한 방문자는 WAF를 거치지 않고, 요청도 침입 방지의 웹 경로 탐색에 집계되지 않습니다. WAF나 미끼 경로 규칙이 내부 사용자를 잘못 막는 경우에 씁니다. 신뢰하는 자격 증명은 웹 인증 세션, 서드파티 로그인 허용 목록에 하나씩 적힌 ID, 공유 사용자의 SSO, 검증된 기본 인증입니다. github:* 같은 제공자:* 와일드카드로 허용된 ID는 신뢰하지 않습니다. 차단, IP 및 국가 접근 제어, 속도 제한은 그대로 적용됩니다. 자세한 내용은 WAF 방화벽을 참고하세요.
사용자별 분배를 지원하는 사이트 유형 확대 (#79)
리디렉션, 정적 파일, 내비게이션 패널, 고정 텍스트 사이트에서도 인증 사용자별로 분배할 수 있습니다. 규칙에 일치하는 사용자는 규칙의 백엔드로 리버스 프록시되고, 나머지 방문자는 평소대로 사이트 유형에 따라 처리됩니다. 예를 들어 관리자는 관리 화면으로 들어가고 다른 로그인 사용자는 안내 페이지로 리디렉션됩니다. 자세한 내용은 웹 서비스 · 사용자별 분배를 참고하세요.
관리자 요청은 사이트 WAF를 건너뜀
WAF를 켠 사이트를 통해 관리 화면에 접속할 때, 이 인스턴스의 유효한 관리자 세션을 가진 요청은 사이트 WAF를 거치지 않습니다. 파일 경로, HTML, 스크립트 등이 들어 있는 설정을 저장해도 CRS 규칙에 의해 403으로 잘못 차단되지 않습니다. 읽기 전용 계정, 방문자, 다른 인스턴스의 관리 화면 요청은 그대로 검사합니다.
문제 수정
- OpenWrt 패키지 (#82): OpenWrt 25.12의 apk는 아키텍처 확인에 실패한 뒤에도 파일을 교체하기 때문에, 펌웨어에 패키지를 넣을 때 오프라인 폴더에 arm64 패키지가 섞이면 플래싱 후 프로그램이 반복해서 충돌했습니다. 이제 apk가 다른 아키텍처 패키지를 설치하면 실행 중인 gately 프로그램을 유지하고 그 사실을 알려 줍니다. 펌웨어에 넣거나 오프라인으로 설치할 때는 폴더에 장치 아키텍처와 맞는 gately 패키지만 두세요. 자세한 내용은 설치 및 배포 · OpenWrt를 참고하세요.
기타 개선
- API 문서에 로그인이 필요 없는 모듈 엔드포인트(Wake-on-LAN 에이전트의 폴링, 확인, 스크립트 다운로드 등)를 싣고 모듈 자체 자격 증명을 쓴다고 명시했으며, 포트 노킹 필드를 추가했습니다.
업그레이드 안내
- Docker는 새 이미지를 받은 뒤 컨테이너를 다시 만드세요. OpenWrt는 새
.apk/.ipk를 덮어 설치하고, LuCI 페이지가 필요하면 같은 버전의luci-app-gately도 설치하세요. fnOS는 앱 센터에서 새.fpk를 직접 설치하세요. 그 밖의 설치 방식은 "시스템 설정"에서 온라인 업그레이드할 수 있습니다. - 포트 노킹의 방화벽 차단에는 root 또는
CAP_NET_ADMIN이 필요합니다. Docker에서는 host 네트워크와cap_add: NET_ADMIN을 사용하세요.