1 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Rayfish là bản phát hành đầu tiên tạo VPN mesh P2P giữa các thiết bị của người dùng mà không cần máy chủ hay tài khoản, duy trì trạng thái mạng bằng các bản ghi đã ký do các thành viên lưu giữ
  • Loại bỏ control plane tập trung để mạng tiếp tục hoạt động sau khi tham gia, ngay cả khi không có tài khoản công ty, nhà vận hành hay máy chủ điều phối phải luôn bật
  • Iroh v1 là nền tảng giúp phát hành, đảm nhiệm kết nối QUIC được mã hóa, vượt NAT, hole punching và relay fallback khi không có đường đi trực tiếp
  • Hiện hỗ trợ tham gia đồng thời nhiều mạng cô lập, tham gia bằng mã mời hoặc phê duyệt, Magic DNS, tường lửa theo từng thiết bị, provisioning fleet theo kiểu khai báo, kết nối 1:1 và truyền tệp
  • Có thể kém Tailscale về độ trưởng thành và thông lượng, và cũng không phải SDK, nhưng tập trung vào trường hợp cần mạng riêng không có bên trung tâm

Vấn đề mà Rayfish muốn giải quyết

  • Rayfish là một VPN mesh P2P tạo mạng riêng giữa các thiết bị
  • Hoạt động mà không cần máy chủ trung gian hay công ty phải được tin cậy để vận hành liên tục
  • Người dùng nhận khóa, các thiết bị dùng khóa đó để tìm thấy nhau, và mạng được tạo ra thuộc về những người ở trong đó

Thiết kế loại bỏ control plane tập trung

  • Nhiều VPN hiện đại phụ thuộc vào control plane do một công ty vận hành
    • Công ty quyết định thành viên mạng và chính sách
    • Công ty vẫn nằm trong luồng ngay cả khi các thiết bị đang giao tiếp
    • Nếu công ty ngừng hoạt động, tăng giá hoặc cắt quan hệ với khách hàng, sẽ rất khó để mạng riêng vẫn hoàn toàn thuộc sở hữu người dùng
  • Rayfish loại bỏ tài khoản và nhà vận hành trung tâm
    • Trạng thái mạng là bản ghi đã ký mà bất kỳ thành viên nào cũng có thể truyền cho thành viên khác
    • Ngay cả khi đội ngũ tạo ra Rayfish biến mất, các mạng hiện có vẫn tiếp tục hoạt động

Cách một thiết bị xử lý nhiều mạng

  • Rayfish bắt đầu từ giả định rằng người dùng không chỉ dùng một mạng phẳng duy nhất
  • Một thiết bị có thể đồng thời thuộc mạng dành cho bạn bè, dự án phụ và công việc
  • Việc triển khai hoạt động sau một tiến trình và một giao diện ảo duy nhất
  • Mỗi mạng được cô lập với nhau, và người dùng trở thành thành viên chính thức của tất cả mạng mình đã tham gia

Bản phát hành được Iroh v1 mở đường

  • Rayfish giao phần khó của tầng vận chuyển cho Iroh
    • Kết nối QUIC được mã hóa giữa các peer
    • Vượt NAT
    • Hole punching
    • Relay fallback khi không có đường đi trực tiếp
  • Iroh v1 mang lại độ ổn định để tầng vận chuyển không rung lắc trong quá trình xây dựng, giúp bản phát hành này thành hiện thực
  • Thử thách tiếp theo là tinh chỉnh các công cụ ban đầu thành công cụ có thể chạy trong môi trường production mà không gây áp lực

