SSD Nodes Learn Hosting plans →
คู่มือ Matt Connorโดย Matt Connor · อัปเดตเมื่อ 2026-08-28

วิธีติดตั้ง NetBird VPN server บน VPS ด้วยตนเอง

คู่มือติดตั้ง NetBird บน VPS ตั้งแต่การตั้งค่า DNS และ TLS ไปจนถึงการใช้งาน setup keys สำหรับ unattended peers พร้อมเปรียบเทียบความแตกต่างระหว่าง NetBird กับ Headscale อย่างละเอียด

ประโยชน์ของการโฮสต์ NetBird VPN server ด้วยตนเอง

การโฮสต์ NetBird VPN server ด้วยตนเองจะทำให้ control plane อยู่บน VPS ของคุณ ซึ่งเป็นส่วนที่เก็บรายการ peer, ตัดสินใจว่าเครื่องใดสามารถเข้าถึงเครื่องใดได้บ้าง และช่วยให้ peer สองเครื่องค้นหากันและกันได้เมื่ออยู่หลัง NAT (network address translation) สำหรับตัว tunnel นั้นยังคงเป็น WireGuard ซึ่งมีการเข้ารหัสโดยตรงระหว่างเครื่องของคุณ สิ่งที่เปลี่ยนไปคือไม่มีบริษัทภายนอกถือครองรายการอุปกรณ์หรือขั้นตอนการเข้าสู่ระบบของคุณ คุณควรทำความเข้าใจให้ชัดเจนว่าสิ่งนี้ให้ประโยชน์อย่างไร เพราะ control plane แบบโฮสต์ก็ไม่ได้ถือครองกุญแจที่ใช้เข้ารหัส traffic ของคุณเช่นกัน และ สิ่งที่ coordination server สามารถทำได้จริงหากถูกบุกรุก นั้นมีขอบเขตจำกัดกว่าที่คนส่วนใหญ่เข้าใจก่อนที่จะได้อ่านรายละเอียด

NetBird อยู่กึ่งกลางระหว่างสิ่งที่คุณอาจรู้จักอยู่แล้ว มันเป็น mesh overlay ดังนั้น peer จึงเชื่อมต่อถึงกันโดยตรงแทนที่จะส่งทุกอย่างผ่าน gateway เดียว นอกจากนี้ยังสามารถโฮสต์เองได้ทั้งหมดตั้งแต่ต้นจนจบ ซึ่งทำให้มันถูกนำไปเปรียบเทียบกับ Headscale ซึ่งเป็น control server สำหรับ Tailscale ที่โฮสต์เองได้ หากคุณเคยใช้งานเพียง tunnel แบบ gateway เดียว ให้ลองอ่าน ความแตกต่างระหว่าง WireGuard แบบปกติกับ mesh overlay ก่อน เพราะแนวคิดนั้นคือสิ่งที่ทำให้เนื้อหาในส่วนที่เหลือของหน้านี้มีประโยชน์

หากสิ่งที่คุณต้องการจริงๆ คือเซิร์ฟเวอร์เพียงเครื่องเดียวที่ traffic ทั้งหมดของคุณวิ่งผ่าน mesh อาจเป็นระบบที่ซับซ้อนเกินความจำเป็น WireGuard VPN แบบปกติบน VPS เครื่องเดียว หรือ Tailscale exit node สามารถทำงานนั้นได้โดยใช้การตั้งค่าที่น้อยกว่ามาก และหากเป้าหมายคือการเข้าถึงเครือข่ายส่วนตัวเครือข่ายหนึ่ง แทนที่จะเป็นการเชื่อมต่อเครื่องเข้าหากัน Tailscale subnet router บน VPS จะทำหน้าที่ประกาศช่วงเครือข่ายนั้นไปยัง tailnet ที่คุณมีอยู่แล้ว โดยไม่ต้องใช้ stack ทั้งหมดที่กล่าวมาข้างต้น

สิ่งที่ stack ทำงานอยู่จริงในปัจจุบัน

โครงสร้างมีการเปลี่ยนแปลงเมื่อเร็วๆ นี้ และบทความเก่าส่วนใหญ่ยังคงอธิบายโครงสร้างแบบเดิม ณ เดือนสิงหาคม 2026 ใน release v0.76.2 สคริปต์ quickstart จะเขียนไฟล์ Compose ที่มี 3 บริการเป็นค่าเริ่มต้น

  • netbird-server ทำหน้าที่จัดการ API, บริการ signal, relay พร้อมตัวรับ STUN ในตัว และ identity provider ในตัว ใน release รุ่นเก่า บริการเหล่านี้เป็น container แยกกัน และ identity provider เป็นการติดตั้ง Zitadel แยกต่างหากที่คุณต้องสร้างขึ้นก่อน
  • dashboard คือคอนโซลเว็บสำหรับผู้ดูแลระบบ
  • traefik ทำหน้าที่จัดการ TLS (transport layer security) และร้องขอใบรับรองจาก Let's Encrypt ในการเริ่มทำงานครั้งแรก

ยังมีอีก 2 บริการที่คงสถานะปิดไว้จนกว่าคุณจะตอบตกลงที่ prompt บริการ NetBird Proxy จะเผยแพร่บริการภายในบนชื่อโฮสต์สาธารณะ ส่วน CrowdSec จะกรอง traffic ที่ไม่พึงประสงค์ ทั้งสองอย่างนี้ไม่จำเป็นสำหรับการสร้าง mesh ที่ใช้งานได้ และทั้งคู่ใช้หน่วยความจำบนเครื่องขนาดเล็ก

