SSD Nodes Learn Hosting plans →
คู่มือ Matt Connorโดย Matt Connor

วิธีติดตั้ง wg-easy WireGuard ผ่าน Docker พร้อมเว็บ UI

เรียนรู้วิธีติดตั้ง wg-easy บน Docker Compose อย่างถูกต้อง ตั้งค่าพอร์ต 51820 และสิทธิ์ NET_ADMIN พร้อมแก้ปัญหา sysctls ที่จำเป็นเพื่อให้ VPN ใช้งานได้จริงและรองรับ QR code

สิ่งที่คุณกำลังสร้าง

wg-easy คือ WireGuard ที่มาพร้อมกับเว็บอินเทอร์เฟซ โดยทำงานเป็น Docker container หนึ่งชุด มันจะจัดการอินเทอร์เฟซ WireGuard ให้คุณและเพิ่ม UI บนเบราว์เซอร์สำหรับการสร้างไคลเอนต์ ไคลเอนต์ทุกตัวที่คุณสร้างจะได้รับไฟล์คอนฟิกและ QR code ทำให้โทรศัพท์สามารถเชื่อมต่อ VPN ได้เพียงแค่ใช้กล้องส่องไปที่หน้าจอ

ตัวท่อส่งข้อมูล (tunnel) เองนั้นเป็น WireGuard ตามปกติ โมดูลเคอร์เนลจะเป็นตัวย้ายแพ็กเก็ต ดังนั้นอัตราการรับส่งข้อมูลจึงเท่ากับการตั้งค่าด้วยตนเอง สิ่งที่คุณได้รับคือวงจรชีวิตของไคลเอนต์: การเพิ่ม การปิดใช้งาน และการลบ peer โดยไม่ต้องแก้ไขไฟล์คอนฟิกผ่าน SSH สิ่งที่คุณต้องแลกคือการควบคุมคอนฟิกนั้นโดยตรง ซึ่งเป็นหัวข้อของ การตั้งค่า WireGuard ด้วยตนเองบน VPS

คุณจำเป็นต้องมีโฮสต์ Linux ที่คุณสามารถจัดการได้ เช่น KVM VPS ที่มี public IP address หรือโดเมนเนมที่ชี้มายังโฮสต์นั้น, CPU สถาปัตยกรรม x86_64 หรือ arm64, Docker Engine ที่ติดตั้ง Compose plugin และสิทธิ์ root การทำ container virtualization ที่ใช้เคอร์เนลร่วมกับโฮสต์ เช่น OpenVZ หรือ LXC มักจะไม่สามารถโหลดโมดูล WireGuard ได้ และ container จะไม่สามารถเปิดใช้งานอินเทอร์เฟซได้

เวอร์ชัน 15 ย้ายการตั้งค่าออกจาก environment

คู่มือส่วนใหญ่ที่คุณพบถูกเขียนขึ้นสำหรับ wg-easy 14 ซึ่งคุณต้องตั้งค่า WG_HOST เป็นที่อยู่เซิร์ฟเวอร์ของคุณ และ PASSWORD_HASH เป็น bcrypt hash ของรหัสผ่านผู้ดูแลระบบ โดยทั้งคู่กำหนดเป็น environment variables แต่เวอร์ชัน 15 เป็นการเขียนโปรแกรมขึ้นใหม่ บันทึกการย้ายระบบอย่างเป็นทางการระบุไว้อย่างชัดเจนว่า v15 ไม่ใช้ environment variables ชุดเดียวกับ v14 และส่วนใหญ่ถูกย้ายไปไว้ในแผงควบคุมผู้ดูแลระบบบน web UI แล้ว

ดังนั้น WG_HOST และ PASSWORD_HASH จึงไม่มีผลใดๆ อีกต่อไป หากคุณคัดลอกไฟล์ compose เก่ามาใช้ คอนเทนเนอร์จะเริ่มทำงานโดยเพิกเฉยต่อบรรทัดเหล่านั้น จากนั้นจะขอให้คุณสร้างบัญชีผู้ดูแลระบบในเบราว์เซอร์ นี่ไม่ใช่ข้อผิดพลาด แต่เป็นขั้นตอนการตั้งค่าแบบใหม่

