여러 고객 온프레미스 K8s를 동일 IP로 운영할 때: Tailscale 4via6 적용기

 MSP(Managed Service Provider)나 SaaS 플랫폼을 운영할 때, 여러 고객의 온프레미스 또는 클라우드 인프라를 관리해야 하는 경우가 많습니다. 특히 각 고객이 독립적으로 구축한 Kubernetes 클러스터를 중앙에서 관리하려면 원격 접근이 필수적입니다. (물론 원격 접근이 불가능 한 고객들도 있습니다.)

 저희는 3대의 서버와 이를 연결하는 라우터를 1세트로 구성해 온프레미스 환경을 구축합니다. 이후 Kubernetes 클러스터에 원격으로 안정적으로 접근하기 위해 라우터에 Tailscale을 설치하고, 라우터가 연결된 내부 IP 대역을 광고(advertise)하는 Tailscale subnet router로 설정합니다. 이를 통해 운영자는 Tailscale을 통해 각 노드와 Kubernetes 리소스에 원격으로 접근할 수 있습니다.

 그러다보니 문제가 발생했습니다. 여러 고객들에게 온프레미스 환경을 제공하다보니, 각 고객 별로 다른 IP 대역대를 사용하면 기본적인 k8s 설정이 바뀌게 되고 접근 방식도 바뀌게 되니 이를 개별적으로 관리하는 것이 너무 번거로웠습니다. 그렇다고 동일한 사설 IP 대역(예: 192.168.0.0/24, 10.0.0.0/24)을 사용하게 되면 일반적인 VPN이나 Subnet Router만으로는 IP 충돌이 발생하여 여러 고객에게 동시에 접근할 수 없습니다.

 이러한 문제를 해결하기 위해, tailscale의 4via6 기술을 도입했습니다. 적용 결과 아쉬운 점도 있었지만, 생각보다 효율적으로 유저들을 관리할 수 있겠다 라는 생각이 들었습니다. 따라서 이번 기회에 제가 적용한 기술이 뭐고 어떻게 저희의 문제를 해결했는지 정리하려고 합니다.

 

---

 

환경

 저희는 다음과 같은 환경을 운영하고 있습니다.

• 각 고객: talos OS 위에 동작하는 Kubernetes 클러스터 (3개 노드)
• 노드 IP: 192.168.0.49, 192.168.0.59, 192.168.0.69
• 네트워크 대역: 모든 고객이 192.168.0.0/24 사용
• 게이트웨이: 각 고객 사이트마다 OpenWrt 라우터 설치

 위와 같은 형태로 고객들이 Onpremise 환경을 구축합니다. 고객이 1명일 때는 OpenWrt 라우터에 Tailscale을 설치하여, 고객사 내부망인 192.168.0.0/24 대역을 호스팅하는 서브넷 라우터(Subnet Router) 역할을 하도록 구성했습니다. 그렇게해서, 저희의 로컬 PC에서 Tailscale을 통해 고객사 내부 k8s 서버로 원격 접속할 수 있었습니다.

 하지만 고객사가 늘어나면서 문제가 발생했습니다. 다수의 고객사에 동일하게 서버 IP 구성을 하려고 하니, 단일 Tailnet에서 서브넷 라우트를 그대로 광고하면 대역 충돌로 인해 라우팅이 모호해지거나 특정 고객사로 트래픽이 잘못 전달되는 상황이 생길 수 있는 문제가 생겼습니다. 따라서 이를 해결하기 위해 tailscale 4via6을 도입하게 되었습니다.

 

---

Tailscale이란?

 일단 tailscale의 4via6을 설명하기에 앞서, tailscale에 대해서 설명드리려고 합니다.

• Tailscale은 WireGuard 기반의 제로 트러스트 네트워크(Zero Trust Network) 솔루션입니다.
• 여러 디바이스들을 안전하게 연결해주는 VPN 서비스 (모든 디바이스가 하나의 거대한 사설 네트워크에 있는 것처럼 동작하게 함)
• Tailscale은 복잡한 네트워크 설정 없이 클릭 몇 번으로 디바이스 간 프라이빗 네트워크를 구성할 수 있습니다.
  • 각 디바이스에 고유한 IP 주소(100.x.y.z 형태)를 할당하고, P2P(peer-to-peer) 방식으로 직접 연결을 시도하기 때문에 속도가 빠릅니다.