หากคุณย้ายมาจาก wg-easy ใน Docker container เดียว นี่ถือเป็นการเพิ่มจำนวนส่วนประกอบ สิ่งที่คุณได้รับคือการจัดการนโยบายการเข้าถึง บัญชีผู้ใช้รายบุคคล และ peer ที่เชื่อมต่อถึงกันโดยตรงแทนที่จะผ่าน gateway เพียงจุดเดียว

สิ่งที่ต้องเตรียมก่อนเริ่มต้น

ชื่อโดเมนสาธารณะเป็นสิ่งที่จำเป็น Dashboard, API และ relay ทั้งหมดทำงานผ่าน HTTPS บนพอร์ต 443 โดย Traefik จะขอใบรับรองจาก Let's Encrypt ผ่านกระบวนการ HTTP challenge ซึ่งต้องใช้ชื่อโดเมนที่ชี้มายัง VPS ของคุณจากอินเทอร์เน็ตสาธารณะ การใช้เพียง IP address จะไม่สามารถใช้งานในกระบวนการนี้ได้

ให้สร้าง A record หนึ่งรายการ netbird.example.com โดยชี้ไปยัง IPv4 สาธารณะของ VPS และรอให้ DNS อัปเดตก่อนเริ่มดำเนินการใดๆ

dig +short netbird.example.com

คำสั่งดังกล่าวต้องแสดงผลเป็น IP address ของเซิร์ฟเวอร์คุณ การรันตัวติดตั้งก่อนที่ DNS จะอัปเดตจะทำให้การขอใบรับรองล้มเหลวในการเริ่มทำงานครั้งแรก และหากการตรวจสอบล้มเหลวซ้ำๆ จะติดข้อจำกัดด้านอัตราการร้องขอ (rate limits) ของ Let's Encrypt ทำให้คุณต้องรออีกหนึ่งชั่วโมงเพื่อลองใหม่

พอร์ต 3 รายการต้องสามารถเข้าถึงได้จากอินเทอร์เน็ต: TCP 80 สำหรับการทำ certificate challenge และการเปลี่ยนเส้นทางไปยัง HTTPS, TCP 443 สำหรับ Dashboard, API, signal และ relay traffic และ UDP 3478 สำหรับ STUN

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 3478/udp
sudo ufw reload
sudo ufw status

อย่าลืมเปิดพอร์ตเหล่านี้ที่ network firewall ของผู้ให้บริการ VPS ด้วย นี่เป็นส่วนควบคุมแยกต่างหากในแผงควบคุม VPS ส่วนใหญ่ และเป็นสาเหตุที่ทำให้แม้การตั้งค่า ufw status ในเครื่องจะถูกต้อง แต่ก็ยังไม่สามารถเชื่อมต่อได้

STUN (session traversal utilities for NAT) คือวิธีที่ peer จะเรียนรู้ที่อยู่สาธารณะและพอร์ตที่ NAT ของตนเองกำหนดให้ เพื่อให้ peer สองฝั่งสามารถพยายามสร้างอุโมงค์เชื่อมต่อโดยตรงได้ หากบล็อก UDP 3478 ไว้ peer จะยังคงเชื่อมต่อได้ผ่าน relay บน TCP 443 ทำให้ดูเหมือนไม่มีอะไรเสียหาย แต่คุณจะพบ Connection type: Relayed บน peer ทุกเครื่องแทน และทราฟฟิกทั้งหมดจะวิ่งผ่าน VPS ของคุณแทนที่จะเป็นการเชื่อมต่อแบบ peer to peer

ในส่วนของซอฟต์แวร์ คุณต้องมี Docker พร้อมด้วย Compose v2 plugin รวมถึง jq และ curl สคริปต์จะตรวจสอบสิ่งเหล่านี้ทั้งหมดและหยุดทำงานหากขาดรายการใดรายการหนึ่งไป หาก Docker เป็นของใหม่บนเครื่องนี้ ให้ดำเนินการ ติดตั้ง Docker Compose บน VPS ให้เรียบร้อยก่อน

พอร์ตที่ต้องใช้หากไม่ใช้ reverse proxy ที่มาพร้อมกับระบบ

การรันโดยไม่ใช้ Traefik หมายความว่าบริการแต่ละตัวจะถูกเปิดเผยโดยตรง และรายการพอร์ตจะเพิ่มขึ้นดังนี้:

  • TCP 80, สำหรับ HTTP redirects
  • TCP 443, สำหรับ HTTPS
  • TCP 33073, สำหรับ management gRPC
  • TCP 10000, สำหรับ signal gRPC
  • TCP 33080, สำหรับ relay ผ่าน WebSocket หรือ QUIC
  • UDP 3478, สำหรับ STUN

ให้เลือกวิธีนี้เฉพาะเมื่อเซิร์ฟเวอร์ของคุณมีการทำ TLS termination สำหรับบริการอื่นอยู่แล้วเท่านั้น มิฉะนั้นการใช้ Traefik ที่มาพร้อมกับระบบจะช่วยลดจำนวนกฎที่ต้องตั้งค่าและลดโอกาสเกิดข้อผิดพลาดได้มากกว่า

