Rayfish: P2P VPN ที่ใช้ Iroh

• Rayfish เป็นรีลีสแรกที่สร้าง P2P mesh VPN ระหว่างอุปกรณ์ของผู้ใช้โดยไม่ต้องมีเซิร์ฟเวอร์หรือบัญชี และคงสถานะเครือข่ายไว้เป็นบันทึกที่ลงนามซึ่งสมาชิกเก็บรักษาไว้
• การตัด control plane ส่วนกลางออก ทำให้เครือข่ายยังทำงานต่อได้หลังเข้าร่วมแล้ว โดยไม่ต้องมีบัญชีบริษัท ผู้ปฏิบัติการ หรือ เซิร์ฟเวอร์ประสานงาน ที่ต้องเปิดอยู่ตลอด
• Iroh v1 รับหน้าที่เป็นฐานสำหรับการเปิดตัว โดยดูแล การเชื่อมต่อ QUIC ที่เข้ารหัส การข้าม NAT, hole punching และ fallback ผ่าน relay เมื่อไม่มีเส้นทางตรง
• ปัจจุบันรองรับการเข้าร่วมเครือข่ายแยกหลายเครือข่ายพร้อมกัน, invite code และการเข้าร่วมแบบอนุมัติ, Magic DNS, firewall รายอุปกรณ์, การ provisioning fleet แบบ declarative, การเชื่อมต่อ 1:1 และการส่งไฟล์
• อาจด้อยกว่า Tailscale ในด้านความสุกงอมและ throughput และไม่ใช่ SDK แต่โฟกัสกับกรณีที่ต้องการ เครือข่ายส่วนตัวที่ไม่มีบุคคลกลางส่วนกลาง

---

ปัญหาที่ Rayfish ต้องการแก้

• Rayfish คือ P2P mesh VPN ที่สร้างเครือข่ายส่วนตัวระหว่างอุปกรณ์
• ทำงานได้โดยไม่ต้องมีเซิร์ฟเวอร์กลางหรือบริษัทที่ต้องเชื่อว่าจะดำเนินงานต่อไป
• ผู้ใช้ได้รับคีย์ จากนั้นอุปกรณ์จะใช้คีย์นั้นค้นหากัน และเครือข่ายที่สร้างขึ้นจะเป็นของคนในเครือข่ายนั้น

การออกแบบที่ตัด control plane ส่วนกลางออก

• VPN สมัยใหม่จำนวนมากพึ่งพา control plane ที่บริษัทเป็นผู้ดำเนินการ
  • บริษัทเป็นผู้ตัดสินสมาชิกและนโยบายของเครือข่าย
  • บริษัทจะยังอยู่ในเส้นทางการทำงานแม้อุปกรณ์กำลังสื่อสารกัน
  • หากบริษัทหยุดให้บริการ ขึ้นราคา หรือตัดความสัมพันธ์กับลูกค้า เครือข่ายส่วนตัวก็ยากที่จะยังเป็นของผู้ใช้อย่างสมบูรณ์
• Rayfish ตัด บัญชี และผู้ดำเนินการส่วนกลางออก
  • สถานะเครือข่ายเป็น บันทึกที่ลงนาม ซึ่งสมาชิกคนใดก็ส่งต่อให้สมาชิกคนอื่นได้
  • แม้ผู้สร้าง Rayfish จะหายไป เครือข่ายที่มีอยู่เดิมก็ยังทำงานต่อได้

วิธีจัดการหลายเครือข่ายบนอุปกรณ์เดียว

• Rayfish เริ่มจากสมมติฐานว่าผู้ใช้ไม่ได้ใช้เพียงเครือข่ายแบบแบนเครือข่ายเดียว
• อุปกรณ์หนึ่งเครื่องสามารถอยู่ในเครือข่ายสำหรับเพื่อน, side project และงาน พร้อมกันได้
• การใช้งานทำงานอยู่หลัง process เดียวและ virtual interface เดียว
• แต่ละเครือข่ายถูก แยกจากกัน และผู้ใช้จะเป็นสมาชิกเต็มตัวของทุกเครือข่ายที่เข้าร่วม