ณ เดือนตุลาคม 2026 tag หลักที่ควรระบุคือ 15 ให้ระบุเวอร์ชันหลักแทนการใช้ latest เนื่องจากการอัปเกรดเวอร์ชันหลักจะเปลี่ยนรูปแบบการตั้งค่าบนดิสก์และจะไม่สามารถย้อนกลับได้อย่างสมบูรณ์ การเปลี่ยนมาใช้ 15 ได้แทนที่ไฟล์ JSON ของ v14 ด้วยฐานข้อมูล SQLite

ไฟล์ compose

สร้างไดเรกทอรีสำหรับ stack นี้และเขียนไฟล์ compose อย่างเป็นทางการลงไป นี่คือไฟล์ต้นฉบับจากผู้พัฒนา โดยตัดบรรทัดตัวเลือกที่ถูกคอมเมนต์ไว้ออกไป

sudo mkdir -p /etc/docker/containers/wg-easy
sudo curl -o /etc/docker/containers/wg-easy/docker-compose.yml \
  https://raw.githubusercontent.com/wg-easy/wg-easy/master/docker-compose.yml

เนื้อหาของไฟล์มีลักษณะดังนี้:

volumes:
  etc_wireguard:

services:
  wg-easy:
    image: ghcr.io/wg-easy/wg-easy:15
    container_name: wg-easy
    networks:
      wg:
        ipv4_address: 10.42.42.42
        ipv6_address: fdcc:ad94:bacf:61a3::2a
    volumes:
      - etc_wireguard:/etc/wireguard
      - /lib/modules:/lib/modules:ro
    ports:
      - "51820:51820/udp"
      - "51821:51821/tcp"
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    sysctls:
      - net.ipv4.ip_forward=1
      - net.ipv4.conf.all.src_valid_mark=1
      - net.ipv6.conf.all.disable_ipv6=0
      - net.ipv6.conf.all.forwarding=1
      - net.ipv6.conf.default.forwarding=1

networks:
  wg:
    driver: bridge
    enable_ipv6: true
    ipam:
      driver: default
      config:
        - subnet: 10.42.42.0/24
        - subnet: fdcc:ad94:bacf:61a3::/64

etc_wireguard คือ named volume ที่เก็บคีย์ของเซิร์ฟเวอร์และไคลเอนต์ทุกตัวที่คุณสร้างขึ้น โดยจัดเก็บไว้ในฐานข้อมูล SQLite ที่ชื่อ wg-easy.db โปรดสำรองข้อมูล volume นี้ไว้ มิฉะนั้นการสร้างระบบใหม่จะทำให้ข้อมูล peer ทั้งหมดของคุณสูญหาย หากคุณต้องการให้ไฟล์เหล่านี้ปรากฏบนระบบไฟล์ของโฮสต์ ให้เปลี่ยนไปใช้ bind mount แทน แต่โปรดอ่าน ความแตกต่างระหว่าง bind mounts และ named volumes ก่อนดำเนินการ เนื่องจากสิทธิ์การเข้าถึงไฟล์ (permissions) มีการทำงานที่แตกต่างกัน

เหตุผลที่ต้องใช้ NET_ADMIN, SYS_MODULE และ sysctl

โดยปกติแล้วคอนเทนเนอร์จะไม่ได้รับอนุญาตให้เข้าถึง network stack ของระบบ และแต่ละบรรทัดที่ระบุไว้เป็นการปลดล็อกข้อจำกัดเฉพาะส่วน

NET_ADMIN ช่วยให้คอนเทนเนอร์สามารถสร้างอินเทอร์เฟซ wg0 กำหนดที่อยู่ IP และเขียนเส้นทางเครือข่าย (routes) ได้ หากไม่มีสิทธิ์นี้ คอนเทนเนอร์จะเริ่มทำงานแล้วหยุดไปในขณะที่กำลังเปิดใช้งานอินเทอร์เฟซ เนื่องจาก ip link add wg0 type wireguard จะส่งค่ากลับเป็น Operation not permitted

SYS_MODULE ร่วมกับการ mount /lib/modules แบบอ่านอย่างเดียว ช่วยให้คอนเทนเนอร์สามารถโหลด kernel module ของ WireGuard ได้ในกรณีที่โฮสต์ยังไม่ได้โหลดโมดูลดังกล่าวไว้ โมดูลนี้จะอยู่ใน kernel ของโฮสต์ ไม่ได้อยู่ในอิมเมจของคอนเทนเนอร์ จึงจำเป็นต้องทำให้ไดเรกทอรีของโฮสต์มองเห็นได้จากภายในคอนเทนเนอร์ สำหรับ kernel รุ่นใหม่ โมดูลนี้มักจะถูกรวมไว้ในตัว kernel อยู่แล้ว ซึ่งคุณสามารถตรวจสอบได้ด้วยคำสั่ง sudo modprobe wireguard && echo ok บนโฮสต์