ติดตั้ง NetBird server ด้วยสคริปต์ quickstart

คำสั่งแบบบรรทัดเดียวที่ระบุไว้ในเอกสารจะทำการ pipe รุ่นล่าสุดลงใน shell โดยตรง:

curl -fsSL https://github.com/netbirdio/netbird/releases/latest/download/getting-started.sh | bash

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

mkdir -p ~/netbird
cd ~/netbird
curl -fsSL -o getting-started.sh \
  https://github.com/netbirdio/netbird/releases/download/v0.76.2/getting-started.sh
less getting-started.sh
bash getting-started.sh

สคริปต์จะถามหาชื่อโดเมนก่อน:

Enter the domain you want to use for NetBird (e.g. netbird.my-domain.com):

จากนั้นจะถามถึงวิธีการจัดการ TLS:

Which reverse proxy will you use?
  [0] Traefik (recommended - automatic TLS, included in Docker Compose)
  [1] Existing Traefik (labels for external Traefik instance)
  [2] Nginx (generates config template)
  [3] Nginx Proxy Manager (generates config + instructions)
  [4] External Caddy (generates Caddyfile snippet)
  [5] Other/Manual (displays setup documentation)
Enter choice [0-5] (default: 0):

ให้เลือก [0] สำหรับตัวเลือกที่ 2 ถึง 5 นั้นจะเป็นการเขียนไฟล์ config snippet และปล่อยให้คุณจัดการการเชื่อมต่อเอง ซึ่งเป็นวิธีที่ถูกต้องสำหรับเครื่องที่มี proxy ทำงานอยู่แล้ว แต่ไม่เหมาะสมสำหรับเครื่องที่เพิ่งติดตั้งใหม่ ส่วนตัวเลือกที่ 0 จะถามหาอีเมลสำหรับ Let's Encrypt เพื่อใช้ในการแจ้งเตือนเมื่อใบรับรองหมดอายุ

ให้ปฏิเสธการติดตั้ง NetBird Proxy service ในการติดตั้งครั้งแรก เนื่องจากบริการนี้ต้องการ DNS record เพิ่มอีกสองรายการคือ proxy.netbird.example.com และ wildcard *.proxy.netbird.example.com ซึ่งไม่มีความจำเป็นสำหรับเครือข่ายแบบ mesh พื้นฐาน และให้ปฏิเสธ CrowdSec ไปก่อนเช่นกัน ทั้งสองอย่างนี้สามารถเพิ่มภายหลังได้

สคริปต์จะเขียนไฟล์ลงในไดเรกทอรีปัจจุบัน ได้แก่ docker-compose.yml, config.yaml (ด้วยโหมด 600), dashboard.env และ traefik-dynamic.yaml (หากคุณเลือกใช้ Traefik ที่มาพร้อมกัน) ให้ถือว่าไดเรกทอรีนี้เป็นสถานะของระบบที่คุณต้องเก็บรักษาไว้ เพราะ config.yaml เก็บกุญแจที่ใช้เข้ารหัสข้อมูลใน store หากทำไฟล์นี้หาย การติดตั้งใหม่ก็ไม่สามารถแก้ไขได้

docker compose ps
docker compose logs -f netbird-server

ทุกบริการควรจะอ่าน running ได้ และ log ของเซิร์ฟเวอร์ควรจะนิ่ง ไม่ใช่การรีสตาร์ทวนซ้ำไปมา ให้ตรวจสอบใบรับรองแยกต่างหาก:

docker compose logs traefik | grep -i acme

ACME (automatic certificate management environment) คือโปรโตคอลที่ Traefik ใช้เพื่อขอใบรับรอง ข้อผิดพลาดที่เกิดขึ้นในส่วนนี้มักเกิดจากปัญหา DNS หรือการไม่ได้เปิดพอร์ต 80

สร้างบัญชีผู้ดูแลระบบบัญชีแรก

เปิด https://netbird.example.com ในการติดตั้งใหม่ หน้าเว็บจะแสดงหน้าตั้งค่าแทนที่จะเป็นแบบฟอร์มเข้าสู่ระบบ ให้กรอกที่อยู่อีเมล ชื่อ และรหัสผ่าน จากนั้นคลิก Create Account บัญชีนี้จะกลายเป็นผู้ดูแลระบบคนแรก และหน้าเว็บจะเปลี่ยนเส้นทางไปยังแบบฟอร์มเข้าสู่ระบบ

บัญชีดังกล่าวจะถูกเก็บไว้ในที่เก็บข้อมูลผู้ใช้ของ NetBird เอง ซึ่งขับเคลื่อนโดย identity provider ที่ฝังอยู่ในคอนเทนเนอร์ netbird-server โดยไม่ต้องพึ่งพาระบบภายนอก นี่คือการเปลี่ยนแปลงครั้งใหญ่ที่สุดจาก NetBird เวอร์ชัน self-hosted เมื่อปีก่อน ซึ่งการติดตั้งให้ใช้งานได้จำเป็นต้องตั้งค่า Zitadel หรือ Keycloak ก่อน และต้องคัดลอกค่า OIDC (OpenID Connect) จำนวน 4 ค่าลงใน setup.env ก่อนที่ระบบจะเริ่มทำงานได้

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

เชื่อมต่อ peer เครื่องแรกของคุณ

