How to Configure a WireGuard Point-to-Site VPN Server on Debian 12

A WireGuard point-to-site VPN on Debian 12 (Bookworm) is a practical way to let laptops, phones, or remote workstations reach a server or route traffic through it. One important clarification comes first: WireGuard does not have a special “server mode.” Every participant is a peer. In a point-to-site design, one Debian host simply acts as the stable, publicly reachable hub and each remote device gets its own key pair and tunnel address.

This guide uses Debian’s packaged WireGuard tools, wg-quick, IPv4 forwarding, and nftables. It assumes the Debian server has root or sudo access and that UDP port 51820 can reach it. If the server is behind a home or office router, you must forward that UDP port to the Debian host. If the ISP uses carrier-grade NAT (CGNAT), ordinary router port forwarding may not be enough; confirm that you actually have a reachable public address before troubleshooting WireGuard itself.

What will this configuration do?

The example VPN uses 10.8.0.0/24. The server is 10.8.0.1, and the first client is 10.8.0.2. The client can be configured as either a full-tunnel VPN, where IPv4 Internet traffic exits through the Debian server, or a split tunnel, where only selected private networks use WireGuard.

Debian’s own WireGuard documentation confirms that WireGuard is available through the distribution packages, while the official WireGuard quick-start documents key generation, wg-quick, and the optional persistent keepalive behavior. See the Debian WireGuard documentation, the official WireGuard Quick Start, and Debian’s wg-quick manual page.

Step 1: Install WireGuard and nftables

Update package metadata, then install WireGuard and nftables:

sudo apt update
sudo apt install wireguard nftables

A common misconception is that Debian 12 needs an out-of-tree WireGuard kernel module. It does not. WireGuard has been in the Linux kernel for years; Debian’s packages provide the userspace management tools you need. Action: use Debian packages instead of downloading an unverified installation script.

Step 2: Generate the server key pair

Create the key files with restrictive permissions:

sudo -i
install -d -m 700 /etc/wireguard
umask 077
wg genkey | tee /etc/wireguard/server_private.key | wg pubkey > /etc/wireguard/server_public.key
chmod 600 /etc/wireguard/server_private.key
cat /etc/wireguard/server_public.key

The private key must remain private. The public key is what you copy into client configurations. Ideally, generate each client’s private key on that client rather than on the server. That way the server never needs to possess client private keys.

Step 3: Enable IPv4 forwarding

อุโมงค์ VPN อาจสร้างขึ้นได้สำเร็จในขณะที่การรับส่งข้อมูลแบบเราเตอร์ยังคงล้มเหลว สาเหตุเป็นเพราะการส่งต่อ IP ของ Linux เป็นการตั้งค่าเคอร์เนลที่แยกต่างหากจาก WireGuard เอง สร้างไฟล์ sysctl แบบถาวร:

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

คำสั่งสุดท้ายควรรายงานnet.ipv4.ip_forward = 1. เอกสารเคอร์เนลของ Debian อธิบายip_forwardว่าเป็นสวิตช์ที่เปิดใช้งานการส่งต่อแพ็กเก็ต IPv4 การดำเนินการ: ตรวจสอบค่านี้อย่างชัดเจนแทนที่จะสันนิษฐานว่าอินเทอร์เฟซอุโมงค์จะเปิดใช้งานการกำหนดเส้นทางโดยอัตโนมัติ ดูคู่มือ Debian ip(7)และเอกสารsysctl.conf

ขั้นตอนที่ 4: สร้างการตั้งค่าเซิร์ฟเวอร์

อ่านรหัสส่วนตัวของเซิร์ฟเวอร์ จากนั้นสร้าง/etc/wireguard/wg0.conf:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.8.0.2/32

จากนั้นให้ปกป้องไฟล์:

sudo chmod 600 /etc/wireguard/wg0.conf

AllowedIPsมักเข้าใจผิดว่าเป็นเพียงรายการอนุญาตแบบไฟร์วอลล์เท่านั้น แต่จริงๆ แล้วมันยังควบคุมการกำหนดเส้นทางด้วย บนเซิร์ฟเวอร์ การกำหนดให้10.8.0.2/32กับ peer นี้จะบอก WireGuard ว่าแพ็กเก็ตสำหรับที่อยู่ tunnel นั้นเป็นของไคลเอ็นต์นี้ ให้ไคลเอ็นต์แต่ละรายมีที่อยู่ที่ไม่ซ้ำกันและ[Peer]บล็อก แยกต่างหาก