สิ่งที่ Iroh v1 ทำให้การเปิดตัวเป็นไปได้

• Rayfish มอบส่วนที่ยากของ transport layer ให้ Iroh จัดการ
  • การเชื่อมต่อ QUIC ที่เข้ารหัสระหว่าง peer
  • การข้าม NAT
  • hole punching
  • fallback ผ่าน relay เมื่อไม่มีเส้นทางตรง
• Iroh v1 มอบความเสถียรที่ทำให้ transport layer ไม่สั่นคลอนระหว่างการ build จึงทำให้รีลีสนี้เกิดขึ้นได้
• งานถัดไปคือขัดเกลาเครื่องมือเริ่มต้นให้เป็นเครื่องมือที่รันใน production ได้อย่างสบายใจ

สปินออฟจาก Field Technologies

• Rayfish เป็นโปรเจกต์ที่แยกออกมาจาก Field Technologies บริษัทซื้อขายความถี่สูง
• พื้นฐานมาจากประสบการณ์ภายในในการจัดการระบบกระจายตัว และสร้างการค้นหาอุปกรณ์ การตกลงสถานะร่วมกัน และการสื่อสารที่รวดเร็วและเป็นส่วนตัวมาหลายครั้ง
• โครงสร้างพื้นฐานภายในลักษณะนี้ส่วนใหญ่ถูกสร้างขึ้นเพื่อไม่ต้องพึ่งพา control plane ของบริษัทอื่น
• Rayfish เป็นไอเดียที่ดำเนินต่อเนื่องมากว่า 4 ปี แต่เพราะคุณสมบัติที่ไม่มีผู้ดำเนินการส่วนกลาง ทำให้ไม่มีจุดคิดค่าบริการที่ชัดเจน การทำเป็นผลิตภัณฑ์จึงล่าช้า
• ในอนาคตอาจขยายไปสู่ปัญหาสำหรับองค์กร เช่น fleet management หรือ audit แต่ฟีเจอร์เหล่านั้นยังไม่มีอยู่ในตอนนี้

ฟีเจอร์ที่มีในปัจจุบัน

• โครงสร้างแบบ point-to-point

  • Rayfish ไม่ใช่โครงสร้างแบบ hub-and-spoke แต่เป็น point-to-point
  • สมาชิกทุกคนเชื่อมต่อกับสมาชิกคนอื่นทั้งหมดโดยตรง
  • membership ไม่ใช่ค่าที่ต้องถามจากเซิร์ฟเวอร์ แต่เป็นบันทึกที่ลงนามซึ่งสมาชิกแต่ละคนพกติดตัว
  • ผู้ประสานงานที่สร้างเครือข่ายจำเป็นเฉพาะตอนรับสมาชิกใหม่ และหลังจากเข้าร่วมแล้วเครือข่ายจะทำงานได้โดยไม่มีใครอยู่ส่วนกลาง

• เครือข่ายแบบปิดและวิธีเข้าร่วม

  • โดยพื้นฐาน เครือข่ายอยู่ใน สถานะปิด
  • ผู้ประสานงานสามารถรับสมาชิกใหม่ได้สองวิธี
    • invite code ใช้ครั้งเดียว
    • การอนุมัติแบบ realtime ต่อคำขอเข้าร่วม
  • หากต้องการเครือข่ายสาธารณะ สามารถเปิด gate ด้วย ray create --open และในกรณีนี้เข้าร่วมได้ด้วย room id เท่านั้น
  • สมาชิกที่เข้าร่วมแล้วสามารถเข้าถึงได้ด้วย IP ที่เสถียรและชื่อ Magic DNS ที่คุ้นเคย
  • ตั้ง hostname เริ่มต้นได้ เช่น ray up --hostname dario และ override --hostname แยกตามเครือข่ายได้

  ray up --hostname dario
  ray create --name prod
  ray invite prod --hostname web
  ray join <code>
  