ติดตั้ง client บนเครื่อง Linux ใดก็ได้ รวมถึงตัว VPS เองหากคุณต้องการให้มันอยู่ใน mesh:

curl -fsSL https://pkgs.netbird.io/install.sh | sh

บน Debian และ Ubuntu สคริปต์ดังกล่าวจะตั้งค่า package repository ของ NetBird จากนั้นจึงติดตั้ง client ผ่าน apt ทำให้ package manager เป็นผู้ดูแลแพ็กเกจนั้นโดยสมบูรณ์ หากคุณไม่ต้องการรันสคริปต์ผ่าน pipe ให้บันทึกไฟล์ไว้ก่อนด้วย curl -fsSL -o install.sh https://pkgs.netbird.io/install.sh และตรวจสอบเนื้อหาก่อนรันด้วย sh install.sh ไม่ว่าจะใช้วิธีใด ให้ตรวจสอบสิ่งที่ติดตั้งลงไป:

apt-cache policy netbird

netbird คือ command line client และ daemon ส่วน netbird-ui คือแอปพลิเคชันบน desktop tray ซึ่งเซิร์ฟเวอร์แบบ headless ไม่จำเป็นต้องใช้งาน

จากนั้นระบุตำแหน่งเซิร์ฟเวอร์ให้ client ทราบ:

sudo netbird up --management-url https://netbird.example.com

หากละเว้น --management-url ไว้ client จะลงทะเบียนกับบริการ hosted ของ NetBird เนื่องจากเป็นค่าเริ่มต้นที่ถูกคอมไพล์มาในตัว คำสั่งจะยังคงทำงานสำเร็จ เครื่องจะได้รับ IP address แต่ dashboard ที่คุณโฮสต์เองจะยังคงว่างเปล่า นี่เป็นจุดที่ผู้ใช้งานส่วนใหญ่พลาดเป็นครั้งแรก

คำสั่งจะแสดง URL เพื่อให้คุณเปิดในเบราว์เซอร์เพื่อดำเนินการล็อกอินให้เสร็จสิ้น หลังจากนั้น:

netbird status
ip addr show wt0

อ่านข้อมูลสี่บรรทัดจาก netbird status: Management: Connected, Signal: Connected, บรรทัด Relays: ที่รายงาน relay ทั้งหมดที่มี และ NetBird IP: ในช่วง overlay range ส่วน wt0 คืออินเทอร์เฟซ WireGuard ที่ NetBird สร้างขึ้น ซึ่งควรจะมี IP address เดียวกันนี้ปรากฏอยู่

การเชื่อมต่อเครื่องที่สองแบบไม่ต้องเฝ้าหน้าจอด้วย setup key

การล็อกอินผ่านเบราว์เซอร์ไม่สามารถทำได้กับเครื่องที่ไม่มีเบราว์เซอร์และไม่มีผู้ใช้งานอยู่หน้าเครื่อง setup key คือโทเค็นสำหรับการยืนยันตัวตนล่วงหน้า ซึ่งใช้ลงทะเบียนเครื่องโดยไม่ต้องผ่านขั้นตอนโต้ตอบ คุณสามารถสร้างคีย์นี้ได้ในแดชบอร์ดภายใต้หัวข้อ Setup Keys

คีย์มีอยู่ 2 ประเภท ประเภทใช้ครั้งเดียว (one-off key) จะยืนยันตัวตนได้เพียงเครื่องเดียวและจะถูกใช้ไปทันที ส่วนคีย์แบบใช้ซ้ำได้ (reusable key) สามารถลงทะเบียนได้หลายเครื่อง โดยสามารถกำหนดจำนวนสูงสุดได้ ทั้งสองประเภทต้องกำหนดวันหมดอายุ และสามารถกำหนดให้ peer ใหม่เข้ากลุ่มโดยอัตโนมัติ เพื่อให้กฎการเข้าถึงของกลุ่มนั้นมีผลทันทีที่เครื่องปรากฏในระบบ

sudo netbird up --setup-key <SETUP-KEY> \
  --management-url https://netbird.example.com \
  --hostname build-runner-01

--hostname ใช้สำหรับกำหนดชื่อที่จะแสดงในแดชบอร์ด หากไม่ระบุชื่อ peer จะใช้ชื่อที่เครื่องเรียกตัวเอง ซึ่งการมีรายการจำนวนมากที่ชื่อ ubuntu จะไม่เป็นประโยชน์ต่อการจัดการ

สำหรับคอนเทนเนอร์และ build agent ที่มีอายุการใช้งานสั้น ให้ทำเครื่องหมายคีย์ว่าเป็น ephemeral ในขณะสร้าง peer ที่ลงทะเบียนด้วย ephemeral key จะถูกลบออกโดยอัตโนมัติเมื่อออฟไลน์นานเกิน 10 นาที ซึ่งช่วยป้องกันไม่ให้มีรายการที่ไม่ได้ใช้งานตกค้างอยู่ในรายการ peer

ข้อจำกัดประการหนึ่งที่ควรทราบก่อนวางแผนใช้งาน setup key คือ การหมดอายุหรือการลบคีย์จะหยุดการลงทะเบียนใหม่ แต่จะไม่ตัดการเชื่อมต่อเครื่องที่ลงทะเบียนไปแล้ว การเพิกถอนสิทธิ์การเข้าถึงของเครื่องต้องทำโดยการลบ peer นั้นออกโดยตรง