Spin-off từ Field Technologies

  • Rayfish là dự án tách ra từ công ty giao dịch tần suất cao Field Technologies
  • Nền tảng của nó đến từ kinh nghiệm nội bộ nhiều lần xây dựng khám phá thiết bị, đồng thuận trạng thái chia sẻ và giao tiếp nhanh, riêng tư khi xử lý các hệ thống phân tán
  • Hạ tầng nội bộ này chủ yếu được tạo ra để không phải phụ thuộc vào control plane của công ty khác
  • Rayfish là ý tưởng kéo dài hơn 4 năm, nhưng vì đặc tính không có nhà vận hành trung tâm nên không có điểm thu phí rõ ràng, khiến việc sản phẩm hóa bị chậm lại
  • Trong tương lai có thể mở rộng sang các bài toán doanh nghiệp như quản lý fleet hay audit, nhưng hiện các tính năng đó vẫn chưa tồn tại

Các tính năng hiện có

  • Cấu trúc point-to-point

    • Rayfish là cấu trúc point-to-point, không phải hub-and-spoke
    • Mọi thành viên kết nối trực tiếp với mọi thành viên khác
    • Membership không phải giá trị hỏi từ máy chủ mà là bản ghi đã ký do từng thành viên mang theo
    • Điều phối viên tạo mạng chỉ cần thiết khi chấp nhận thành viên mới; sau khi tham gia xong, mạng vận hành mà không cần bất kỳ thực thể trung tâm nào
  • Mạng đóng và cách tham gia

    • Mạng mặc định ở trạng thái đóng
    • Điều phối viên có thể thêm thành viên mới theo hai cách
      • Mã mời dùng một lần
      • Phê duyệt theo thời gian thực đối với yêu cầu tham gia
    • Nếu cần mạng công khai, có thể mở cổng bằng ray create --open, khi đó chỉ cần room id là có thể tham gia
    • Các thành viên đã tham gia có thể được truy cập bằng IP ổn định và tên Magic DNS dễ nhớ
    • Hostname mặc định có thể đặt như ray up --hostname dario, và có thể ghi đè --hostname theo từng mạng
    ray up --hostname dario
    ray create --name prod
    ray invite prod --hostname web
    ray join <code>
    
  • Tường lửa theo từng thiết bị

    • Mỗi thiết bị có tường lửa riêng và tự quyết định sẽ nhận gì từ ai
    • Điều phối viên có thể công bố các quy tắc tường lửa được khuyến nghị theo từng mạng
    • Mỗi host có thể chấp nhận quy tắc hoặc chọn cài đặt tự động
    • Đây là cách cung cấp mặc định dùng chung mà không cần máy chủ chính sách trung tâm buộc tất cả phải tuân theo
  • Provisioning fleet

    • Với nhiều thiết bị, có thể định nghĩa và áp dụng mạng cùng quy tắc tường lửa bằng tệp khai báo
    • Đặc tả là map networks:, dưới mỗi mạng ghi các peer và cổng được phép theo từng host
    networks:
      prod:
        web:
          allows:
            "*": "tcp:443"
        db:
          allows:
            web: "tcp:5432"
      game:
        "*":
          allows:
            "*": "tcp:6969"
    
    ray apply deploy.yaml --dry-run
    ray apply deploy.yaml --invite-missing
    
    • Với fleet, có thể tạo khóa tái sử dụng thay vì cấp mã cho từng máy
    ray invite prod --reusable
    ray join <key> --hostname web01 --auto-accept-firewall
    
    • Khi thu hồi khóa, chỉ chặn lượt tham gia mới chứ không ảnh hưởng các máy chủ đã vào trước đó
    • ray apply hoạt động idempotent, để tệp đặc tả trở thành trạng thái chuẩn của fleet
  • Kết nối 1:1 và truyền tệp

    • Khi không cần tạo hẳn một mạng, có thể dùng ray connect để tạo kết nối 1:1 dựa trên contact ID
    ray contact id
    ray connect <their-contact-id>
    ray connections approve <id>
    
    • Sau khi được phê duyệt, một mạng riêng 2 peer sẽ được tạo tự động
    • Magic DNS, tường lửa và các tính năng mesh hoạt động tương tự, đồng thời được hiển thị là [direct] trong ray status
    • Contact ID có thể được xoay vòng, và các kết nối đã tạo vẫn tiếp tục hoạt động
    • Vì giữa các thành viên đã có sẵn đường truyền được xác thực và mã hóa, có thể gửi tệp mà không cần dịch vụ riêng
    ray send ./build.tar.gz web01
    ray files accept 1
    