• Firewall รายอุปกรณ์

  • อุปกรณ์แต่ละเครื่องมี firewall ของตัวเอง และตัดสินใจเองว่าจะรับอะไรจากใคร
  • ผู้ประสานงานสามารถเผยแพร่กฎ firewall ที่แนะนำสำหรับแต่ละเครือข่ายได้
  • host แต่ละตัวสามารถยอมรับกฎหรือเลือกติดตั้งอัตโนมัติได้
  • เป็นวิธีให้ ค่าเริ่มต้นร่วมกัน โดยไม่มีเซิร์ฟเวอร์นโยบายส่วนกลางที่ทุกคนต้องทำตามเสมอ

• Fleet provisioning

  • อุปกรณ์หลายเครื่องสามารถนิยามและนำเครือข่ายกับกฎ firewall ไปใช้ผ่านไฟล์แบบ declarative ได้
  • specification เป็น map networks: และใต้แต่ละเครือข่ายให้เขียน peer และ port ที่อนุญาตเป็นราย 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
  

  • สำหรับ fleet สามารถสร้าง คีย์ใช้ซ้ำได้ โดยไม่ต้องออก code ให้แต่ละกล่อง

  ray invite prod --reusable
  ray join <key> --hostname web01 --auto-accept-firewall
  

  • เมื่อเพิกถอนคีย์ จะป้องกันเฉพาะการเข้าร่วมใหม่ และไม่รบกวนเซิร์ฟเวอร์ที่เข้ามาแล้ว
  • ray apply ทำงานแบบ idempotent ทำให้ไฟล์ specification ยังคงเป็นสถานะอ้างอิงของ fleet

• การเชื่อมต่อ 1:1 และการส่งไฟล์

  • เมื่อไม่จำเป็นต้องสร้างเครือข่ายแยก สามารถใช้ ray connect สร้างการเชื่อมต่อ 1:1 จาก contact ID ได้

  ray contact id
  ray connect <their-contact-id>
  ray connections approve <id>
  

  • เมื่ออนุมัติแล้ว เครือข่ายส่วนตัวแบบ 2 peer จะถูกสร้างขึ้นโดยอัตโนมัติ
  • Magic DNS, firewall และฟีเจอร์ mesh ทำงานเหมือนกัน และใน ray status จะแสดงเป็น [direct]
  • contact ID สามารถหมุนเวียนได้ และการเชื่อมต่อที่สร้างไว้แล้วจะยังทำงานต่อ
  • เนื่องจากมีเส้นทางที่ยืนยันตัวตนและเข้ารหัสระหว่างสมาชิกอยู่แล้ว จึงส่งไฟล์ได้โดยไม่ต้องมีบริการแยกต่างหาก

  ray send ./build.tar.gz web01
  ray files accept 1
  

ความแตกต่างจาก Tailscale

• ทั้ง Tailscale และ Rayfish ต่างให้ IP ที่เสถียร, Magic DNS, การข้าม NAT และ data plane แบบ P2P
• ความแตกต่างใหญ่ที่สุดคือ ตำแหน่งของการควบคุม
  • Tailscale ใช้ control plane เช่น เซิร์ฟเวอร์ประสานงานของ Tailscale หรือ Headscale แบบ self-hosted
  • Rayfish ไม่มี control plane ส่วนกลาง และเก็บสถานะเครือข่ายเป็นบันทึกที่ลงนามซึ่งส่งต่อแบบ P2P
• data plane ก็แตกต่างกัน
  • Tailscale ใช้ WireGuard ที่ทำงานใน kernel
  • Rayfish ใช้ Iroh/QUIC datagram ใน user space
