THAI DATA CLOUD
Linux Server Manual

Site-to-Site VPN ด้วย WireGuard: เชื่อมออฟฟิศกับคลาวด์

ตั้ง Site-to-Site VPN ด้วย WireGuard ให้ทั้งวงแลนสำนักงานเข้าถึงเครือข่ายภายในของ Cloud Server ได้ตรง ครอบคลุม AllowedIPs, IP Forwarding, Firewall และ NAT

โดย ทีมงาน THAI DATA CLOUD อัปเดต อ่าน 12 นาที

แชร์FacebookXLINELinkedIn
Site-to-Site — Site-to-Site VPN ด้วย WireGuard: เชื่อมออฟฟิศกับคลาวด์
Site-to-Site VPN ด้วย WireGuard: เชื่อมออฟฟิศกับคลาวด์

คำตอบสั้น ๆ: ตั้ง Site-to-Site VPN ด้วย WireGuard ให้ทั้งวงแลนสำนักงานเข้าถึงเครือข่ายภายในของ Cloud Server ได้ตรง ครอบคลุม AllowedIPs, IP Forwarding, Firewall และ NAT

คู่มือนี้อธิบาย Site-to-Site ทีละขั้นตอน พร้อมคำสั่งที่ใช้ได้จริงและปัญหาที่พบบ่อย

Site-to-Site VPN คือการเชื่อมเครือข่ายสองแห่งเข้าหากันผ่านอุโมงค์ที่เข้ารหัส เช่น วงแลนของสำนักงานกับเครือข่ายภายในของ Cloud Server ทำให้เครื่องทุกเครื่องในออฟฟิศเรียก IP ภายในของเซิร์ฟเวอร์บนคลาวด์ได้ตรง โดยไม่ต้องติดตั้งโปรแกรม VPN ทีละเครื่อง เหมาะกับองค์กรที่ย้ายระบบบัญชี ERP ไฟล์เซิร์ฟเวอร์ หรือฐานข้อมูลขึ้นคลาวด์ แต่ยังอยากให้พนักงานใช้งานเหมือนอยู่ในวงแลนเดียวกัน

คู่มือนี้ใช้ WireGuard ต่อจาก คู่มือติดตั้ง WireGuard แบบเครื่องต่อเครื่อง แต่เปลี่ยนจากการเชื่อมเครื่องเดียวเป็นการ Route ทั้ง Subnet เมื่อจบคุณจะมีอุโมงค์ Site-to-Site ที่ฝั่งสำนักงานเป็นผู้เริ่มเชื่อมต่อ เปิดเฉพาะทราฟฟิกที่จำเป็นผ่าน Firewall และรู้วิธีให้เซิร์ฟเวอร์อื่นบนคลาวด์ตอบกลับมาหาออฟฟิศได้

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

  • Cloud Server หนึ่งเครื่องทำหน้าที่ VPN Gateway (Ubuntu 22.04/24.04, Debian 12 หรือ AlmaLinux/Rocky Linux 9) มี Public IP 203.0.113.10 และการ์ดเครือข่ายภายใน eth1 = 10.10.0.5 ตรวจชื่อการ์ดจริงด้วย ip -br addr
  • อุปกรณ์ฝั่งสำนักงานที่รัน WireGuard ได้ เช่น เครื่อง Linux ขนาดเล็กในวงแลน (ตัวอย่าง 192.168.50.2) หรือ Router ที่รองรับ WireGuard ในตัว และสิทธิ์แก้ Route บน Router หลักของออฟฟิศ
  • แผน IP ที่ไม่ซ้อนกัน: ออฟฟิศ 192.168.50.0/24, คลาวด์ 10.10.0.0/24, อุโมงค์ 10.99.0.0/30
  • ช่องทางสำรองเข้าเครื่อง เช่น Console ผ่านหน้าเว็บของผู้ให้บริการ เพราะขั้นตอนนี้แก้ Firewall และ Routing
แผนภาพ Site-to-Site VPN วงแลนสำนักงาน 192.168.50.0/24 ผ่านอุโมงค์ WireGuard ไปเครือข่ายภายในคลาวด์ 10.10.0.0/24
ออฟฟิศเป็นผู้เริ่มเชื่อมไปที่ 203.0.113.10:51820 แล้วทั้งสองวงคุยกันด้วย IP ภายใน

