포트 포워딩 없이 Tailscale으로 NAS 연결하기

Tailscale은 포트 포워딩이 필요한가요?

Tailscale은 포트 포워딩이 필요하지 않으며, 본인의 장치에 접근할 때는 포트 포워딩을 완전히 대체합니다. tailnet(Tailscale이 장치 간에 구축하는 사설 네트워크)에 속한 모든 장치는 자체적으로 아웃바운드 연결을 생성합니다. 가정용 라우터에서 변경해야 할 사항은 전혀 없습니다. 포트 포워딩, DMZ(비무장지대) 호스트 설정, 동적 DNS 레코드, 공인 IP 주소 등이 필요하지 않습니다. ipTIME이나 Fritz!Box 라우터 뒤에 있는 NAS(네트워크 결합 스토리지), Raspberry Pi, 게임 서버는 라우터의 인바운드 포트를 열지 않고도 어디서든 노트북을 통해 고유한 사설 주소로 접근할 수 있습니다.

Tailscale이 수행하지 않는 작업은 간단합니다. Tailscale은 본인의 tailnet에 로그인되어 있거나 공유된 장치들만 연결합니다. 인터넷상의 낯선 사람이나 tailnet에 가입하지 않은 친구는 Tailscale을 통해 어떠한 장치에도 접근할 수 없습니다. 서비스를 공용 인터넷 전체에 노출하는 것은 별개의 작업이며, 이 문서의 마지막 부분에서 다룹니다.

Tailscale이 포트 포워딩 없이 NAT를 통과하는 원리

포트 포워딩은 NAT(network address translation) 때문에 존재합니다. 대부분의 가정용 네트워크에서 라우터는 공인 IPv4 주소를 하나만 소유하며, 그 뒤에 있는 모든 장치는 사설 주소를 사용합니다. 라우터에 외부에서 패킷이 들어오면 어떤 사설 장치로 보내야 할지 알 수 없으므로 라우터는 해당 패킷을 폐기합니다. 포트 포워딩은 "25565번 포트는 192.168.0.20으로 보낸다"와 같이 수동으로 규칙을 설정하는 것입니다. Tailscale은 다음 네 단계를 통해 규칙 설정 없이 동일한 결과를 얻습니다.

첫째, 모든 노드가 외부로 연결을 시도합니다. 시작 시 tailscaled은 조정 서버(coordination server)에 연결합니다. 자체 암호화 전송 계층으로 감싼 TCP 80번 포트의 일반 HTTP를 우선 사용하며, 80번 포트 응답이 없으면 TCP 443번 포트의 HTTPS로 전환합니다. 이때 자신의 WireGuard 공개 키를 전송하고, tailnet 내 다른 모든 노드의 공개 키와 주소 정보를 받아옵니다. 조정 서버는 사용자의 트래픽을 직접 전달하지 않으며, 오직 키와 주소록 정보만 관리합니다.

둘째, 각 노드는 외부에서 자신이 어떻게 보이는지 확인합니다. Tailscale의 릴레이 서버에 있는 UDP 3478번 포트로 STUN(session traversal utilities for NAT) 요청을 보냅니다. 응답에는 라우터가 해당 아웃바운드 패킷에 할당한 공인 IP와 포트 정보가 포함됩니다. 이는 포트 포워딩으로 수동 생성했을 매핑과 같지만, 라우터가 아웃바운드 흐름을 위해 스스로 생성했다는 점이 다릅니다. 라우터가 UPnP나 NAT-PMP를 지원하면 Tailscale은 자동으로 매핑을 요청하여 도움을 받기도 하지만, 필수적인 과정은 아닙니다.

셋째, 양측이 홀 펀칭(punching)을 수행합니다. 노드 A와 노드 B는 조정 서버를 통해 서로의 공인 엔드포인트를 파악합니다. 양측은 동시에 자신의 리스너 포트(기본값 41641)에서 상대방의 공인 엔드포인트로 UDP 패킷을 보냅니다. 각 라우터는 이미 자신의 노드에 대한 아웃바운드 매핑을 유지하고 있으므로, 상대방으로부터 들어오는 패킷이 해당 매핑과 일치하여 통과하게 됩니다. 이 순간부터 두 노드는 WireGuard를 통해 직접 통신하며, 라우터에는 여전히 별도의 규칙이 필요 없습니다.