• โดยทั่วไป Tailscale ได้เปรียบด้านความเร็ว
  • WireGuard ทำงานใน kernel จึงอาจเห็นความต่างชัดเจนเมื่อส่งข้อมูลปริมาณมากบนลิงก์ความเร็วสูง
  • Rayfish เป็นการแลก throughput ดิบเล็กน้อยกับโครงสร้างที่ไม่มีบุคคลกลางส่วนกลาง
• Rayfish ใช้ คู่คีย์ บนดิสก์เป็นตัวตน ไม่ใช่บัญชีหรือ SSO
• Rayfish ยังใหม่และเน้นฟีเจอร์ขั้นต่ำ ส่วน Tailscale สุกงอมและมีขอบเขตฟีเจอร์กว้างกว่า

ความแตกต่างจาก Yggdrasil

• Yggdrasil ให้เครือข่าย IPv6 ที่เข้ารหัสแบบ end-to-end และไม่มีอำนาจส่วนกลาง
• ความต่างอยู่ที่ขั้นสุดท้ายที่ผู้ใช้ต้องจัดการเอง
  • Yggdrasil ให้เครือข่าย global เดียวและที่อยู่ IPv6
  • Rayfish ให้เครือข่ายส่วนตัวแยกต่างหากที่ผู้ใช้สร้างและรับสมาชิกเข้าเอง
• Rayfish รวมฟีเจอร์อำนวยความสะดวก เช่น invite code, ชื่อ DNS ที่คุ้นเคย, firewall รายเครือข่าย และ prompt อนุมัติการเข้าร่วม
• Yggdrasil เหมาะกับวิศวกรที่มีความรู้ด้านเครือข่าย ส่วน Rayfish มุ่งถึงผู้ใช้ที่ต้องการสร้างเครือข่ายส่วนตัวสำหรับไม่กี่คนได้ง่าย ๆ ด้วย

สิ่งที่สร้างได้และสร้างไม่ได้

• Rayfish ไม่ใช่ไลบรารี แต่เป็น เครื่องมือสำเร็จรูป
• ไม่สามารถ embed เป็น SDK ในแอปพลิเคชันได้
• เหมาะกับกรณีที่อุปกรณ์ที่ติดตั้ง Rayfish ต้องสื่อสารกันแบบส่วนตัว
  • เซิร์ฟเวอร์เกม P2P ที่เพื่อน ๆ เชื่อมต่อด้วยชื่อ
  • internal API ที่ไม่แตะอินเทอร์เน็ตสาธารณะ
  • เป้าหมายสำหรับ backup
  • แอป chat หรือ call ระหว่างสมาชิกเครือข่าย
  • ฐานข้อมูลที่แชร์โดยสองทีมที่ไม่ควรมองเห็นกัน
• แอปพลิเคชันสามารถเข้าถึง peer ผ่าน name.network.ray
• คนนอกที่ไม่ได้ติดตั้ง Rayfish จะเข้าถึงเครือข่ายไม่ได้ และไม่มี gateway สำหรับคนนอก

ตัวอย่างการตั้งค่าจริง

• กรณีที่สองแผนกแชร์ฐานข้อมูล

  • หากแยก payments และ analytics เป็นคนละเครือข่าย ทั้งสองแผนกจะมองไม่เห็นกัน
  • มีเพียงกล่องฐานข้อมูลเท่านั้นที่เข้าร่วมทั้งสองเครือข่าย
  • ตั้งค่า firewall ที่แนะนำให้เปิดเฉพาะ port ที่จำเป็นในแต่ละเครือข่าย

  networks:
    payments:
      db:
        allows:
          "*": "tcp:8123,tcp:9000"
    analytics:
      db:
        allows:
          "*": "tcp:8123,tcp:9000"
  

  • แต่ละทีมเข้าถึงผ่าน db.payments.ray หรือ db.analytics.ray
  • สองเครือข่ายไม่รู้ถึงการมีอยู่ของกันและกัน และการแยกเครือข่ายกับการควบคุมการเข้าถึงผ่าน shared host ถูกจัดวางได้โดยไม่ต้องมี audit ACL ส่วนกลาง