net.ipv4.ip_forward=1 สั่งให้ kernel ส่งต่อแพ็กเก็ตที่ไม่ได้มีจุดหมายปลายทางมาที่เครื่องนี้โดยตรง หากไม่มีการตั้งค่านี้ ไคลเอนต์จะเชื่อมต่อได้สำเร็จและทำ handshake ผ่าน แต่แพ็กเก็ตทั้งหมดที่จะออกสู่อินเทอร์เน็ตจะถูกทิ้ง ทำให้ ping 1.1.1.1 หมดเวลา (timeout) ทั้งที่สถานะ VPN ดูเหมือนเชื่อมต่ออยู่

net.ipv4.conf.all.src_valid_mark=1 เป็นสิ่งที่มักทำให้ผู้ใช้งานประหลาดใจ WireGuard จะทำเครื่องหมาย (mark) แพ็กเก็ตขาออกของตัวเองไว้เพื่อไม่ให้ถูกส่งกลับเข้าไปในอุโมงค์ (tunnel) อีกครั้ง ซึ่งการตรวจสอบ reverse path filtering แบบเข้มงวดจะมองว่าแพ็กเก็ตที่มีที่อยู่ต้นทางไม่ตรงกับเส้นทางที่คาดไว้เป็นสิ่งผิดปกติและทิ้งแพ็กเก็ตนั้นไป การตั้งค่า sysctl นี้จะบอกให้ kernel ยอมรับแพ็กเก็ตที่มีการทำเครื่องหมายไว้ ซึ่งเป็นสิ่งที่ป้องกันไม่ให้ full tunnel ทำงานผิดพลาดด้วยตัวมันเอง

เริ่มการทำงานและสร้างบัญชีผู้ดูแลระบบ

cd /etc/docker/containers/wg-easy
sudo docker compose up -d
sudo docker compose logs -f

ให้ใช้ docker compose up และ docker compose down แทนการใช้ start และ stop เนื่องจาก start จะทำการรีสตาร์ทเฉพาะคอนเทนเนอร์ที่มีอยู่เดิมเท่านั้น ดังนั้นการเปลี่ยนแปลงใดๆ ที่คุณทำในไฟล์ compose รวมถึงการตั้งค่า network และ sysctl จะไม่มีผล ในขณะที่ up จะสร้างคอนเทนเนอร์ขึ้นใหม่ตามการเปลี่ยนแปลงที่เกิดขึ้น หากคุณต้องการให้ stack กลับมาทำงานหลังจากรีบูต restart: unless-stopped ได้ครอบคลุมส่วนนี้ไว้แล้ว และ พฤติกรรมการบูตของบริการ compose จะอธิบายว่านโยบายดังกล่าวรับประกันและไม่รับประกันสิ่งใดบ้าง

Web UI จะรับฟังการเชื่อมต่อที่ TCP 51821 ในการเข้าใช้งานครั้งแรก ระบบจะแสดงหน้าตั้งค่าเพื่อให้คุณสร้างบัญชีผู้ดูแลระบบและยืนยันที่อยู่ของโฮสต์ที่ไคลเอนต์จะใช้เชื่อมต่อกับเซิร์ฟเวอร์ ที่อยู่โฮสต์ดังกล่าวจะถูกนำไปใส่ในบรรทัด Endpoint ของไฟล์คอนฟิกไคลเอนต์ทุกชุด ดังนั้นที่อยู่นี้จะต้องเป็น Public IP หรือชื่อ DNS ของ VPS หากระบุผิดพลาด QR code ที่คุณส่งให้โทรศัพท์จะชี้ไปยังจุดที่ไม่สามารถเข้าถึงได้ และการทำ handshake จะไม่สำเร็จ