넷째, 홀 펀칭에 실패하면 트래픽은 릴레이 상태로 유지됩니다. 모든 연결은 실제로 DERP(designated encrypted relay for packets) 서버를 통해 릴레이되는 것으로 시작합니다. DERP 서버는 암호화된 WireGuard 패킷을 TCP 443번 포트의 HTTPS로 전달하며, Tailscale은 이후 세 번째 단계의 직접적인 UDP 경로로 업그레이드를 시도합니다. CGNAT(ISP가 제어하는 두 번째 NAT 뒤에 사용자가 위치하는 경우)와 대칭형 NAT(라우터가 목적지마다 새로운 포트를 선택하여 STUN 응답이 무용지물이 되는 경우), 그리고 UDP를 차단하는 기업용 방화벽은 이러한 업그레이드를 방해합니다. 업그레이드에 실패하면 Tailscale은 먼저 사용자가 직접 설정한 tailnet 내의 피어 릴레이(UDP 트래픽을 중계하도록 설정된 장치)를 시도하며, 사용 가능한 장치가 없으면 연결은 DERP에 머무릅니다. 릴레이 서버는 암호문만 볼 수 있습니다. 릴레이 연결은 지연 시간과 처리량에 영향을 미치며, Tailscale 릴레이 연결이 느린 이유와 직접 연결로 전환하는 방법에서 현재 경로를 확인하고 무엇을 변경해야 하는지 다룹니다.

이 네 단계 중 어느 것도 라우터로 들어오는 인바운드 연결을 생성하지 않습니다. 이것이 바로 포트 포워딩이 필요 없는 이유입니다.

클라이언트 설치 및 경로 확인

설치는 각 장치에서 스크립트 하나를 실행하고 로그인하는 것으로 완료됩니다.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale ip -4

tailscale up은 로그인 URL을 출력합니다. 해당 URL을 열고 로그인하면 장치가 tailnet에 추가됩니다. tailscale ip -4는 100.64.0.0/10 범위 내의 장치 tailnet 주소를 출력합니다. 이 주소는 재부팅이나 네트워크 변경 시에도 유지되므로, SSH 설정이나 게임 클라이언트에 기입하면 됩니다.

tailnet 내의 다른 장치에서 첫 번째 장치로의 경로를 확인합니다.

tailscale ping nas

호스트 이름이나 tailnet 주소를 사용하십시오. 첫 번째 응답은 종종 via DERP로 표시되는데, 이는 직접 경로가 협상되는 동안 모든 연결이 릴레이 방식으로 시작되기 때문입니다. 몇 초 이내에 응답이 공인 IP와 포트로 전환되어야 하며, 이는 홀 펀칭(hole punch)이 성공했음을 의미합니다. 1분이 지나도 응답이 계속 via DERP로 표시된다면 펀칭이 완료되지 않은 것입니다. 이는 보통 한쪽이 펀칭을 통과할 수 없는 NAT 뒤에 있거나 UDP를 차단하는 네트워크에 있어 릴레이 연결이 사용되고 있음을 의미합니다.

추가할 가치가 있는 유일한 방화벽 규칙

Tailscale은 대부분의 네트워크에서 별도의 방화벽 변경 없이 작동합니다. 이는 아웃바운드 UDP가 일반적으로 허용되기 때문입니다. 선택 사항인 규칙 하나를 추가하면 직접 연결 경로를 확보할 확률이 높아집니다. 41641 포트에서 나가는 UDP 트래픽을 허용하십시오.

아웃바운드 UDP를 제한하는 가정용 라우터나 회사 방화벽을 사용하는 경우, 장치가 소스 포트 41641에서 임의의 주소 및 임의의 대상 포트로 UDP 패킷을 보낼 수 있도록 허용해야 합니다. 또한 STUN을 위해 대상 포트 3478로 나가는 UDP 트래픽도 허용해야 합니다. 대상 포트 41641만 허용하는 것으로는 충분하지 않습니다. 상대방의 NAT나 설정에 따라 연결의 반대편 끝이 임의의 포트가 될 수 있기 때문입니다. 대부분의 가정용 라우터는 이미 모든 아웃바운드 UDP를 허용하므로 별도의 조치가 필요하지 않습니다.

