홈서버가 쓸 만해질수록 밖에서도 쓰고 싶어진다. 그리고 여기가 홈서버 운영에서 보안 사고와 가장 가까운 갈림길이다. 외부 접속을 여는 방법은 크게 둘 — 포트포워딩으로 서비스를 인터넷에 공개하거나, VPN으로 나만의 통로를 만들거나. 둘의 차이는 편의성이 아니라 노출면(attack surface)의 차이다.
포트포워딩: 인터넷 전체에게 문을 보여주는 일
공유기에서 포트를 서버로 포워딩하면 그 순간부터 인터넷의 모든 사람이 그 포트에 도달할 수 있다. “내 주소를 아무도 모르는데”는 방어가 아니다. 인터넷 전체 주소 공간을 자동으로 훑는 스캐너들이 상시로 돌고 있고, 열린 포트는 수 시간 내에 발견된다고 보는 게 현실적이다. SSH를 기본 포트로 열어본 사람이라면 로그에 쌓이는 무차별 로그인 시도로 이를 직접 확인했을 것이다.
포트포워딩 자체가 악은 아니다. 문제는 그 포트 뒤의 서비스가 인증 우회 취약점을 가지는 순간, 방어선이 0이 된다는 구조다. 서비스의 보안 품질에 집 전체 네트워크를 거는 셈이다.
VPN: 문 자체를 숨기는 일
VPN 방식에서는 서비스 포트를 하나도 공개하지 않는다. 대신 암호화 터널의 입구 하나만 만들고, 등록된 키를 가진 기기만 그 터널로 들어와 내부망의 서비스를 쓴다. 외부에서 보면 서비스는 존재하지 않는 것과 같다. 서비스에 취약점이 있어도, 공격자는 터널을 통과하기 전까지 그 서비스에 닿을 수조차 없다 — 방어선이 한 겹에서 두 겹이 된다.
WireGuard — 직접 구축의 표준
WireGuard는 현대적 암호화로 설계된 경량 VPN 프로토콜로 리눅스 커널에 포함되어 있다. 설정은 공개키 교환 기반이라 OpenVPN 시절보다 훨씬 단순하지만, 서버 측 포트 개방(UDP 1개)과 키 관리, DDNS가 필요하다. “VPN 포트 하나는 열리는 것 아닌가?”라는 의문이 들 텐데, WireGuard는 올바른 키 없이 온 패킷에는 응답하지 않도록 설계되어 스캐너 입장에서는 포트가 닫힌 것처럼 보인다.
Tailscale — 설정을 대신해주는 메시 VPN
Tailscale은 WireGuard를 기반으로 키 교환·NAT 통과·기기 관리를 자동화한 서비스다. 각 기기에 앱을 설치하고 같은 계정으로 로그인하면 끝 — 공유기 포트 개방도, DDNS도 필요 없다. NAT 뒤에서도 동작하므로 통신사 공유기 이중 NAT 환경에서 특히 유용하다. 개인 사용 범위의 무료 플랜이 제공되며, 조정 서버(키 배포)는 Tailscale사가 운영하지만 데이터 트래픽 자체는 기기 간 종단간 암호화로 흐른다는 점을 이해하고 선택하면 된다.
그래서 기준은: 누가 쓰는 서비스인가
| 상황 | 권장 |
|---|---|
| 나(와 가족 기기)만 쓰는 서비스 전부 | VPN — 공개할 이유가 없다 |
| 입문자, 이중 NAT, 빠른 시작 | Tailscale |
| 외부 의존 없이 직접 통제하고 싶음 | WireGuard 직접 구축 |
| 불특정 다수에게 공개해야 하는 것 (블로그 등) | 그것만 리버스 프록시로 공개 |
원칙은 **“기본은 VPN, 공개는 예외”**다. 공개가 필요한 서비스만 리버스 프록시 + HTTPS 뒤에 두고, 나머지는 전부 터널 안에 숨긴다. 열린 것이 적을수록 지킬 것도 적다.
내 선택은 WireGuard 직접 구축이다. 도커로 wg-easy 컨테이너를 올려 서버를 VPN 허브로 쓰고 있는데, wg-easy는 WireGuard에 웹 관리 UI를 씌운 것이라 기기 추가가 QR 코드 스캔 한 번으로 끝난다 — “직접 구축”의 키 관리 부담을 거의 지워준다. 외부에서 필요한 접근(SSH, 내부 도구)은 전부 터널 안에서만 하고, 인터넷에 공개된 서비스는 0개다. 이 구성의 좋은 점은 고민이 사라진다는 것이다. 새 내부 도구를 올릴 때마다 “이걸 어떻게 안전하게 노출하지”가 아니라 “어차피 터널 안”이므로, 보안 검토가 서비스 추가의 병목이 되지 않는다.
참고로 “포트포워딩 + 강한 비밀번호면 충분하지 않나”라는 절충안에 대해: 비밀번호는 인증 단계의 방어일 뿐, 인증 이전의 취약점(서비스 자체의 버그)에는 아무 역할을 하지 못한다. 방어 계층을 고를 때는 “비밀번호가 뚫리면”이 아니라 “이 서비스에 인증 우회 버그가 발견되면”을 기준으로 생각해야 구조가 보인다.
무엇으로 시작하든, 이것만은
- SSH는 인터넷에 직접 열지 않는다. VPN 너머에 둔다. 열어야만 한다면 키 인증 전용이 전제다.
- 공유기의 UPnP 자동 포트 개방은 꺼두기를 권한다. 내가 모르는 포트가 열리는 통로다.
- 분기마다 한 번, 공유기의 포워딩 목록을 열어 “이게 다 아직 필요한가”를 점검한다. 노출면은 줄어드는 일이 없다 — 의식적으로 줄여야 한다.
외부 접속은 홈서버의 효용을 두 배로 만들지만, 구조를 잘못 잡으면 리스크는 그보다 크게 늘어난다. 다행히 좋은 구조(VPN 기본)가 더 어려운 것도 아니다. 처음부터 그 길로 가자.