ขั้นตอนที่ 1: ติดตั้ง WireGuard และสร้างคีย์ทั้งสองฝั่ง

ทำซ้ำบนทั้ง Cloud Server และ Gateway ของสำนักงาน โดยตั้งชื่อไฟล์คีย์ให้ต่างกัน (cloud.key กับ office.key)

# Ubuntu / Debian
sudo apt update && sudo apt install -y wireguard
# AlmaLinux / Rocky Linux 9
sudo dnf install -y wireguard-tools

sudo -i
cd /etc/wireguard && umask 077
wg genkey | tee cloud.key | wg pubkey > cloud.pub
exit

แลกเปลี่ยนเฉพาะไฟล์ .pub ระหว่างสองฝั่ง ไฟล์ .key ห้ามออกจากเครื่อง

ขั้นตอนที่ 2: ตั้งค่าฝั่ง Cloud Server

สร้าง /etc/wireguard/wg0.conf หัวใจของ Site-to-Site อยู่ที่ AllowedIPs ของ Peer ซึ่งต้องใส่ทั้ง IP อุโมงค์ของอีกฝั่งและ Subnet ของสำนักงาน wg-quick จะสร้าง Route ไป 192.168.50.0/24 ผ่าน wg0 ให้เอง

[Interface]
Address = 10.99.0.1/30
ListenPort = 51820
PrivateKey = <เนื้อหาของ cloud.key>

[Peer]
# office-bangkok
PublicKey = <เนื้อหาของ office.pub>
AllowedIPs = 10.99.0.2/32, 192.168.50.0/24

ฝั่งคลาวด์ไม่ใส่ Endpoint เพราะ IP สาธารณะของออฟฟิศอาจเปลี่ยนได้ ให้ออฟฟิศเป็นผู้เริ่มเชื่อมต่อ จากนั้นเปิด IP Forwarding เพื่อให้เครื่องส่งต่อแพ็กเก็ตระหว่าง wg0 กับ eth1 ได้

sudo chmod 600 /etc/wireguard/wg0.conf
echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-site-to-site.conf
sudo sysctl --system
sudo systemctl enable --now wg-quick@wg0

ขั้นตอนที่ 3: ตั้งค่าฝั่งสำนักงาน

บน Gateway ของออฟฟิศ สร้าง wg0.conf ที่กลับด้านกัน AllowedIPs ฝั่งนี้คือ Subnet ของคลาวด์ ส่วน PersistentKeepalive ช่วยให้ NAT ของ Router ออฟฟิศไม่ตัดอุโมงค์ที่เงียบ แล้วเปิด IP Forwarding และ wg-quick@wg0 แบบเดียวกับขั้นตอนที่ 2

[Interface]
Address = 10.99.0.2/30
PrivateKey = <เนื้อหาของ office.key>

[Peer]
PublicKey = <เนื้อหาของ cloud.pub>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.99.0.1/32, 10.10.0.0/24
PersistentKeepalive = 25

ถ้า Gateway ไม่ใช่ Router หลักของออฟฟิศ ให้เพิ่ม Static Route บน Router หลัก: ปลายทาง 10.10.0.0/24 ส่งไป Gateway 192.168.50.2 เครื่องลูกในวงแลนไม่ต้องแก้อะไร เพราะส่งทุกอย่างไป Router อยู่แล้ว หากใช้ Router ที่มี WireGuard ในตัว เช่น MikroTik RouterOS 7 หรือ OPNsense ให้กรอกค่าชุดเดียวกัน (Private Key, Public Key ของคลาวด์, Endpoint และ Allowed Address 10.10.0.0/24) แล้วเพิ่ม Route ไปที่ Interface WireGuard

ขั้นตอนที่ 4: เปิด Firewall และอนุญาตการ Forward บนคลาวด์

ก่อนแก้ Firewall ให้เปิด SSH ค้างไว้หนึ่งหน้าต่าง และทดสอบด้วยหน้าต่างใหม่ทุกครั้ง บน Ubuntu/Debian ที่ใช้ UFW การ Forward ถูกปิดเป็นค่าเริ่มต้น จึงต้องเพิ่มกฎ route ทั้งสองทิศ