VPS에서는 인바운드 방향의 규칙이 유용합니다. VPS는 일반적으로 자체 네트워크 인터페이스에 공인 IP를 가지고 있거나, AWS 인터넷 게이트웨이와 같은 고정된 일대일 NAT를 사용합니다. 따라서 UDP 41641에 대한 인바운드 규칙을 설정하면 모든 피어가 안정적으로 접근할 수 있는 대상을 확보하게 됩니다. 까다로운 NAT 뒤에 있는 피어라도 자신의 네트워크에서 UDP 아웃바운드가 허용된다면 직접 연결이 가능해지는 경우가 많습니다. UDP를 차단하는 네트워크에 있는 피어는 VPS의 설정과 관계없이 릴레이를 통해 연결됩니다. ufw를 사용하는 경우 다음과 같이 설정합니다.

sudo ufw allow 41641/udp
sudo ufw status

ufw status 명령을 실행하면 41641/udp 항목이 Anywhere에서 오는 ALLOW로 표시되어야 합니다. 클라우드 제공업체의 제어판에서 별도의 네트워크 방화벽을 운영하는 경우, 해당 위치에도 동일한 규칙을 추가해야 합니다. 제공업체 경계에서 차단된 패킷은 ufw에 도달하지 못하기 때문입니다. 이 규칙은 편의를 위한 것이며 필수 사항은 아닙니다. 포트가 닫혀 있어도 VPS는 tailnet에 정상적으로 참여하며, 피어들은 직접 연결 대신 릴레이를 거쳐 해당 VPS에 도달할 수 있습니다.

외부에서 홈 NAS나 Raspberry Pi에 접속하기

첫 번째 사례는 가장 간단하며, 대부분의 사용자가 "Tailscale을 이용한 포트 포워딩"이라고 부르는 방식입니다. 집에 있지 않은 노트북이나 휴대폰에서 집에 있는 장비로 접속하는 경우입니다.

홈 장비와 노트북에 클라이언트를 설치합니다. 이것으로 설정은 모두 끝납니다. 이제 NAS나 Pi는 모든 인터페이스에서 수신 대기 중인 모든 서비스에 대해 자신의 tailnet 주소로 응답하며, 별도의 포트 포워딩은 필요하지 않습니다. 127.0.0.1 또는 LAN 주소에만 바인딩된 서비스는 수신 대기 설정을 변경하기 전까지는 tailnet에서 보이지 않습니다.

ssh pi@100.101.102.103
curl -I http://100.101.102.103:8080/

홈 장비에서 tailscale ip -4을 실행하여 나온 출력값으로 주소를 대체하십시오. SSH 로그인은 홈 Wi-Fi에서와 동일하게 작동해야 하며, curl -I는 해당 장비에서 실행 중인 웹 애플리케이션의 HTTP 상태 라인을 출력해야 합니다. 연결은 로그인된 기기에 연결된 WireGuard 키로 인증되므로, 포트 포워딩 시 위험할 수 있는 SMB(server message block) 공유나 웹 관리 패널 같은 서비스도 여기서는 안전하게 사용할 수 있습니다. 오직 본인의 기기만이 해당 서비스로 패킷을 보낼 수 있기 때문입니다. 중간에 있는 ipTIME이나 Fritz!Box는 인바운드 연결을 전혀 확인하지 않으므로 설정을 변경할 필요가 없습니다. ISP가 사용자를 CGNAT 뒤에 배치했더라도 이 방식은 작동합니다. 홈 장비는 항상 외부로 연결을 시도하며, 최악의 경우에도 릴레이를 통해 경로가 형성되기 때문입니다.

새로운 tailnet에서 기본적으로 활성화되는 MagicDNS를 사용하면 모든 노드에 이름이 부여되므로, 노트북이 tailnet에 연결되면 ssh pi@nas도 정상적으로 작동합니다.

Tailscale을 실행할 수 없는 장치를 위한 서브넷 라우터

프린터, IP 카메라, 운영체제가 잠겨 있는 구형 NAS, 스마트 TV와 같이 클라이언트를 직접 실행할 수 없는 장치들이 있습니다. 서브넷 라우터는 이러한 문제를 해결합니다. 홈 네트워크에서 Tailscale을 실행할 수 있는 장치 한 대(Raspberry Pi로도 충분합니다)가 전체 홈 서브넷을 광고하면, 다른 tailnet 장치들은 해당 장치를 통해 서브넷으로 라우팅합니다.

echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-tailscale.conf
sudo sysctl --system
sudo tailscale up --advertise-routes=192.168.0.0/24