อีกทางเลือกที่มีประโยชน์คือ การละเว้นSaveConfig = trueเมื่อคุณตั้งใจจะจัดการไฟล์นี้ด้วยตนเอง การใช้คำสั่ง ` SaveConfigset_state_file` wg-quickสามารถเขียนสถานะปัจจุบันกลับไปยังการกำหนดค่าเมื่อปิดระบบ ซึ่งอาจเขียนทับการแก้ไขด้วยตนเองได้ คำแนะนำ: เก็บไฟล์ไว้ในรูปแบบประกาศเว้นแต่คุณต้องการบันทึกสถานะปัจจุบันโดยเฉพาะ

ขั้นตอนที่ 5: กำหนดค่าการทำ masquerading ของ nftables

หากไคลเอ็นต์แบบฟูลทูเนลต้องการเข้าถึงอินเทอร์เน็ตผ่านเซิร์ฟเวอร์ Debian วิธีที่ง่ายที่สุดคือการใช้ IPv4 masquerading ขั้นแรกให้ระบุอินเทอร์เฟซขาออกของเซิร์ฟเวอร์:

ip route get 1.1.1.1

มองหาอินเทอร์เฟซหลังจากนั้นdevเช่นeth0, ens3, หรือenp1s0อย่าคิดว่ามันจะเป็นแบบนั้นเสมอeth0ไป

หากคุณดูแลรักษาระบบอยู่แล้ว/etc/nftables.confให้ผสานตาราง NAT ต่อไปนี้เข้ากับชุดกฎที่มีอยู่ของคุณแทนที่จะแทนที่ไฟล์:

table ip wireguard-nat {
    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        oifname "eth0" ip saddr 10.8.0.0/24 masquerade
    }
}

แทนที่eth0ด้วยอินเทอร์เฟซขาออกจริง ตรวจสอบความถูกต้องก่อนโหลด:

sudo nft -c -f /etc/nftables.conf
sudo systemctl enable --now nftables
sudo nft list ruleset

WireGuard ไม่จำเป็นต้องใช้ NAT โดยพื้นฐาน หาก LAN ปลายทางมีเส้นทางย้อนกลับไปยังเซิร์ฟเวอร์อยู่แล้ว10.8.0.0/24การเข้าถึงแบบกำหนดเส้นทางสามารถทำงานได้โดยไม่ต้องใช้การปลอมแปลงที่อยู่ IP NAT มีประโยชน์หลักๆ เมื่อคุณต้องการให้ไคลเอ็นต์ระยะไกลใช้เส้นทางอินเทอร์เน็ตที่มีอยู่ของเซิร์ฟเวอร์ และคุณไม่ได้ควบคุมเส้นทางย้อนกลับที่อื่น คำแนะนำ: ใช้การปลอมแปลงที่อยู่ IP สำหรับกรณีการส่งออกไปยังอินเทอร์เน็ตแบบง่ายๆ ควรเลือกใช้การกำหนดเส้นทางแบบชัดเจนเมื่อคุณควบคุมเครือข่ายและต้องการรักษาที่อยู่ต้นทางไว้

คุณจำเป็นต้องตั้งค่ากฎไฟร์วอลล์ด้วยหรือไม่?

ขึ้นอยู่กับไฟร์วอลล์ที่ติดตั้งไว้แล้ว หากนโยบายการรับข้อมูลของ nftables เข้มงวด ให้อนุญาตการรับส่งข้อมูล UDP ขาเข้า51820หากเชนการส่งต่อของคุณมีนโยบายการปฏิเสธโดยค่าเริ่มต้น ให้เพิ่มกฎที่นั่นเพื่ออนุญาตการรับส่งข้อมูลจากwg0ไปยังปลายทางที่ต้องการ และอนุญาตการรับส่งข้อมูลขาเข้าที่กำหนดไว้แล้ว ผู้ให้บริการ Cloud VPS อาจมีกลุ่มความปลอดภัยหรือไฟร์วอลล์ของผู้ให้บริการแยกต่างหากที่ต้องอนุญาต UDP 51820ด้วย