# Ubuntu / Debian (UFW)
sudo ufw allow from 198.51.100.20 to any port 51820 proto udp
sudo ufw route allow in on wg0 out on eth1
sudo ufw route allow in on eth1 out on wg0

# AlmaLinux / Rocky Linux 9 (firewalld)
sudo firewall-cmd --permanent --zone=public --add-port=51820/udp
sudo firewall-cmd --permanent --zone=internal --add-interface=wg0
sudo firewall-cmd --permanent --zone=internal --add-interface=eth1
sudo firewall-cmd --permanent --zone=internal --add-forward
sudo firewall-cmd --reload

198.51.100.20 คือ IP สาธารณะของออฟฟิศ ถ้า IP เปลี่ยนบ่อยให้เปิด UDP 51820 แบบไม่จำกัดต้นทางแทน ซึ่งยังปลอดภัยพอสมควร เพราะ WireGuard ไม่ตอบแพ็กเก็ตที่ไม่มีคีย์ถูกต้องเลย ถ้า Gateway ฝั่งออฟฟิศเปิด Firewall ไว้ ให้เพิ่มกฎ route ระหว่าง wg0 กับการ์ดแลนแบบเดียวกัน สำหรับ firewalld ให้ตรวจกฎเดิมของ eth1 ก่อนย้ายเข้าโซน internal ถ้ามีหน่วยงานใช้ Security Group ของแพลตฟอร์มด้วย ให้เปิด UDP 51820 ที่นั่นเช่นกัน

ขั้นตอนที่ 5: ให้เซิร์ฟเวอร์อื่นบนคลาวด์ตอบกลับมาที่ออฟฟิศ

ตัว Gateway รู้จัก Route ไปออฟฟิศแล้ว แต่เครื่องอื่นใน 10.10.0.0/24 เช่น db01 ยังไม่รู้ จะตอบกลับไปทาง Default Gateway แล้วแพ็กเก็ตหาย เลือกได้สองวิธี

ตารางเปรียบเทียบการตอบกลับจากเซิร์ฟเวอร์บนคลาวด์ด้วย Static Route กับ NAT ที่ Gateway
ถ้าต้องการ Log ที่เห็น IP จริงของเครื่องในออฟฟิศ ให้ใช้ Static Route

วิธี A: เพิ่ม Static Route บนแต่ละเครื่อง

# Ubuntu: /etc/netplan/60-site-to-site.yaml (chmod 600) แล้ว sudo netplan apply
network:
  version: 2
  ethernets:
    eth1:
      routes:
        - to: 192.168.50.0/24
          via: 10.10.0.5

# AlmaLinux / Rocky Linux 9 (ดูชื่อ connection ด้วย nmcli con show)
sudo nmcli connection modify "System eth1" +ipv4.routes "192.168.50.0/24 10.10.0.5"
sudo nmcli connection up "System eth1"

วิธี B: ทำ NAT ที่ Gateway

เพิ่มสองบรรทัดนี้ใต้ [Interface] ของคลาวด์ แล้วรีสตาร์ต wg-quick@wg0 บน firewalld ใช้ sudo firewall-cmd --permanent --zone=internal --add-masquerade แทน

PostUp = iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o eth1 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 192.168.50.0/24 -o eth1 -j MASQUERADE

วิธี B ง่ายกว่าแต่เครื่องปลายทางจะเห็นทุกคนเป็น 10.10.0.5 ทำให้ Log ไม่บอกว่าเครื่องไหนในออฟฟิศเข้ามา บางแพลตฟอร์มคลาวด์ตรวจ IP ต้นทางบนเครือข่ายภายใน (Anti-spoofing) ถ้าวิธี A ใช้ไม่ได้แต่วิธี B ใช้ได้ มักเป็นเพราะเหตุนี้

ตรวจสอบว่า Site-to-Site ทำงานถูกต้อง

บน Cloud Server ตรวจว่ามี Handshake ล่าสุดและ Route ไปออฟฟิศชี้ออก wg0 จากนั้นทดสอบจากคอมพิวเตอร์ในออฟฟิศด้วย ping 10.10.0.21 และ tracert 10.10.0.21 (Windows) ควรเห็น Hop ผ่าน 10.99.0.1 ถ้า ping ไม่ผ่าน ให้รัน sudo tcpdump -ni wg0 icmp บน Gateway เพื่อดูว่าแพ็กเก็ตมาถึงหรือไม่

