VPN 구성하고 내 삶에 응용하기 2 - Tailscale 연결이 왜 이렇게 느릴까?
Tailscale이 왜 이렇게 느릴까?
VPN 포스트 1편에서 우리는 직접 wireguard 서버를 설치하고 운영하는 대신, wireguard 프로토콜에 기반한 아주 간편한 VPN 서비스인 tailscale에 대해 간단히 알아보았다. 상당히 편리하다보니 필자도 tailscale을 설치한 이후로 몇 년간 wireguard를 거의 사용하지 않게 되었다. 그만큼 tailscale이 부족한 게 없었단 말이기도 하다.
그런데 오늘, 몇 년 만에 tailscale의 부족한 점을 발견했다. 그것은 바로 tailscale을 통해 대용량을 파일을 송수신할 때, Node 간 연결방식에 따라 업로드/다운로드 속도가 느릴수도 있단 점이다.
그럼, 이 문제의 원인을 진단하고 해결책을 찾아보자.
진짜 속도가 느릴까?
특정 두 지점 간의 속도를 측정할 수 있는 iperf3라는 툴이 있다.
나는 내부망의 tailscale node에 iperf3 서버를 설치하고 사무실 pc에서 해당 지점에 대한 업로드/다운로드 속도를 측정해봤다.
(당연하지만 두 지점은 VPN으로 연결되어 있다.)
will@office-node:~ $ iperf3 -c 192.168.80.10
Connecting to host 192.168.80.10, port 5201
[ 5] local 100.115.164.47 port 42220 connected to 192.168.80.10 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 4.88 MBytes 40.9 Mbits/sec 0 621 KBytes
[ 5] 1.00-2.00 sec 2.75 MBytes 23.1 Mbits/sec 0 760 KBytes
[ 5] 2.00-3.00 sec 2.62 MBytes 22.0 Mbits/sec 0 901 KBytes
[ 5] 3.00-4.00 sec 2.75 MBytes 23.1 Mbits/sec 0 1.02 MBytes
[ 5] 4.00-5.00 sec 2.75 MBytes 23.1 Mbits/sec 0 1.15 MBytes
[ 5] 5.00-6.00 sec 2.75 MBytes 23.1 Mbits/sec 0 1.29 MBytes
[ 5] 6.00-7.00 sec 2.75 MBytes 23.1 Mbits/sec 0 1.42 MBytes
[ 5] 7.00-8.00 sec 2.75 MBytes 23.1 Mbits/sec 0 1.56 MBytes
[ 5] 8.00-9.00 sec 2.75 MBytes 23.1 Mbits/sec 0 1.70 MBytes
[ 5] 9.00-10.00 sec 2.62 MBytes 22.0 Mbits/sec 0 1.83 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 29.4 MBytes 24.6 Mbits/sec 0 sender
[ 5] 0.00-10.67 sec 28.2 MBytes 22.2 Mbits/sec receiver
iperf Done.will@office-node:~ $ iperf3 -c 192.168.80.10 -R
Connecting to host 192.168.80.10, port 5201
Reverse mode, remote host 192.168.80.10 is sending
[ 5] local 100.115.164.47 port 42464 connected to 192.168.80.10 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 2.25 MBytes 18.9 Mbits/sec
[ 5] 1.00-2.00 sec 2.75 MBytes 23.1 Mbits/sec
[ 5] 2.00-3.00 sec 2.62 MBytes 22.0 Mbits/sec
[ 5] 3.00-4.00 sec 2.75 MBytes 23.1 Mbits/sec
[ 5] 4.00-5.00 sec 2.75 MBytes 23.1 Mbits/sec
[ 5] 5.00-6.00 sec 2.75 MBytes 23.1 Mbits/sec
[ 5] 6.00-7.00 sec 2.62 MBytes 22.0 Mbits/sec
[ 5] 7.00-8.00 sec 2.75 MBytes 23.1 Mbits/sec
[ 5] 8.00-9.00 sec 2.75 MBytes 23.1 Mbits/sec
[ 5] 9.00-10.00 sec 2.75 MBytes 23.1 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.06 sec 29.0 MBytes 24.2 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 26.8 MBytes 22.4 Mbits/sec receiver
iperf Done.사무실의 인터넷망이 100Mbits/s 이니 80~90Mbits/s 정도는 나와야 하는데, 대략 평균 24 Mbits/s 정도가 나온다. 확실히 느리다.
느린 이유가 뭘까?
tailscale에는 점대점 ping을 찍어보고 연결이 어떤지 확인할 수 있는 기능이 있다.
tailscale ping [destination node]를 사용하면 된다.
will@office-node:~ $ tailscale ping home-node
pong from home-node (100.98.119.80) via DERP(tok) in 61ms
pong from home-node (100.98.119.80) via DERP(tok) in 61ms
pong from home-node (100.98.119.80) via DERP(tok) in 61ms
pong from home-node (100.98.119.80) via DERP(tok) in 61ms
pong from home-node (100.98.119.80) via DERP(tok) in 60ms
pong from home-node (100.98.119.80) via DERP(tok) in 60ms
pong from home-node (100.98.119.80) via DERP(tok) in 61ms
pong from home-node (100.98.119.80) via DERP(tok) in 61ms
pong from home-node (100.98.119.80) via DERP(tok) in 62ms
pong from home-node (100.98.119.80) via DERP(tok) in 62ms
direct connection not established위 결과에서 중요한 부분은 via DERP(tok)이다. 아하! 한국에서 한국으로 연결하는데 굳이 일본으로 패킷을 보내고 다시 한국으로 돌아오는 연결을 하고 있었던 것이다.
그럼, 반대로 집에서 사무실로 tailscale ping을 해보면 어떨까?
이 경우는 직접 연결이 성공한다.
이 경우는 문제가 없다.
will@home-node:~ $ tailscale ping office-node
pong from office-node (100.115.164.47) via [사무실 공인 ip]:41641 in 3ms정리하자면 사무실 -> 집으로 연결하는 방향에 직접 연결이 안되고 DERP 서버를 경유한 것이 속도가 느린 원인이었다.
(UDP로 펀칭을 할 때 집 네트워크 쪽에서 뭔가 협조가 안되는 것 같다.)
DERP 서버를 사용할 때 느리다.
이전 포스팅의 Tailscale 개요에서 언급한 것과 같이 tailscale의 node들 간의 연결을 위해 이렇게 DERP 서버를 경유하기도 한다. Tailscale은 각 노드들 간의 peer-to-peer(P2P) 연결이 가능한지 먼저 검사해보고 그것이 실패할 때만 DERP 서버를 경유한다.
항상 DERP 서버를 경유하여 목적지 tailscale node와 연결이 성공하는 건 아니다. 공유기를 여러번 통과해야하는 상황이거나 방화벽 규칙 등이 빡빡한 상황이면 직접 연결에 실패하기도 한다. 이 경우 P2P 연결은 불가하고 DERP 서버로 우회하여 패킷을 전송하게 되는 것이다.
이때 중계해주는 DERP 서버가 한국이 아닌 외국에 위치한다면 패킷들이 다른 나라로 갔다가 돌아돌아 한국의 목적지 node로 향하기 때문에 전송 속도와 지연시간이 나빠진다. (그리고 한국엔 DERP 서버가 없고 가장 가까운 서버위치는 도쿄로 보인다.)
DERP 우회하는 상태로 그냥 쓰면 안되나?
DERP를 경유하더라도 ssh나 RDP 등과 같이 대용량의 데이터 전송을 하지 않는 연결만 사용한다면 크게 느린 것을 인지하지 못할 수도 있다. 그래서 필자도 2년 넘게 이 문제를 인지하지 못한 것이다.
그렇지만 ftp나 samba, nfs와 같은 프로토콜로 대용량의 파일을 전송하는 경우 얘기가 달라진다. 수십 Gbyte의 데이터를 홈서버로부터 받아올 때 시간이 네 다섯배나 더 걸리는 일이 발생한다. 이렇게 사용하려면 이걸 반드시 해결해야만 한다.
라우터의 static NAT port mapping 설정을 확인해보자.
필자는 홈서버 네트워크망과 그냥 일상용 네크워크망을 각각 다른 라우터로 분리하여 사용하고 있다.
그리고 홈서버 네크워크에는 OPNsense router를 사용하고 있다.
구글링을 해보니, OPNSense를 사용하면 직접 연결에 실패할 수 있는 듯 하다. Tailscale 공식 사이트에서도 Tailscale과 OPNsense를 함께 사용하기 위한 가이드를 제공한다.
가이드를 내리다보면 Static NAT port mapping 섹션이 있다.
Tailscale이 직접 연결을 위해 UDP 패킷을 41641 포트로 쏴보고 목적지가 인식되는지 확인을 하는데, OPNsense는 기본적으로 내부적으로 무작위로 매번 다른 포트로 변경하도록 설정되어 있기 때문에 직접 연결에 실패할 수 있다고 한다.
이걸 해결하려면 Static NAT port mapping을 설정해주면 된다.
필자는 내부망 전체가 아니라 필요한 tailscale node IP에서만 Static NAT port mapping을 사용하도록 rule을 설정해주었다.
해치웠나?
해당 rule을 설정하고 일정 시간이 지난 뒤 다시 사무실에서 집으로 연결을 확인해봤다.
will@office-node:~ $ iperf3 -c 192.168.80.10
Connecting to host 192.168.80.10, port 5201
[ 5] local 100.115.164.47 port 42008 connected to 192.168.80.10 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 11.5 MBytes 96.4 Mbits/sec 13 92.3 KBytes
[ 5] 1.00-2.00 sec 10.4 MBytes 87.0 Mbits/sec 14 85.1 KBytes
[ 5] 2.00-3.00 sec 10.5 MBytes 88.1 Mbits/sec 14 113 KBytes
[ 5] 3.00-4.00 sec 10.9 MBytes 91.2 Mbits/sec 24 94.7 KBytes
[ 5] 4.00-5.00 sec 10.4 MBytes 87.0 Mbits/sec 26 83.9 KBytes
[ 5] 5.00-6.00 sec 10.5 MBytes 88.1 Mbits/sec 21 83.9 KBytes
[ 5] 6.00-7.00 sec 10.5 MBytes 88.0 Mbits/sec 12 118 KBytes
[ 5] 7.00-8.00 sec 10.9 MBytes 91.3 Mbits/sec 10 138 KBytes
[ 5] 8.00-9.00 sec 10.4 MBytes 87.0 Mbits/sec 19 81.5 KBytes
[ 5] 9.00-10.00 sec 10.4 MBytes 87.0 Mbits/sec 2 109 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 106 MBytes 89.1 Mbits/sec 155 sender
[ 5] 0.00-10.01 sec 106 MBytes 88.5 Mbits/sec receiver
iperf Done.will@office-node:~ $ iperf3 -c 192.168.80.10 -R
Connecting to host 192.168.80.10, port 5201
Reverse mode, remote host 192.168.80.10 is sending
[ 5] local 100.115.164.47 port 43882 connected to 192.168.80.10 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 10.5 MBytes 88.1 Mbits/sec
[ 5] 1.00-2.00 sec 10.6 MBytes 89.1 Mbits/sec
[ 5] 2.00-3.00 sec 10.6 MBytes 89.1 Mbits/sec
[ 5] 3.00-4.00 sec 10.5 MBytes 88.1 Mbits/sec
[ 5] 4.00-5.00 sec 10.6 MBytes 89.1 Mbits/sec
[ 5] 5.00-6.00 sec 10.6 MBytes 89.1 Mbits/sec
[ 5] 6.00-7.00 sec 10.6 MBytes 89.1 Mbits/sec
[ 5] 7.00-8.00 sec 10.6 MBytes 89.1 Mbits/sec
[ 5] 8.00-9.00 sec 10.5 MBytes 88.1 Mbits/sec
[ 5] 9.00-10.00 sec 10.6 MBytes 89.1 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 106 MBytes 89.2 Mbits/sec 27 sender
[ 5] 0.00-10.00 sec 106 MBytes 88.8 Mbits/sec receiver
iperf Done.오호.. 다운로드와 업로드 속도 모두 약 89 Mbits/s로, 망의 최대속도인 100 Mbits/s에 가까운 속도가 나온다!
tailscale ping을 찍어보니, DERP가 아니라 직접 연결을 사용하고 있는 것도 확인할 수 있다.
will@office-node:~ $ tailscale ping home-node
pong from home-node (100.98.119.80) via [집 공인 ip]:41641 in 3ms마무리하며
생각보다 싱겁게 문제를 해결할 수 있었다. 혹시나 비슷한 tailscale 속도 저하 문제를 겪고 있다면 직접 연결이 가능하도록 설정을 한번 바꿔보시길…