อีกเรื่องหนึ่งเกี่ยวกับพอร์ตนี้: wg-easy ไม่ได้ทำหน้าที่เป็น TLS termination ด้วยตัวเอง และไม่ได้ปฏิเสธการเชื่อมต่อแบบ plain HTTP หากเข้าใช้งานผ่าน http:// ตัว UI จะยังคงโหลดขึ้นมาและแสดงแถบคำเตือน สิ่งที่ค่าเริ่มต้นเปลี่ยนแปลงคือ session cookie ซึ่งมี flag Secure กำกับอยู่ ดังนั้นเบราว์เซอร์ที่เข้าถึง UI ผ่าน plain HTTP บน public address จะละทิ้งคุกกี้นี้และทำให้ไม่สามารถล็อกอินค้างไว้ได้ INSECURE=true จะลบ flag ดังกล่าวออกและไม่มีผลอื่นใด การวาง reverse proxy ไว้ด้านหน้าเพื่อทำ TLS termination แม้จะเป็น self-signed certificate ก็ไม่จำเป็นต้องแก้ไขการตั้งค่าใดๆ ใน wg-easy เลย

ห้ามเปิดพอร์ต UI สู่สาธารณะ

ไฟล์ compose จะเปิดพอร์ต 51821 บนทุกอินเทอร์เฟซ ซึ่งเป็นหน้าล็อกอินสำหรับระบบที่สามารถกำหนดเส้นทางทราฟฟิกของคุณได้ จึงไม่ควรเปิดให้โลกภายนอกเข้าถึง การเปิดพอร์ตใน Docker จะเขียนกฎลงใน chain DOCKER ซึ่งจะถูกประเมินก่อน ufw ดังนั้นกฎ deny ของ ufw จึงไม่สามารถปิดพอร์ตนี้ได้ กับดักนี้เป็นเรื่องที่ควรทำความเข้าใจแยกต่างหาก และ เหตุใดพอร์ตที่เปิดโดย Docker จึงเพิกเฉยต่อ ufw ได้อธิบายเรื่องนี้ไว้อย่างละเอียด

วิธีแก้ไขที่ง่ายที่สุดคือการ bind UI ไว้ที่ loopback และเข้าถึงผ่าน SSH tunnel:

    ports:
      - "51820:51820/udp"
      - "127.0.0.1:51821:51821/tcp"
    environment:
      - INSECURE=true

จากนั้นจากแล็ปท็อปของคุณ:

ssh -L 51821:127.0.0.1:51821 youruser@your.server.address

เปิด http://127.0.0.1:51821 ในเบราว์เซอร์บนแล็ปท็อปของคุณ ทราฟฟิกจะถูกเข้ารหัสโดย SSH และพอร์ตนี้จะไม่ตอบสนองต่อผู้อื่น INSECURE=true จะลบเพียง flag Secure ออกจาก session cookie เพื่อให้เบราว์เซอร์คงสถานะการล็อกอินของคุณไว้บนที่อยู่ plain HTTP นี้ ซึ่งมีความปลอดภัยในกรณีนี้เนื่องจากทราฟฟิก plain HTTP จะไม่หลุดออกไปนอกอินเทอร์เฟซ loopback

เปิดพอร์ต UDP 51820 และตรวจสอบไฟร์วอลล์ทั้งสองชั้น

ตัว WireGuard เองจำเป็นต้องเข้าถึงพอร์ต UDP 51820 ได้จากอินเทอร์เน็ต แม้ Docker จะทำการ publish พอร์ตนี้ไว้แล้ว แต่ผู้ให้บริการหลายรายมักมีไฟร์วอลล์เครือข่ายแยกต่างหากอยู่หน้า VPS ซึ่ง Docker ไม่สามารถรับรู้ได้ คุณจึงต้องเปิดพอร์ตในทั้งสองจุด หากคุณจัดการไฟร์วอลล์ของโฮสต์ด้วย ufw การใช้ กฎพื้นฐานของ ufw สำหรับ VPS จะเป็นวิธีที่รวดเร็วกว่าการเขียน nftables ด้วยตนเอง

ตรวจสอบว่าคอนเทนเนอร์กำลังรอรับการเชื่อมต่ออยู่จริงหรือไม่:

sudo ss -ulnp | grep 51820

คุณควรจะเห็น UDP socket ที่อยู่ในสถานะ listening หากไม่ปรากฏข้อมูลในบรรทัดดังกล่าว แสดงว่าคอนเทนเนอร์ไม่สามารถเปิดใช้งานอินเทอร์เฟซได้ และ sudo docker compose logs wg-easy จะระบุสาเหตุของปัญหาให้ทราบ