คุณยังจำเป็นต้องมี Identity Provider แยกต่างหากหรือไม่?

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

คุณควรใช้ Identity Provider ภายนอกเมื่อคุณมีระบบดังกล่าวอยู่แล้วและไม่ต้องการจัดการรายชื่อผู้ใช้ซ้ำซ้อน NetBird รองรับ Provider ทุกรายที่ใช้โปรโตคอล OIDC ให้คุณลงทะเบียน confidential OIDC client ใน Provider ของคุณ จากนั้นเพิ่มข้อมูลลงในแดชบอร์ดของ NetBird โดยใช้ค่า 4 รายการ ได้แก่ name, client ID, client secret และ issuer โดย NetBird จะให้ redirect URL เพื่อนำไปกรอกกลับใน Provider ของคุณ ทั้งนี้มีระบบเชื่อมต่อสำเร็จรูปสำหรับ Google, Microsoft Entra ID, Okta, Zitadel, Keycloak, Authentik และ Pocket ID ส่วนบริการอื่นๆ สามารถตั้งค่าเป็น generic OIDC ได้ หากคุณใช้งาน Authentik เป็นระบบ single sign-on แบบ self-hosted อยู่แล้ว นี่คือวิธีที่จะช่วยให้คุณรักษาฐานข้อมูลผู้ใช้ไว้เพียงชุดเดียวแทนที่จะเป็นสองชุด

การล็อกอินแบบ local จะยังคงใช้งานได้หลังจากที่คุณเพิ่ม Provider เข้าไป และ Provider ทุกตัวที่ตั้งค่าไว้จะปรากฏบนหน้าล็อกอิน โปรดรักษาบัญชีผู้ดูแลระบบแบบ local ไว้หนึ่งบัญชีโดยใช้รหัสผ่านที่คาดเดายาก เพื่อให้คุณยังมีช่องทางเข้าถึงระบบได้ในกรณีที่การตั้งค่า OIDC เกิดข้อผิดพลาด

NetBird หรือ Headscale: คุณควรเลือกใช้ control plane ตัวไหน?

ทั้งสองตัวช่วยขจัดข้อจำกัดเดียวกัน คือการต้องพึ่งพา control server แบบ hosted ที่ไคลเอนต์ของคุณต้องเชื่อมต่อกลับไป แต่ทั้งสองโครงการมีรูปแบบการทำงานที่แตกต่างกัน

Headscale เป็นการนำ control server ของ Tailscale มาสร้างใหม่ โดยคุณยังคงใช้ไคลเอนต์อย่างเป็นทางการของ Tailscale ต่อไป ทั้งนี้ไม่มีเว็บคอนโซลอย่างเป็นทางการ คุณต้องจัดการผู้ใช้และ pre-authentication keys ผ่านคำสั่ง headscale โดยอ้างอิงกับไฟล์คอนฟิก ซึ่งมีเว็บอินเทอร์เฟซจากชุมชนให้เลือกใช้ แต่ไม่ได้เป็นส่วนหนึ่งของโครงการหลัก วิธีนี้เหมาะสำหรับผู้ที่ต้องการเก็บสถานะไว้ในไฟล์และจัดการการเปลี่ยนแปลงผ่านระบบ version control

NetBird มาพร้อมกับผลิตภัณฑ์ที่ครบวงจร ทั้งไคลเอนต์ของตนเอง แดชบอร์ด ผู้ให้บริการระบุตัวตน (identity provider) ในตัว และนโยบายการเข้าถึงที่แก้ไขผ่านเบราว์เซอร์ได้ ซึ่งหมายถึงจำนวนส่วนประกอบที่ต้องดูแลบน VPS ของคุณมีมากขึ้น แต่ก็ช่วยลดภาระงานได้อย่างมากหากต้องส่งมอบให้เพื่อนร่วมงานที่ไม่ต้องการใช้งานผ่าน terminal

เลือกใช้ Headscale หากคุณใช้งานไคลเอนต์ของ Tailscale อยู่แล้ว หรือต้องการ control plane ที่มีขนาดเล็กที่สุดเท่าที่จะเป็นไปได้ เลือกใช้ NetBird หากมีหลายคนที่ต้องช่วยกันจัดการ peer และคุณต้องการคอนโซลรวมถึงระบบ SSO โดยไม่ต้องประกอบระบบขึ้นมาเอง ก่อนที่คุณจะตัดสินใจเลือกตัวใดตัวหนึ่ง โปรดตรวจสอบ สิ่งที่แผนบริการฟรีของ Tailscale ครอบคลุมจริง ๆ เนื่องจากกลุ่มผู้ใช้ที่มีจำนวนไม่เกิน 6 คนและมีอุปกรณ์ไม่จำกัดจะไม่เสียค่าใช้จ่ายใด ๆ สำหรับการใช้ hosted control plane และอาจไม่มีเหตุผลจำเป็นต้องติดตั้งระบบเอง หากเกินขีดจำกัดดังกล่าว ค่าใช้จ่ายจะเพิ่มขึ้นตามจำนวนคนไม่ใช่จำนวนเครื่อง ดังนั้นการ คำนวณค่าใช้จ่ายที่ Tailscale จะเรียกเก็บจากกลุ่มของคุณ จะช่วยให้คุณได้ตัวเลขเพื่อนำไปเปรียบเทียบกับค่า VPS และเวลาที่ต้องเสียไปในการดูแลระบบนี้