Khác gì so với Tailscale

  • Tailscale và Rayfish đều cung cấp IP ổn định, Magic DNS, vượt NAT và data plane P2P
  • Khác biệt lớn nhất là vị trí control
    • Tailscale dùng control plane như máy chủ điều phối Tailscale hoặc Headscale tự host
    • Rayfish không có control plane trung tâm, mà để trạng thái mạng dưới dạng bản ghi đã ký được truyền P2P
  • Data plane cũng khác
    • Tailscale dùng WireGuard chạy trong kernel
    • Rayfish dùng datagram Iroh/QUIC trong user space
  • Tốc độ thường nghiêng về Tailscale
    • WireGuard chạy trong kernel nên trên các liên kết nhanh, chênh lệch sẽ rõ khi truyền dữ liệu lớn
    • Rayfish đánh đổi một phần thông lượng thô để lấy cấu trúc không có bên trung tâm
  • Rayfish dùng cặp khóa trên đĩa làm danh tính thay vì tài khoản hay SSO
  • Rayfish còn non trẻ và tập trung vào bộ tính năng tối thiểu, trong khi Tailscale đã trưởng thành và có phạm vi tính năng rộng hơn

Khác gì so với Yggdrasil

  • Yggdrasil cung cấp mạng IPv6 mã hóa đầu cuối không có thẩm quyền trung tâm
  • Khác biệt nằm ở chặng cuối mà người dùng phải trực tiếp xử lý
    • Yggdrasil cung cấp một mạng toàn cục duy nhất cùng địa chỉ IPv6
    • Rayfish cung cấp các mạng riêng biệt do người dùng tạo và thêm thành viên
  • Rayfish bao gồm các tính năng tiện lợi như mã mời, tên DNS dễ nhớ, tường lửa theo từng mạng và prompt phê duyệt tham gia
  • Yggdrasil phù hợp với kỹ sư am hiểu mạng, còn Rayfish nhắm cả tới người dùng muốn dễ dàng tạo mạng riêng cho một nhóm nhỏ

Có thể làm gì và không thể làm gì

  • Rayfish là công cụ hoàn chỉnh, không phải thư viện
  • Không thể nhúng vào ứng dụng như một SDK
  • Phù hợp cho các trường hợp các thiết bị có cài Rayfish cần giao tiếp riêng tư với nhau
    • Máy chủ game P2P để bạn bè kết nối bằng tên
    • API nội bộ không chạm tới Internet công cộng
    • Đích sao lưu
    • Ứng dụng chat hoặc gọi giữa các thành viên trong mạng
    • Cơ sở dữ liệu dùng chung giữa hai đội không nên nhìn thấy nhau
  • Ứng dụng có thể truy cập peer qua name.network.ray
  • Người ngoài không cài Rayfish không thể truy cập mạng, và không có gateway cho người ngoài

Ví dụ cấu hình thực tế

  • Khi hai bộ phận chia sẻ cơ sở dữ liệu

    • Nếu để paymentsanalytics là hai mạng riêng, hai bộ phận sẽ không nhìn thấy nhau
    • Chỉ máy cơ sở dữ liệu tham gia cả hai mạng
    • Thiết lập tường lửa khuyến nghị để chỉ mở các cổng cần thiết trên từng mạng
    networks:
      payments:
        db:
          allows:
            "*": "tcp:8123,tcp:9000"
      analytics:
        db:
          allows:
            "*": "tcp:8123,tcp:9000"
    
    • Mỗi đội truy cập qua db.payments.ray hoặc db.analytics.ray
    • Hai mạng không biết đến sự tồn tại của nhau, và việc tách mạng cùng host dùng chung sẽ tạo ra kiểm soát truy cập mà không cần audit ACL tập trung
  • Máy chủ Minecraft cho bạn bè

    • Tạo một mạng đóng rồi mời bạn bè, họ có thể kết nối bằng tên mà không cần địa chỉ IP, port forwarding hay dynamic DNS
    ray create --name mc
    ray invite mc
    
    • Client kết nối tới mc-host.mc.ray:25565
  • Nhóm đóng nơi mọi người đều mở cổng

    • Nếu mọi thành viên đều phải mở TCP 6969, quản trị viên có thể đề xuất quy tắc một lần
    ray firewall suggest mc --subject '*' --allow '*:tcp:6969'
    
    • Mỗi thành viên có thể xem xét rồi chấp nhận hoặc từ chối quy tắc được đề xuất
    ray firewall pending mc
    ray firewall accept mc
    
    • Đề xuất tường lửa không phải quy tắc bắt buộc, và thành viên có thể từ chối nếu không muốn