สร้างไคลเอนต์และสแกนบนโทรศัพท์

ใน UI ให้สร้างไคลเอนต์และตั้งชื่อที่คุณจะจำได้ในภายหลัง เช่น ชื่ออุปกรณ์ที่ใช้งาน wg-easy จะจัดสรรที่อยู่ tunnel ที่ว่างถัดไปและสร้างคู่กุญแจให้คุณโดยอัตโนมัติ แต่ละแถวของไคลเอนต์จะมี QR code และไฟล์ .conf ให้ดาวน์โหลด

ติดตั้งแอป WireGuard อย่างเป็นทางการบนโทรศัพท์ เลือกเพิ่ม tunnel จาก QR code แล้วหันกล้องไปที่รหัสบนหน้าจอของคุณ tunnel จะปรากฏขึ้นพร้อมชื่อที่คุณตั้งไว้ เปิดใช้งาน tunnel แล้วแถวของไคลเอนต์ใน UI จะเริ่มแสดงตัวนับการรับส่งข้อมูลและเวลาการทำ handshake ล่าสุด เมื่อโทรศัพท์เชื่อมต่อกับ tunnel แล้ว จะสามารถเข้าถึงบริการที่คุณไม่ได้เปิดเผยต่อสาธารณะได้ ซึ่งเป็นวิธีที่โทรศัพท์ใช้ในการอัปโหลดไปยัง เซิร์ฟเวอร์รูปภาพที่โฮสต์เอง จากที่ใดก็ได้ โดยที่เซิร์ฟเวอร์นั้นไม่ต้องเปิดพอร์ตใดๆ สู่โลกภายนอก เทคนิคเดียวกันนี้ยังใช้กับสื่อบันเทิงได้ เช่น คลังสื่อ Jellyfin ที่ปรับโฉมเป็นร้านวิดีโอในยุค 90 ซึ่งเป็นสิ่งที่น่าใช้งานจากห้องพักโรงแรมในขณะที่ยังคงความเป็นส่วนตัวเหมือนอยู่บน LAN ของคุณ การแจ้งเตือนจะทำงานในทางกลับกันบน tunnel เดียวกันนี้ เนื่องจาก เซิร์ฟเวอร์ ntfy ที่โฮสต์เอง สามารถส่งข้อความไปยังโทรศัพท์เครื่องนั้นได้ทันทีที่งานสำรองข้อมูลล้มเหลว โดยไม่ต้องตอบรับคำขอจากอินเทอร์เน็ตสาธารณะเลย

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

สำหรับเดสก์ท็อป ให้ดาวน์โหลดไฟล์ .conf แล้วนำเข้าสู่ไคลเอนต์ WireGuard แทนการพิมพ์ใหม่ กุญแจส่วนตัว (private key) ในไฟล์นั้นจะถูกสร้างขึ้นและแสดงให้เห็นเพียงครั้งเดียวเท่านั้น ให้ปฏิบัติต่อไฟล์นี้เช่นเดียวกับที่คุณปฏิบัติต่อกุญแจส่วนตัวของ SSH

เมื่อไหร่ที่ควรเลิกใช้ UI

wg-easy เป็นเครื่องมือที่เหมาะสมในขณะที่ peer ของคุณคือบุคคลและโทรศัพท์มือถือ UI ทำงานได้เร็วกว่าการแก้ไขไฟล์คอนฟิก และการเพิกถอนสิทธิ์โทรศัพท์ที่สูญหายทำได้เพียงคลิกเดียว