실제 홈 서브넷을 사용하십시오. 이후 관리자 콘솔의 해당 장치 라우트 설정에서 라우트를 승인해야 하며, Linux 클라이언트는 sudo tailscale set --accept-routes을 사용하여 옵트인(opt-in)해야 합니다. 설정이 완료되면 노트북에서 ping 192.168.0.50를 통해 가정 내 카메라에 접근할 수 있습니다. 패킷 포워딩을 위한 sysctl 설정이 중요한 이유는, 이 설정이 없으면 Raspberry Pi가 자신에게 오지 않은 모든 패킷을 폐기하여 라우트는 승인된 것으로 표시되더라도 내부 장치와는 통신할 수 없기 때문입니다. 승인 단계, 클라이언트 측 옵트인, 그리고 라우트가 승인되었음에도 연결되지 않는 기타 원인들에 대해서는 Tailscale 서브넷 라우터 운영하기를 참조하십시오. 해당 문서는 VPS를 라우터로 사용하는 예시를 들고 있으나, 거실에 있는 Raspberry Pi에도 동일하게 적용됩니다.

라우터 포트 개방 없이 친구들을 Minecraft 서버에 초대하기

두 번째 사례는 가정용 PC에서 Minecraft 서버를 운영하고 친구들을 초대하는 경우입니다. 기존 방식은 라우터에서 TCP 25565 포트를 포트 포워딩하고 공인 IP를 공유하는 것이었으나, 이는 인터넷상의 모든 스캐너에게 서버를 노출하는 결과를 초래합니다. Tailscale은 이를 공유(sharing) 기능으로 대체합니다.

두 가지 방법이 있습니다. 첫 번째는 친구들을 사용자로 tailnet에 초대하는 것입니다. 이 방법도 가능하지만 무료 플랜의 사용자 좌석은 제한되어 있으며, 기본적으로 초대된 사용자는 tailnet 내의 모든 장치에 접근할 수 있습니다. 접근 제어 규칙을 작성하여 범위를 좁히지 않는 한, 게임 서버 접속 이상의 권한을 부여하게 됩니다. 두 번째이자 더 간단한 방법은 노드 공유(node sharing)입니다. 관리 콘솔의 Machines 페이지에서 게임용 PC를 찾아 메뉴를 열고 Share를 선택하십시오. Tailscale이 초대 링크를 생성합니다. 각 친구는 자신의 무료 Tailscale 계정이 필요하며, 해당 계정으로 링크를 수락해야 합니다. 그러면 공유된 장치가 친구의 장치 목록에 나타나며, 오직 해당 장치만 표시됩니다. 공유를 통해 수신자는 공유된 장치에만 접근할 수 있으며 tailnet 내의 다른 장치에는 접근할 수 없습니다. 또한 공유된 장치는 기본적으로 격리되어 있어, 친구의 tailnet에서 오는 연결에 응답할 수는 있지만 스스로 연결을 시작할 수는 없습니다.

친구들은 Minecraft에서 서버를 추가할 때 tailnet 주소인 100.101.102.103:25565을 사용하거나, 포트가 기본값인 경우 해당 주소만 입력하면 됩니다. 게임용 PC는 포트 포워딩 없이 실행되며 라우터 설정은 변경할 필요가 없습니다. 공유된 장치는 서브넷 경로를 광고하지 않으므로, 공유된 장치 자체에서 실행되는 서비스에 적합하며 이는 게임 서버 사례에 정확히 부합합니다.

이 방법의 한계는 모든 플레이어가 Tailscale을 실행하고 공유를 수락해야 한다는 점입니다. 소규모 친구 그룹에게는 적합하지만, 누구나 참여할 수 있는 공개 서버에는 적합하지 않습니다. 다음 두 섹션에서 그에 대한 해결책을 다룹니다.

VPS에서 게임 서버를 실행하고 RCON을 tailnet에 유지하기

포트 포워딩을 피하는 다른 방법은 집에서 게임 서버를 운영하지 않는 것입니다. VPS는 공인 IP를 가지고 있어 직접 접근이 가능하므로, 가정용 라우터 없이도 게임 포트를 외부로 공개할 수 있습니다. VPS에서 Minecraft 서버 실행하기 문서에서는 서버 사양 산정, Java 플래그, 백업, systemd 유닛 설정 방법을 다룹니다. 여기서 중요한 점은 어떤 포트를 인터넷에 노출할지 결정하는 것입니다.