Bảo mật và xử lý địa chỉ

  • Địa chỉ IP không do máy chủ cấp phát mà được suy ra từ danh tính mật mã của từng peer
  • Va chạm địa chỉ gần như không xảy ra, nhưng nếu có, điều phối viên sẽ đặt peer thứ hai vào slot trống tiếp theo
  • Tất cả peer sẽ hội tụ một cách tất định đến cùng một cách gán địa chỉ mà không cần allocator trung tâm
  • Rayfish xây dựng bảo mật bằng hai yếu tố thay cho ACL trung tâm
    • Phân tách để chỉ các peer cùng chia sẻ một mạng mới có thể giao tiếp
    • Tường lửa theo từng mạng trên từng thiết bị
  • Nếu muốn cô lập proddev, chỉ cần tạo thành hai mạng
  • Các host thuộc nhiều mạng sẽ mang theo tường lửa riêng của mình trên từng mạng

Có cần mở máy chủ và cổng hay không

  • Không cần tự host máy chủ điều khiển riêng
  • Điều phối viên tạo mạng có thể offline sau khi mọi thành viên đã tham gia xong
  • Iroh xử lý vượt NAT và hole punching, và nếu không thể đi trực tiếp thì dùng relay fallback đã mã hóa
  • Nếu bạn kiểm soát router và muốn một số máy có đường đi trực tiếp được đảm bảo, có thể forward cổng UDP cố định của Rayfish, nhưng đó chỉ là tùy chọn

Kế hoạch sắp tới và khi nào không phù hợp

  • Hiện được cung cấp dưới dạng công cụ dòng lệnh trên desktop và server
  • Bước tiếp theo là mở rộng sang các thiết bị người dùng thực sự mang theo
    • Client Android
    • Client iOS
    • Ứng dụng desktop đúng nghĩa
  • Đồng thời, nhóm cũng đang củng cố các tính năng hiện có để có thể dùng trong môi trường production mà không gây trở ngại
  • Nếu bạn đã dùng tốt Tailscale, VPN công ty hoặc mesh WireGuard tự cấu hình, thì lý do chuyển sang Rayfish là không nhiều
  • Rayfish còn mới hơn, ít tính năng hơn, và nhiều việc các công cụ hiện tại làm mượt mà hơn
  • Điều Rayfish loại bỏ là một thứ duy nhất
    • Tài khoản
    • Một công ty có thể ngắt mạng của bạn
    • Máy chủ điều khiển phải luôn bật
    • Cơ sở dữ liệu chính sách do người khác vận hành

Cách bắt đầu

  • Cài đặt bắt đầu bằng một lệnh một dòng
curl -fsSL https://rayfish.xyz/install.sh | sh
  • Quy trình tạo mạng đầu tiên và mời thành viên được hướng dẫn tiếp trong tài liệu

