모든 포트를 전달하는 규칙은 WireGuard 리스너를 삼킬 수 있습니다
넓은 전달 규칙은 게이트웨이 자체의 WireGuard 및 SSH 리스너를 삼킬 수 있습니다. 좁은 규칙이나 별도의 공인 주소를 선택한 뒤 제어 경로를 시험하세요.
공인 게이트웨이가 이미 UDP 51820에서 WireGuard를, 22번에서 SSH를 실행하고 있으며 인터넷에서 접근해야 하는 애플리케이션 하나를 운영하고 있다고 합시다. 솔깃한 규칙은 모든 포트를 피어로 전달하고 일을 끝냈다고 선언합니다. WireGuard 게이트웨이에서 그런 규칙은 터널 자체의 전송을 붙잡아 터널을 종료하는 머신에서 당신을 잠글 수 있습니다. 공개는 제어 평면의 예외를 둔 라우팅 결정이며 DNAT 한 줄이 아닙니다.
공인 진입과 터널 진입, 하나를 고르세요
서비스를 공개한다는 것은 인터넷에 새로운 진입점을 만드는 일입니다. 방문자가 터널에 들어오지 않고 게이트웨이가 백엔드의 공개 얼굴이 되므로, 피어에 VPN 멤버십을 부여하는 것과 같지 않습니다. 그 차이가 규칙의 대상과 인증서를 결정합니다.
관리 인터페이스는 그 자리에 거의 어울리지 않습니다. 권한 있는 VPN 클라이언트가 접근하는 관리 페이지는 공격 표면을 터널 안에 두고 로그인 양식을 무차별 스캔에 노출하지 않습니다. 공개 애플리케이션 엔드포인트에는 여전히 자체 TLS 인증서와 인증, 속도 제한이 필요합니다. 암호화된 WireGuard 구간은 방문자에서 게이트웨이까지의 구간을 보호하지 않습니다.
서비스가 정말로 공개되어야 한다면 호스트 이름, 그것을 포함하는 인증서, 접근해야 하는 방문자 대역을 적어 두세요. 그 세 가지가 나중에 규칙의 형태와 필터 정책을 결정합니다. 그 밖의 것은 공인 리스너에서의 범위 확장입니다.
들어오는 포트 하나, 나가는 백엔드 하나
공인 포트 하나와 백엔드 서비스 하나를 사용합니다. 이 예에서 eth0는 공인 주소 198.51.100.20을 갖고, 게이트웨이의 터널 주소는 10.200.0.1이며, 피어는 10.200.0.7에서 애플리케이션을 실행합니다. 공인 TCP 9443은 피어의 TCP 8443으로 매핑됩니다.
iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1SNAT 규칙은 변환된 백엔드와 원래 공인 목적지에 일치합니다. 그래서 같은 백엔드 서비스로 가는 다른 연결은 이 매핑 밖에 남습니다. 또한 방문자의 주소를 피어에게서 숨기며, 이것이 출발지를 보존하는 라우팅 반환 경로를 별도 설계로 만드는 절충입니다. iptables 확장 참조는 두 타깃과 그 일치 옵션을 문서화합니다.
전달은 여전히 활성화되어야 하고, 필터 체인에는 변환된 목적지와 포트, 그리고 수립된 응답에 대한 허용이 필요합니다. FORWARD 체인은 DNAT 이후의 변환된 목적지를 보므로, 공인 주소를 기준으로 쓴 규칙은 전달되는 패킷과 일치하지 않습니다. 허용은 공인 주소가 아니라 백엔드 튜플을 기준으로 작성하세요.
피어는 게이트웨이의 터널 주소에서 오는 서비스 연결을 받아들이고 응답을 터널로 돌려보내야 합니다. AllowedIPs는 피어가 실제로 받는 출발지를 허용해야 하며, 출발지 변환 아래에서는 그것이 게이트웨이의 터널 주소입니다. 이 설계에 모든 피어의 넓은 0.0.0.0/0 항목은 필요하지 않습니다. 반환 트래픽을 떨어뜨리는 것은 그 주소를 목록에서 뺀 피어이거나, 대신 방문자 자신의 주소를 전달하는 출발지 보존 설계입니다. 그러니 규칙에 적은 출발지가 아니라 피어가 실제로 보는 출발지를 확인하세요.
게이트웨이 자체 리스너를 규칙 밖에 두세요
포트 일치를 모든 TCP 및 UDP 목적지를 포함하는 규칙으로 바꾸면 게이트웨이 자체의 WireGuard 소켓이 그 안에 들어갑니다. 목적지 변환은 머신이 패킷을 로컬로 판단하기 전에 일어납니다. 그래서 UDP 51820은 모든 피어 연결을 유지하는 프로세스가 아니라 피어에 도착할 수 있습니다. 규칙은 정상적으로 적재되고 터널은 죽습니다. 피어 쪽에서 읽어 내기 어려운 장애입니다.
SSH, 모니터링 에이전트, 게이트웨이에서 호스팅되는 다른 모든 서비스도 같은 노출을 갖습니다. 모든 것을 전달하는 규칙은 제어 평면과 공개된 애플리케이션을 구분하지 않으며, 잠김이 분명해지는 것은 변경 후 첫 재부팅 때입니다. 무엇이든 잡는 규칙은 조용히 넘겨받은 서비스에 대해 경고하지 않습니다. 다음 연결이 실패할 때 알게 됩니다.
넓은 전달이 정말로 필요하다면 무엇이든 잡는 규칙보다 먼저 제어 포트를 예약하거나, 공개용으로 별도의 공인 주소를 사용하세요. 두 번째 선택지가 제어 주소가 자체 정책을 유지하므로 더 깔끔하지만, 사업자가 그 주소를 제공해야 합니다. DNS 레코드를 추가한다고 주소가 할당되지는 않습니다.
넓은 TCP 및 UDP 전달이 모든 프로토콜은 아닙니다. ICMP, IPv6, path-MTU 피드백, 외부 VPN 전송에는 자체 정책이 필요하며, TCP와 UDP를 포함하는 규칙은 그런 경우를 기본 체인에 남깁니다.
규칙을 쓰기 전에 모델을 고르세요
네 가지 형태가 게이트웨이 공개의 대부분을 포함하며, 선택은 운영하는 서비스 수와 감당할 수 있는 제어 평면 위험에 달려 있습니다. 아래 표는 좁은 것에서 넓은 것 순으로 정렬합니다.
| Model | What it protects | Cost | Use when |
|---|---|---|---|
| Narrow port forward | Every other listener, including the VPN | One rule per service | Few services, stable ports |
| Catch-all with reserved ports | Ports named in the exception list | Rule order becomes critical | Many services and disciplined review |
| Separate public address | Control address fully isolated | Provider must supply the address | High-value publication |
| VPN-only access | No public entry at all | Visitors need the tunnel | Admin interfaces and internal tools |
나중에 서비스가 늘어날 것으로 예상해도 좁은 모델로 시작하세요. 감사하기 가장 쉽고, 좁은 규칙 집합을 검토된 무엇이든 잡는 규칙으로 바꾸는 것이 넓은 규칙이 어느 리스너를 잡았는지 알아내는 것보다 간단합니다. 어떤 모델을 고르든 규칙은 방화벽 소유자와 함께 두세요. 같은 체인을 관리하는 UFW나 nftables 설정 옆에 iptables 줄을 적용하면 부팅 순서에 따라 달라지는 정책이 생깁니다.
공개와 제어 경로를 모두 증명하세요
승인된 외부 클라이언트에서 승인된 호스트 이름과 그에 유효한 인증서로 시험하세요. 어느 백엔드가 응답했는지 확인한 뒤, 무관한 공인 포트가 여전히 거부되는지 점검합니다. 인증서 검사를 끈 것은 통과한 HTTPS 시험이 아니며, 잘못된 백엔드에 닿는 연결은 실패한 연결보다 나쁩니다.
그다음 게이트웨이 자체를 검증하세요. WireGuard 피어를 연결하고 SSH 세션을 열어 모니터링이 여전히 보고하는지 확인합니다. 공개한 서비스가 동작해도 제어 평면이 깨져 있을 수 있으므로 두 확인은 같은 변경 창에 속합니다. 한 번 재부팅해 규칙이 예상 순서로 다시 적용되는지 증명하고, 그다음 공개를 제거해 제거가 추가와 실제로 일치하는지 확인하세요. 시작 시 대량 추가와 불완전한 정리는 임시 시험이 영구적인 구멍이 되는 방식입니다.