Minecraft 서버는 두 개의 포트를 사용합니다. TCP 25565는 게임용 포트로, 플레이어들이 접속하기 위해 필요합니다. TCP 25575는 RCON(원격 콘솔) 포트로, 비밀번호를 입력하면 op 및 stop를 포함한 모든 서버 명령을 실행할 수 있습니다. 인터넷에 노출된 RCON 포트는 비밀번호 추측 공격의 표적이 됩니다. VPS를 tailnet에 추가하고 두 포트에 대해 서로 다른 규칙을 적용하십시오.

sudo ufw allow OpenSSH
sudo ufw allow 25565/tcp
sudo ufw allow in on tailscale0 to any port 25575 proto tcp
sudo ufw enable
sudo ufw status

두 번째 규칙은 게임 포트를 모든 사람에게 개방합니다. 세 번째 규칙은 tailscale0 인터페이스로 들어오는 패킷에 대해서만 RCON을 허용하며, 이는 tailnet에 포함된 기기나 VPS를 공유받은 사용자만 접근할 수 있음을 의미합니다. VPS를 공유하는 경우, 인터페이스 규칙만으로는 공유 사용자와 본인의 기기를 구분할 수 없으므로 tailnet 정책의 접근 제어 규칙을 사용하여 공유 사용자가 25575 포트에 접근하지 못하도록 차단하십시오. 공인 IP는 여전히 25565 포트로 응답하며, 외부에서 25575 포트로 연결을 시도하면 ufw의 기본 거부 정책에 의해 차단됩니다. tailnet에 연결된 노트북에서 두 포트를 모두 확인하십시오.

nc -zv 100.101.102.103 25575
nc -zv <vps-public-ip> 25575

첫 번째 명령은 succeeded을 출력해야 합니다. 두 번째 명령은 응답 없이 시간 초과(time out)가 발생해야 하는데, 이는 패킷이 공용 인터페이스로 들어왔으나 허용 규칙과 일치하지 않기 때문입니다. 이와 동일한 패턴을 SSH, 웹 지도, 데이터베이스, 메트릭 대시보드에도 적용할 수 있습니다. 즉, 공용 서비스는 공인 IP의 포트로, 관리용 포트는 tailscale0 인터페이스로만 접근하도록 제한하십시오.

인터넷 전체에 서비스 노출하기: Funnel 또는 VPS 리버스 터널

세 번째 사례는 Tailscale만으로는 해결할 수 없는 경우입니다. 블로그, 공개 API, 공개 게임 서버, 상태 페이지 등 방문자가 사용자의 tailnet에 속해 있지 않으며 앞으로도 그럴 가능성이 없는 경우입니다. 이를 처리하는 두 가지 도구가 있으며, 각각 별도의 게시물에서 다룹니다.

Tailscale Funnel은 Tailscale의 릴레이를 통해 노드에서 공개 인터넷으로 HTTPS 서비스를 게시합니다. 이 기능은 TLS(transport layer security)를 통해서만 작동하며 443, 8443, 10000 포트에서만 사용할 수 있으므로, 웹 애플리케이션에는 적합하지만 25565 포트를 사용하는 일반적인 게임 프로토콜에는 적합하지 않습니다. Tailscale Serve와 Funnel 비교에서는 각 기능이 무엇을 누구에게 노출하는지 설명합니다.

VPS 리버스 터널은 그 외의 모든 경우를 처리합니다. 홈 서버는 공인 IP가 있는 VPS로 아웃바운드 터널을 열고, VPS는 해당 터널을 통해 TCP 또는 UDP의 모든 포트로 공인 포트를 다시 전달합니다. 이것이 CGNAT 뒤에 있는 가정용 서버에서 공개 Minecraft 서버를 운영하기 위한 도구이며, CGNAT 뒤의 홈 서버를 위한 VPS 리버스 터널에서 그 과정을 안내합니다. 이 두 가지 중 하나를 선택하십시오. 포트를 외부로 개방하는 Tailscale 설정을 찾으려 하지 마십시오. 그런 설정은 존재하지 않습니다.

Tailscale이 수행하지 않는 작업

• 임의의 외부 클라이언트를 위해 포트를 포워딩하지 않습니다. tailnet 외부에서 보낸 패킷은 노드에 도달할 수 없습니다. 해당 패킷에는 유효한 WireGuard 키가 없으며, 유효한 키가 없는 WireGuard 패킷은 응답 없이 폐기되기 때문입니다.
• 외부 사용자에게 내부망으로 들어오는 경로를 제공하지 않습니다. 사용자는 반드시 tailnet의 구성원이거나 공유 노드를 수락한 상태여야 합니다.
• 직접적인 경로를 보장하지 않습니다. NAT 환경이 복잡한 경우 연결은 릴레이를 거치게 되며, 이로 인해 속도가 저하될 수 있습니다.
• 라우터를 개방하지 않습니다. 라우터는 닫힌 상태를 유지하며, 이것이 바로 이 서비스의 핵심 목적입니다.