1 bình luận

 
Các ý kiến trên Lobste.rs
  • Mình rất thích việc Rayfish ngay từ đầu đã giả định sẽ xử lý nhiều hơn một mạng cùng lúc
    Trong Tailscale, điều này có vẻ không phải là ưu tiên, nên đây có thể là một lợi thế khá lớn
    Đoạn nói rằng nó được tách ra từ một công ty giao dịch tần suất cao thì khá bất ngờ, còn việc nói Tailscale thắng về tốc độ vì “data plane của WireGuard chạy trong kernel” là sai. Tailscale không dùng kernel WireGuard, vậy mà mọi người vẫn cứ hiểu lầm như thế
    Tác giả nói “ý tưởng, sản phẩm, câu chữ là của tôi”, nhưng việc trong kho có CLAUDE.md thì hơi đáng tiếc. Tuy vậy, nhìn phần tóm tắt đóng góp thì clod có 1.017++ / 383-- dòng, còn tác giả có 104.786++ / 47.064-- dòng, nên có vẻ phần lớn code không phải được AI làm qua loa. Dù vậy, cũng không rõ liệu có lý do gì để để lại dấu vết như vậy trong repo chỉ vì 1/100 khối lượng công việc hay không

    • Dù có được AI hỗ trợ thì mình cũng không quá bận tâm. Điều quan trọng là khả năng dùng thực tế, và nếu đây thật sự là một lựa chọn thay thế Tailscale phi tập trung đúng nghĩa thì sẽ rất tuyệt
      Cho đến giờ mình chủ yếu thấy Iroh được dùng theo những cách dễ thương nhưng không mấy hữu ích, và đây có thể chính là ứng dụng dành cho nó
    • Vì dựa trên Iroh nên có QUIC, do đó cuối cùng ta có thể dùng mã hóa kháng lượng tử trong VPN dạng mesh
      Điều này trong Tailscale cũng có vẻ không phải là ưu tiên
  • Bản thân sản phẩm trông thật sự rất hay, và thứ duy nhất ngăn mình thay thế mesh Tailscale của mình là chưa có client Android
    Tuy nhiên bài viết đọc lên có cảm giác ít nhất một phần được AI viết, nên hơi khó chịu

  • Phần so sánh với Yggdrasil còn sơ sài và cũng sai về mặt sự thật. Testnet Yggdrasil đúng là được vận hành như một mạng toàn cầu, nhưng đó chỉ là hệ quả tiện lợi từ cấu trúc topo của Yggdrasil mà thôi
    Nó có thể động chấp nhận bất kỳ kết nối nào giữa hai tập khóa tách biệt, và khác biệt giữa hai mạng Yggdrasil riêng rẽ với một mạng lớn chỉ là chúng có đang trao đổi thông điệp với nhau hay không. Bất kỳ ai cũng có thể tạo mạng Yggdrasil riêng tư
    Khóa thì không thể đoán được về mặt mật mã học, nhưng mình không cho rằng điều đó đồng nghĩa với dịch vụ ẩn. Tên miền là tùy ý, nhưng nhiều người cũng trỏ DNS toàn cầu tới không gian địa chỉ Yggdrasil
    Nếu nhìn theo góc độ “tôi chỉ muốn một mạng cho server game với ba người bạn, còn Yggdrasil thì có quá nhiều thứ phải lắp ghép”, thì việc không so sánh với tinc — gần như là tiêu chuẩn cho trường hợp ba người bạn và một server game — lại càng đáng ngạc nhiên

    • Bản thân ID công khai có thể không đoán được, nhưng ID công khai có thể xuất hiện trong log được chia sẻ hoặc báo cáo lỗi. Vì vậy, mạng riêng tư có prompt phê duyệt sẽ xử lý vấn đề đó
      Ý ở đây là Yggdrasil không có khái niệm tạo một mạng riêng tư tách biệt rồi chấp nhận người tham gia, cũng không có các tính năng tiện lợi như mã mời, tên DNS thân thiện, tường lửa theo từng mạng, hay prompt phê duyệt khi ai đó muốn tham gia. Nếu bạn là kỹ sư mạng thì có thể đó không phải vấn đề
      Một điểm khác bị bỏ sót trong phần so sánh với Yggdrasil là Rayfish tận dụng NAT hole punching của Iroh, nên hai peer vẫn có thể giao tiếp ngay cả khi không bên nào có thể truy cập công khai