WireGuard VPN ที่โฮสต์เองช่วยให้แล็ปท็อปและโทรศัพท์ของคุณมีเส้นทางเข้ารหัสไปยังเซิร์ฟเวอร์ที่คุณควบคุมเอง มีประโยชน์เมื่อคุณต้องการ IP ขาออกที่คงที่ การเข้าถึงอย่างปลอดภัยบน Wi-Fi ที่ไม่น่าเชื่อถือ หรือเส้นทางส่วนตัวเข้าสู่เครือข่ายอื่น แต่ไม่ได้ทำให้คุณไม่ระบุตัวตน เว็บไซต์ยังคงเห็นที่อยู่ VPS เพียงหนึ่งเดียว และผู้ให้บริการโฮสติ้งยังคงดูแลเครือข่ายพื้นฐานอยู่
คู่มือนี้สร้าง VPN แบบ full-tunnel บน IPv4 บน Ubuntu Server คุณจะติดตั้ง WireGuard สร้างคีย์ด้วยสิทธิ์ที่จำกัด เปิดใช้งานการกำหนดเส้นทาง เพิ่มกฎไฟร์วอลล์และ NAT เชื่อมต่อไคลเอนต์บนเดสก์ท็อปและมือถือ แล้วตรวจสอบอุโมงค์ การออกแบบเดียวกันนี้รองรับ IPv6 ได้ แต่ต้องหลังจากที่ VPS มีพื้นที่ IPv6 ที่กำหนดเส้นทางแล้ว และคุณตั้งค่าการส่งต่อและกฎไฟร์วอลล์สำหรับ IPv6 แยกต่างหาก
WireGuard คืออะไร?
WireGuard เป็นโปรโตคอล VPN สมัยใหม่ที่รองรับหลายแพลตฟอร์ม พร้อมตัวการใช้งานจริง ซึ่งส่งแพ็กเก็ต IP ที่เข้ารหัสผ่าน UDP ข้อกำหนดโปรโตคอล WireGuard กำหนดชุดพื้นฐานทางการเข้ารหัสที่ตายตัว ได้แก่ ChaCha20-Poly1305, Curve25519, BLAKE2s, SipHash24 และ HKDF การออกแบบให้เล็กโดยตั้งใจเช่นนี้ทำให้การตั้งค่าและการตรวจสอบง่ายกว่าโปรโตคอลที่มีชุดรหัสให้สลับเปลี่ยนมากมาย
WireGuard ไม่มีระบบบัญชีส่วนกลางหรือไดเรกทอรีผู้ใช้ในตัว อุปกรณ์แต่ละเครื่องคือ peer ที่มีคู่คีย์ ที่อยู่ในอุโมงค์ และกฎ AllowedIPs ของตัวเอง บน VPS มักมี peer หนึ่งทำหน้าที่เป็นเกตเวย์ที่หันออกสู่อินเทอร์เน็ต ขณะที่แล็ปท็อปและโทรศัพท์เป็นฝ่ายเริ่มการเชื่อมต่อเข้ามา
ทำไมต้องใช้ WireGuard บน VPS?
- โมเดล peer ที่เรียบง่าย: อุปกรณ์แต่ละเครื่องได้คู่คีย์หนึ่งชุดและรายการ peer หนึ่งรายการ
- พื้นที่โจมตีน้อย: WireGuard ใช้โปรโตคอลที่กระชับและชุดการเข้ารหัสที่ตายตัว แทนที่จะเปิดตัวเลือกเก่า ๆ ให้เลือกมากมาย
- ประสิทธิภาพดี: การผสานเข้ากับเคอร์เนลบน Linux และการเข้ารหัสที่มีประสิทธิภาพช่วยให้ได้ทรูพุตสูง แม้ผลลัพธ์ยังขึ้นอยู่กับ CPU ความจุเครือข่าย ค่าหน่วงเวลา และขนาดแพ็กเก็ต
- ไคลเอนต์รองรับหลายแพลตฟอร์ม: มีไคลเอนต์อย่างเป็นทางการสำหรับ Windows 10 และ 11, macOS, Android และ iOS ส่วน Linux และระบบ BSD หลายตัวมีเครื่องมือหรือแพ็กเกจดั้งเดิมให้ใช้
- การโรมมิ่ง: peer สามารถเปลี่ยนเครือข่ายและที่อยู่ IP ต้นทางได้โดยไม่ต้องรับข้อมูลระบุตัวตน WireGuard ใหม่ เพราะเซิร์ฟเวอร์จะเรียนรู้ปลายทางล่าสุดที่ผ่านการยืนยันตัวตนแล้ว
- ควบคุมการกำหนดเส้นทางได้ชัดเจน: AllowedIPs กำหนดทั้งว่าปลายทางใดจะใช้อุโมงค์ และที่อยู่ในอุโมงค์ใดเป็นของ peer แต่ละตัว
อ่านเพิ่มเติม: คู่มือ VPS สำหรับ VPN ของ Cloudzy. สำหรับการติดตั้งรุ่นเก่า ดูที่ คู่มือตั้งค่า PPTP ของ Cloudzy ทั้งนี้อย่าเลือก PPTP สำหรับ VPN ใหม่ที่ต้องการความปลอดภัย
ข้ามการติดตั้งด้วยตนเอง: WireGuard แบบคลิกเดียว
หากคุณไม่มีพื้นฐานทางเทคนิค หรือไม่อยากติดตั้งเองด้วยมือ Cloudzy มีบริการติดตั้ง WireGuard VPN แบบคลิกเดียว ส่วนที่เหลือของคู่มือนี้ว่าด้วยการติดตั้งด้วยตนเอง ส่วนหัวข้อนี้ว่าด้วยทางลัด
- เข้าสู่ระบบแผงควบคุมของ Cloudzy
- เลือก WireGuard จากรายการแอปพลิเคชัน
- สร้าง VPS ในตำแหน่งที่ต้องการด้วยแพ็กเกจที่คุณเลือก เครื่อง Ubuntu สเปกพื้นฐานก็เพียงพอแล้ว
เมื่อ VPS พร้อมแล้ว ให้เข้าสู่ระบบและรันคำสั่งต่อไปนี้เพื่อแสดงการตั้งค่าของคุณ:
cat client.conf
คุณจะเห็นผลลัพธ์ประมาณนี้:
นำการตั้งค่านั้นไปสร้างอุโมงค์ใหม่ในไคลเอนต์ WireGuard บนพีซีของคุณ แล้วการเชื่อมต่อก็พร้อมใช้งาน แต่ถ้าคุณอยากเข้าใจทุกส่วนประกอบ หรือต้องการรูปแบบที่อิมเมจแบบคลิกเดียวไม่ครอบคลุม ให้ทำต่อด้วยการติดตั้งด้วยตนเองด้านล่าง
วิธีตั้งค่า WireGuard บน Ubuntu
คำสั่งด้านล่างมุ่งไปที่ Ubuntu Server รุ่นปัจจุบัน ให้รันผ่าน SSH ด้วยผู้ใช้ที่มีสิทธิ์ sudo เปิดเซสชัน SSH ค้างไว้จนกว่าจะยืนยันไฟร์วอลล์เรียบร้อย และสร้างสแนปช็อตของ VPS ไว้ก่อนหากผู้ให้บริการของคุณรองรับ
ข้อกำหนดเบื้องต้น
- VPS ที่ใช้ Ubuntu หนึ่งเครื่องพร้อมที่อยู่ IPv4 สาธารณะ
- บัญชีที่ไม่ใช่ root แต่มีสิทธิ์ sudo
- การเข้าถึงผ่าน SSH และรายละเอียดคอนโซลกู้คืนของผู้ให้บริการ VPS
- อุปกรณ์ไคลเอนต์หนึ่งเครื่องที่มีแอป WireGuard อย่างเป็นทางการหรือเครื่องมือบรรทัดคำสั่ง
คุณไม่จำเป็นต้องมีเซิร์ฟเวอร์ Ubuntu เครื่องที่สอง ไคลเอนต์จะเป็นพีซี Windows, Mac, แล็ปท็อป Linux, โทรศัพท์ Android หรือ iPhone ก็ได้
ขั้นที่ 1: ติดตั้ง WireGuard
sudo apt update
sudo apt install wireguard -y
ยืนยันว่าเครื่องมือพร้อมใช้งาน:
wg --version
ขั้นที่ 2: สร้างคีย์ของเซิร์ฟเวอร์อย่างปลอดภัย
สร้างไดเรกทอรีของ WireGuard และสร้างคู่คีย์โดยใช้ umask ที่จำกัดสิทธิ์ ห้ามคัดลอกคีย์ส่วนตัวไปยังไคลเอนต์หรือปล่อยให้ปรากฏในบันทึกเด็ดขาด
sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/server.key; wg pubkey < /etc/wireguard/server.key > /etc/wireguard/server.pub'
แสดงคีย์เมื่อคุณต้องนำไปวางในไฟล์กำหนดค่า:
sudo cat /etc/wireguard/server.key
sudo cat /etc/wireguard/server.pub
ขั้นที่ 3: สร้างไฟล์กำหนดค่าของเซิร์ฟเวอร์
เปิดไฟล์กำหนดค่าของอินเทอร์เฟซ:
sudo nano /etc/wireguard/wg0.conf
วางบล็อกต่อไปนี้ แล้วแทนที่ SERVER_PRIVATE_KEY ด้วยคีย์ส่วนตัวจากขั้นตอนก่อนหน้า:
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY
เครือข่ายอุโมงค์ 10.8.0.0/24 เป็นเพียงตัวอย่าง หากซ้อนทับกับเครือข่ายบ้าน สำนักงาน หรือคลาวด์ที่คุณต้องเข้าถึง ให้เลือกช่วงที่อยู่ส่วนตัวอื่นแทน และอย่าเพิ่ม SaveConfig = true เพราะอาจเขียนทับไฟล์เมื่ออินเทอร์เฟซปิดลง และลบการแก้ไขที่คุณทำเองไป
sudo chmod 600 /etc/wireguard/wg0.conf
ขั้นที่ 4: เปิดใช้งานการส่งต่อ IPv4
VPS ต้องกำหนดเส้นทางแพ็กเก็ตระหว่าง wg0 กับอินเทอร์เฟซเครือข่ายสาธารณะของตัวเอง ให้ใส่ค่านี้ไว้ในไฟล์ sysctl แยกต่างหาก:
sudo nano /etc/sysctl.d/70-wireguard-routing.conf
net.ipv4.ip_forward = 1
นำไปใช้แล้วตรวจสอบ:
sudo sysctl -p /etc/sysctl.d/70-wireguard-routing.conf
sysctl net.ipv4.ip_forward
แนวทางนี้อ้างอิงรูปแบบการกำหนดเส้นทางจาก คู่มือเกตเวย์ WireGuard ของ Ubuntu ทั้งนี้ IPv6 ต้องมีคำนำหน้า IPv6 ที่กำหนดเส้นทางแล้ว ที่อยู่ในอุโมงค์แยกต่างหาก การส่งต่อ IPv6 และกฎไฟร์วอลล์สำหรับ IPv6 อย่าส่งทราฟฟิกของไคลเอนต์ไปยัง ::/0 จนกว่าเส้นทางนั้นจะพร้อมสมบูรณ์
ขั้นที่ 5: เพิ่มกฎไฟร์วอลล์และ NAT
ค้นหาชื่ออินเทอร์เฟซสาธารณะของ VPS ในผลลัพธ์ด้านล่าง ให้ดูค่าที่อยู่หลัง dev ชื่อที่พบบ่อยได้แก่ eth0, ens3 และ enp1s0
ip route show default
เปิด wg0.conf อีกครั้งแล้วเพิ่มบรรทัดต่อไปนี้ไว้ใต้ [Interface] หากอินเทอร์เฟซสาธารณะของคุณชื่ออื่น ให้แทนที่ eth0 ทุกจุด:
PostUp = iptables -I FORWARD 1 -i %i -o eth0 -j ACCEPT; iptables -I FORWARD 1 -i eth0 -o %i -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT; iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
PreDown = iptables -D FORWARD -i %i -o eth0 -j ACCEPT; iptables -D FORWARD -i eth0 -o %i -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT; iptables -t nat -D POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
หาก UFW เปิดใช้งานอยู่ ให้อนุญาต SSH ก่อนไปยุ่งกับสถานะของมัน แล้วจึงเปิดพอร์ต UDP ของ WireGuard:
sudo ufw allow OpenSSH
sudo ufw allow 51820/udp
sudo ufw status
หากตอนนี้ UFW ปิดอยู่และคุณต้องการเปิดใช้งาน ให้ยืนยันก่อนว่ามีกฎ OpenSSH อยู่แล้ว อย่าปิดแล้วเปิด UFW ใหม่ผ่าน SSH เพียงเพื่อให้กฎเหล่านี้มีผล เพราะจะเพิ่มความเสี่ยงที่จะถูกล็อกออกโดยไม่จำเป็น
ขั้นที่ 6: เริ่มอินเทอร์เฟซ WireGuard
sudo systemctl enable --now wg-quick@wg0
sudo systemctl status wg-quick@wg0 --no-pager
sudo wg show
หากบริการล้มเหลว ให้รัน journalctl ก่อนจะไปแก้อย่างอื่น:
sudo journalctl -u wg-quick@wg0 -n 50 --no-pager
เพิ่มไคลเอนต์ WireGuard
อุปกรณ์ทุกเครื่องต้องมีคู่คีย์และ IP ในอุโมงค์ที่ไม่ซ้ำกัน อย่านำการตั้งค่าไคลเอนต์ชุดเดียวไปใช้กับสองเครื่องเด็ดขาด เพราะคีย์และที่อยู่ที่ซ้ำกันจะทำให้การกำหนดเส้นทางคาดเดาไม่ได้ และเพิกถอนสิทธิ์อย่างสะอาดไม่ได้
ขั้นที่ 1: สร้างคีย์ของไคลเอนต์
แอปอย่างเป็นทางการทั้งบนเดสก์ท็อปและมือถือสามารถสร้างคีย์ให้ได้เมื่อคุณสร้างอุโมงค์เปล่า ส่วนบนไคลเอนต์ Linux ให้ใช้:
umask 077
wg genkey | tee client.key | wg pubkey > client.pub
เก็บ client.key ไว้บนอุปกรณ์นั้น และคัดลอกเฉพาะ client.pub ไปยังเซิร์ฟเวอร์เท่านั้น
ขั้นที่ 2: เพิ่ม peer บนเซิร์ฟเวอร์
sudo nano /etc/wireguard/wg0.conf
เพิ่มบล็อก peer หนึ่งบล็อก แล้วแทนที่ CLIENT_PUBLIC_KEY ด้วยคีย์สาธารณะของไคลเอนต์:
[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.8.0.2/32
บรรทัด Address = 10.8.0.2/32 กำหนดที่อยู่ในอุโมงค์ฝั่งไคลเอนต์ ส่วนในบล็อก [Peer] บนเซิร์ฟเวอร์ AllowedIPs = 10.8.0.2/32 จะผูกที่อยู่นั้นเข้ากับ peer ตัวนี้เพื่อใช้กำหนดเส้นทางและตรวจสอบต้นทาง สำหรับอุปกรณ์ถัดไปให้ใช้ 10.8.0.3/32 แล้วไล่เลขขึ้นไปโดยไม่ให้ซ้ำกัน
sudo systemctl restart wg-quick@wg0
ขั้นที่ 3: สร้างไฟล์กำหนดค่าของไคลเอนต์
สร้างไฟล์ client.conf บนเครื่องไคลเอนต์ แล้วแทนที่ตัวยึดตำแหน่งทั้งหมด:
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY
Address = 10.8.0.2/32
DNS = 1.1.1.1
[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = VPS_PUBLIC_IP:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
AllowedIPs = 0.0.0.0/0 ทำให้เป็นอุโมงค์แบบเต็มบน IPv4 หากต้องการเข้าถึงเฉพาะเครือข่าย VPN ให้ใช้ AllowedIPs = 10.8.0.0/24 ส่วน PersistentKeepalive มีประโยชน์กับไคลเอนต์ที่อยู่หลัง NAT ซึ่งต้องคงการแมปให้เข้าถึงได้แม้ในยามว่าง โดย คู่มือเริ่มต้นอย่างเร็วของ WireGuard คู่มือเริ่มต้นอย่างเร็วระบุว่า peer ส่วนใหญ่ไม่จำเป็นต้องใช้
ขั้นที่ 4: นำเข้าไฟล์กำหนดค่า
ใช้ คู่มือติดตั้งไคลเอนต์ WireGuard เพื่อดาวน์โหลดไคลเอนต์ที่รองรับแพลตฟอร์มของคุณ
- Windows: เลือก Add Tunnel แล้วนำเข้าไฟล์ client.conf
- macOS: เลือก Import tunnel(s) from file แล้วเลือกไฟล์ client.conf
- Android หรือ iOS: นำเข้าไฟล์ หรือสแกนรหัส QR ที่สร้างจากไฟล์นั้น
บนไคลเอนต์ Ubuntu หรือ Debian ที่มีไฟล์ client.conf อยู่ ให้ติดตั้ง qrencode แล้วแสดงไฟล์นั้นในเทอร์มินัลของไคลเอนต์เครื่องนั้น:
sudo apt install qrencode -y
qrencode -t ansiutf8 < client.conf
รหัส QR มีคีย์ส่วนตัวของไคลเอนต์อยู่ข้างใน ให้แสดงเฉพาะในเทอร์มินัลที่เชื่อถือได้ อย่าบันทึกภาพหน้าจอ และล้างหน้าจอเทอร์มินัลหลังจากโทรศัพท์นำเข้าเรียบร้อยแล้ว
ขั้นที่ 5: ตรวจสอบอุโมงค์
เปิดใช้งานอุโมงค์ สร้างทราฟฟิกจากฝั่งไคลเอนต์ แล้วรันคำสั่งตรวจสอบเหล่านี้บน VPS:
sudo wg show
ip -brief address show wg0
การจับมือ (handshake) ล่าสุดและตัวนับการรับส่งข้อมูลที่เพิ่มขึ้นยืนยันว่า WireGuard กำลังแลกเปลี่ยนแพ็กเก็ตอยู่จริง จากนั้นให้ตรวจสอบทางออกแบบ full-tunnel จากฝั่งไคลเอนต์:
curl -4 https://api.ipify.org; echo
คำสั่งนี้ควรคืนค่าที่อยู่ IPv4 สาธารณะของ VPS หากไม่มีการจับมือเกิดขึ้น ให้ตรวจสอบที่อยู่ปลายทาง พอร์ต UDP ไฟร์วอลล์ของคลาวด์ กฎ UFW และคีย์ต่าง ๆ แต่ถ้าจับมือได้แล้วยังใช้อินเทอร์เน็ตไม่ได้ ให้ตรวจสอบการส่งต่อ IP ชื่ออินเทอร์เฟซสาธารณะ กฎ NAT และ DNS
วาง WireGuard ไว้หลัง Nginx ได้ไหม?
ผู้ใช้ เอกสารโมดูล stream ของ NGINX อธิบายว่า NGINX สามารถส่งต่อทราฟฟิก UDP จากพอร์ตหนึ่งไปอีกพอร์ตได้อย่างไร จึงสามารถส่งต่อ UDP/80 หรือ UDP/443 ไปยัง WireGuard ที่ UDP/51820 ได้ แต่นั่นคือการรีเลย์ UDP ไม่ใช่รีเวิร์สพร็อกซี HTTP มันไม่ได้แปลง WireGuard ให้เป็น TCP หรือ HTTPS และไม่ได้ทำให้โปรโตคอลดูเหมือนทราฟฟิกเว็บทั่วไป
สำหรับการติดตั้งส่วนใหญ่ การเปลี่ยนค่า ListenPort ของ WireGuard แล้วเปิดพอร์ต UDP ที่ตรงกัน ง่ายกว่าการเพิ่ม NGINX เข้ามา และหากเครือข่ายบล็อก UDP ทั้งหมดหรือใช้การตรวจสอบแพ็กเก็ตเชิงลึก การรีเลย์ UDP ผ่าน NGINX ก็แก้ปัญหานี้ไม่ได้ โดย เอกสารข้อจำกัดของ WireGuard เอกสารข้อจำกัดของ WireGuard ระบุว่าการอำพรางทราฟฟิกอยู่นอกขอบเขตของโปรโตคอลนี้
เชื่อม VPS เข้ากับเครือข่ายที่บ้าน
VPS สามารถทำหน้าที่เป็นศูนย์กลางระหว่างไคลเอนต์ที่เคลื่อนที่ไปมากับอุปกรณ์ภายในบ้านของคุณได้ โดย peer ฝั่งบ้านจะเป็นฝ่ายเริ่มเชื่อมต่อ WireGuard ออกไปยัง VPS ซึ่งทำให้ไม่จำเป็นต้องมี IP สาธารณะที่บ้าน หาก peer ฝั่งบ้านอยู่หลัง NAT ให้ตั้งค่า PersistentKeepalive ไว้ด้วย
การเข้าถึง LAN ที่บ้านทั้งวงต้องทำมากกว่าแค่เพิ่ม peer เข้าไป รายการ peer บน VPS ที่ตรงกับเกตเวย์ที่บ้านต้องระบุซับเน็ตของบ้านไว้ใน AllowedIPs เช่น 192.168.1.0/24 ส่วนไคลเอนต์ระยะไกลที่ใช้อุโมงค์แบบเต็ม (AllowedIPs = 0.0.0.0/0) นั้นส่งทราฟฟิกของซับเน็ตบ้านผ่าน VPS อยู่แล้ว ให้เพิ่ม 192.168.1.0/24 ที่ฝั่งไคลเอนต์เฉพาะเมื่อคุณใช้ split tunneling เท่านั้น นอกจากนี้เกตเวย์ที่บ้านก็ต้องส่งต่อทราฟฟิกระหว่าง WireGuard กับ LAN ด้วย โดยเพิ่มเส้นทางบนเราเตอร์ที่บ้าน หรือเพิ่มกฎ NAT ที่จำกัดขอบเขตอย่างรอบคอบบนเกตเวย์ที่บ้าน และควรตรวจสอบการซ้อนทับก่อน เพราะไคลเอนต์ที่ต่ออยู่กับเครือข่าย 192.168.1.0/24 อีกวงหนึ่งจะไม่สามารถกำหนดเส้นทางทั้งสองเครือข่ายได้อย่างสะอาด หากไม่เปลี่ยนเลขเครือข่ายใหม่หรือใช้ policy routing ที่ซับซ้อนกว่านี้
WireGuard ที่โฮสต์เอง เทียบกับ VPN เชิงพาณิชย์
การโฮสต์เองเปลี่ยนแค่ว่าใครเป็นผู้ดูแล VPN แต่ไม่ได้ทำให้ไม่ระบุตัวตนดีขึ้นโดยอัตโนมัติ VPS ส่วนตัวให้ IP ขาออกที่คงที่เพียงหมายเลขเดียว ซึ่งเชื่อมโยงกับเครือข่ายโฮสติ้งได้ง่าย ส่วนบริการเชิงพาณิชย์มักให้ที่อยู่ขาออกแบบใช้ร่วมกันและสลับตำแหน่งได้ง่าย แต่คุณต้องพึ่งพานโยบาย การดำเนินงาน และผลตรวจสอบอิสระที่ผู้ให้บริการนั้นเผยแพร่
ตัว WireGuard เองนั้นเบา และ VPS ขนาดเล็กมักเป็นจุดเริ่มต้นที่สมเหตุสมผลสำหรับคนหนึ่งคนกับอุปกรณ์ไม่กี่เครื่อง อย่าถือว่าตัวเลข RAM หรือ vCPU ตายตัวเป็นการรับประกันทรูพุต ให้ทดสอบด้วยจำนวนอุปกรณ์จริง ภูมิภาคที่ใช้ ขนาดแพ็กเก็ต และแบนด์วิดท์ที่คาดหวัง แล้วค่อยปรับขนาดหาก CPU เต็ม แพ็กเก็ตสูญหาย หรือค่าหน่วงเวลากลายเป็นข้อจำกัด
เลือกโฮสต์เองเมื่อ IP ขาออกส่วนตัวที่คงที่ การเข้าถึงจากระยะไกล หรือการควบคุมเซิร์ฟเวอร์ สำคัญกว่าตัวเลือกด้านตำแหน่งและความสะดวก และเลือก VPN เชิงพาณิชย์เมื่อคุณต้องการหลายประเทศ ทางออกแบบใช้ร่วมกัน การรองรับอุปกรณ์ผู้บริโภคที่กว้างขวาง และมีคนอื่นคอยจัดการเมื่อเกิดปัญหา
| ปัจจัยในการตัดสินใจ | WireGuard ที่โฮสต์เอง | VPN เชิงพาณิชย์ |
|---|---|---|
| โมเดลต้นทุน | เซิร์ฟเวอร์หนึ่งเครื่อง บวกกับเวลาที่คุณใช้ดูแลระบบ | แบบสมัครสมาชิก มักมีส่วนลดเมื่อผูกสัญญายาวขึ้น |
| ตำแหน่งทางออก | หนึ่งตำแหน่งต่อหนึ่งเซิร์ฟเวอร์ | มีตำแหน่งให้เลือกมากมายในแอป |
| การติดตั้ง | คุณเป็นคนตั้งค่าคีย์ การกำหนดเส้นทาง กฎไฟร์วอลล์ และไคลเอนต์เอง | ติดตั้งแอปแล้วลงชื่อเข้าใช้ |
| การบำรุงรักษา | คุณเป็นคนอัปเดตแพตช์ เฝ้าระวัง สำรองข้อมูล และแก้ปัญหาเอง | ผู้ให้บริการเป็นผู้ดูแลระบบให้ |
| รูปแบบความเป็นส่วนตัว | คุณควบคุมเซิร์ฟเวอร์เอง แต่ผู้ให้บริการโฮสติ้งยังคงเห็นข้อมูลเมตาได้อยู่ดี | คุณต้องพึ่งพานโยบายของผู้ให้บริการ และผลตรวจสอบอิสระที่ผู้ให้บริการเผยแพร่ |
| เหมาะสมที่สุด | IP ขาออกส่วนตัวที่คงที่ การเข้าถึงจากระยะไกล และการควบคุมโครงสร้างพื้นฐาน | สลับตำแหน่งได้ ดูแลรักษาน้อย และรองรับอุปกรณ์ได้กว้าง |
บทสรุป
การติดตั้ง WireGuard ที่เชื่อถือได้สรุปได้เป็นห้าเรื่อง คือ คีย์ส่วนตัวที่ได้รับการปกป้อง ที่อยู่ของ peer ที่ไม่ซ้ำกัน ค่า AllowedIPs ที่ถูกต้อง การส่งต่อและ NAT ที่ทำงานได้จริง และกฎไฟร์วอลล์สำหรับพอร์ต UDP ที่รับฟังอยู่ ก่อนจะไว้ใจอุโมงค์นี้ ให้ตรวจสอบทั้งการจับมือและที่อยู่ขาออกสาธารณะ และหลังติดตั้งแล้วก็ควรอัปเดตแพตช์ VPS อย่างสม่ำเสมอ
หากคุณต้องการสร้างเซิร์ฟเวอร์ด้วยตนเอง ให้เริ่มจาก Cloudzy Ubuntu VPS แต่ถ้าคุณอยากข้ามขั้นตอนการติดตั้ง ให้ใช้ บริการติดตั้ง WireGuard แบบคลิกเดียวของ Cloudzy แล้วข้ามไปที่การตั้งค่าไคลเอนต์และการตรวจสอบได้เลย
คำถามที่พบบ่อย
ทำไม WireGuard ถึงแสดง peer แต่ไม่มีการจับมือ?
การมีรายการ peer พิสูจน์ได้เพียงว่าไฟล์กำหนดค่าถูกโหลดแล้วเท่านั้น การที่ไม่มีการจับมือมักหมายความว่าไคลเอนต์ไปไม่ถึงเซิร์ฟเวอร์ หรือคีย์ไม่ตรงกัน ให้ตรวจสอบค่า Endpoint ของไคลเอนต์ IP สาธารณะของเซิร์ฟเวอร์ พอร์ต UDP/51820 ทั้งในไฟร์วอลล์ของผู้ให้บริการและใน UFW รวมถึงคีย์สาธารณะของทั้งสองฝั่ง และควรสร้างทราฟฟิกจากไคลเอนต์ก่อนตรวจสอบ เพราะ WireGuard จะเงียบเมื่อไม่มีการใช้งาน
ทำไมอุโมงค์เชื่อมต่อได้ แต่ใช้อินเทอร์เน็ตไม่ได้?
การที่จับมือได้แต่ใช้อินเทอร์เน็ตไม่ได้ มักชี้ไปที่การกำหนดเส้นทางมากกว่าการเข้ารหัส ให้ตรวจสอบค่า net.ipv4.ip_forward ยืนยันชื่ออินเทอร์เฟซสาธารณะในกฎ NAT ตรวจกฎ FORWARD และทดสอบ DNS แยกจากการเชื่อมต่อด้วย IP ตรง ๆ นอกจากนี้ให้แน่ใจว่าค่า AllowedIPs บนไคลเอนต์ตรงกับรูปแบบ full-tunnel หรือ split-tunnel ที่คุณตั้งใจไว้
ไคลเอนต์ทุกเครื่องจำเป็นต้องใช้ PersistentKeepalive ไหม?
ไม่จำเป็น ให้เพิ่มเมื่อ peer ที่อยู่หลัง NAT ต้องคงการแมปให้เปิดไว้ในช่วงที่ไม่มีการใช้งาน ซึ่งพบบ่อยกับโทรศัพท์ เกตเวย์ที่บ้าน และเครือข่ายที่มีข้อจำกัดบางแห่ง แต่ไม่ต้องใส่หาก peer นั้นสื่อสารบ่อยอยู่แล้ว หรือไม่จำเป็นต้องให้ฝั่งตรงข้ามติดต่อเข้ามาในยามว่าง