FAQ

Tailscale은 포트 포워딩이 필요한가요?

아니요. 모든 Tailscale 노드는 아웃바운드 연결만 수행합니다. 노드는 TCP 80 포트로 조정 서버(coordination server)에 접속하며, 80 포트 응답이 없으면 TCP 443 포트의 HTTPS로 전환합니다. 또한 UDP 3478 포트의 STUN을 통해 자신의 공인 IP 주소를 확인합니다. 모든 피어 연결은 처음에 TCP 443 포트를 통한 DERP 릴레이로 시작하며, 이후 UDP 홀 펀칭(hole punching)을 통해 41641 포트에서 직접 연결 경로로 업그레이드됩니다. 홀 펀칭에 실패하면 트래픽은 설정된 피어 릴레이로 이동하거나 DERP에 머무릅니다. 가정용 공유기에서 포트 포워딩이나 DMZ 설정을 할 필요가 없으며, CGNAT 환경에 있는 기기도 동일한 방식으로 연결됩니다.

Tailscale으로 마인크래프트 서버의 포트 포워딩을 대체할 수 있나요?

네, 친구들과 함께하는 서버라면 가능합니다. 게임을 실행하는 PC에 Tailscale을 설치하고, 관리 콘솔의 Machines 페이지에서 해당 기기를 친구들과 공유하십시오. 친구들은 포트 포워딩 없이도 25565 포트를 통해 해당 기기의 tailnet 주소로 접속할 수 있습니다. 다만, 공개 서버를 운영하는 경우에는 포트 포워딩을 대체할 수 없습니다. tailnet 외부의 플레이어는 해당 노드에 접근할 수 없기 때문입니다. 공개 서버가 필요하다면 공인 IP를 가진 VPS에서 게임을 호스팅하고 RCON만 tailnet으로 연결하거나, 가정용 PC에서 VPS로 리버스 터널을 구성해야 합니다.

Tailscale은 어떤 포트를 사용하나요?

네 가지 포트를 사용합니다. TCP 80 아웃바운드는 조정 서버 연결을 위한 우선 포트이며, Tailscale 고유의 암호화된 전송 방식을 사용합니다. TCP 443 아웃바운드는 80 포트 응답이 없을 때 사용하는 대체 경로이며, 항상 DERP 릴레이 트래픽을 처리합니다. UDP 3478 아웃바운드는 공인 IP 주소를 확인하는 STUN 용도입니다. UDP 41641은 직접 연결을 위한 기본 로컬 WireGuard 포트입니다. 패킷은 이 포트에서 출발하여 피어 측의 포트로 전달되며, 41641 포트를 사용할 수 없는 경우 변경이 가능합니다. 이 중 인바운드로 열어야 하는 포트는 없으며, TCP 80을 차단해도 클라이언트가 443으로 전환하므로 문제없습니다. VPS에서 UDP 41641 인바운드를 허용하면 피어 간 직접 연결 성공률이 높아집니다.

왜 Tailscale 연결이 직접 연결이 아닌 릴레이로 작동하나요?

UDP 홀 펀칭이 완료되지 않으면 tailscale ping는 계속해서 via DERP 상태를 유지합니다. 일반적인 원인으로는 펀칭이 통과할 수 없는 NAT(CGNAT 또는 목적지마다 새로운 포트를 할당하는 대칭형 NAT) 환경이거나, 아웃바운드 UDP를 차단하는 방화벽이 있는 경우입니다. 제어 가능한 범위 내에서 해결하려면 41641 포트에서 모든 목적지 포트로 나가는 아웃바운드 UDP를 허용하고, 3478 포트로 나가는 아웃바운드 UDP를 허용하십시오. 또는 한쪽 피어를 UDP 41641 인바운드가 열린 VPS에 배치하여 상대방의 펀칭이 고정된 타겟을 찾을 수 있게 하십시오. 네트워크 자체에서 UDP를 차단하는 환경에 있는 피어는 어떤 경우에도 릴레이로 연결됩니다.