• เซิร์ฟเวอร์ Minecraft สำหรับเพื่อน

  • สร้างเครือข่ายแบบปิดและเชิญเพื่อน ๆ จากนั้นทุกคนจะเชื่อมต่อด้วยชื่อได้โดยไม่ต้องใช้ IP address, port forwarding หรือ dynamic DNS

  ray create --name mc
  ray invite mc
  

  • client เชื่อมต่อไปยัง mc-host.mc.ray:25565

• กลุ่มปิดที่ทุกคนเปิดพอร์ต

  • หากสมาชิกทุกคนต้องเปิด TCP 6969 ผู้ดูแลสามารถเสนอ rule ได้ครั้งเดียว

  ray firewall suggest mc --subject '*' --allow '*:tcp:6969'
  

  • สมาชิกแต่ละคนตรวจสอบ rule ที่เสนอ แล้วเลือกยอมรับหรือปฏิเสธ

  ray firewall pending mc
  ray firewall accept mc
  

  • ข้อเสนอ firewall ไม่ใช่ rule บังคับ และสมาชิกสามารถปฏิเสธได้หากไม่ต้องการ

ความปลอดภัยและการจัดการที่อยู่

• IP address ไม่ได้ถูกจัดสรรโดยเซิร์ฟเวอร์ แต่ derive จาก ตัวตนเชิงเข้ารหัส ของแต่ละ peer
• โอกาส address conflict แทบไม่มี แต่หากเกิด conflict ผู้ประสานงานจะวาง peer ตัวที่สองไว้ใน slot ว่างถัดไป
• peer ทั้งหมดจะ converge ไปยังการกำหนดที่อยู่เดียวกันแบบ deterministic โดยไม่มีตัวจัดสรรส่วนกลาง
• Rayfish สร้างความปลอดภัยด้วยสองอย่างแทน ACL ส่วนกลาง
  • การแบ่งส่วน ที่ให้สื่อสารได้เฉพาะ peer ที่แชร์เครือข่ายเดียวกัน
  • firewall รายเครือข่ายของแต่ละอุปกรณ์
• หากต้องการแยก prod กับ dev ก็สร้างเป็นสองเครือข่าย
• host ที่อยู่ในหลายเครือข่ายจะมี firewall ของตัวเองในแต่ละเครือข่าย

จำเป็นต้องมีเซิร์ฟเวอร์และเปิดพอร์ตหรือไม่

• ไม่จำเป็นต้อง host control server แยกต่างหาก
• ผู้ประสานงานที่สร้างเครือข่ายสามารถ offline ได้หลังสมาชิกทุกคนเข้าร่วมแล้ว
• Iroh จัดการการข้าม NAT และ hole punching และเมื่อไม่มีเส้นทางตรงได้ก็ใช้ fallback ผ่าน relay ที่เข้ารหัส
• หากควบคุม router ได้และต้องการเส้นทางตรงที่รับประกันไปยังกล่องใดกล่องหนึ่ง สามารถ forward พอร์ต UDP แบบคงที่ของ Rayfish ได้ แต่เป็นทางเลือก

แผนต่อไปและกรณีที่ไม่เหมาะ

• ปัจจุบันให้บริการเป็นเครื่องมือ command line บน desktop และ server
• งานถัดไปคือขยายไปยังอุปกรณ์ที่ผู้ใช้พกพาจริง
  • Android client
  • iOS client
  • desktop app ที่สมบูรณ์