• 보안 측면에서도 모든 트래픽이 암호화되어 전송되고 ACL로 유저 권한을 관리해 각 디바이스에 세밀한 접근 제어가 가능합니다.

 

Tailscale 4via6란?

 Tailscale의 4via6는 서로 겹치는 IPv4 사설망 대역(예: 여러 장소가 모두 10.0.0.0/24 또는 192.168.0.0/24를 쓰는 경우)을 주소 변경 없이 동시에 붙일 수 있게 해주는 서브넷 라우팅 기능입니다. 일반적인 서브넷 라우팅에서는 tailnet 안에서 10.0.0.5로 접속하면, 어느 장소의 10.0.0.5인지 구분이 안 돼서 잘못된 곳(현재 primary 라우터 뒤)으로 갈 수 있습니다. 4via6는 이 충돌을 해결합니다.

 

할당된 주소

• 주소 생성 시 사용하는 명령어
  • tailscale debug via <site-id> <ipv4-cidr>
  • 이걸로 생성된 IPv6 라우트를 --advertise-routes=로 광고하는 흐름입니다.
• 4via6는 fd7a:115c:a1e0:b1a:0:XXXX:YYYY:YYYY 형태의 Tailscale 전용 IPv6 프리픽스를 씀
• 각 부분의 의미
  • fd7a:115c:a1e0:b1a: Tailscale 4via6의 고정 prefix
  • 0:XXXX: Site ID (0-65535까지 사용 가능)
  • YYYY:YYYY: IPv4 주소를 16비트 hex로 표현

 

동작 원리

• Tailscale 4via6(Four via Six)는 중복되는 IPv4 서브넷을 고유한 IPv6 주소 공간으로 매핑하여 구분
• 각 서브넷에 고유한 Site ID를 부여하면, Tailscale이 내부적으로 IPv6 주소를 사용하여 올바른 목적지로 트래픽을 라우팅합니다.
• 중요한 점은 실제 고객 환경에서는 IPv4를 그대로 사용하며, IPv6 설정이 전혀 필요하지 않다는 것입니다. IPv6 주소 매핑은 Tailscale 라우팅 레벨에서만 사용되는 내부 메커니즘입니다.

서브넷 라우터가 패킷을 IPv6 ↔ IPv4로 재작성(translation/rewrite) 해서 실제 내부 IPv4 장비로 전달합니다. 즉, “IPv4를 IPv6로 태그 붙여서(사이트 ID로) 구분한 뒤 전달”이라고 보시면 됩니다.

 

동작 방식

1. 각 고객 사이트의 Subnet Router에 고유 Site ID 할당 (예: 고객A=1, 고객B=2)
2. Subnet Router가 IPv6 형식의 route를 Tailscale에 광고
3. 관리자가 192.168.0.49에 접근하면 Tailscale이 Site ID로 올바른 고객 구분
4. 트래픽이 해당 Subnet Router를 통해 목적지로 전달

 

---

구현 방법

 

1.  각 고객별 site ID 계획

• 먼저 각 고객에게 고유한 Site ID를 할당합니다. Site ID는 0부터 65535까지 사용할 수 있습니다.
• Site ID란?
  • 4via6에서 site ID는 이 트래픽이 어느 고객/현장(사이트)로 가야 하는지”를 구분하기 위해 4via6 IPv6 주소에 넣는 식별 값
  • 겹치는 IPv4 대역(예: 여러 고객 모두 192.168.0.0/24)을 동시에 쓰려면, 사이트마다 서로 다른 site ID를 부여해서 충돌을 피함

# Site ID 계획 예시
고객 A: Site ID = 1
고객 B: Site ID = 2
고객 C: Site ID = 3
고객 D: Site ID = 4
...


고객이 많은 경우 조직 단위나 지역별로 범위 할당 가능
예: 서울 고객 = 1000-1999, 부산 고객 = 2000-2999

 

2.  OpenWrt 라우터에 Tailscale 설치