VPS ขนาดเล็กที่สุดที่สามารถรันระบบนี้ได้คือเท่าใด

ข้อกำหนดขั้นต่ำที่ระบุไว้คือ CPU 1 คอร์ และหน่วยความจำ 2 GB บันทึกของ NetBird ระบุว่าปัจจุบันสามารถรันได้ที่ RAM ประมาณ 1 GB เนื่องจากระบบจัดการผู้ใช้เปลี่ยนมาเป็นแบบ local แล้ว ซึ่งต่างจากโครงสร้างเดิมที่ต้องใช้ RAM 2 GB ถึง 4 GB เมื่อต้องรัน Zitadel เต็มรูปแบบร่วมด้วย แนะนำให้เลือกซื้อขนาด 2 GB เพราะพื้นที่หน่วยความจำที่เหลือจะช่วยให้การอัปเกรดสามารถดึง image ใหม่มาเก็บไว้ได้ในขณะที่ image เก่ายังคงอยู่ในดิสก์

มี 3 สิ่งที่คุณสามารถตัดออกได้หากใช้เครื่องขนาดเล็ก: ให้ปฏิเสธการติดตั้งบริการ NetBird Proxy ซึ่งมีไว้สำหรับเผยแพร่บริการภายในสู่ชื่อโฮสต์สาธารณะและไม่มีผลต่อการเชื่อมต่อระหว่าง peer, ให้ปฏิเสธการติดตั้ง CrowdSec ซึ่งสามารถเพิ่มภายหลังได้เมื่อเครื่องเปิดรับการเชื่อมต่อจากภายนอก ไม่จำเป็นต้องติดตั้งตั้งแต่วันแรก, และให้ใช้ SQLite store แบบค่าเริ่มต้นใน volume netbird_data โดยให้ย้ายไปใช้ PostgreSQL เฉพาะเมื่อคุณแยกการติดตั้งออกเป็นหลายเครื่องหรือเมื่อมีปริมาณงานที่ต้องประมวลผลพร้อมกันสูงจริง ซึ่งมีเอกสารระบุขั้นตอนการย้ายข้อมูลไว้ให้ทำภายหลังได้

ส่วนประกอบที่คุณไม่สามารถตัดออกได้คือ relay เนื่องจาก peer สองเครื่องที่ NAT กำหนดพอร์ตต่างกันสำหรับทุกปลายทางจะไม่สามารถสร้าง tunnel โดยตรงได้ relay จึงเป็นเส้นทางเดียวที่ทำให้การเชื่อมต่อทำงานได้ การปิดใช้งาน relay ช่วยประหยัดหน่วยความจำได้เพียงเล็กน้อย แต่จะทำให้การเชื่อมต่อล้มเหลวในลักษณะที่ตรวจสอบหาสาเหตุได้ยาก

เมื่อเครื่องเดียวไม่เพียงพอต่อการใช้งาน relay คือสิ่งแรกที่ควรย้ายออกไปรันแยกต่างหาก โดย relay แบบ standalone จะรันด้วย NB_LISTEN_ADDRESS, NB_EXPOSED_ADDRESS, NB_AUTH_SECRET และ NB_ENABLE_STUN ทั้งนี้ shared secret บน relay และบนเซิร์ฟเวอร์หลักจะต้องตรงกัน มิฉะนั้นไคลเอนต์จะไม่สามารถยืนยันตัวตนกับ relay ได้

รูปแบบความล้มเหลวและสิ่งที่คุณจะพบ

แดชบอร์ดแสดงคำเตือนเกี่ยวกับใบรับรอง (certificate) Traefik ไม่สามารถขอใบรับรองได้ ให้รันคำสั่ง docker compose logs traefik | grep -i acme สาเหตุมีอยู่ 2 ประการ คือ dig +short netbird.example.com ยังไม่ชี้มาที่ VPS นี้ หรือพอร์ต TCP 80 ถูกปิดกั้นไว้ที่จุดใดจุดหนึ่งระหว่าง Let's Encrypt กับคอนเทนเนอร์ ซึ่งมักจะเป็นที่ไฟร์วอลล์เครือข่ายของผู้ให้บริการมากกว่าจะเป็นที่ ufw ให้แก้ไขสาเหตุให้เรียบร้อยก่อนลองใหม่ซ้ำๆ เพราะการตรวจสอบที่ล้มเหลวจะถูกจำกัดอัตรา (rate limit) และคุณจะถูกล็อกไม่ให้ลองใหม่เป็นเวลาหนึ่งชั่วโมง

ไคลเอนต์แจ้งว่าเชื่อมต่อแล้ว แต่แดชบอร์ดว่างเปล่า ไคลเอนต์ไปลงทะเบียนกับบริการโฮสต์ของ NetBird เนื่องจากค่า --management-url หายไป ให้รัน netbird status --detail แล้วอ่านบรรทัด Management: ซึ่งจะระบุชื่อเซิร์ฟเวอร์ที่ไคลเอนต์กำลังติดต่ออยู่จริง หากเห็น Management: Connected to https://api.netbird.io:443 แสดงว่าไคลเอนต์เชื่อมต่อไปยังระบบคลาวด์ ให้รัน sudo netbird down แล้วรัน sudo netbird up --management-url https://netbird.example.com อีกครั้ง