• พร้อมกันนั้นจะทำให้ฟีเจอร์เดิมแข็งแรงพอที่จะใช้ใน production ได้อย่างสบายใจ
• หาก Tailscale, VPN บริษัท หรือ WireGuard mesh ที่ตั้งเองทำงานได้ดีอยู่แล้ว เหตุผลที่จะเปลี่ยนมาใช้ Rayfish ยังไม่มากนัก
• Rayfish ยังใหม่กว่าและมีฟีเจอร์น้อยกว่า และเครื่องมือที่มีอยู่ก็ให้ฟีเจอร์หลายอย่างได้ลื่นไหลกว่า
• สิ่งที่ Rayfish ตัดออกมีเพียงอย่างเดียว
  • บัญชี
  • บริษัทที่สามารถหยุดเครือข่ายได้
  • control server ที่ต้องเปิดอยู่ตลอด
  • ฐานข้อมูลนโยบายที่คนอื่นดำเนินการ

วิธีเริ่มต้น

• การติดตั้งเริ่มด้วยคำสั่งบรรทัดเดียว

curl -fsSL https://rayfish.xyz/install.sh | sh

• ขั้นตอนสร้างเครือข่ายแรกและเชิญสมาชิกมีแนะนำต่อใน เอกสาร

[GN⁺]

ความคิดเห็นจาก Lobste.rs

• ชอบมากที่ Rayfish ตั้งสมมติฐานมาตั้งแต่แรกว่าจะต้องจัดการมากกว่าหนึ่งเครือข่ายพร้อมกัน
  ใน Tailscale เรื่องนี้ดูเหมือนจะ ไม่ใช่สิ่งที่ให้ความสำคัญ จึงอาจเป็นข้อได้เปรียบที่ค่อนข้างใหญ่
  ส่วนที่บอกว่าแยกตัวออกมาจากบริษัทเทรดความถี่สูงนั้นคาดไม่ถึง และคำพูดที่ว่า Tailscale ชนะด้านความเร็วเพราะ “data plane ของ WireGuard รันอยู่ในเคอร์เนล” นั้นไม่ถูกต้อง Tailscale ไม่ได้ใช้ kernel WireGuard แต่ผู้คนก็ยังเข้าใจผิดแบบนั้นอยู่เรื่อย ๆ
  แม้จะบอกว่า “ไอเดีย ผลิตภัณฑ์ และถ้อยคำเป็นของผม” แต่การที่มี CLAUDE.md อยู่ในรีโพสิตอรีก็น่าเสียดาย อย่างไรก็ตามเมื่อดูสรุปการมีส่วนร่วม clod อยู่ที่ 1,017++ / 383-- บรรทัด ส่วนผู้เขียนอยู่ที่ 104,786++ / 47,064-- บรรทัด จึงดูเหมือนว่าโค้ดส่วนใหญ่ไม่ได้ถูกทำลวก ๆ ด้วย AI ถึงอย่างนั้นก็ยังไม่แน่ใจว่าจำเป็นต้องทิ้งร่องรอยแบบนั้นไว้ในรีโพสิตอรีเพราะงานเพียง 1/100 หรือไม่

  • ต่อให้ได้รับความช่วยเหลือจาก AI ก็ไม่ได้สนใจมากนัก สิ่งสำคัญคือ ใช้งานจริงได้หรือไม่ และถ้าเป็นทางเลือกแทน Tailscale ที่กระจายศูนย์อย่างแท้จริงก็คงยอดเยี่ยมมาก
    จนถึงตอนนี้ส่วนใหญ่เห็น Iroh ถูกใช้ในรูปแบบที่น่ารักแต่ไม่ค่อยมีประโยชน์ นี่อาจเป็นแอปนั้นก็ได้
  • เพราะสร้างบน Iroh จึงมี QUIC และดังนั้นในที่สุดเราอาจได้ใช้การเข้ารหัสที่ทนต่อควอนตัมใน mesh VPN
    เรื่องนี้ก็ดูเหมือนจะ ไม่ใช่สิ่งที่ Tailscale ให้ความสำคัญ

