Tailscale이 말하는 새로운 인터넷

 (tailscale.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Tailscale은 개발자가 불필요한 확장성 중심 구조에 갇히지 않도록, 모든 기기가 안전하게 직접 연결되는 새로운 OSI 3계층을 만들려 함
  • 많은 프로그램은 실제로 대규모 확장이 필요 없지만, Kubernetes, 컨테이너 배포, 클라우드 로그 수집이 기본값이 되면서 개발과 운영이 느려졌다고 봄
  • IPv4 부족, NAT, 방화벽, 동적 IP, TLS 인증서 구조는 클라이언트와 서버를 갈라놓고, AWS 같은 중앙 클라우드 제공자를 연결성의 중심에 세움
  • Tailscale은 각 기기에 인증서, IP 주소, DNS 이름, 종단 간 암호화, ID를 부여해 방화벽 뒤에서도 안전하게 연결하고, 모든 기기를 피어로 만들려 함
  • Taildrop의 HTTP PUT 기반 파일 전송은 중간 클라우드 계층을 줄일 수 있음을 보여주지만, 이런 앱 생태계가 생기려면 충분한 보급이 먼저 필요함

Tailscale 비전의 출발점

  • Tailscale은 단기 기능보다 더 큰 비전을 공개적으로 많이 말하지 않았지만, 일부 기업은 현재 기능뿐 아니라 앞으로 가능해질 연결성 때문에 Tailscale을 구매하고 있음
  • 초기 문제의식은 네트워킹 회사가 되는 데 있지 않았고, 개발자가 확장할 필요 없는 것까지 확장하려 하면서 개발 경험이 나빠지는 데 있었음
  • 1990년대 LAN 경험을 기억하는 세대가 Tailscale 창업의 맥락에 있으며, 그 경험은 현재 기술 복잡성을 비교하는 기준이 됨
  • 컴퓨터 성능, 프로그래밍 접근성, 앱스토어, 결제 시스템, 그래픽은 좋아졌지만, 개발자의 일상 작업 중 예전에는 쉬웠던 많은 일이 오히려 어려워졌다고 봄

불필요한 확장성이 만든 개발 오버헤드

  • 현대 개발자는 첫 코드 작성 전부터 10억 사용자 규모를 고려하도록 훈련되고, 알고리듬과 아키텍처 선택도 확장 가능성을 우선하는 경향이 있음
  • big-O 표기법을 잘못 적용하면 해시 테이블이 배열보다 항상 빠른 것처럼 보이지만, 10개 항목 수준에서는 배열이 더 빠르고 단순할 수 있음
  • 확장 가능한 구조를 고르면 실제로 확장하지 않는 경우 더 느리고 만들기 어려운 시스템이 될 수 있음
  • 월 500,000 페이지뷰를 Kubernetes로 처리했다는 사례는 초당 약 0.2 요청 수준이며, 1990년대의 느린 컴퓨터에서도 Perl이나 Python 프로그램이 밀리초 단위로 시작해 그보다 많은 요청을 처리할 수 있었다고 비교함
  • 긴 빌드, Docker 빌드, 컨테이너 저장소 업로드, 수십 초에서 수분 단위 배포, 늦게 도착하는 로그는 “모든 것이 확장해야 한다”는 전제에서 생긴 오버헤드로 묶임
  • Tailscale은 모든 개발자가 시간의 상당 부분을 쓰는 대시보드, 밈 생성기 같은 확장할 필요 없는 긴 꼬리 작업을 쉽게 만들기 위한 도구로 자리 잡음

현재 인터넷이 복잡성을 키우는 방식

  • 많은 복잡성은 본질적 복잡성이 아니라, 단순하게 풀 수 있는 문제에 복잡한 해법을 얹은 결과로 간주됨
    • 로그 시스템은 한 곳에서 다른 곳으로 텍스트를 스트리밍하는 일인데도 결과가 5분 뒤 보일 수 있음
    • 오케스트레이션 시스템은 다른 프로그램을 실행하는 프로그램인데, Unix 커널은 수십 년 동안 밀리초 단위로 이를 처리해 왔음
  • 네트워킹은 현대 소프트웨어에 필수지만, 현재 인터넷은 많은 문제를 어렵게 만듦
  • Tailscale은 기존 OSI 스택의 최상단에 계층을 더해 문제를 숨기기보다, 다른 전제 위에 새로운 OSI 3계층을 만들려 함

클라우드 중앙화와 연결성의 임대료

  • 기술 산업에서 누가 임대료를 받을 수 있는지 보면 병목이 보이며, 현재 소프트웨어 배포에서는 AWS가 그런 위치에 있다고 봄
  • 클라우드는 확장 가능한 컴퓨팅 자원을 제공하지만, 중급 MacBook도 SSD에서 클라우드 로컬 디스크보다 10배 또는 100배 많은 초당 트랜잭션을 처리할 수 있다고 비교함
  • 자체 컴퓨터가 서버가 되기 어려운 이유는 위치와 연결성임
    • 방화벽, NAT, 동적 IP, 비대칭 네트워크 링크가 있음
    • 포트 포워딩, 정적 IP, 중복 인터넷 링크를 직접 구성할 수는 있지만 많은 작업과 전문성이 필요함
  • 결국 IP 주소와 대역폭을 가진 호스팅 제공자에게 비용을 지불하게 되고, 진지한 회사라면 장비 접근 권한을 신뢰할 수 있는 큰 제공자를 선택하게 됨
  • “아무도 AWS를 사서 해고되지 않는다”는 구도는 과거 IBM에 대한 표현과 연결됨

운영체제에서 HTTPS로 이동한 게이트키퍼

  • IBM은 중앙집중형 컴퓨팅에서 임대료를 받을 수 있었고, Microsoft는 PC 기반의 분산 컴퓨팅으로 그 구도를 흔들었음
  • 현재 클라우드와 휴대폰 중심의 세계는 다시 중앙집중형으로 돌아갔다고 봄
    • 책상과 주머니의 기기는 20년 전 기준으로 슈퍼컴퓨터급이지만, AWS가 꺼지면 쓸 수 없는 벽돌처럼 됨
    • 서버 다중 인스턴스와 분산 합의 시스템이 있어도, 대부분 중앙 클라우드 제공자 위에서 실행됨
  • 1990년대에는 운영체제가 프로그램 간 호환성과 연결을 좌우했지만, 웹 이후에는 JavaScript와 HTTPS 연결 가능성이 더 중요해짐
  • HTTPS는 기본적으로 클라이언트와 서버의 중앙집중형 구조를 가짐
    • 서버는 정적 IP, DNS 이름, TLS 인증서, 열린 포트를 가짐
    • 클라이언트는 보통 그런 요소가 없음
    • 서버가 사라지면 클라이언트는 아무것도 하지 못함
  • 보안 문제와 IPv4 주소 부족 때문에 방화벽과 NAT가 추가되었고, 연결은 클라이언트에서 서버로 향하는 일방향 구조가 됨

Tailscale의 New Internet

  • Tailscale은 지난 5년 동안 이 문제의 해법으로 제품을 만들어 왔음
  • 각 기기는 인증서, IP 주소, DNS 이름, 종단 간 암호화, ID를 갖고 방화벽을 안전하게 우회함
  • 모든 기기는 서버와 클라이언트의 고정된 역할이 아니라 서로 연결되는 피어가 될 수 있음
  • Tailscale은 이를 지연 시간이나 오버헤드 추가 없이 수행한다고 봄
  • Tailscale 사용자는 이미 여러 겹의 복잡한 계층을 제거한 환경을 경험하며, 인터넷이 원래 기대했던 방식에 더 가깝게 동작함

Taildrop이 보여주는 단순화

  • Taildrop은 Tailscale이 가능하게 하는 구조의 작은 예시임
  • Tailscale이 이미 설치된 상태에서 Taildrop의 핵심은 HTTP PUT 한 번임
    • 보내는 쪽이 받는 쪽에 HTTP 요청을 보냄
    • “X라는 파일을 보낸다”고 알림
    • 파일을 전송함
  • 기존 인터넷에서는 받는 기기가 방화벽 뒤에 있고 열린 포트와 ID가 없기 때문에, 클라우드에 업로드한 뒤 다시 다운로드하는 방식이 필요했음
  • 클라우드 경유 방식은 여러 추가 계층을 만듦
    • 네트워크 송신 비용, 저장 비용, 서버 CPU 비용이 발생함
    • 다운로드되지 않은 파일을 언제 삭제할지 정해야 함
    • 사용하지 않을 때도 서버를 온라인으로 유지해야 함
    • 클라우드 직원이 이론적으로 파일에 접근할 수 있으므로 암호화가 필요함
    • 암호화를 위해 송신자와 수신자 사이의 키 교환이 필요함
    • 수신자에게 파일이 대기 중임을 알리려면 플랫폼별 푸시 알림 시스템이 필요할 수 있음
  • Taildrop은 이런 비용 오버헤드가 사라지기 때문에 무료 파일 전송이 가능하며, 이는 Tailscale의 무료 플랜 맥락과 연결됨

보급이 필요한 이유

  • Taildrop은 사소한 예시지만, Tailscale이 있으면 10배 쉬워질 수 있는 프로그램 범주의 존재 증명 역할을 함
  • 연결성 부족은 중앙화를 만들고, 중앙화는 작은 프로그램에도 임대료를 내게 하며, 느리고 복잡하고 디버그하기 어려운 구조를 만듦
  • Tailscale 위에서만 동작하는 앱이 생기려면 충분한 사람이 Tailscale을 써야 함
  • 보급이 충분하지 않으면 아무도 그런 앱을 만들지 않는 닭과 달걀 문제가 생김
  • 이 때문에 Tailscale은 무료 제공에 많은 노력을 쓰는 동시에, 직장 도입과 Fortune 500 기업 전체 배포를 쉽게 하는 엔터프라이즈 기능에도 힘을 쏟음

목표와 현재 위치

  • 인터넷은 모두를 위한 것이며, 과거 여러 internetwork가 있었지만 가장 다양하고 포용적인 Internet이 승리했다고 봄
  • New Internet도 집의 개발자, 대학의 개발자, 기업 직원, 궁극적으로 모든 사람이 쓸 수 있어야 함
  • 현재 전 세계 사람 중 약 30,000명 중 1명이 New Internet, 즉 Tailscale을 사용함
  • Tailscale은 모든 사람이 사용할 때까지 멈추지 않겠다는 목표를 내세움
  • Microsoft가 모든 책상 위에 컴퓨터를 놓겠다는 목표로 조롱받던 시기와, TCP/IP가 서드파티에서 사야 하는 선택적 추가 기능이던 시기를 떠올리며, 기술 세계는 30년 안에도 빠르게 바뀔 수 있음을 강조함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Tailscale, Cloudflare, Google 같은 회사의 영원한 문제는 인터넷이 원래 스스로 해결했어야 할 문제, 예컨대 단순한 종단 간 보안 연결을 대신 해결하면서 그 문제가 계속 남아 있어야 할 유인이 생긴다는 점임
    인터넷에 필요한 건 DNSSEC가 제공하는 공개 키 기반 구조와 IPsec 자동 암호화를 갖춘 IPv6 같은 것이지만, 그런 것이 널리 호환되게 구현되면 Tailscale의 사업이 무너짐
    결국 이들의 사업은 문제가 계속 존재하는 데 의존함
    재게시: https://news.ycombinator.com/item?id=38570370

    • 그럴듯한 지적처럼 들리지만, 생각할수록 디지털 고행처럼 느껴짐
      IPv6는 1998년에 나왔고, Tailscale이 2019년에 출시되기까지 21년 동안에도 말한 방식은 구현되지 않았음
      그때 누가 막았고, 지금은 누가 막고 있나? Google, Cloudflare, Tailscale은 실제 문제를 풀었기 때문에 돈이나 개인정보 같은 돈에 준하는 대가를 받은 것임
      인터넷을 모두에게 더 나쁘게 만들어야 진짜 좋은 해법이 등장한다는 식의 역가속주의에는 동의하기 어려움
      Tailscale 때문에 그런 해법이 안 나오는 게 아니라, 그걸 만드는 데 필요한 막대한 작업량 때문이고, WireGuard가 없었다면 Tailscale도 없었을 가능성이 큼
      Tailscale이 생기면서 Headscale도 생겼고, 이는 말한 “무언가”를 만들기 위한 또 하나의 발판이 됨
    • 더 나쁘게는, Tailscale은 NAT와 방화벽 통과를 돕는 조정 서버를 사용하게 만들 유인이 있음
      말은 길지만 핵심은 기기들이 서로를 찾는 중간에 Tailscale이 앉는 구조라는 것임
      다른 방식도 있음. 임시 IP만 가진 기기에 영구 이름을 붙이는 동적 DNS는 수십 년 전부터 있었지만 평판은 좋지 않은 편임
      서로를 아는 여러 조정 노드와 공개 노드 목록을 쓰는 방식도 가능함. 목록이 낡아도 살아 있는 노드 하나만 있으면 연결해 갱신할 수 있고, Ethereum 네트워크와 일부 파일 공유 시스템의 기반인 Kademlia가 이런 식으로 동작함
      검색과 전송을 분리하는 절충도 가능함. Peertube는 일반 웹 검색으로 찾은 서버에서 HTTP로 스트리밍할 파일을 찾고, 실제 전송은 현재 시청자들이 블록을 서로 보내는 분산 방식이라 영상이 입소문 나도 잘 확장됨
      그러니 누군가가 중간에서 산소줄을 끊을 수 없는 방식으로도 충분히 가능함
    • “자동 IPsec”, 특히 IPsec 자동화는 원하지 않음. 네트워크 계층에서 강제 암호화를 넣는 것도 지금 기준으로는 WireGuard처럼 멀쩡한 것이라 해도 위험함
      오래된 VPN 프로토콜이나 RADIUS 같은 인증 방식은 심각한 보안 구멍이 있어도 호환성 때문에 고치기 어렵고, 그것들도 인터넷 전체보다 훨씬 작은 규모에서 돌아감
      업계가 TCP 경직화 문제를 TCP를 버리고 UDP 위에 다시 구현하는 식으로 풀고 있다는 사실이 많은 걸 말해줌
    • Zerotier가 어느 정도 그런 역할을 함. 터널이지만 트래픽은 직접 가고, 이중 NAT가 아니면 엔드포인트 IP로 직접 라우팅할 수 있을 때 zt를 건너뛸 수도 있음
      위치 서비스도 원하면 자가 호스팅할 수 있어서, 서비스를 꼭 써야 하는 건 아님
      DNSSEC를 제외하면 요구한 것과 꽤 비슷함
    • 그건 지나치게 부정적인 해석임. Tailscale의 가치 제안은 “어디서든 네트워크에 안전하게 접속할 수 있고, 다른 사람은 못 들어온다”는 것이기도 함
      이 가치는 IPsec이 생긴다고 사라지지 않음

  • 임대료를 뽑아먹는 중앙집중적 통제에 대한 아주 긴 불평으로 시작하는데, 그 자체는 타당한 불만임
    하지만 클라이언트-서버 컴퓨팅이 말이 되는지, 혹은 그것이 임대 수익 추구의 원인인지 같은 별개의 논점에 빠졌다가 결국 “내일은 Tailscale을 가진 사람과 못 가진 사람이 갈릴 것”이라는 결론에 도달함
    왕은 죽었다, 새 왕 만세라는 느낌임

    • 독점적인 피어 투 피어 시스템에서도 임대 수익을 뽑을 수 있다는 말에는 동의하지만, 아직도 Tailscale보다 오래됐고 OpenVPN도 아닌 비독점 도구를 쓰고 있음
      프로그래머가 아닌 나도 고칠 수 있을 만큼 작고 단순함
      모두가 인터넷에서 직접 접근 가능한 방화벽 없는 IP를 가진 게 아니므로, 피어 투 피어를 달성하려고 클라이언트-서버를 쓸 수도 있음
      호스팅 회사 서버에 “슈퍼노드”를 올려야 할 수 있지만, 랑데부 서버로만 쓰면 트래픽은 지나가지 않아 비용이 작음
      “무료”와 경쟁하려는 회사는 늘 강하게 의심하게 됨. 무료 소프트웨어를 그만 쓰고 우리에게 돈을 내라, 대신 불필요한 기능 100개를 붙였다는 식임
      Slack처럼 이런 기업 전략이 단기적으로는 성공할 수 있겠지만, 이런 구독은 내 취향이 아님
      핵심은 클라이언트-서버 대 피어 투 피어가 아니라 독점 대 비독점이라고 봄
    • Tailscale CEO가 “내일은 Tailscale을 가졌느냐 아니냐가 갈리고, 없으면 post-Tailscale 세계에서만 동작하는 앱을 못 돌릴 것”이라고 설교하는 건가?
      10년 안에 Microsoft급 거물이 되지 못하면 좋게 받아들여지기 어려울 듯함
    • 지난 수십 년 동안 Hamachi가 꽤 그리웠음
      당시에는 개인 사설망을 설계하고 설정하기에 정말 훌륭하고 쉬운 도구였음. 파일 공유, 로컬 게임 LAN, 개발 협업, 심지어 미디어 스트리밍도 쉽게 가능했음
      피어 투 피어의 미래는 Tailscale이라기보다, 서로 다른 NAT와 ASN 너머의 노드들을 일반적으로 묶어주고 NAT 우회 기법, STUN/TURN, 터틀 라우팅을 이해하는 자가 호스팅 Hamachi 변형에 더 가까울 것 같음
      중앙 VPN 게이트웨이 없이 원격 사용자가 쉽게 합류할 수 있는 도구라면 현대 환경에서 강력한 기능이 될 것임
    • 임대 수익 추구자는 나쁘다면서, 지금 내는 임대료에 더해 나에게도 임대료를 내라고 하는 구조처럼 들림
    • “엄청나게 긴 도입부”라는 데 동의함
      우리 모두 Iceberg Articles를 배우고 적용하면 좋겠음: https://john.kozubik.com/pub/IcebergArticle/tip.html

  • 실제로 Tailscale을 프로덕션 시스템에 쓰고 있음. 서버는 물리적으로 가까운 곳이나 통제된 다른 위치에 있고, 수백 킬로미터 떨어진 수백 명의 사용자가 모두 Tailscale로 작업함
    두 가지는 말해야 함. Tailscale은 놀랍고 정말 좋음. 이 시스템은 Tailscale 없이는 존재할 수 없었거나, 24시간 운영을 위해 팀에 최소 10명은 더 필요했을 것임
    다만 기대치는 낮춰야 함. “인터넷”만큼 좋지는 않음. 지연 시간이 주기적으로 튀고, 연결이 가끔 끊기며, MagicDNS가 말 그대로 마법처럼 멈추거나 시스템과 충돌함
    사용자가 많다 보니 겪을 수 있는 문제는 거의 다 겪었고, 내일 또 새로운 문제가 나올 수 있음
    그래도 Tailscale과 그 비전을 믿음. 하드웨어 통제권을 주면서 비용을 낮추고 보안을 높이는 완전히 새로운 접근임
    첫 대형 프로덕션 서버는 4코어 Linux 노트북이었음

    • Tailscale을 통해 4코어 Linux 노트북을 프로덕션 서버로 쓴 구성을 더 자세히 듣고 싶음
      나도 내부용 자가 호스팅에는 Tailscale을 잘 쓰고 있지만, 공개 프로덕션 서비스에 쓸 생각은 못 해봐서 설정이 궁금함
    • 수백 킬로미터 떨어진 수백 명의 사용자가 Tailscale로 작업한다면, 사용자들에게 Tailscale 설치를 요구하는 건가?

  • Tailscale은 좋아하지만, 이 글은 섬뜩함
    인터넷이 성공한 건 표준 위에 만들어졌고 완전히 자유로웠기 때문임
    Tailscale에서는 WireGuard가 오픈소스이고 Headscale 같은 것도 있지만, “모두가 IP를 갖는다”는 구조는 Tailscale이 거대한 IP 주소 공간을 소유하는 데 의존하는 것 아닌가?
    완전한 IPv6 보급을 기다리거나, 중앙화된 IPv4와 서버와 독점적인 것들에 의존해야 한다면 약간 위선적으로 보임

    • Headscale로 Tailscale 제어 서버를 자가 호스팅할 수 있음: https://github.com/juanfont/headscale
      Tailscale과 완전한 기능 동등성은 아니지만 현재 기능 대부분을 지원하고 매일 개선되고 있음
      기억이 맞다면 핵심 개발자 중 한 명은 Tailscale에서 보수를 받으며 작업함
      개인 자가 호스팅 인프라에 쓰고 있는데 아주 잘 동작함. 사용자 지정 제어 서버 URL 설정도 Windows와 Android에서는 비교적 쉬웠음
      taildrop도 쓰고, Docker 컨테이너를 tailnet에 제공하는 등 Headscale은 충분히 잘 작동하니 시도해볼 만함
    • 100.64.0.0/10은 통신사급 NAT용 예약 IP 블록임
    • Tailscale은 “인터넷”이 아니라 서로 떨어진 여러 해자들의 묶음이라서 거대한 IP 공간이 필요하지 않음
      필요한 IP 공간은 가장 큰 해자만큼이면 되고, 한 번에 하나의 해자에만 연결될 수 있음
    • Tailscale에서 옮겨야 한다면 어디로 옮길 건가?

  • Tailscale은 좋아하지만, 이 글은 너무 자기 과시적으로 읽힘
    부가 서비스를 얹은 메시 VPN 제품이고, 그 자체로 훌륭하지만 새롭거나 유일한 아이디어는 아님
    왜 이 해법이 다른 대안이 아니라 새 인터넷이어야 하나?
    어쨌든 인터넷 인프라 전체를 한 회사에 의존하고 싶지는 않음. 그래서 복잡하더라도 전통적인 인터넷을 계속 쓰겠음
    큰 문제들은 기술보다 사회적이고, 새 기술이 그것들을 해결하지는 못함

    • 현재 인터넷의 큰 문제가 정말 사회적인가? 초기 약속이었던 100% 탈중앙 네트워크가 현실적으로 관리하기 너무 복잡해서 서비스가 본질적으로 중앙화되는 것이 핵심 문제라면, 그건 깊이 기술적인 문제로 보임
      소셜 미디어를 예로 들어, Facebook/Twitter/TikTok/YouTube/Reddit/HN 등이 BitTorrent처럼 매끄럽게 동작하는 세계를 상상할 수 있음
      내 컴퓨터의 앱이 “Facebook” 네트워크에 참여하고, 친구들은 각자의 앱 인스턴스를 통해 내가 온라인인 걸 보며, 피드와 담벼락은 내 기기에서 직접 제공됨
      중앙 서버 없이 2명, 1000명, 수백만 명이 직접 통신하는 구조임
      BitTorrent, Soulseek, Bitcoin 등 이미 여러 피어 투 피어 네트워크가 가능성을 보여줌
      하지만 facebook.com에 접속하는 것만큼 매끄럽게 만들려면 전부 기술 문제가 튀어나옴. 포트 포워딩, 동적 DNS, 고급 네트워크·보안·시스템 관리 지식 없이도 되는 매끄러운 피어 투 피어 연결이 첫 큰 장벽임
      노드가 오프라인이면 어떻게 할지, 피드를 가져오려고 수천·수십만·수백만 대에 연결해야 할 때 지연과 부하는 어떻게 될지, 캐시는 어떻게 할지, 업데이트와 알림은 어떻게 밀어줄지, 아주 오래된 노드끼리는 어떻게 통신할지, 데이터는 어디 저장할지, 발견 가능성과 보안은 어떻게 할지 모두 기술 문제임
      대부분 풀 수는 있지만, 중앙화 서비스처럼 바보처럼 쉬운 경험에 도달하려면 문제를 하나씩 푸는 막대한 노력이 필요함
      Fediverse도 이 문제의 작은 일부를 10년 넘게 풀고 있지만, 아직도 twitter.com과 비슷하거나 조금 나쁜 경험을 주려면 꽤 유능한 시스템 관리자가 필요함
    • Tailscale의 가치 제안이 뭔가? 여러 거물급 자유 오픈소스 소프트웨어를 엮은 임시방편 아닌가?

  • Yggdrasil이 새 인터넷이 되려던 것 아닌가? https://yggdrasil-network.github.io
    아니라면 왜 하필 Tailscale이고, Netbird, Nebula, Netmaker나 다른 경쟁자는 아닌가?
    글은 아주 잘 썼지만 인수, 전환, 분사, 종료 같은 뭔가가 다가오는 듯한 이상한 느낌을 줌. “이제 시작일 뿐”이라는 말도 유명한 마지막 말처럼 들림
    균형을 위해 덧붙이면, Tailscale 사용자로서는 만족하고 있고, 별로 신경 쓰지 않아도 그냥 동작한다는 점에는 인상받았음

    • 설명만 보면 Yggdrasil이 더 잘 맞음
      다만 잘 동작하긴 해도 아직 연구 프로젝트라는 점은 감안해야 함

  • Tailscale 서비스는 정말 즐기고 고맙게 쓰지만, 이 글은 와닿지 않았음
    영감을 주는 CEO의 결집 연설도 좋아하고, 컴퓨팅에 개발자 마찰과 복잡성이 터무니없이 많다는 데 동의하지만, Tailscale도 자체 마찰이 있고 큰 그림의 문제를 전혀 해결하는 방향으로 가고 있지 않음
    몇 주 전 아버지를 내 tailnet에 초대해서 원격 데스크톱으로 컴퓨터 문제를 고치려 했음. 아버지는 초대를 수락했고 TS 도메인 웹 인터페이스에는 기기가 보였지만, ping이 안 됐음
    이제 아버지는 Tailscale을 싫어하고, 내가 멋지다고 말해둔 덕분에 내 신뢰도도 떨어졌음. 아버지 눈에는 시간을 낭비했고 “제대로 작동하지 않는” 물건이었음

    • 아버지가 Windows를 쓰는가? Windows 방화벽은 ICMP 트래픽을 막는 것으로 알려져 있고, 이건 Tailscale이나 다른 피어 투 피어 VPN이 해결할 수 없는 문제임
    • 같은 문제인지는 모르겠지만, Gmail 주소만 쓰는 가족 환경에서 동작 방식을 오해해서 문제가 생긴 적이 있음
      꽤 직관에 어긋남. 조직 기능은 그런 용도가 아니고, 대신 각자가 자기 tailnet을 만들고 그것들을 연결해야 함
      참고: https://github.com/tailscale/tailscale/issues/10731
    • 아마 새 네트워크 인터페이스가 생겼고, 아버지나 Windows가 그것을 ping이나 RDP에 응답해도 되는 신뢰된 홈/개인 연결로 보지 않았을 가능성이 큼
      이런 용도라면 TeamViewer, AnyDesk 같은 도구가 맞음
    • ACL 문제일 수도 있나?

  • 글쓴이가 문제를 잘못 진단했고, 제안한 해법은 중앙화를 제거하는 대신 숨길 뿐이라고 봄
    AWS가 비싼 이유는 IPv4나 데이터센터 때문이 아니라, 주로 소프트웨어·관리형 서비스와 서버를 빠르게 추가할 수 있는 능력 때문임
    “진지한 회사”가 AWS나 비슷한 회사에 돈을 내기 싫다면 랙을 빌리고 자체 서버를 코로케이션하는 건 가능하고 많은 회사가 실제로 함
    인증서가 중앙화를 만들었다는 데 동의하지 않음. 인증서는 가진 자와 못 가진 자를 나누는 것도 아니고 메인프레임 보유 여부와 비교할 것도 아님
    HTTPS가 사실상 필수가 됐다고 해서 사람들이 자기 도메인이나 서브도메인을 갖게 된 게 아니라, 편의 때문에 이미 그렇게 된 것임
    또 다른 중앙화 지점으로 DNS가 나오지만, Tailscale은 DNS를 전혀 피하지 않음. MagicDNS도 ICANN 루트에 의존하고, Tailscale 제어 평면도 마찬가지임
    무료 서브도메인이 필요할 뿐이라면 제공하는 곳은 많음
    CGNAT 뒤에 있다면 tailnet도 딱히 덜 중앙화된 게 아님. 트래픽이 DERP 서버를 지나야 하기 때문임
    트래픽 규모가 Gbps가 아니라 Tbps가 되면 Tailscale이 이를 무료로 계속 제공할 수 있을지 의심스러움
    Tailscale과 유사한 해법이 NAT 뒤 컴퓨터에 접근하는 마지막 남은 경우에는 도움이 된다는 데 동의하고, 수천만 사용자까지 갈 수도 있다고 봄
    하지만 이것만으로 새 인터넷이라는 칭호를 주장하기엔 부족함

    • 이건 대부분의 애플리케이션이 서버를 빠르게 늘려야 할 정도의 규모를 필요로 한다는 잘못된 가정 위에 있음
      글에서도 그 가정이 틀렸다고 짚고 있음

  • 이런 아이디어는 당연히 새롭지 않음
    IPv6는 모두에게 종단 간 연결성을 주기 위한 것이었고, 원래 IPsec은 IPv6의 필수 구성 요소로서 각 인터넷 호스트에 암호학적 정체성을 부여하려던 것이었음

    • 글에서 IPv6를 전혀 언급하지 않은 게 궁금했음. Tailscale도 IPv6를 지원하기 때문임
      IPv6와 WireGuard를 함께 쓰면 프라이버시, 보안, 성능을 얻을 수 있음. 단점은 설정 복잡성임
      Tailscale은 거인들의 어깨 위에 서 있음. IPv4, WireGuard, Samy Kamkar의 NAT 펀칭, OpenSSH 등 더 많을 것임
      장점은 이들을 조합했고 관리 인터페이스가 대체로 쉽다는 점임
      다만 인증 기관에 해당하는 말은 Tailscale에도 적용됨. 둘 다 자유 오픈소스 소프트웨어를 이용해 결국 독점 서비스를 제공함
      그래도 거의 모든 것이 자유 오픈소스 위에 있고 Headscale도 있으며 Tailscale이 이를 괜찮게 본다는 점 때문에 큰 문제는 아님
      단점이긴 하지만 주요 단점은 아니고, 실질적으로 공급자 종속도 거의 없음. 사업과 지원 관점에서는 오히려 장점일 수도 있음

  • 글의 전제는 마지막 문단까지는 정말 좋았는데, 거기서 다시 읽게 됐음
    Tailscale이 인터넷을 다시 쉽게 만들어주는 건 맞지만, 여전히 임대인에게 의존해야 함
    인터넷에서는 그럴 필요가 없었고 지금도 꼭 필요하지 않음. 많은 것이 중앙화됐더라도, 오늘날에도 링크 하나만 있으면 전 세계 어떤 서버에도 접속할 수 있음

    • “임대인에게 의존해야 한다”는 점은 아주 좋은 지적임
      반론은 다른 곳에서도 언급한 Headscale 자가 호스팅임: https://github.com/juanfont/headscale
      몇 가지 설정만 바꾸면 기본 Tailscale 클라이언트와 함께 동작하고, 나도 직접 쓰고 있음
답변달기