Peer ทุกตัวแสดงสถานะ Connection type: Relayed ไม่มีการสร้างอุโมงค์ (tunnel) โดยตรง ทำให้ทราฟฟิกทั้งหมดต้องวิ่งผ่าน VPS ของคุณและเพิ่มความหน่วง (latency) ให้ตรวจสอบพอร์ต UDP 3478 บนไฟร์วอลล์ของ VPS และไฟร์วอลล์ของผู้ให้บริการ เนื่องจาก STUN คือสิ่งที่ช่วยให้ Peer ทราบที่อยู่ IP สาธารณะและพอร์ตของตนเอง นอกจากนี้ netbird status --detail ยังแสดง Direct: false และประเภทของ ICE (interactive connectivity establishment) candidate สำหรับ Peer แต่ละตัว ซึ่งจะแสดงให้เห็นว่ากระบวนการเชื่อมต่อดำเนินไปถึงขั้นตอนใด ในบางเครือข่าย การเชื่อมต่อแบบ relayed อาจเป็นผลลัพธ์เดียวที่ทำได้และไม่ได้หมายความว่ามีสิ่งใดผิดปกติ

Peer เข้าร่วมเครือข่ายแล้วแต่ไม่สามารถเข้าถึงสิ่งใดได้ การอยู่ใน mesh ไม่ได้หมายความว่า Peer สองตัวจะคุยกันได้เสมอไป นโยบายการเข้าถึง (access policies) เป็นตัวกำหนดเรื่องนี้ และกลุ่มที่ไม่มีการกำหนดนโยบายไว้จะไม่สามารถเข้าถึงสิ่งใดได้เลย ให้ตรวจสอบนโยบายในแดชบอร์ดก่อนที่คุณจะเริ่มแก้ไขปัญหาเส้นทาง (routes) และไฟร์วอลล์

netbird status รายงานปัญหาเกี่ยวกับ daemon บริการไม่ได้ทำงานอยู่ ให้ใช้คำสั่ง sudo netbird service status และ sudo netbird service start โดย log ของไคลเอนต์จะอยู่ที่ /var/log/netbird/client.log สำหรับปัญหาใดๆ ที่คุณระบุสาเหตุไม่ได้ ให้ใช้ netbird debug bundle --anonymize --system-info เพื่อรวบรวม log, สถานะ, เส้นทาง, การตั้งค่า DNS และสถานะไฟร์วอลล์ไว้ในไฟล์เก็บถาวรเดียว

การสำรองข้อมูลและการอัปเกรด

มีสองส่วนสำคัญที่ครอบคลุมการติดตั้งทั้งหมด ได้แก่ ไดเรกทอรีที่เก็บ docker-compose.yml และ config.yaml รวมถึง Docker volume ที่เก็บฐานข้อมูลและคีย์เข้ารหัสลับ ให้สำรองข้อมูลทั้งสองส่วนนี้พร้อมกัน config.yaml เป็นที่เก็บคีย์สำหรับเข้ารหัสข้อมูลในคลังข้อมูล ดังนั้นหากคัดลอกเฉพาะฐานข้อมูลโดยไม่มีคีย์นี้ ข้อมูลที่กู้คืนมาจะไม่สามารถอ่านได้

docker volume ls
docker compose down
sudo tar czf netbird-config.tgz -C ~ netbird
docker run --rm -v netbird_netbird_data:/data -v "$PWD":/backup \
  alpine tar czf /backup/netbird-data.tgz -C /data .
docker compose up -d

Compose จะเติมชื่อโปรเจกต์นำหน้าชื่อ volume ดังนั้น volume ที่ระบุไว้ใน netbird_data มักจะปรากฏในชื่อ netbird_netbird_data ให้รันคำสั่ง docker volume ls ก่อนแล้วใช้ชื่อที่แสดงผลออกมา มิฉะนั้นคำสั่ง docker run ด้านบนจะล้มเหลวโดยการสร้าง volume เปล่าขึ้นมาเงียบๆ และไม่ได้สำรองข้อมูลใดๆ เลย ควรเก็บไฟล์สำรองไว้นอก VPS หากคุณมีเครื่องมือสำรองข้อมูลอยู่แล้ว restic หรือ BorgBackup สามารถจัดการส่วนการสำรองข้อมูลนอกสถานที่ได้

การอัปเกรดเซิร์ฟเวอร์ทำได้โดยการดึงอิมเมจใหม่และสร้างคอนเทนเนอร์ขึ้นมาใหม่:

docker compose pull
docker compose up -d
docker compose ps

ก่อนที่คุณจะดำเนินการดังกล่าว ให้รันคำสั่ง docker compose config | grep image: เสียก่อน แท็กใดก็ตามที่ระบุว่าเป็น latest ควรถูกล็อกเวอร์ชันไว้ (pin) ด้วยเหตุผลเดียวกับที่คุณล็อกเวอร์ชันของสคริปต์ติดตั้ง นั่นคือเพื่อให้คุณทราบว่าซอฟต์แวร์เวอร์ชันใดกำลังทำงานอยู่ และเพื่อให้มีเวอร์ชันที่สามารถย้อนกลับไปได้หากการอัปเกรดเกิดปัญหา ส่วนไคลเอนต์จะอัปเกรดผ่านตัวจัดการแพ็กเกจที่ใช้ติดตั้งโปรแกรมนั้นๆ