• ตัวผลิตภัณฑ์เองดูเจ๋งจริง ๆ และสิ่งเดียวที่ทำให้ผมยังเปลี่ยนจาก mesh ของ Tailscale ไม่ได้คือ ไม่มีไคลเอนต์ Android
  อย่างไรก็ตาม บทความอ่านแล้วรู้สึกว่าอย่างน้อยบางส่วนเหมือนเขียนด้วย AI เลยขัดใจเล็กน้อย

  • สงสัยว่าเห็นอันนี้หรือยัง: https://github.com/rayfish/rayfish/…
    และดูเหมือนว่าแท็ก nightly จะปล่อยบิลด์ APK แบบดีบักด้วย: https://github.com/rayfish/rayfish/…
    ผมเองก็เพิ่งเห็นบทความนี้เมื่อ 5 นาทีที่แล้ว จึงไม่รู้มากไปกว่าลิงก์นั้นว่ามันใช้งานได้จริงหรือไม่

• การเปรียบเทียบกับ Yggdrasil อ่อนมากและข้อเท็จจริงก็ผิดด้วย แม้ testnet ของ Yggdrasil จะถูกใช้งานเป็นเครือข่ายระดับโลก แต่นั่นเป็นเพียงผลลัพธ์ที่เกิดขึ้นเพื่อความสะดวกจากโทโพโลยีของ Yggdrasil เท่านั้น
  มันสามารถยอมรับการเชื่อมต่อใด ๆ ระหว่างชุดคีย์สองชุดที่แยกจากกันได้แบบไดนามิก และความแตกต่างระหว่างเครือข่าย Yggdrasil ที่แยกจากกันสองเครือข่ายกับเครือข่ายขนาดใหญ่หนึ่งเครือข่าย ก็มีเพียงว่าพวกมันกำลังส่งข้อความหากันอยู่หรือไม่ ใคร ๆ ก็สร้างเครือข่าย Yggdrasil แบบส่วนตัว ได้
  คีย์นั้นคาดเดาไม่ได้ในเชิงคริปโตกราฟี แต่ผมไม่คิดว่านั่นจะหมายถึงบริการที่ซ่อนอยู่ด้วย ชื่อโดเมนเป็นสิ่งที่กำหนดได้เอง แต่หลายคนก็ชี้ DNS ทั่วโลกไปยังพื้นที่ที่อยู่ของ Yggdrasil
  ถ้ามองว่า “หากต้องการแค่เครือข่ายสำหรับเซิร์ฟเวอร์เกมกับเพื่อนสามคน Yggdrasil มีหลายอย่างที่ต้องประกอบเอง” ก็ยิ่งน่าแปลกใจที่ไม่มีการเทียบกับ tinc ซึ่งแทบจะเป็นมาตรฐานสำหรับกรณีเพื่อนสามคนกับเซิร์ฟเวอร์เกม

  • ID สาธารณะเองอาจคาดเดาไม่ได้ก็จริง แต่ ID สาธารณะ อาจปรากฏในล็อกหรือรายงานบั๊กที่แชร์ออกไปได้ ดังนั้นเครือข่ายส่วนตัวที่มีพรอมป์ต์อนุมัติจึงจัดการปัญหานั้น
    คำอธิบายนั้นหมายถึงว่าไม่มีแนวคิดเรื่องการสร้างเครือข่ายส่วนตัวแยกต่างหากแล้วรับคนเข้ามา และไม่มีฟีเจอร์อำนวยความสะดวกอย่างรหัสเชิญ ชื่อ DNS ที่คุ้นเคย ไฟร์วอลล์แยกตามเครือข่าย หรือพรอมป์ต์อนุมัติเมื่อมีใครพยายามเข้ามา ซึ่งถ้าเป็นวิศวกรเครือข่ายก็อาจไม่ใช่ปัญหา
    อีกจุดหนึ่งที่ตกหล่นในการเปรียบเทียบกับ Yggdrasil คือ Rayfish ใช้ประโยชน์จาก NAT hole punching ของ Iroh ทำให้เพียร์สองฝั่งสื่อสารกันได้แม้ไม่มีฝ่ายใดเข้าถึงได้แบบสาธารณะ