อย่าคัดลอกชุดกฎไฟร์วอลล์แบบตั้งค่าเริ่มต้นใหม่ทั้งหมดไปวางในเซิร์ฟเวอร์ SSH ระยะไกลโดยไม่ตรวจสอบให้ดี เพราะอาจทำให้คุณเข้าใช้งานไม่ได้ วิธีแก้ไข: ตรวจสอบsudo nft list rulesetและผสาน WireGuard เข้ากับไฟร์วอลล์ที่คุณมีอยู่แล้ว

ขั้นตอนที่ 6: สร้างโปรไฟล์ลูกค้า

บนฝั่งไคลเอ็นต์ ให้สร้างคู่คีย์ของตัวเองโดยใช้แอป WireGuard หรือwg genkeyโปรไฟล์ IPv4 แบบ full-tunnel จะมีลักษณะดังนี้:

[Interface]
Address = 10.8.0.2/24
PrivateKey = CLIENT_PRIVATE_KEY
DNS = 1.1.1.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

แทนที่vpn.example.comด้วยชื่อ DNS สาธารณะหรือ IP สาธารณะของเซิร์ฟเวอร์DNSบรรทัดนี้เป็นตัวเลือก และการรองรับการใช้งานของไคลเอ็นต์อาจแตกต่างกันไป สำหรับการแบ่งอุโมงค์ ให้เปลี่ยนAllowedIPsเป็นเฉพาะเครือข่ายที่ควรผ่าน VPN เท่านั้น เช่น10.8.0.0/24บวกกับ LAN ส่วนตัว เช่น192.168.50.0/24.

PersistentKeepalive = 25การตั้งค่านี้ก็เป็นตัวเลือกเช่นกัน เอกสารอย่างเป็นทางการของ WireGuard แนะนำว่า 25 วินาทีเป็นค่าที่เหมาะสมเมื่ออุปกรณ์ปลายทางที่อยู่หลัง NAT หรือไฟร์วอลล์แบบ Stateful จำเป็นต้องรักษาการแมปข้อมูลไว้ในระหว่างช่วงเวลาที่ไม่ได้ใช้งาน การตั้งค่านี้ไม่ใช่การตั้งค่าเพื่อเพิ่มประสิทธิภาพและไม่จำเป็นสำหรับอุปกรณ์ทุกเครื่อง วิธีใช้: ควรใช้เป็นหลักสำหรับอุปกรณ์ที่โรมมิ่งหรืออุปกรณ์ที่ใช้ NAT ซึ่งหากไม่ตั้งค่านี้จะไม่สามารถติดต่อได้หลังจากช่วงเวลาที่ไม่ได้ใช้งาน

ขั้นตอนที่ 7: เริ่ม WireGuard เมื่อบูตเครื่อง

ก่อนอื่นให้เปิด nftables ขึ้นมา จากนั้นจึงเปิดใช้งานอินเทอร์เฟซ WireGuard:

sudo systemctl enable --now nftables
sudo systemctl enable --now wg-quick@wg0
systemctl is-active nftables
systemctl is-active wg-quick@wg0

wg-quick@wg0อ่านว่า/etc/wireguard/wg0.conf. wg-quickคู่มือยืนยันว่ารูปแบบการตั้งชื่อนี้เป็นทางลัดปกติสำหรับการกำหนดค่าที่จัดเก็บไว้ภายใต้/etc/wireguard. การดำเนินการ: ใช้บริการแทนสคริปต์บูตแบบกำหนดเอง เว้นแต่คุณจะมีดีไซน์ตัวจัดการเครือข่ายที่ซับซ้อนกว่า

ขั้นตอนที่ 8: ตรวจสอบการเชื่อมต่อและการรับส่งข้อมูล

เชื่อมต่อไคลเอ็นต์ จากนั้นตรวจสอบเซิร์ฟเวอร์:

sudo wg show
ip address show wg0
ping -c 3 10.8.0.2

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

ปัญหาทั่วไปและความหมายที่แท้จริงของปัญหาเหล่านั้น