# OpenWrt 라우터에 SSH 접속 후

opkg update

opkg install iptables iptables-nft
opkg install tailscale

# Tailscale 시작 및 인증

 

3.  1번에서 정한 Site ID 기반으로 4via6 IPv6 주소 생성 및 tailscale Subnet Router 광고

# 고객 A (Site ID = 1, IPv4 = 192.168.0.0/24)

tailscale debug via 1 192.168.0.0/24

# 출력:
fd7a:115c:a1e0:b1a:0:1:c0a8:0/120

tailscale up \
  --advertise-routes=fd7a:115c:a1e0:b1a:0:1:c0a8:0/120 \
  --snat-subnet-routes=false \
  --accept-dns=false \
  --accept-routes=false

 

4.  Tailscale Admin Console에서 승인

• Tailscale Admin Console (https://login.tailscale.com/admin/machines) 접속
• 3번에 tailscale up 결과 생긴 기기 클릭
• 광고된 4via6 router 승인

 

5.  MagicDNS를 통한 서버 IPv6 확인

dig AAAA [서버 MagicDNS]

• MagicDNS는 Tailscale에서 제공하는 사설 DNS 기능입니다.
• Tailnet(=Tailscale 네트워크) 안의 각 장비에 대해 사람이 읽을 수 있는 이름(호스트네임)을 자동으로 만들어 주고, 그 이름으로 접속하면 해당 장비의 Tailscale IP로 자동 해석(resolution) 해줍니다.
• 형식: {IP를 대시로 연결}-via-{Site ID}
  
  • ex) 192-168-0-99-via-1

 

6.  /etc/hosts 파일 수정 및 kubeconfig 반영

/etc/host
[확인된 IPv6 주소] [적용할 DNS명]


/kube/config 파일 수정

server: https://[DNS 명]:6443
# /etc/hosts 에서 등록한 dns 명으로 server명 수정

• 추가로 저는 talos OS을 사용하기 때문에 talos machineconfig 파일에 적용할 DNS 명을 certSAN에 추가

 

이렇게하면, 192.168.0.0/24 대역대를 subnet router로 동작하는 tailscale 내부 기기들을 Site ID기반 IPv6로 접근하기 때문에 여러 기기들을 관리할 수 있습니다. 아래는 4via6을 적용해 여러 고객들을 관리하는 구조도 입니다.

 

※  구조도

 

---

정리

 이렇게해서 여러 고객들을 동일한 IP 대역대로 관리할 수 있었습니다. tailscale 4via6 초기에는 IPv6 주소 매핑 개념이 복잡해 보일 수 있지만, 실제로는 고객 환경에서 IPv4를 그대로 사용하며 Tailscale이 백그라운드에서 모든 라우팅을 처리합니다. 관리자는 MagicDNS 이름이나 간단한 IPv6 주소만 사용하면 되므로 실제 운영은 매우 직관적입니다.

 물론 저희의 OpenWrt 라우터를 사용하기 때문에 다른 대역대로 node들을 관리하면, 이렇게 할 필요가 없긴 합니다. 다른 대역대의 IP를 사용한다면 다른 subnet router를 호스팅하면 되기 때문에 대역대 충돌이 생기지 않기 때문입니다. 하지만 이렇게되면 다음과 같은 문제가 있습니다.

• 고객 별로 어떤 IP 대역대를 사용하는지 알아야한다.
• k8s node IP & talosOS node IP를 고객 별로 관리해야 하기 때문에 복잡하다.

 그래서 알아보던 중 tailscale의 4via6을 알게 되었습니다. 이 기술 자체가 지금 저같은 문제를 해결하기 위한 기술이였어서 이를 적용해서 더 간편하게 고객들을 관리할 수 있었습니다.

 물론, 고객들의 Site ID 및 IPv6는 별도로 관리해야하는 단점이 있지만 이 또한 DNS 서버를 따로 둔다면 해결될 문제라고 생각했습니다. 다음번에는 DNS 서버까지 적용해 다른 로컬 PC에서도 별도의 파일 수정 없이 접근할 수 있는 환경까지 추가로 설명드리도록 하겠습니다.