sudo wg show
ip route get 192.168.50.10
ผลคำสั่ง wg show บน Gateway ของ Site-to-Site VPN แสดง allowed ips ของออฟฟิศและ handshake ล่าสุด
allowed ips ต้องมี 192.168.50.0/24 และ Route ไปออฟฟิศต้องออกทาง wg0

ปัญหาที่พบบ่อยเกี่ยวกับ Site-to-Site VPN

Handshake สำเร็จแต่เครื่องในออฟฟิศ ping เซิร์ฟเวอร์บนคลาวด์ไม่ได้ เกิดจากอะไร?

ไล่ทีละจุด: sysctl net.ipv4.ip_forward ต้องเป็น 1 ทั้งสองฝั่ง, AllowedIPs ต้องมี Subnet ของอีกฝั่ง, Firewall ต้องมีกฎ route ทั้งสองทิศ, Router หลักของออฟฟิศต้องมี Static Route และเครื่องปลายทางต้องมีทางตอบกลับตามขั้นตอนที่ 5

เปิดเว็บหรือ ping ได้ แต่โอนไฟล์ใหญ่หรือ SMB ค้าง ต้องแก้อย่างไร?

มักเป็นปัญหา MTU โดยเฉพาะอินเทอร์เน็ตออฟฟิศแบบ PPPoE ให้เพิ่ม MTU = 1380 ใน [Interface] ทั้งสองฝั่ง แล้วรีสตาร์ต wg-quick@wg0 ค่าเริ่มต้นของ WireGuard คือ 1420

Subnet ของออฟฟิศซ้ำกับคลาวด์ ใช้ Site-to-Site ได้ไหม?

ไม่ควรใช้ เพราะเครื่องจะไม่รู้ว่า 192.168.1.10 อยู่ฝั่งไหน ทางที่ถูกคือเปลี่ยน Subnet ฝั่งใดฝั่งหนึ่งก่อนเชื่อม ควรเลี่ยง 192.168.0.0/24 และ 192.168.1.0/24 ซึ่งซ้ำกับ Router ตามบ้านบ่อยที่สุด

IP สาธารณะของออฟฟิศเปลี่ยน อุโมงค์จะหลุดไหม?

ไม่หลุดถาวร เพราะออฟฟิศเป็นฝั่งเริ่มเชื่อมและ WireGuard จะจำ Endpoint ใหม่จากแพ็กเก็ตถัดไปเอง ยกเว้นคุณจำกัด UDP 51820 ไว้เฉพาะ IP เดิมใน Firewall ซึ่งต้องแก้กฎตาม

เช็กลิสต์ตรวจความพร้อมของ Site-to-Site VPN ทั้งแผน IP Firewall และช่องทางสำรอง
ข้อสีแดงคือสาเหตุที่ทำให้อุโมงค์เชื่อมได้แต่ใช้งานจริงไม่ได้บ่อยที่สุด

ถ้าต้องการเชื่อมหลายสาขาเข้าคลาวด์ หรือออกแบบเครือข่ายภายในบน Cloud Server ให้รองรับ Site-to-Site ติดต่อทีมงาน THAI DATA CLOUD อ่านรายละเอียดโปรโตคอลเพิ่มเติมได้ที่ WireGuard Quick Start

สรุปขั้นตอน Site-to-Site

ทบทวน Site-to-Site ทั้งหมดตามลำดับ ก่อนนำไปใช้กับระบบจริง

  1. ติดตั้ง WireGuard และสร้างคีย์ทั้งสองฝั่ง
  2. ตั้งค่าฝั่ง Cloud Server
  3. ตั้งค่าฝั่งสำนักงาน
  4. เปิด Firewall และอนุญาตการ Forward บนคลาวด์
  5. ให้เซิร์ฟเวอร์อื่นบนคลาวด์ตอบกลับมาที่ออฟฟิศ

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

อ่านเพิ่มเติมเกี่ยวกับ Site-to-Site

แชร์FacebookXLINELinkedIn

มีคำถามเรื่องบริการ? ติดต่อทีมงาน