FAQ

ฉันจำเป็นต้องมี Identity Provider ของตัวเองเพื่อ self-host NetBird หรือไม่?

ไม่จำเป็น รุ่นปัจจุบันมีระบบจัดเก็บผู้ใช้ในตัว คุณจึงสามารถสร้างบัญชีผู้ดูแลระบบบัญชีแรกได้ผ่านเบราว์เซอร์ที่ https://netbird.example.com และเพิ่มผู้ใช้รายอื่นจากแดชบอร์ดได้ในภายหลัง การใช้ OIDC provider ภายนอกเป็นเพียงทางเลือกและสามารถเพิ่มในภายหลังได้โดยใช้ค่า 4 รายการ ได้แก่ name, client ID, client secret และ issuer คู่มือที่แนะนำให้คุณติดตั้ง Zitadel หรือ Keycloak ก่อน NetBird เป็นการตั้งค่าที่ไม่จำเป็นอีกต่อไป และการทำตามคู่มือเหล่านั้นจะทำให้คุณต้องดูแลบริการเพิ่มขึ้นโดยไม่จำเป็น

ทำไม peer ทั้งหมดของฉันถึงแสดงสถานะเป็น Connection type: Relayed?

การเชื่อมต่อโดยตรงไม่สามารถสร้างขึ้นได้ ข้อมูลจึงต้องวิ่งผ่าน relay บน VPS ของคุณ สาเหตุทั่วไปคือพอร์ต UDP 3478 ถูกบล็อก ซึ่งเป็นพอร์ต STUN ที่ peer ใช้สำหรับค้นหา public address และพอร์ตของตนเอง ให้เปิดพอร์ตนี้บนไฟร์วอลล์ของ VPS และบนไฟร์วอลล์เครือข่ายของผู้ให้บริการ จากนั้นรันคำสั่ง netbird status --detail อีกครั้งและอ่านบรรทัด Direct: หากอยู่ในเครือข่ายที่ NAT กำหนดพอร์ตต่างกันในแต่ละปลายทาง การเชื่อมต่อผ่าน relay จะเป็นผลลัพธ์เดียวที่เป็นไปได้และไม่ได้มีการตั้งค่าผิดพลาดแต่อย่างใด

ไคลเอนต์เชื่อมต่อแล้วแต่แดชบอร์ดไม่แสดง peer เกิดอะไรขึ้น?

ไคลเอนต์ลงทะเบียนกับบริการที่โฮสต์โดย NetBird แทนที่จะเป็นเซิร์ฟเวอร์ของคุณ ซึ่งเป็นสิ่งที่เกิดขึ้นเมื่อไม่ได้ระบุค่า --management-url คำสั่ง netbird status --detail จะแสดงเซิร์ฟเวอร์ที่ไคลเอนต์กำลังติดต่ออยู่บนบรรทัด Management: ดังนั้นค่าอย่างเช่น https://api.netbird.io:443 จึงเป็นการยืนยันว่าเชื่อมต่อผิดที่ ให้รันคำสั่ง sudo netbird down ตามด้วย sudo netbird up --management-url https://netbird.example.com แล้ว peer จะปรากฏในแดชบอร์ดของคุณ

NetBird แบบ self-hosted แตกต่างจาก Headscale อย่างไร?

ทั้งสองอย่างเป็นการแทนที่ control server ที่โฮสต์โดยผู้ให้บริการด้วยเซิร์ฟเวอร์ที่คุณดูแลเอง Headscale เป็นเพียง control plane เท่านั้น: คุณจัดการผ่านคำสั่ง headscale และไฟล์คอนฟิก ไม่มีเว็บคอนโซลอย่างเป็นทางการ และทำงานร่วมกับไคลเอนต์ Tailscale อย่างเป็นทางการ ส่วน NetBird มาพร้อมกับไคลเอนต์ของตัวเอง แดชบอร์ดผู้ดูแลระบบ และการรวมระบบ Identity Provider ไว้ใน stack เดียวกัน Headscale ใช้ทรัพยากรน้อยกว่าและเก็บสถานะไว้ในไฟล์ ส่วน NetBird ใช้งานง่ายกว่าสำหรับผู้ที่ไม่ต้องการใช้ terminal

เซิร์ฟเวอร์ VPS ขนาดเท่าใดที่จำเป็นสำหรับ NetBird แบบ self-hosted?

ขั้นต่ำที่ระบุไว้คือ CPU 1 คอร์ และหน่วยความจำ 2 GB ซึ่ง 2 GB คือขนาดที่ควรเลือกใช้ ปัจจุบันความต้องการขั้นต่ำในทางปฏิบัติลดลงเหลือประมาณ 1 GB ในรุ่นล่าสุดเนื่องจาก Identity Provider ถูกรวมไว้ในตัวแทนที่จะต้องติดตั้งแยกต่างหาก คุณสามารถเลือกไม่ติดตั้งบริการ proxy และ CrowdSec ในระหว่างการติดตั้ง และใช้ SQLite ตามค่าเริ่มต้นไปก่อนจนกว่าคุณจะมีความจำเป็นต้องใช้ PostgreSQL จริงๆ