คุณจะพบข้อจำกัดเมื่อต้องการสิ่งที่ UI ไม่รองรับ การทำ site to site routing ซึ่ง AllowedIPs ของ peer ครอบคลุมทั้ง subnet ระยะไกลแทนที่จะเป็นเพียงที่อยู่เดียว มักจะเป็นกำแพงด่านแรกที่พบ การทำ split tunnel ที่มีกฎการกำหนดเส้นทางแยกตาม peer หรือคอนฟิกที่สร้างโดยเครื่องมือ provisioning ของคุณคือด่านถัดไป ณ จุดนั้น การตั้งค่าด้วยตนเองไม่ได้ยากกว่า เพียงแต่แตกต่างออกไป และ คู่มือ WireGuard แบบมาตรฐาน แสดงให้เห็นถึงการสร้างท่อส่งข้อมูลเดียวกันจาก wg0.conf หากคุณต้องการหยุดรัน control plane โดยสิ้นเชิง การเปรียบเทียบ WireGuard กับ Tailscale จะครอบคลุมถึงตัวเลือกแบบที่มีผู้จัดการให้ การที่นั่นเป็นการแลกเปลี่ยนที่คุ้มค่าหรือไม่ขึ้นอยู่กับว่า coordination server สามารถเข้าถึงอะไรได้บ้าง และ โมเดลความเชื่อถือของ Tailscale เป็นสิ่งที่ควรอ่านก่อนที่คุณจะมอบเครือข่ายของคุณให้พวกเขา ค่าใช้จ่ายมักเป็นคำถามถัดไป และ สิ่งที่แผนฟรีของ Tailscale ครอบคลุมจริงๆ คือผู้ใช้สูงสุด 6 คนโดยไม่มีค่าใช้จ่าย สำหรับการใช้งานที่ไม่ใช่เชิงพาณิชย์เท่านั้น ดังนั้นครัวเรือนจึงไม่ต้องเสียค่าใช้จ่าย ในขณะที่ทีมธุรกิจขนาดเล็กไม่มีสิทธิ์ใช้แม้จะมีจำนวนคนน้อยก็ตาม หลังจากจุดนั้น การเรียกเก็บเงินจะนับตามจำนวนผู้ใช้แทนที่จะเป็นจำนวนอุปกรณ์ ซึ่งเป็นรูปแบบการเรียกเก็บเงินที่ต่างจาก VPS ที่คุณจ่ายอยู่แล้ว ดังนั้น ค่าใช้จ่ายของ Tailscale เมื่อคุณเกินขีดจำกัดของแผนฟรี คือตัวเลขที่ควรตรวจสอบก่อนที่คุณจะย้ายทีม ท่อส่งข้อมูลแบบเต็มที่คุณเพิ่งสร้างไปมีสิ่งที่เทียบเท่ากันที่นั่น เนื่องจาก การประกาศให้ VPS เป็น Tailscale exit node จะทำให้คุณได้เส้นทางออกผ่านเซิร์ฟเวอร์แบบเดียวกัน โดยอนุมัติใน admin console แทนที่จะต้องเขียนลงในคอนฟิกของไคลเอนต์แต่ละตัว กำแพงเรื่อง subnet ก็มีสิ่งที่เทียบเท่ากันเช่นกัน เพราะ การประกาศเครือข่ายส่วนตัวทั้งหมดจาก VPS จะส่งเครือข่ายนั้นให้กับทุกอุปกรณ์ใน tailnet โดยไม่ต้องแก้ไข AllowedIPs ราย peer ซึ่งเป็นสาเหตุที่ทำให้คุณต้องเลิกใช้ UI หากคุณต้องการแดชบอร์ดและการทำ mesh routing อัตโนมัติ แต่ไม่ต้องการใช้ coordination server ของผู้อื่น การรัน NetBird server ของคุณเองบน VPS จะช่วยเก็บ control plane ไว้บนฮาร์ดแวร์ที่คุณเป็นเจ้าของ โดยแลกกับการตั้งค่า DNS และ TLS ที่ wg-easy ไม่เคยถามคุณ

หากไวยากรณ์ของ compose ด้านบนเป็นส่วนที่คุณไม่คุ้นเคยมากกว่าส่วนของ WireGuard พื้นฐาน Docker Compose บน VPS จะอธิบายรูปแบบไฟล์และคำสั่งที่ใช้ในชีวิตประจำวัน

FAQ

เหตุใด wg-easy จึงเพิกเฉยต่อ WG_HOST และ PASSWORD_HASH ของฉัน?

ตัวแปรเหล่านั้นเป็นของ wg-easy 14 ส่วนเวอร์ชัน 15 เป็นการเขียนใหม่ทั้งหมด และผู้พัฒนาได้ย้ายการตั้งค่าเกือบทั้งหมดไปไว้ในแผงควบคุมใน Web UI คอนเทนเนอร์จะไม่เรียกอ่านตัวแปรทั้งสอง ดังนั้นมันจะเริ่มทำงานตามปกติและขอให้คุณสร้างบัญชีผู้ดูแลระบบในการเข้าใช้งานครั้งแรก ให้ตั้งค่าที่อยู่โฮสต์สำหรับไคลเอนต์ในหน้าตั้งค่านั้นแทน