อุโมงค์เต็มรูปแบบหรืออุโมงค์แบบแบ่งส่วน: คุณควรเลือกแบบไหน?

ใช้ Full Tunnel เมื่อเป้าหมายคือการปกป้องการรับส่งข้อมูลบน Wi-Fi ที่ไม่น่าเชื่อถือ หรือต้องการให้การรับส่งข้อมูลอินเทอร์เน็ตออกจากเซิร์ฟเวอร์ Debian ใช้ Split Tunnel เมื่อคุณต้องการเข้าถึงเซิร์ฟเวอร์ เครือข่ายภายในบ้าน ห้องปฏิบัติการ หรือแอปพลิเคชันภายในจากระยะไกลเท่านั้น และต้องการให้การรับส่งข้อมูลอินเทอร์เน็ตปกติอยู่ภายในเครือข่ายนั้น การเลือกใช้ขึ้นอยู่กับการตั้งค่าของไคลเอ็นต์เป็นAllowedIPsหลัก

สำหรับการใช้งานแบบจุดต่อไซต์ขนาดเล็ก การกำหนดค่าข้างต้นก็เพียงพอที่จะสร้างพื้นฐานที่บำรุงรักษาได้: บล็อกเพียร์หนึ่งบล็อกต่อไคลเอ็นต์หนึ่งราย ที่อยู่ท่อส่งข้อมูลที่ไม่ซ้ำกัน บริการที่จัดการโดย Debian และ nftables สำหรับพฤติกรรมการกำหนดเส้นทางที่คุณต้องการจริง สำหรับการใช้งานขนาดใหญ่ การแจกจ่ายคีย์ วงจรชีวิตของเพียร์ DNS การบันทึก และการจัดการการกำหนดค่าจะกลายเป็นข้อกังวลในการดำเนินงาน แม้ว่าโปรโตคอล WireGuard เองจะยังคงเรียบง่ายก็ตาม

รายการตรวจสอบการยืนยันขั้นสุดท้าย

• wg-quick@wg0มีความกระตือรือร้นและwg0มี10.8.0.1/24อยู่
• เซิร์ฟเวอร์รับฟังการเชื่อมต่อผ่านโปรโตคอล UDP 51820และสามารถเข้าถึงพอร์ตดังกล่าวได้ผ่านไฟร์วอลล์หรือเราเตอร์ต้นทางใดๆ ก็ตาม
• ลูกค้าแต่ละรายจะมีคู่คีย์เฉพาะของตนเองและ/32ข้อมูลที่ไม่ซ้ำกันบนเซิร์ฟเวอร์
• net.ipv4.ip_forwardเท่ากับ1เมื่อต้องการการเข้าถึงแบบกำหนดเส้นทาง
• การแปลงที่อยู่เครือข่าย (masquerading) ของ nftables มีอยู่สำหรับการเข้าถึงอินเทอร์เน็ตแบบเต็มรูปแบบ เว้นแต่คุณจะใช้เส้นทางส่งกลับแบบกำหนดเส้นทาง (routed return paths) แทนโดยเจตนา
• wg showแสดงการเชื่อมต่อล่าสุดหลังจากที่ไคลเอ็นต์ส่งข้อมูล
• ความต้องการ ของลูกค้าAllowedIPsตรงกับแบบอุโมงค์เต็มรูปแบบหรือแบบอุโมงค์แยกส่วนที่ลูกค้าตั้งใจไว้

ขั้นตอนเหล่านี้มุ่งเป้าไปที่ Debian 12 และเครื่องมือ WireGuard มาตรฐานที่มีให้ใช้งานผ่าน Debian โครงสร้างเครือข่าย, NAT ต้นทาง, ไฟร์วอลล์บนคลาวด์, การกำหนดเส้นทาง LAN ส่วนตัว และนโยบาย IPv6 นั้นขึ้นอยู่กับสภาพแวดล้อม ดังนั้นจึงไม่สามารถอนุมานส่วนประกอบเหล่านั้นได้จากการกำหนดค่า WireGuard เพียงอย่างเดียว ตรวจสอบแต่ละส่วนแยกกัน แทนที่จะมองว่าปัญหาการเชื่อมต่อทุกอย่างเป็นความล้มเหลวของ WireGuard