WireGuard 외부 접속 안 될 때 UFW 방화벽 규칙 점검하기

학습 주제

라즈베리파이에 Samba와 WireGuard로 운영 중인 NAS 서버에서, 외부 접속이 갑자기 끊긴 문제를 진단하고 해결하는 과정을 다뤘습니다. 학습 날짜는 2026년 8월 5일입니다.

탐구 과정

문제 상황은 단순했습니다. 평소처럼 잘 쓰던 ~/shared 디렉토리에 외부에서 갑자기 연결이 안 되는 것. 처음엔 원인을 전혀 짐작할 수 없어서 하나씩 지워나가는 방식으로 접근했습니다.

가장 먼저 의심한 건 서비스 자체였습니다. smbd/nmbd가 죽었나? 확인해보니 정상 실행 중이었고, ~/shared도 로컬에서는 문제없이 접근됐습니다. 이 시점에 한 가지 착각하고 있었던 걸 알게 됐는데, ~/shared는 마운트된 디렉토리가 아니라 그냥 로컬 디렉토리였습니다. 이런 기본적인 부분부터 확인하고 넘어가야 헛다리를 덜 짚는다는 걸 다시 느꼈습니다.

다음은 WireGuard 쪽. 인터페이스는 떠 있었지만 피어 중 하나("pad")가 handshake 기록이 아예 없어서 의심스러웠습니다. 하지만 이건 나중에 확인해보니 그 기기가 애초에 접속 시도를 한 적이 없는 것뿐이었고, 오늘 문제와는 무관했습니다. 의심스러워 보인다고 다 원인은 아니라는 걸 배운 지점입니다.

방화벽 규칙(ufw+iptables)과 IP 포워딩도 살펴봤는데 여기까진 다 정상으로 보였습니다. 그 다음엔 네트워크 인터페이스 상태를 봤는데, eth0(유선랜)이 NO-CARRIER 상태로 죽어 있고 기본 라우트가 wlan0(무선)으로 넘어가 있는 게 눈에 띄었습니다. 순간 "유선에서 무선으로 전환되면서 IP가 바뀌었고, 공유기 포트포워딩이 예전 IP로 고정돼 있는 게 원인 아닐까" 하는 가설을 세웠습니다. 그럴듯한 시나리오였는데, 실제로 로컬 IP 이력을 확인해보니 최근에 바뀐 게 아니라 오랫동안 안정적으로 유지되고 있었습니다. eth0 다운 자체도 부팅 이후 계속 그래왔던 상태였고요. 그럴듯해 보이는 가설도 반드시 시간순으로 검증해야 한다는 걸 다시 확인한 순간이었습니다.

이 지점에서 결정적인 단서가 나왔습니다. UFW를 껐다 켰던 기억이 떠올라서, 로그를 실시간으로 들여다봤습니다. 그랬더니 바로 그 순간에도 노트북에서 UDP 51820(WireGuard 포트)으로 접속을 계속 시도하는데, UFW가 매번 그걸 막고 있는 게 눈에 보였습니다. 원인을 눈으로 직접 확인한 셈입니다.

핵심 학습 내용

문제의 핵심은 UFW 규칙 구성에 있었습니다. 기존 규칙은 22, 80, 443 포트와 LAN 대역(172.30.1.0/24), 그리고 WireGuard 터널 내부 서브넷(10.0.0.0/24)만 허용하고 있었습니다. 그런데 정작 WireGuard 자체가 쓰는 포트인 51820/udp를 외부("Anywhere")에서 접근 가능하도록 허용하는 규칙이 빠져 있었습니다.

여기서 헷갈렸던 부분이자 새로 이해한 개념이 하나 있습니다. 10.0.0.0/24를 허용해뒀다고 해서 WireGuard가 되는 게 아니라는 점입니다. 이 서브넷 허용 규칙은 터널이 이미 수립된 이후의 트래픽에만 적용됩니다. 반면 터널을 처음 맺기 위한 handshake 패킷은 외부 공인 IP에서 51820/udp 포트로 직접 들어오는 패킷이라서, 별도로 그 포트 자체를 열어주지 않으면 handshake 단계에서부터 막혀버립니다. 즉 "터널 안쪽 트래픽 허용"과 "터널을 여는 포트 허용"은 완전히 다른 문제였습니다.

해결은 간단했습니다.

ufw allow 51820/udp

이 명령 하나로 즉시 handshake가 성공했습니다.

latest handshake: 37 seconds ago

이해한 내용

이번 트러블슈팅에서 가장 크게 배운 건 두 가지입니다.

첫째, WireGuard 같은 VPN을 방화벽 뒤에서 운영할 때는 "터널 내부 서브넷 허용"과 "VPN 포트 자체 허용"을 구분해서 생각해야 한다는 점입니다. 전자는 이미 연결된 상태의 트래픽만 다루고, 후자가 있어야 애초에 연결이 시작될 수 있습니다.

둘째, 문제 진단 순서의 중요성입니다. 이번에도 여러 개의 그럴듯한 가설(IP 변경, 인터페이스 전환, 의심스러운 피어)을 세웠지만 실제 원인은 UFW 로그를 실시간으로 들여다보고 나서야 확실해졌습니다. 서비스 상태 → 네트워크 인터페이스 → 방화벽 로그 순으로 좁혀나가는 과정 자체가 유용한 진단 루틴이라는 걸 느꼈습니다.

원인 파악 후 돌이켜보니, 전날(8/4) UFW 규칙을 수정하면서 51820/udp 허용 규칙이 실수로 빠진 게 전부였습니다. smbd/nmbd, IP 포워딩, wg0 인터페이스는 처음부터 아무 문제가 없었다는 것도 확인이 끝난 뒤에야 명확해졌습니다.

실전 적용

방화벽 규칙을 수정할 때는 변경 전후로 필수 포트 목록을 체크리스트처럼 정리해두는 게 좋겠다는 생각이 들었습니다. 이번처럼 규칙을 손보다가 핵심 포트 하나가 누락되는 실수는 언제든 다시 생길 수 있으니까요.

또한 이번 사건 자체를 기록으로 남겨두는 작업도 같이 했습니다. NAS에 운영 중인 공유 폴더에 트러블슈팅 기록을 마크다운으로 저장해서, 나중에 비슷한 문제가 생겼을 때 바로 참고할 수 있게 했습니다. 이렇게 사건 단위로 원인과 해결 과정을 남겨두는 습관이 결국 다음번 진단 시간을 크게 줄여준다는 걸 다시 느꼈습니다.

추가 학습 계획

• UFW 로그를 실시간으로 모니터링하는 방법과 로그 분석을 좀 더 체계적으로 익히고 싶습니다.
• WireGuard 핸드셰이크 과정 자체(키 교환, 패킷 구조)를 더 깊이 파보고 싶습니다.
• 방화벽 규칙 변경 시 자동으로 필수 포트 유지 여부를 검증하는 스크립트를 만들어보는 것도 고려 중입니다.
• 의심스러웠지만 이번 문제와 무관했던 "pad" 피어의 handshake 부재는 별도로 확인이 필요해 보입니다.