ฉันจำเป็นต้องใช้ SYS_MODULE หรือไม่หากเคอร์เนลของฉันมี WireGuard อยู่แล้ว?

ไม่จำเป็น SYS_MODULE และการ mount /lib/modules มีไว้เพื่อให้คอนเทนเนอร์สามารถโหลดโมดูลได้ในกรณีที่โฮสต์ยังไม่มี บนโฮสต์ที่คำสั่ง sudo modprobe wireguard ทำงานได้สำเร็จอยู่แล้ว ความสามารถนี้ก็ไม่มีความจำเป็น การลบออกเป็นขั้นตอนการเพิ่มความปลอดภัยที่สมเหตุสมผล และยังคงต้องใช้ NET_ADMIN ไม่ว่าจะในกรณีใดก็ตาม

ไคลเอนต์เชื่อมต่อได้แต่ไม่มีอินเทอร์เน็ต เกิดอะไรขึ้น?

การทำ handshake ได้แต่ไม่มีทราฟฟิกมักหมายถึงปัญหาเรื่อง forwarding ให้ยืนยันว่า net.ipv4.ip_forward=1 และ net.ipv4.conf.all.src_valid_mark=1 ยังคงอยู่ในไฟล์ compose เนื่องจากไฟล์ที่คัดลอกมาแก้ไขมักจะทำส่วนนี้หายไป หากเปิด forwarding แล้ว ให้ตรวจสอบ DNS server ที่ไคลเอนต์ได้รับมา อุโมงค์ที่ส่งทราฟฟิกทั้งหมดผ่าน VPN แต่ชี้ไปยัง DNS server ที่ไม่สามารถเข้าถึงได้ จะแสดงผลเหมือนการเชื่อมต่อที่ตายแล้วในเบราว์เซอร์

ฉันจะสำรองข้อมูลไคลเอนต์ได้อย่างไร?

ข้อมูลทั้งหมดอยู่ใน volume ที่ตั้งชื่อว่า etc_wireguard ในเวอร์ชัน 15 หมายถึงฐานข้อมูล SQLite ที่ /etc/wireguard/wg-easy.db ภายในคอนเทนเนอร์ เอกสารของ v15 ไม่ได้ระบุถึงฟีเจอร์การสำรองข้อมูลหรือส่งออกข้อมูล ดังนั้นให้สำรองข้อมูลตัว volume เอง: รันคำสั่ง docker compose down, คัดลอกเนื้อหาของ volume ไปไว้ที่อื่นนอกเซิร์ฟเวอร์ จากนั้นจึงนำ stack กลับมาทำงานด้วย docker compose up -d ให้ทำขั้นตอนนี้ก่อนการอัปเกรดใดๆ ไฟล์ wg0.json ที่คู่มือเก่ากล่าวถึงเป็นของ wg-easy 14 ซึ่งเป็นสิ่งที่ปุ่มสำรองข้อมูลของ v14 ส่งออก และใน v15 ประโยชน์เดียวของมันคือการใช้เป็นไฟล์สำหรับอัปโหลดในตัวช่วยตั้งค่าเมื่อคุณย้ายข้อมูลจากการติดตั้งเก่า

ฉันสามารถรัน wg-easy หลัง reverse proxy ได้หรือไม่?

ได้ ให้วาง proxy ไว้หน้าพอร์ต Web UI, ทำ TLS termination ที่นั่น และไม่ต้องตั้งค่า INSECURE คอนเทนเนอร์จะยอมรับการเชื่อมต่อแบบ plain HTTP จาก proxy ตามปกติ และตัวอย่างการตั้งค่า Caddy และ Traefik อย่างเป็นทางการก็ไม่ได้กำหนดตัวแปร INSECURE ใดๆ เลย เนื่องจากเบราว์เซอร์สื่อสารผ่าน HTTPS กับ proxy คุณจึงต้องการให้ session cookie คง flag Secure ไว้ ซึ่งเป็นสิ่งเดียวที่ INSECURE=true จะลบออก ให้เปิดพอร์ต UDP 51820 ไว้โดยตรง เนื่องจากทราฟฟิก VPN เป็น UDP และไม่ผ่าน HTTP proxy

บทความนี้มีประโยชน์หรือไม่