이번 기능이 정말 합리적이라 생각함
직접 연결이 불가능할 때만 중간 노드를 사용하는 구조로, 트래픽은 종단 간 암호화됨
직접 derp 서버를 운영하는 것과 비슷하지만 포트를 열 필요가 없고, Tailscale의 릴레이 사용량을 줄여 대역폭 비용도 절감됨
다만 두 개 이상의 릴레이를 쓰면 왜 유료인지 궁금함
대부분의 경우 인터넷에 포트를 열어야 함
그렇지 않다면 애초에 tailscale이 필요 없을 수도 있음
예외적으로 두 클라이언트가 릴레이에는 접근 가능하지만 서로 직접 연결은 안 되는 경우가 있음
예전 tinc가 이미 이런 문제를 해결했음
모든 노드가 릴레이 역할을 할 수 있고, 중앙 서버 없이 진짜 메시 네트워크로 동작함
굳이 새로 구현하기보다 wireguard 기반으로 메모리 안전 언어로 포팅하는 게 낫다고 봄
나도 30개 노드의 Tinc 네트워크를 운영 중인데, NAT 뒤에 있는 호스트들이 자주 경로를 잃음
SSH 연결 직후 경로가 끊기는 경우도 많음
릴레이 노드에서 트래픽이 복호화·재암호화되는 구조라 종단 간 암호화를 위해선 실험적 프로토콜을 써야 함
cjdns 프로토콜 기반으로 다시 써보고 싶지만 쉽지 않음
Wireguard로도 같은 기능을 구현할 수 있음
Tailscale의 새 Peer Relay 기능이 ZeroTier가 예전에 하던 것과 비슷해 보임
“Tailscale만의 독자 기능”이라 주장하기엔 무리이고, 사용자당 요금 외에 추가 과금은 과하다고 느낌
예전에 ZeroTier를 써봤지만 이런 기능은 없었음
대신 자체 암호화 방식, 단일 스레드 성능 저하, 느린 개발 속도가 문제였음
여러 대안을 써봤지만 Tailscale만큼 기능과 성능을 모두 갖춘 건 아직 없음
“FTP 있는데 왜 Dropbox 쓰냐”는 식의 비교처럼 느껴짐
외부 IPv4/IPv6 주소를 직접 지정할 수 있는지 궁금함
송신과 수신 트래픽이 다른 주소를 쓰거나, 여러 인터넷 연결 주소 중 일부만 방화벽이 허용된 경우가 있기 때문임
지난주에 headscale과 split horizon SSL을 설정했는데, 결국 DERP만 가능하다는 걸 알게 됨
로컬 네트워크에서 UDP 포트를 직접 노출하는 게 더 낫다고 생각함
Wireguard 클라이언트의 보안이 충분히 검증됐다면 그게 더 편함
“DERP만 가능하다”는 게 무슨 뜻인지 궁금함
직접 Wireguard 포트를 열려고 한 건지, 아니면 Tailscale 포트를 말하는 건지 묻고 싶음
DERP 대신 이 기능을 쓰면 브라우저에서는 동작하지 않음 네이티브 UDP 기반이라서임
나중에 WebTransport로 구현할 수 있을지 궁금함
(Tailscalar) 나도 WebTransport에 기대가 큼
하지만 NAT 트래버설 문제는 해결하지 못함
Iroh의 QAD 진행 상황도 주의 깊게 보고 있음
다 잘 맞아떨어지면 훨씬 매직 같은 네트워크가 될 것 같음
다음 단계로 모든 tailscale 클라이언트가 자동으로 포워딩 요청을 받아서 메시 네트워크가 끊김 없이 자가 복구되면 어떨까 생각함
홉이 늘어나면 지연이 커지므로, 차라리 요청이 실패해서 문제를 명확히 드러내는 게 낫다고 봄
이런 확장은 오버레이 네트워크에서 자주 논의됨
다만 다른 사람의 트래픽 중계를 허용할지 여부가 핵심임
Tailscale로 서비스 간 연결이 가능하지만, 만약 Tailscale 장애가 나면 내 서비스끼리도 통신이 끊기는지 궁금함
실제로 로그인 서버 장애가 있었을 때 로컬 네트워크까지 모두 끊김
tailscale에 접속할 수 없어 재연결도 불가능했음
그래서 이제 headscale을 직접 구축하려고 함
로컬 LAN 장치끼리도 통신이 안 되는 건 좀 어이없었음
주말 내내 Kubernetes Operator용으로 임시 솔루션을 만들었는데, 이제 이 기능 덕분에 다 걷어낼 수 있게 됨
정말 브라보임
K8s는 내 악몽임 ㅋㅋ 완전 공감함
이 기능의 사용 사례가 궁금했음
SaaS 제품이 고객 시스템의 데이터를 필요로 할 때, 고객 쪽에서 데이터를 릴레이로 노출해 통합하는 용도 같음
그래도 인증·로깅 등을 위한 소프트웨어는 필요할 듯함
이건 tailscale이 운영하는 DERP 서버의 대안임
NAT 우회가 안 되는 경우가 많아 DERP가 자주 쓰이는데, 속도가 느림
이제는 네트워크 내에서 연결이 좋은 피어를 릴레이로 지정해 더 빠르게 쓸 수 있음
새로운 사용 사례라기보다 기존 DERP의 성능 개선판임
Tailscale은 기본적으로 보안 VPN 플랫폼임
전통적인 허브-스포크 구조 대신, 가능한 한 모든 노드가 직접 UDP/IP로 연결되는 P2P 구조를 지향함
하지만 NAT와 방화벽 때문에 직접 연결이 안 되는 경우가 많아 DERP가 이를 중계함
DERP는 느리고 사용자가 성능을 개선할 방법이 없었는데, 이번 Peer Relay로 직접 릴레이를 운영할 수 있게 됨
위치를 잘 잡으면 지연도 줄일 수 있음
물론 모든 사용자에게 필요한 기능은 아님
Hacker News 의견
이번 기능이 정말 합리적이라 생각함
직접 연결이 불가능할 때만 중간 노드를 사용하는 구조로, 트래픽은 종단 간 암호화됨
직접 derp 서버를 운영하는 것과 비슷하지만 포트를 열 필요가 없고, Tailscale의 릴레이 사용량을 줄여 대역폭 비용도 절감됨
다만 두 개 이상의 릴레이를 쓰면 왜 유료인지 궁금함
그렇지 않다면 애초에 tailscale이 필요 없을 수도 있음
예외적으로 두 클라이언트가 릴레이에는 접근 가능하지만 서로 직접 연결은 안 되는 경우가 있음
예전 tinc가 이미 이런 문제를 해결했음
모든 노드가 릴레이 역할을 할 수 있고, 중앙 서버 없이 진짜 메시 네트워크로 동작함
굳이 새로 구현하기보다 wireguard 기반으로 메모리 안전 언어로 포팅하는 게 낫다고 봄
SSH 연결 직후 경로가 끊기는 경우도 많음
릴레이 노드에서 트래픽이 복호화·재암호화되는 구조라 종단 간 암호화를 위해선 실험적 프로토콜을 써야 함
cjdns 프로토콜 기반으로 다시 써보고 싶지만 쉽지 않음
Tailscale의 새 Peer Relay 기능이 ZeroTier가 예전에 하던 것과 비슷해 보임
“Tailscale만의 독자 기능”이라 주장하기엔 무리이고, 사용자당 요금 외에 추가 과금은 과하다고 느낌
대신 자체 암호화 방식, 단일 스레드 성능 저하, 느린 개발 속도가 문제였음
여러 대안을 써봤지만 Tailscale만큼 기능과 성능을 모두 갖춘 건 아직 없음
“FTP 있는데 왜 Dropbox 쓰냐”는 식의 비교처럼 느껴짐
외부 IPv4/IPv6 주소를 직접 지정할 수 있는지 궁금함
송신과 수신 트래픽이 다른 주소를 쓰거나, 여러 인터넷 연결 주소 중 일부만 방화벽이 허용된 경우가 있기 때문임
지난주에 headscale과 split horizon SSL을 설정했는데, 결국 DERP만 가능하다는 걸 알게 됨
로컬 네트워크에서 UDP 포트를 직접 노출하는 게 더 낫다고 생각함
Wireguard 클라이언트의 보안이 충분히 검증됐다면 그게 더 편함
직접 Wireguard 포트를 열려고 한 건지, 아니면 Tailscale 포트를 말하는 건지 묻고 싶음
DERP 대신 이 기능을 쓰면 브라우저에서는 동작하지 않음
네이티브 UDP 기반이라서임
나중에 WebTransport로 구현할 수 있을지 궁금함
하지만 NAT 트래버설 문제는 해결하지 못함
Iroh의 QAD 진행 상황도 주의 깊게 보고 있음
다 잘 맞아떨어지면 훨씬 매직 같은 네트워크가 될 것 같음
다음 단계로 모든 tailscale 클라이언트가 자동으로 포워딩 요청을 받아서 메시 네트워크가 끊김 없이 자가 복구되면 어떨까 생각함
다만 다른 사람의 트래픽 중계를 허용할지 여부가 핵심임
Tailscale로 서비스 간 연결이 가능하지만, 만약 Tailscale 장애가 나면 내 서비스끼리도 통신이 끊기는지 궁금함
tailscale에 접속할 수 없어 재연결도 불가능했음
그래서 이제 headscale을 직접 구축하려고 함
로컬 LAN 장치끼리도 통신이 안 되는 건 좀 어이없었음
주말 내내 Kubernetes Operator용으로 임시 솔루션을 만들었는데, 이제 이 기능 덕분에 다 걷어낼 수 있게 됨
정말 브라보임
이 기능의 사용 사례가 궁금했음
SaaS 제품이 고객 시스템의 데이터를 필요로 할 때, 고객 쪽에서 데이터를 릴레이로 노출해 통합하는 용도 같음
그래도 인증·로깅 등을 위한 소프트웨어는 필요할 듯함
NAT 우회가 안 되는 경우가 많아 DERP가 자주 쓰이는데, 속도가 느림
이제는 네트워크 내에서 연결이 좋은 피어를 릴레이로 지정해 더 빠르게 쓸 수 있음
새로운 사용 사례라기보다 기존 DERP의 성능 개선판임
전통적인 허브-스포크 구조 대신, 가능한 한 모든 노드가 직접 UDP/IP로 연결되는 P2P 구조를 지향함
하지만 NAT와 방화벽 때문에 직접 연결이 안 되는 경우가 많아 DERP가 이를 중계함
DERP는 느리고 사용자가 성능을 개선할 방법이 없었는데, 이번 Peer Relay로 직접 릴레이를 운영할 수 있게 됨
위치를 잘 잡으면 지연도 줄일 수 있음
물론 모든 사용자에게 필요한 기능은 아님