วิธีติดตั้ง wg-easy บน Docker พร้อมตั้งค่า WireGuard VPN

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

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

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

คุณจำเป็นต้องมี KVM VPS ที่มี public IPv4 address, Docker Engine ที่ติดตั้ง Compose plugin และสิทธิ์ root การทำ container virtualization ที่ใช้ kernel ร่วมกับโฮสต์ เช่น OpenVZ หรือ LXC มักจะไม่สามารถโหลด WireGuard module ได้ และ 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 ในการเข้าใช้งานครั้งแรก ระบบจะแสดงหน้าตั้งค่าเพื่อให้คุณสร้างบัญชีผู้ดูแลระบบและยืนยัน host address ที่ไคลเอนต์จะใช้เชื่อมต่อมายังเซิร์ฟเวอร์ host address ดังกล่าวจะถูกนำไปใส่ในบรรทัด Endpoint ของไฟล์คอนฟิกไคลเอนต์ทุกชุด ดังนั้นค่านี้จะต้องเป็น Public IP หรือ DNS name ของ VPS หากระบุผิดพลาด QR code ที่คุณส่งให้โทรศัพท์จะชี้ไปยังตำแหน่งที่ไม่สามารถเข้าถึงได้ และการทำ handshake จะไม่สำเร็จ

อีกเรื่องหนึ่งเกี่ยวกับพอร์ตดังกล่าว: wg-easy 15 จะปฏิเสธการเชื่อมต่อผ่าน HTTP ธรรมดา เว้นแต่คุณจะตั้งค่า INSECURE=true การเข้าถึงผ่าน HTTPS ด้วยใบรับรองที่ไม่น่าเชื่อถือ หรือการทำ TLS termination ที่ reverse proxy ด้านหน้าบริการนั้นถือว่าใช้งานได้ตามปกติ แต่การเข้าถึงผ่าน http:// ด้วยการตั้งค่าเริ่มต้นนั้นไม่สามารถทำได้

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

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

วิธีแก้ไขที่ง่ายที่สุดคือการผูก 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 จะมีความปลอดภัยในกรณีนี้เนื่องจากการรับส่งข้อมูล 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 ที่มีกฎการ routing แยกตามราย peer หรือการใช้คอนฟิกที่สร้างจากเครื่องมือ provisioning ของคุณ ในจุดนั้นการตั้งค่าด้วยตนเองไม่ได้ยากกว่า เพียงแต่มีรูปแบบที่ต่างออกไป และ คู่มือ WireGuard แบบมาตรฐาน แสดงให้เห็นถึงการสร้าง tunnel เดียวกันจาก wg0.conf หากคุณต้องการเลิกดูแล control plane ด้วยตนเอง การเปรียบเทียบ WireGuard กับ Tailscale จะครอบคลุมทางเลือกแบบ managed ว่าการแลกเปลี่ยนนี้คุ้มค่าหรือไม่ขึ้นอยู่กับว่า coordination server สามารถเข้าถึงอะไรได้บ้าง และ โมเดลความเชื่อถือของ Tailscale เป็นสิ่งที่ควรศึกษาให้เข้าใจก่อนที่คุณจะมอบเครือข่ายให้พวกเขาดูแล เรื่องค่าใช้จ่ายมักเป็นคำถามถัดมา และ สิ่งที่แผนฟรีของ Tailscale ครอบคลุมจริง นั้นเพียงพอสำหรับครัวเรือนหรือทีมขนาดเล็กที่จะใช้งานได้โดยไม่มีค่าใช้จ่าย หลังจากจุดนั้นไป การเรียกเก็บเงินจะนับตามจำนวนผู้ใช้แทนจำนวนอุปกรณ์ ซึ่งเป็นรูปแบบค่าใช้จ่ายที่ต่างจาก VPS ที่คุณจ่ายอยู่แล้ว ดังนั้น ค่าใช้จ่ายของ Tailscale เมื่อเกินแผนฟรี คือตัวเลขที่ควรตรวจสอบก่อนย้ายทีมไปใช้งาน tunnel แบบเต็มรูปแบบที่คุณเพิ่งสร้างขึ้นมีสิ่งที่เทียบเท่ากันในระบบนั้น เนื่องจาก การประกาศให้ VPS เป็น Tailscale exit node ช่วยให้คุณได้เส้นทางออกผ่านเซิร์ฟเวอร์แบบเดียวกัน โดยอนุมัติผ่าน admin console แทนการเขียนลงในคอนฟิกของ client แต่ละเครื่อง กำแพงเรื่อง 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 แทน คอนเทนเนอร์จะไม่สนใจตัวแปรทั้งสองนี้ จึงเริ่มทำงานตามปกติแล้วให้คุณสร้างบัญชีผู้ดูแลระบบในการเข้าใช้งานครั้งแรกแทน ให้ตั้งค่าที่อยู่ host สำหรับ client ในหน้าตั้งค่าดังกล่าวแทน

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

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

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

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

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

ข้อมูลทั้งหมดอยู่ใน 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 ไว้หน้า TCP 51821, ทำ TLS termination ที่นั่น และตั้งค่า INSECURE=true บนคอนเทนเนอร์เพื่อให้ยอมรับการเชื่อมต่อ HTTP แบบธรรมดาจาก proxy ส่วน UDP 51820 ให้เปิดใช้งานโดยตรงตามปกติ เนื่องจากข้อมูล VPN เป็น UDP และไม่สามารถผ่าน HTTP proxy ได้