가정용 유동 IP가 바뀔 때마다 서버 방화벽 화이트리스트를 손으로 고치던 문제를 Tailscale로 해결한 실제 후기. 설치 과정에서 겪은 시행착오 세 가지와 SSH를 완전히 전환한 순서를 정리했습니다.
가정용 유동 IP가 바뀔 때마다 서버 방화벽의 SSH 화이트리스트를 손으로 고쳐야 했던 문제를, WireGuard 기반 메시 VPN 서비스 Tailscale로 완전히 없앴습니다. 관리용 PC와 서버 양쪽에 Tailscale을 설치해 사설망으로 직접 연결하고, 기존 공인 IP 기반 SSH 방화벽 규칙은 아예 제거했습니다. 이제 집 IP가 바뀌어도 SSH 접속만큼은 더 이상 손댈 일이 없습니다.
최종 업데이트: 2026-09-15 · 환경: Windows 11 관리용 PC, 리눅스 서버 2대(클라우드 서버 1대·단독 서버 1대), Tailscale 1.102.4
- 왜 IP 화이트리스트 대신 Tailscale을 찾아보게 됐을까?
- Tailscale은 뭐고, 돈은 얼마나 들까?
- 설치는 실제로 어떻게 진행했을까?
- 설치하고 나면 매번 실행해야 할까? 로그인은 얼마나 자주 해야 할까?
- 설치하면서 겪은 시행착오 세 가지
- 1) 설치 명령 네 줄을 한 번에 붙여넣었더니 첫 줄만 실행된 것처럼 보였다
- 2) 서버가 자기 자신에게 접속했더니 Broken pipe
- 3) 방화벽을 닫기 전에 내 접속 경로부터 먼저 옮겨야 했다
- SSH 화이트리스트, 실제로 어떻게 없앴을까?
- 놓치기 쉬운 점 여섯 가지
- 자주 묻는 질문
- 정리
- 주요 내용 요약
왜 IP 화이트리스트 대신 Tailscale을 찾아보게 됐을까?
서버를 두 대 운영하다 보니(클라우드 서버 1대, 단독 서버 1대) SSH 접속과 관리자 페이지를 아무나 못 열게 집 IP만 방화벽에 등록해 두고 썼습니다. 문제는 가정용 인터넷 대부분이 그렇듯 유동 IP라 몇 달에 한 번씩 바뀐다는 점입니다.
IP가 바뀌는 순간 SSH부터 막힙니다. 그러면 서버마다 방화벽 설정에 들어가 옛 IP를 새 IP로 바꿔야 다시 접속이 됩니다. 이 클라우드 서버를 만든 과정 자체는 지난 글 OCI 무료 A1 인스턴스 만들기에서 다룬 적이 있는데, 그렇게 애써 만든 서버를 정작 IP가 바뀔 때마다 손으로 열어줘야 한다는 게 계속 걸렸습니다. 이번에도 갱신 작업을 하다가 "이걸 아예 안 하는 방법은 없을까" 찾아보게 됐습니다.
Tailscale은 뭐고, 돈은 얼마나 들까?
Tailscale은 WireGuard 기반의 메시(mesh) VPN입니다. 기존 VPN처럼 중앙 서버를 거쳐 트래픽이 오가는 구조가 아니라, 기기끼리 직접 암호화 터널을 뚫어 연결합니다.
| 항목 | 내용 |
|---|---|
| 연결 방식 | 메시 VPN — 기기끼리 직접 연결(WireGuard 종단간 암호화) |
| 로그인 | 자체 계정 없이 Google/Microsoft 등 기존 계정으로 로그인 |
| 개인 플랜 가격 | 무료(Free forever) |
| 사용자 수 | 최대 6명 |
| 기기 수 | 사용자당 무제한 |
가격과 인원 제한은 Tailscale 공식 요금 페이지에서 2026년 9월 기준으로 확인한 값입니다. 혼자 서버 두어 대 관리하는 정도면 무료 플랜으로 충분합니다.
구조가 궁금해서 공식 설명 페이지도 읽어봤는데, 핵심은 이렇습니다. 작은 "코디네이션 서버"가 각 기기의 공개키만 모아뒀다가 나눠주고, 실제 트래픽은 기기끼리 직접 주고받습니다. 직접 연결이 안 되는 까다로운 네트워크에서는 DERP라는 중계 서버가 대신 전달해주는데, 개인키가 기기 밖으로 나가지 않는 구조라 이 중계 서버조차 트래픽 내용을 복호화할 방법이 없습니다.
설치는 실제로 어떻게 진행했을까?
순서는 간단합니다. 먼저 관리용 PC(Windows)에 설치하고 Google 계정으로 로그인하면 자동으로 등록됩니다. 그다음 서버 쪽 차례입니다.
우분투 서버는 공식 설치 스크립트 한 줄이면 끝났습니다.
curl -fsSL https://tailscale.com/install.sh | sudo sh
sudo systemctl enable --now tailscaled
sudo tailscale up --hostname=my-server --sshRocky Linux 계열 서버는 저장소를 먼저 등록해야 했습니다.
sudo dnf config-manager --add-repo https://pkgs.tailscale.com/stable/rhel/8/tailscale.repo
sudo dnf install -y tailscale
sudo systemctl enable --now tailscaled
sudo tailscale up --hostname=my-server --ssh
설치하고 나면 매번 실행해야 할까? 로그인은 얼마나 자주 해야 할까?
설치 후 실제로 써보면서 가장 먼저 든 궁금증이었습니다. 결론부터 말하면 둘 다 신경 쓸 필요가 없습니다.
Tailscale은 설치하는 순간부터 백그라운드 서비스로 동작합니다. Windows가 켜지면 자동으로 함께 시작되고, 트레이 아이콘에 상주하며 연결 상태를 계속 유지합니다. SSH로 접속할 때 따로 실행할 필요 없이, 트레이 아이콘이 연결 상태이기만 하면 Tailscale IP가 그냥 하나의 네트워크 경로처럼 항상 열려 있습니다.
로그인도 매번 하지 않습니다. 다만 공식 문서에 따르면 기본적으로 키가 180일(약 6개월)마다 만료되도록 설정돼 있습니다. 만료되면 그 기기와의 연결이 멈추고, 다시 로그인해야 복구됩니다. 사람이 쓰는 노트북·휴대폰이라면 트레이 아이콘을 눌러 재로그인하면 끝이라 크게 문제되지 않습니다.
그래서 서버 두 대는 키 만료 자체를 꺼뒀습니다. 관리자 콘솔(Machines 목록)에서 해당 서버의 "⋯" 메뉴 → Disable key expiry를 선택하면 됩니다. 클릭 몇 번이면 끝나는 작업입니다.
1. https://login.tailscale.com/admin/machines 접속
2. 서버 이름 옆 "⋯" 메뉴 클릭
3. "Disable key expiry" 선택
4. 목록에 "Expiry disabled" 표시로 바뀌는지 확인
반대로 노트북·휴대폰처럼 사람이 쓰는 기기는 기본값(180일 만료) 그대로 두는 걸 권합니다. 기기를 분실했을 때 만료 기능이 있어야 시간이 지나면 자동으로 접근이 끊기기 때문입니다.
설치하면서 겪은 시행착오 세 가지
매뉴얼대로 하면 끝날 줄 알았는데, 실제로는 세 군데서 걸렸습니다. 검색해서 들어오신 분은 아마 이 부분이 제일 궁금하실 것 같습니다.
1) 설치 명령 네 줄을 한 번에 붙여넣었더니 첫 줄만 실행된 것처럼 보였다
증상. 저장소 등록·설치·서비스 활성화·로그인, 이 네 줄을 원격 터미널에 한 번에 붙여넣었는데 화면에는 "저장소 등록됨" 한 줄만 뜨고 나머지는 아무 흔적이 없었습니다.
진단. 아래 명령으로 실제 설치 여부부터 확인했습니다.
rpm -q tailscale
systemctl is-active tailscaled
sudo tailscale status결과는 "package tailscale is not installed", "inactive", "command not found" — 설치 자체가 안 된 상태였습니다.
원인(추정). 정확히 확인하지는 못했지만, 패키지 설치 과정에서 뜨는 GPG 서명 키 확인 절차에 걸려, 뒤이어 붙여넣은 나머지 명령 줄이 그 확인 질문에 대한 답으로 잘못 들어간 것으로 보입니다. 원격 터미널에 여러 줄을 한 번에 밀어 넣을 때 흔히 벌어지는 일입니다.
해결. 설치 명령만 단독으로 다시 실행하니 문제없이 끝났고, 이후로는 한 번에 한 줄씩만 실행하는 것으로 방침을 바꿨습니다.
2) 서버가 자기 자신에게 접속했더니 Broken pipe
증상. 설치가 끝난 뒤 "잘 되는지 보자"며 서버 터미널에서 그 서버 자신의 Tailscale IP로 SSH 접속을 시도했더니, 호스트 키까지는 잘 넘어가고 Broken pipe로 끊겼습니다.
원인. 자기 자신에게 접속하는 셀프 루프 특유의 라우팅 문제였습니다. 실제 사용 시나리오(다른 기기에서 서버로 접속)가 아니라 검증 자체가 애매한 방법이었던 겁니다.
해결. 관리용 PC의 새 터미널에서 같은 주소로 접속해보니 곧바로 성공했습니다. 테스트는 항상 실제로 쓸 기기에서 해야 한다는, 당연하지만 놓치기 쉬운 부분이었습니다.
3) 방화벽을 닫기 전에 내 접속 경로부터 먼저 옮겨야 했다
상황. SSH를 Tailscale 전용으로 완전히 넘기려면 기존 공인 IP 기반 방화벽 규칙을 지워야 합니다. 그런데 평소 쓰던 SSH 설정(단축 접속 별칭)이 여전히 공인 IP를 바라보고 있었습니다.
만약 그대로 방화벽부터 지웠다면? 다음 접속 시도부터 곧바로 막혀, 서버에 다시 들어갈 방법이 없어질 뻔했습니다.
해결한 순서. ① 접속 설정의 주소를 Tailscale IP로 먼저 바꾼다 → ② 그 경로로 접속이 되는지 확인한다 → ③ 확인되면 그때 기존 공인 IP 방화벽 규칙을 지운다. 새 문이 열린 걸 확인하고 나서 옛 문을 닫는다가 이번 작업 전체에서 가장 크게 배운 원칙입니다.
SSH 화이트리스트, 실제로 어떻게 없앴을까?
서버마다 방화벽 도구는 다르지만(클라우드 서버는 패널 명령, 단독 서버는 firewalld), 하는 일은 똑같습니다. SSH(22번 포트)를 향한, 집 IP를 조건으로 하는 허용 규칙을 찾아서 지우는 것입니다.
| 순서 | 확인할 것 |
|---|---|
| 1 | 현재 방화벽 규칙 목록에서 SSH(22번) + 집 IP 조합의 규칙 번호를 찾는다 |
| 2 | Tailscale IP로 접속 설정을 먼저 바꾸고 접속을 확인한다(위 3번 시행착오) |
| 3 | 확인되면 그 규칙만 지운다 — 사무실 IP·다른 용도의 규칙은 그대로 둔다 |
| 4 | 기존 공인 IP로 직접 접속을 시도해 실제로 막혔는지(타임아웃) 확인한다 |
놓치기 쉬운 점 여섯 가지
- 방화벽 규칙을 지우기 전에 새 접속 경로(Tailscale)가 실제로 되는지부터 확인한다 — 순서가 바뀌면 자기 자신을 잠글 수 있다
- 여러 설치 명령을 한 번에 붙여넣지 말고 하나씩 실행한다
- 연결 테스트는 서버 자신이 아니라 실제로 쓸 다른 기기에서 한다
- SSH만 옮기고 웹 관리자 페이지·FTP는 상황을 보며 나중에 옮긴다 — 한 번에 다 바꾸면 무엇이 문제인지 구분이 안 된다
- 사무실 등 다른 장소에서도 접속해야 한다면, 그 장소의 기기에도 Tailscale을 설치해야 계속 접속된다(설치 전에 그 장소 IP 규칙을 지우면 안 된다)
- 서버 기기는 키 만료를 꺼둔다. 기본값(180일) 그대로 두면 아무도 없는 서버에서 로그인 창만 뜬 채 접속이 끊길 수 있다 — 사람이 쓰는 기기는 반대로 기본값을 유지한다
자주 묻는 질문
정리
가정용 유동 IP가 바뀔 때마다 서버 방화벽을 손으로 고치던 번거로움을, Tailscale을 설치하는 것으로 없앴습니다. 핵심은 세 가지입니다. 첫째, 설치 명령은 한 줄씩 실행한다. 둘째, 연결 테스트는 실제로 쓸 다른 기기에서 한다. 셋째, 새 접속 경로를 확인한 뒤에 옛 경로를 닫는다.
SSH처럼 root 권한 전체가 걸린 곳부터 옮기고, 로그인 폼이 있는 관리자 페이지 같은 곳은 서두르지 않는 게 낫다는 것도 이번에 얻은 판단입니다. 공유 호스팅처럼 root 권한이 없는 환경에는 애초에 설치할 수 없으니, 그런 곳은 기존 화이트리스트 방식을 그대로 유지하면 됩니다.
주요 내용 요약
- 문제: 가정용 유동 IP가 바뀔 때마다 서버 SSH 화이트리스트를 손으로 갱신해야 했음
- 해결: Tailscale(WireGuard 기반 메시 VPN, 개인 플랜 무료)을 서버·관리용 PC에 설치
- 핵심 원칙: 새 접속 경로 확인 → 그다음 옛 방화벽 규칙 삭제 (역순으로 하면 자기 자신을 잠글 수 있음)
- 한계: root 권한이 없는 공유 호스팅에는 설치 불가 — 그런 서버는 기존 화이트리스트 방식 유지
참고 자료
1. Tailscale 요금 안내
Tailscale Inc., 2026년 9월 확인
https://tailscale.com/pricing
2. Tailscale은 어떻게 작동하나(How Tailscale works)
Tailscale Inc.
https://tailscale.com/how-it-works
3. 키 만료(Key expiry) 안내
Tailscale Inc., 2026년 9월 확인
https://tailscale.com/kb/1028/key-expiry