WireGuard ฉบับสมบูรณ์ทุกกรณีการใช้งาน (Complete WireGuard Guide for Every Use Case)

Complete WireGuard Guide: From Cryptokey Routing to Production Deployments

คู่มือฉบับสมบูรณ์เกี่ยวกับ WireGuard VPN ตั้งแต่หลักการเข้ารหัส (Noise Protocol) การติดตั้งทุกแพลตฟอร์ม การตั้งค่า Network/Firewall/DNS ไปจนถึง 18 กรณีการใช้งานจริง การ Hardening การ Monitoring การหลบเลี่ยงการบล็อก และแล็บปฏิบัติ 8 ชุด พร้อมไฟล์ข้อมูลตัวอย่าง (wireguard-sample-data.md) สำหรับทดลองได้จริง

วิธีใช้เอกสารนี้ (How to use this document)

• ทุกหัวข้อที่มีตัวอย่างทดลอง จะมีป้ายกำกับ 🧪 ตัวอย่าง X.Y ชี้ไปยังไฟล์ wireguard-sample-data.md ที่หัวข้อเลขเดียวกัน
• ค่า IP, พอร์ต และชื่อ interface ในเอกสารเป็นค่าสมมติ (ใช้ช่วง documentation/private เช่น 203.0.113.0/24, 198.51.100.0/24) ให้ปรับตามเครือข่ายจริงของท่าน
• ห้ามใช้ private key ตัวอย่างจากเอกสารใด ๆ ในระบบจริง ให้สร้างกุญแจใหม่ด้วย wg genkey เสมอ (ดูหัวข้อ 3.1)
• คำสั่งที่ต้องใช้สิทธิ์ root แสดงด้วย sudo หรือขึ้นต้นด้วย # ในตัวอย่าง

ส่วนที่ 1 พื้นฐานและหลักการทำงาน (Fundamentals and Operating Principles)

1.1 บทนำ (Introduction)

1.1.1 WireGuard คืออะไร

WireGuard คือ VPN (Virtual Private Network) แบบ Layer 3 tunnel ที่ออกแบบให้เรียบง่าย รวดเร็ว และปลอดภัยสมัยใหม่ ทำงานโดยห่อหุ้ม (encapsulate) แพ็กเก็ต IP ด้วยการเข้ารหัส แล้วส่งผ่าน UDP ไปยังปลายทาง ผู้ใช้สร้าง network interface เสมือน (เช่น wg0) ขึ้นมา แล้วตั้งค่า IP address และ route ให้ traffic ที่ต้องการวิ่งผ่าน interface นั้น

ลักษณะเด่นที่ทำให้ WireGuard ต่างจาก VPN รุ่นก่อน:

• Code base เล็ก: โมดูลสำหรับ Linux kernel มีประมาณ 4,000 บรรทัด (โดยประมาณ) ทำให้ตรวจสอบ (audit) ได้จริงโดยคนคนเดียวในเวลาไม่กี่วัน
• Configuration สั้น: tunnel พื้นฐานใช้ config ไม่เกิน 10 บรรทัด
• Cryptography แบบ opinionated: เลือกชุด algorithm ที่ทันสมัยมาให้แล้ว ไม่มีให้เลือก (no cipher negotiation)
• ประสิทธิภาพสูง: ทำงานใน kernel space บน Linux และใช้ชุด cipher ที่เร็วแม้ CPU ไม่มี AES-NI
• รองรับ roaming: เปลี่ยน IP ปลายทางได้โดยไม่ต้อง reconnect

1.1.2 ปัญหาของ VPN รุ่นเก่า

1.1.3 ประวัติและการพัฒนา (History)

ผู้ออกแบบและพัฒนาหลักคือ Jason A. Donenfeld (นักวิจัยด้านความปลอดภัย ผู้ก่อตั้ง Edge Security) เริ่มพัฒนาเป็นโมดูล Linux ราวปี 2015–2016 เผยแพร่เอกสารวิชาการ (whitepaper) ในงาน NDSS 2017 และถูกรวมเข้า Linux kernel 5.6 (ออกเมื่อเดือนมีนาคม 2020) ทำให้ผู้ใช้ Linux จำนวนมากได้ WireGuard ติดมากับ kernel โดยไม่ต้องติดตั้งโมดูลเพิ่ม และมีการ backport ไปยัง kernel LTS ที่เก่ากว่าในหลาย distribution

flowchart LR
    subgraph ERA1["ยุค VPN ดั้งเดิม (Classic VPN Era) 1990s-2000s"]
        A1["IPsec มาตรฐาน RFC 2401
ปี 1998 (IPsec standardized)"]
        A2["OpenVPN เผยแพร่
ปี 2001 (OpenVPN released)"]
        A3["IKEv2 RFC 4306
ปี 2005 (IKEv2 introduced)"]
        A1 --> A2 --> A3
    end
    subgraph ERA2["ยุคกำเนิด WireGuard (Origin Era) 2015-2018"]
        B1["Donenfeld เริ่มพัฒนาโมดูล
ราวปี 2015-2016 (Initial development)"]
        B2["เผยแพร่ whitepaper ที่ NDSS
ปี 2017 (NDSS paper)"]
        B3["แอปทางการ Android/iOS
ปี 2018 (Official mobile apps)"]
        B1 --> B2 --> B3
    end
    subgraph ERA3["ยุคเข้าสู่กระแสหลัก (Mainstream Era) 2019-2021"]
        C1["Tailscale และ mesh VPN
เริ่มเติบโต (Mesh VPN growth)"]
        C2["รวมเข้า Linux 5.6
มีนาคม 2020 (Merged in Linux 5.6)"]
        C3["WireGuardNT สำหรับ Windows
ปี 2021 (Windows kernel driver)"]
        C1 --> C2 --> C3
    end
    subgraph ERA4["ยุคระบบนิเวศ (Ecosystem Era) 2022-ปัจจุบัน"]
        D1["Router/Firewall รองรับกว้างขวาง
(OpenWrt, OPNsense, MikroTik)"]
        D2["เครื่องมือ Post-Quantum และ Obfuscation
(Rosenpass, AmneziaWG)"]
        D1 --> D2
    end
    ERA1 --> ERA2 --> ERA3 --> ERA4

หมายเหตุ: ปีที่ระบุเป็นหมุดหมายโดยประมาณจากเอกสารสาธารณะ ท่านควรตรวจสอบกับ wireguard.com สำหรับรายละเอียดการออกรุ่นล่าสุด

1.1.4 ปรัชญาการออกแบบ (Design Philosophy)

1. เรียบง่าย (Simplicity): ถ้าลดได้ ให้ลด ไม่มีฟีเจอร์เกินจำเป็นใน protocol
2. Code base เล็ก (Small code base): ยิ่งเล็กยิ่งตรวจสอบง่าย ลดช่องโหว่
3. Opinionated cryptography: ผู้ออกแบบเลือก primitive ให้ ผู้ใช้ไม่ต้องตัดสินใจ ลดโอกาส config ผิด
4. ไม่มี state ที่ผู้ใช้ต้องจัดการ: ไม่มี session ที่ต้อง login/logout มี key และ AllowedIPs เท่านั้น
5. เงียบต่อคนแปลกหน้า (Silent to strangers): ไม่ตอบกลับแพ็กเก็ตที่ไม่ผ่านการพิสูจน์ตัวตน จึงสแกนพบได้ยาก

1.1.5 ภาพรวมการใช้งาน (Adoption Overview)

• องค์กร: Remote access, site-to-site, เชื่อมระหว่าง cloud, เป็น CNI encryption ใน Kubernetes
• Home lab: เข้าถึง NAS/Home Assistant จากภายนอกโดยไม่ต้องเปิดพอร์ตบริการ
• ผู้ให้บริการ VPN: Mullvad, ProtonVPN, IVPN และอื่น ๆ ใช้ WireGuard เป็น protocol หลัก
• Mesh VPN: Tailscale, Netbird, Netmaker ใช้ WireGuard เป็นชั้นส่งข้อมูล

🧪 ตัวอย่าง 1.1: สคริปต์ตรวจความพร้อมของเครื่อง (check-wg-ready.sh) ดูในไฟล์ตัวอย่าง

1.2 เปรียบเทียบกับ VPN อื่น (Comparison with Other VPNs)

1.2.1 ตารางเปรียบเทียบ

1.2.2 กราฟเปรียบเทียบเชิงแนวคิด (Conceptual Comparison)

ตารางต่อไปนี้เป็น ค่าเชิงแนวคิดแบบสัมพัทธ์ (relative, ไม่ใช่ผลวัดจริง) เพื่อให้เห็นแนวโน้ม ผลจริงขึ้นกับ CPU, NIC, kernel และขนาด MTU ท่านควรวัดเองด้วย iperf3 (ดูหัวข้อ 9.1)

1.2.3 เมื่อไรควรเลือกและไม่ควรเลือก WireGuard

ควรเลือก WireGuard เมื่อ:

• ต้องการประสิทธิภาพสูงและ latency ต่ำ
• ต้องการ config ที่สั้น ดูแลง่าย ตรวจสอบง่าย
• ใช้งานบนมือถือที่ต้อง roam บ่อย
• ต้องการเชื่อมโครงสร้างพื้นฐานแบบอัตโนมัติ (automation friendly)
• อุปกรณ์ทรัพยากรจำกัด (Raspberry Pi, router)

ไม่ควรเลือก (หรือต้องเสริมเครื่องมืออื่น) เมื่อ:

• เครือข่ายปลายทางบล็อก UDP ทั้งหมด (ต้องใช้ obfuscation ดูส่วนที่ 10)
• ต้องการ user authentication/MFA ในตัว (ต้องใช้ control plane เสริม ดูหัวข้อ 7.4)
• ต้องการ dynamic IP assignment ให้ client จำนวนมากโดยอัตโนมัติ
• มีข้อกำหนดด้าน compliance ที่บังคับใช้ algorithm เฉพาะ (เช่น FIPS) ซึ่งชุด cipher ของ WireGuard ไม่อยู่ในรายการ
• ต้องการ cryptographic agility เพื่อสลับ algorithm โดยไม่เปลี่ยน protocol

flowchart TD
    Start["ต้องการ VPN
(Need a VPN)"] --> Q1{"เครือข่ายอนุญาต UDP หรือไม่?
(UDP allowed?)"}
    Q1 -- "ไม่ (No)" --> R1["ใช้ OpenVPN TCP 443 หรือ
WireGuard + obfuscation"]
    Q1 -- "ใช่ (Yes)" --> Q2{"ต้องใช้ algorithm ตามมาตรฐาน FIPS?
(FIPS required?)"}
    Q2 -- "ใช่ (Yes)" --> R2["ใช้ IPsec ที่ผ่านการรับรอง
(Certified IPsec)"]
    Q2 -- "ไม่ (No)" --> Q3{"ต้องมี SSO/MFA ในตัว?
(Built-in SSO/MFA?)"}
    Q3 -- "ใช่ (Yes)" --> R3["WireGuard + control plane
(Tailscale, Firezone) หรือ SSL VPN"]
    Q3 -- "ไม่ (No)" --> R4["WireGuard ล้วน
(Plain WireGuard)"]

🧪 ตัวอย่าง 1.2: สคริปต์วัด throughput เปรียบเทียบด้วย iperf3 ดูในไฟล์ตัวอย่าง

1.3 โมเดลแนวคิดหลัก (Core Conceptual Model)

1.3.1 Interface และ Peer

• Interface (อินเทอร์เฟซ): network device เสมือน เช่น wg0 มี private key, listen port (ถ้าต้องการรับ connection) และ IP address
• Peer (เพียร์): ปลายทางที่ interface สื่อสารด้วย ระบุด้วย public key พร้อมรายการ AllowedIPs และ Endpoint (ถ้าทราบ)
• ไม่มีบทบาท client/server ใน protocol: ทุกฝั่งคือ peer ที่เท่ากัน คำว่า "server" ใช้เพียงเรียกฝั่งที่มี IP คงที่และคอยรับการติดต่อ

1.3.2 Cryptokey Routing

Cryptokey Routing คือหัวใจของ WireGuard: การผูก public key ของ peer เข้ากับ รายการ IP ที่อนุญาต (AllowedIPs) ตารางนี้ทำหน้าที่สองอย่างพร้อมกัน

1. ขาออก (Outbound) = Routing table: เมื่อมีแพ็กเก็ตจะส่งออก WireGuard ค้นหา peer ที่ AllowedIPs ตรงกับ IP ปลายทาง (แบบ longest prefix match) แล้วเข้ารหัสด้วย key ของ peer นั้น
2. ขาเข้า (Inbound) = Access control list: เมื่อรับแพ็กเก็ตที่ถอดรหัสได้ WireGuard ตรวจว่า source IP ของแพ็กเก็ตชั้นใน อยู่ใน AllowedIPs ของ peer ที่ส่งมาหรือไม่ ถ้าไม่ใช่จะ ทิ้งทันที (drop)

ตัวอย่างตาราง Cryptokey Routing ของ interface หนึ่ง:

1.3.3 WireGuard เป็น Layer 3 Tunnel

• ส่ง IP packet (Layer 3) ไม่ใช่ Ethernet frame (Layer 2) จึง ไม่มี broadcast domain ร่วม และ ไม่ส่ง ARP/DHCP/mDNS ข้าม tunnel โดยปริยาย
• ต้องการ L2 (เช่น bridge, LAN game ที่ใช้ broadcast) ต้องใช้เทคนิคเสริม เช่น GRE/VXLAN ซ้อนใน WireGuard
• ข้อดี: โครงสร้างง่าย ประสิทธิภาพดี ป้องกันปัญหา broadcast storm

1.3.4 ความรู้สึกแบบ Stateless (Stateless-feel)

• ไม่มีการ "เชื่อมต่อ" (connect) หรือ "ตัดการเชื่อมต่อ" (disconnect) อย่างเป็นทางการ
• Interface ที่ up แล้ว จะเงียบ จนกว่าจะมีแพ็กเก็ตที่ต้องส่งไปยัง peer จึงเริ่ม handshake
• "Latest handshake" ใน wg show คือเวลาล่าสุดที่เจรจา key สำเร็จ ไม่ใช่สถานะ "online"
• ไม่มี peer ถูก "หลุด" แต่จะ "เงียบ" ถ้าไม่มี traffic (ยกเว้นตั้ง PersistentKeepalive)

flowchart LR
    subgraph HostA["เครื่อง A (Host A)"]
        AppA["แอปพลิเคชัน
(Application)"]
        RTA["ตาราง route ของระบบ
(System routing table)
10.8.0.0/24 dev wg0"]
        WGA["Interface wg0
Private key A
10.8.0.1/24"]
        CRA["Cryptokey Routing
Peer B = 10.8.0.2/32"]
        AppA --> RTA --> WGA --> CRA
    end
    subgraph Net["อินเทอร์เน็ต (Internet)"]
        UDP["UDP datagram ที่เข้ารหัสแล้ว
(Encrypted UDP)"]
    end
    subgraph HostB["เครื่อง B (Host B)"]
        WGB["Interface wg0
Private key B
10.8.0.2/24"]
        CRB["Cryptokey Routing
Peer A = 10.8.0.1/32"]
        AppB["แอปพลิเคชัน
(Application)"]
        WGB --> CRB --> AppB
    end
    CRA --> UDP --> WGB

🧪 ตัวอย่าง 1.3: สคริปต์ show-cryptokey-table.sh แสดง peer และ AllowedIPs ในรูปตาราง ดูในไฟล์ตัวอย่าง

1.4 หลักการเข้ารหัสที่ใช้ (Cryptographic Principles)

1.4.1 Noise Protocol Framework

WireGuard ใช้ Noise Protocol Framework (ออกแบบโดย Trevor Perrin) รูปแบบ handshake ที่ใช้คือ Noise_IKpsk2 โดยชื่อเต็มของชุดที่ใช้ในเอกสารต้นฉบับคือ Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s

• I (Immediate): initiator ส่ง static public key ของตนทันทีใน message แรก (เข้ารหัสแล้ว)
• K (Known): initiator ทราบ static public key ของ responder ล่วงหน้า (จึงตั้งค่า PublicKey ของ peer ไว้)
• psk2: ผสม pre-shared key เข้าในขั้นตอนที่สอง (ตัวเลือก)

1.4.2 ชุด Primitive ที่ใช้

1.4.3 ทำไมไม่มี Cipher Negotiation

Cipher negotiation คือการที่สองฝั่งเจรจาเลือก algorithm ร่วมกัน ซึ่งเป็นต้นเหตุของช่องโหว่ในหลาย protocol (downgrade attack, config ผิดพลาด, ซับซ้อน)

WireGuard เลือก ไม่มี negotiation:

• ผลดี: ตัด downgrade attack ออกทั้งหมด, โค้ดน้อยลง, ตรวจสอบง่ายขึ้น
• ผลเสีย: ถ้าพบจุดอ่อนใน primitive ต้องออก protocol เวอร์ชันใหม่ และอัปเกรดทุกฝั่งพร้อมกัน (ไม่มี agility)
• แนวคิด: ผู้ออกแบบเห็นว่าการอัปเกรดทั้งระบบเป็นวิธีที่ปลอดภัยกว่า การเก็บ algorithm เก่าไว้ให้เลือก

1.4.4 Perfect Forward Secrecy และการ Rekey

Perfect Forward Secrecy (PFS) หมายถึง การที่กุญแจเซสชันถูกสร้างจาก ephemeral key ซึ่งถูกทิ้งหลังใช้ ดังนั้นแม้ภายหลัง private key ระยะยาวรั่วไหล ผู้โจมตีก็ถอดรหัส traffic ในอดีตที่บันทึกไว้ไม่ได้

WireGuard จะ rekey (เจรจา session key ใหม่) อัตโนมัติ เมื่อ:

• session key มีอายุเกินประมาณ 120 วินาที (REKEY_AFTER_TIME) และมีการส่งข้อมูลอยู่
• จำนวนแพ็กเก็ตเกิน REKEY_AFTER_MESSAGES (ประมาณ 2⁶⁰)
• session key เก่าจะถูกปฏิเสธเมื่ออายุเกินประมาณ 180 วินาที (REJECT_AFTER_TIME)

ตัวอย่างการคำนวณ: จำนวน handshake ต่อวันเมื่อ tunnel ใช้งานตลอดเวลา

• N_hs = จำนวน handshake ต่อวัน (ครั้ง)
• T_day = ระยะเวลาหนึ่งวัน = 86,400 วินาที
• T_rekey = ช่วงเวลา rekey = 120 วินาที

แทนค่า: N_hs = 86,400 ÷ 120 = 720 ครั้งต่อวัน (ประมาณ 1 ครั้งทุก 2 นาที) แต่ละ handshake ใช้ข้อมูลรวมประมาณ 148 + 92 = 240 byte (ไม่รวม header IP/UDP) ดังนั้น overhead ของ rekey ต่อวัน ≈ 720 × 240 = 172,800 byte ≈ 169 KiB ซึ่งน้อยมาก

ตัวอย่างการคำนวณ: เหตุใด limit จำนวนแพ็กเก็ตแทบไม่เป็นปัญหา

• t = เวลาที่ใช้จนครบ 2⁶⁰ แพ็กเก็ต (ปี)
• R = อัตราแพ็กเก็ตต่อวินาที (packets per second)
• 31,557,600 = จำนวนวินาทีใน 1 ปี (365.25 วัน)

แทนค่า: ถ้า R = 1,000,000 แพ็กเก็ต/วินาที จะได้ t ≈ 1.15×10¹⁸ ÷ 3.16×10⁷ ≈ 36,500 ปี ดังนั้นในทางปฏิบัติ rekey จะถูกกระตุ้นด้วยเวลา (120 วินาที) ก่อนเสมอ

1.4.5 Pre-shared Key (PSK)

PSK คือกุญแจลับสมมาตรขนาด 32 byte ที่ทั้งสองฝั่งมีร่วมกัน ถูกผสมเข้าใน handshake เป็นชั้นป้องกันเพิ่ม ประโยชน์คือ:

• ป้องกันกรณีอัลกอริทึม Curve25519 ถูกทำลายในอนาคต (เช่น คอมพิวเตอร์ควอนตัม) เพราะผู้โจมตีต้องรู้ PSK ด้วย
• สร้างด้วย wg genpsk และกำหนดเป็น PresharedKey ใน [Peer] ทั้งสองฝั่ง ค่าต้องเหมือนกัน
• ควรใช้ PSK คนละค่าต่อคู่ peer

🧪 ตัวอย่าง 1.4: สคริปต์สร้างชุดกุญแจและ PSK พร้อมแสดงขนาดและรูปแบบ (demo-keys.sh) ดูในไฟล์ตัวอย่าง

1.5 Handshake และการส่งข้อมูล (Handshake and Data Transport)

1.5.1 ข้อความทั้ง 4 ชนิด (Message Types)

1.5.2 ลำดับการ Handshake

sequenceDiagram
    participant I as Initiator (ผู้เริ่ม)
    participant R as Responder (ผู้ตอบ)
    Note over I: มีแพ็กเก็ตต้องส่งแต่ยังไม่มี session
(Packet queued, no session yet)
    I->>R: Handshake Initiation (type 1, 148 B)
    Note over R: ตรวจ mac1 และ timestamp
ถ้าโหลดสูงอาจตอบ Cookie Reply
    R-->>I: Handshake Response (type 2, 92 B)
    Note over I,R: ทั้งสองฝั่งคำนวณ session keys ด้วย HKDF
(Derive transport keys)
    I->>R: Transport Data แรก (type 4)
    Note over R: ยืนยัน key ครบวงจร (Key confirmation)
    R->>I: Transport Data (type 4)
    Note over I,R: ทุก ~120 วินาที: rekey ด้วย handshake ใหม่

ขั้นตอนโดยย่อ:

1. Initiator สร้าง ephemeral key pair แล้วส่ง Initiation ที่มี static public key และ timestamp (TAI64N) ซึ่งเข้ารหัสไว้
2. Responder ตรวจ mac1 (keyed hash ด้วย public key ของ responder) ถ้าไม่ถูกต้องจะ ไม่ตอบอะไรเลย (ทำให้พอร์ต "เงียบ")
3. Responder ตรวจ timestamp ว่าใหม่กว่าค่าที่เคยเห็นจาก peer นี้ (กัน replay ของ handshake)
4. Responder ส่ง Response พร้อม ephemeral key ของตน
5. ทั้งสองฝั่งสร้าง transport keys (ส่งหนึ่งชุด รับหนึ่งชุด)
6. Initiator ส่งข้อมูลแรก (หรือ keepalive) เพื่อยืนยัน

1.5.3 Transport Data และ Counter กัน Replay

• ทุกแพ็กเก็ตข้อมูลมี counter 64 bit ที่เพิ่มขึ้นทีละหนึ่ง ใช้เป็น nonce ของ ChaCha20-Poly1305
• ฝั่งรับใช้ sliding window จำ counter ที่เคยรับ ปฏิเสธแพ็กเก็ตซ้ำ (replay) และแพ็กเก็ตเก่าเกินหน้าต่าง
• ข้อมูลถูก padding ให้เป็นพหุคูณของ 16 byte (ไม่เกิน MTU) เพื่อลดการรั่วไหลของขนาดจริง
• Keepalive คือ transport data ที่ payload ว่าง ขนาด 32 byte

1.5.4 การป้องกัน DoS ด้วย Cookie

เมื่อ responder ตรวจพบว่าถูกโหลดหนัก (มี handshake เข้ามามากผิดปกติ) จะไม่ประมวลผลการคำนวณ Curve25519 ที่หนัก แต่ส่ง Cookie Reply กลับไปแทน:

1. cookie ผูกกับ IP address ต้นทาง ของ initiator (ผ่าน MAC ที่มี secret หมุนเวียนทุก 2 นาที)
2. initiator ต้องส่ง Initiation ใหม่พร้อม mac2 ที่คำนวณจาก cookie
3. ผู้โจมตีที่ปลอม IP ต้นทาง (IP spoofing) จะไม่ได้รับ cookie จึงไม่ผ่านด่านนี้

1.5.5 Roaming

Roaming คือความสามารถในการเปลี่ยน IP/port ของ peer ได้โดยไม่ต้องตั้งค่าใหม่:

• เมื่อรับแพ็กเก็ตที่ ผ่านการพิสูจน์ตัวตนแล้ว จาก IP/port ใหม่ WireGuard จะอัปเดต Endpoint ของ peer นั้นอัตโนมัติ
• ฝั่งที่ตั้งค่า Endpoint ไว้ แต่ peer ย้ายที่ ก็ยังรับแพ็กเก็ตจากที่ใหม่ได้ และตอบกลับไปยังที่ใหม่
• เหมาะกับมือถือที่สลับ Wi-Fi/4G/5G

1.5.6 PersistentKeepalive และ NAT

อุปกรณ์ NAT/stateful firewall จะลบ mapping ของ UDP ที่เงียบเกินเวลาหนึ่ง (มักราว 30-120 วินาที) ทำให้ฝั่งนอก NAT ส่งหาฝั่งใน NAT ไม่ได้ PersistentKeepalive = N ทำให้ WireGuard ส่ง keepalive ทุก N วินาทีเพื่อรักษา mapping

ตัวอย่างการคำนวณ: ต้นทุนของ keepalive 25 วินาที

• B_day = ปริมาณข้อมูล keepalive ต่อวัน (byte)
• K = ช่วงเวลา keepalive (วินาที) = 25
• S_pkt = ขนาดแพ็กเก็ตรวมบนสาย = 32 (WireGuard) + 8 (UDP) + 20 (IPv4) = 60 byte

แทนค่า: B_day = (86,400 ÷ 25) × 60 = 3,456 × 60 = 207,360 byte ≈ 0.2 MB ต่อวัน (ประมาณ 19.2 bit/s) จึงเหมาะกับมือถือและอุปกรณ์ที่ใช้พลังงานจำกัดเมื่อตั้งค่าเหมาะสม แต่ต้องชั่งน้ำหนักเรื่องการปลุกวิทยุของมือถือ

ข้อแนะนำ: ใช้ 25 วินาทีเป็นค่าเริ่มต้น และเพิ่มได้ถ้า NAT ของท่านมี timeout นาน ฝั่งที่มี public IP และไม่อยู่หลัง NAT ไม่จำเป็น ต้องตั้ง keepalive

🧪 ตัวอย่าง 1.5: ไฟล์ตัวอย่างวิเคราะห์ handshake ด้วย tcpdump พร้อมสคริปต์จำแนก message type จากขนาด ดูในไฟล์ตัวอย่าง

1.6 สถาปัตยกรรม Implementation (Implementation Architecture)

1.6.1 Implementation หลัก

1.6.2 Kernel เทียบกับ Userspace

• Kernel module: แพ็กเก็ตไม่ต้องข้ามระหว่าง kernel กับ userspace จึงลด context switch และการคัดลอกหน่วยความจำ ได้ throughput สูงและ latency ต่ำ
• Userspace (wireguard-go, BoringTun): อ่านแพ็กเก็ตจาก TUN device แล้วเข้ารหัสในโปรเซส แลกกับความพกพาและความปลอดภัยเชิงการแยกโปรเซส แต่มี overhead มากกว่า
• ในทางปฏิบัติ userspace ที่เขียนอย่างดี (หลาย goroutine/thread, ใช้ batching/GSO) ก็ให้ประสิทธิภาพสูงในระดับหลาย Gbps บนฮาร์ดแวร์ที่เหมาะสม

flowchart TB
    subgraph KERNEL["โหมด Kernel (Kernel mode)"]
        K1["แอปพลิเคชัน
(Application)"] --> K2["TCP/IP stack"]
        K2 --> K3["โมดูล WireGuard ใน kernel
(In-kernel WireGuard)"]
        K3 --> K4["UDP socket / NIC
(Network card)"]
    end
    subgraph USER["โหมด Userspace (Userspace mode)"]
        U1["แอปพลิเคชัน
(Application)"] --> U2["TCP/IP stack"]
        U2 --> U3["อุปกรณ์ TUN
(TUN device)"]
        U3 --> U4["โปรเซส wireguard-go หรือ BoringTun
(Userspace process)"]
        U4 --> U5["UDP socket / NIC
(Network card)"]
    end

1.6.3 การรองรับ Windows และ BSD

• WireGuardNT: ไดรเวอร์ kernel เขียนใหม่สำหรับ Windows ใช้ใน WireGuard for Windows รุ่นใหม่ ให้ประสิทธิภาพดีกว่าแบบ userspace เดิม
• FreeBSD: มี implementation if_wg ใน kernel (ในเวอร์ชันใหม่) และมีแพ็กเกจ wireguard-tools/wireguard-go
• OpenBSD: มี wg(4) ใน base system ตั้งค่าผ่าน ifconfig และ hostname.wg0
• NetBSD: ใช้ผ่าน userspace implementation (wireguard-go) หรือตามการรองรับของเวอร์ชัน

ตัวอย่างการคำนวณ: ประเมินความเร็วสูงสุดเชิงทฤษฎีของ tunnel เมื่อ CPU เป็นคอขวด

• T = throughput สูงสุดเชิงทฤษฎีต่อ 1 core (bit/s)
• f = ความถี่ CPU ต่อ core (Hz)
• p = จำนวน cycle ที่ใช้ต่อ 1 byte ของข้อมูล (รวมการเข้ารหัส ChaCha20-Poly1305 และ overhead ของ stack)
• 8 = จำนวน bit ต่อ byte

แทนค่า: ให้ f = 3.0×10⁹ Hz และ p = 3 cycles/byte (ค่าสมมติเพื่อการเรียนรู้) จะได้ T = (3.0×10⁹ ÷ 3) × 8 = 8×10⁹ bit/s = 8 Gbit/s ต่อ core ค่าจริงจะต่ำกว่านี้เพราะมี overhead ของ network stack การคัดลอกหน่วยความจำ และ handshake ดังนั้นต้องวัดจริงด้วย iperf3

🧪 ตัวอย่าง 1.6: สคริปต์ตรวจว่าเครื่องใช้ kernel module หรือ userspace และติดตั้ง wireguard-go ดูในไฟล์ตัวอย่าง

ส่วนที่ 2 การติดตั้งบนทุกแพลตฟอร์ม (Installation on All Platforms)

flowchart TD
    S["เลือกแพลตฟอร์ม
(Choose platform)"] --> L["Linux"]
    S --> W["Windows"]
    S --> M["macOS"]
    S --> P["Android / iOS"]
    S --> B["BSD / pfSense / OPNsense"]
    S --> C["Container (Docker)"]
    L --> L1{"kernel เวอร์ชัน 5.6 ขึ้นไป?
(kernel >= 5.6?)"}
    L1 -- "ใช่ (Yes)" --> L2["ติดตั้ง wireguard-tools อย่างเดียว
(tools only)"]
    L1 -- "ไม่ (No)" --> L3["ติดตั้ง DKMS module + tools
(DKMS + tools)"]
    W --> W1["ติดตั้งแอป WireGuard (WireGuardNT)"]
    M --> M1["App Store หรือ Homebrew (wireguard-go)"]
    P --> P1["แอปทางการ + สแกน QR code"]
    B --> B1["Kernel driver หรือ wireguard-go"]
    C --> C1["NET_ADMIN + SYS_MODULE หรือ userspace"]

2.1 Linux

2.1.1 ตรวจสอบ kernel support

# ดูเวอร์ชัน kernel (Kernel 5.6 ขึ้นไปมี WireGuard ในตัว)
uname -r

# ตรวจว่า kernel มีโมดูล WireGuard หรือไม่ (ทั้งแบบ built-in และ module)
modinfo wireguard 2>/dev/null | head -n 5 || echo "ไม่พบโมดูล wireguard (module not found)"

# ทดสอบสร้าง interface ชนิด wireguard จริง (ต้องใช้ root)
sudo ip link add dev wgtest type wireguard && echo "kernel รองรับ (supported)" ; sudo ip link del dev wgtest 2>/dev/null

# ตัวอย่างผลลัพธ์ที่คาดหวัง:
#   5.15.0-91-generic
#   filename:       /lib/modules/5.15.0-91-generic/kernel/drivers/net/wireguard/wireguard.ko
#   kernel รองรับ (supported)

2.1.2 ติดตั้ง wireguard-tools ตาม Distribution

2.1.3 กรณี kernel เก่า: DKMS module

DKMS (Dynamic Kernel Module Support) คือกลไกคอมไพล์โมดูลให้ตรงกับ kernel ที่ใช้อยู่

# Debian/Ubuntu: ติดตั้ง header ของ kernel และโมดูลแบบ DKMS
sudo apt install -y linux-headers-$(uname -r) wireguard-dkms wireguard-tools

# RHEL-family (หลังเปิด EPEL): ติดตั้งเครื่องมือคอมไพล์และ DKMS
sudo dnf install -y epel-release
sudo dnf install -y kernel-devel-$(uname -r) dkms
# แล้วติดตั้งแพ็กเกจ wireguard-dkms จากคลังที่ใช้ (ชื่อแพ็กเกจแตกต่างตามคลัง)

# ตรวจสอบสถานะการ build ของ DKMS
dkms status | grep -i wireguard

2.1.4 ตรวจสอบการติดตั้ง

# โหลดโมดูล (ถ้า built-in จะไม่มี error)
sudo modprobe wireguard && echo "โหลดโมดูลสำเร็จ (module loaded)"

# ดูว่าโมดูลถูกโหลด
lsmod | grep wireguard

# ดูเวอร์ชันของเครื่องมือ
wg --version
wg-quick --help 2>&1 | head -n 3

# ตัวอย่างผลลัพธ์:
#   wireguard-tools v1.0.20210914 - https://git.zx2c4.com/wireguard-tools/

🧪 ตัวอย่าง 2.1: สคริปต์ install-wireguard.sh ติดตั้งอัตโนมัติตาม distribution และตรวจสอบผลลัพธ์ ดูในไฟล์ตัวอย่าง

2.2 Windows

2.2.1 ติดตั้งแอปอย่างเป็นทางการ

1. ดาวน์โหลดตัวติดตั้งจากหน้า Install ของ wireguard.com (ตรวจ digital signature ของไฟล์ก่อนรัน)
2. ติดตั้ง ต้องใช้สิทธิ์ Administrator
3. แอปใช้ไดรเวอร์ WireGuardNT (kernel driver) ซึ่งเร็วกว่าแบบ userspace เดิม

2.2.2 การนำเข้า config และ Tunnel Service

• เมนู Import tunnel(s) from file เลือกไฟล์ .conf
• หรือ Add empty tunnel เพื่อให้แอปสร้างคู่กุญแจให้ แล้วแก้ไข config ใน GUI
• เมื่อกด Activate แอปจะติดตั้ง tunnel เป็น Windows Service ชื่อรูปแบบ WireGuardTunnel$ชื่อ ทำงานแม้ไม่มีผู้ใช้ login ถ้าตั้งให้เริ่มอัตโนมัติ
• ถ้า AllowedIPs มี 0.0.0.0/0 แอปเปิด Block untunneled traffic (kill-switch) ให้โดยค่าเริ่มต้น

# ติดตั้ง tunnel เป็น service จากไฟล์ config (ใช้ PowerShell แบบ Administrator)
& "C:\Program Files\WireGuard\wireguard.exe" /installtunnelservice "C:\wg\wg0.conf"

# ตรวจสถานะ service (ใช้ single quote เพราะชื่อมีเครื่องหมาย $)
Get-Service -Name 'WireGuardTunnel$wg0'

# ดูสถานะ tunnel ด้วย wg.exe (มาพร้อมแอป)
& "C:\Program Files\WireGuard\wg.exe" show

# ถอน tunnel service
& "C:\Program Files\WireGuard\wireguard.exe" /uninstalltunnelservice wg0

# ตัวอย่างผลลัพธ์ที่คาดหวัง:
#   Status   Name               DisplayName
#   Running  WireGuardTunnel$wg0 WireGuard Tunnel: wg0

2.2.3 ข้อควรระวัง

• สิทธิ์ผู้ดูแลระบบ: การเปิด/ปิด tunnel ปกติต้องใช้ admin ผู้ใช้ทั่วไปต้องมีการตั้งค่ากลุ่ม "Network Configuration Operators" ตามเอกสารของแอป
• Firewall profile: interface ของ WireGuard อาจถูกจัดเป็น Public network ทำให้กฎ Windows Firewall เข้มกว่า (เช่น บล็อกไฟล์แชร์/RDP) ปรับได้ดังนี้

# ดูหมวดหมู่เครือข่ายของ interface wg0
Get-NetConnectionProfile -InterfaceAlias wg0

# เปลี่ยนเป็น Private เพื่อให้กฎ Private profile ใช้งาน (ต้องพิจารณาความเสี่ยงก่อน)
Set-NetConnectionProfile -InterfaceAlias wg0 -NetworkCategory Private

# เปิดกฎให้ ping จาก subnet ของ tunnel ได้ (ตัวอย่าง)
New-NetFirewallRule -DisplayName "Allow ICMPv4 from WG" -Protocol ICMPv4 -IcmpType 8 `
  -RemoteAddress 10.8.0.0/24 -Action Allow

🧪 ตัวอย่าง 2.2: ไฟล์ windows-client.conf พร้อมสคริปต์ PowerShell ติดตั้ง/ถอน ดูในไฟล์ตัวอย่าง

2.3 macOS

2.3.1 App Store เทียบกับ Homebrew

2.3.2 การใช้ wg-quick บน macOS

# ติดตั้งเครื่องมือ (wg-quick ต้องการ bash เวอร์ชัน 4 ขึ้นไป)
brew install wireguard-tools bash

# ตำแหน่ง config: Apple Silicon = /opt/homebrew/etc/wireguard , Intel = /usr/local/etc/wireguard
sudo mkdir -p /opt/homebrew/etc/wireguard
sudo cp wg0.conf /opt/homebrew/etc/wireguard/
sudo chmod 600 /opt/homebrew/etc/wireguard/wg0.conf

# เปิด tunnel (macOS จะสร้าง interface ชื่อ utunN และเก็บชื่อ wg0 ไว้ใน /var/run/wireguard)
sudo wg-quick up wg0

# ตรวจสอบสถานะ
sudo wg show

# ปิด tunnel
sudo wg-quick down wg0

หมายเหตุ: บน macOS ชื่อ interface จริงเป็น utunN ไม่ใช่ wg0 ให้ดูชื่อจริงจาก sudo wg show interfaces หรือไฟล์ /var/run/wireguard/wg0.name

🧪 ตัวอย่าง 2.3: สคริปต์ macos-wgctl.sh สำหรับเปิด/ปิด/ตรวจสถานะ ดูในไฟล์ตัวอย่าง

2.4 Android และ iOS

2.4.1 แอปทางการและการสแกน QR code

• ติดตั้ง WireGuard จาก Google Play / App Store
• แตะ + แล้วเลือก Scan from QR code เพื่อนำเข้า config ที่สร้างบนเซิร์ฟเวอร์ (ดูการสร้าง QR ในหัวข้อ 7.3)
• ทางเลือก: นำเข้าจากไฟล์ .conf หรือสร้าง tunnel เปล่า

2.4.2 On-Demand Activation

• iOS: ตั้ง On-Demand Activation ได้แยกตามชนิดเครือข่าย (Cellular, Wi-Fi, Ethernet) และกำหนดรายชื่อ SSID ที่ "เปิด" หรือ "ปิด" อัตโนมัติ (เช่น เปิด VPN เมื่อไม่ใช่ Wi-Fi บ้าน)
• Android: ใช้ฟีเจอร์ระบบ Always-on VPN + Block connections without VPN (kill-switch) ในการตั้งค่า VPN ของ Android และมี "Auto-connect" ตามเงื่อนไขของแอปในบางรุ่น

2.4.3 Per-app Tunneling (Android Split Tunneling)

Android แอปรองรับการเลือกแอปที่ใช้/ไม่ใช้ tunnel ในหน้าแก้ไข tunnel:

• Excluded applications: แอปที่เลือกจะ ไม่ ผ่าน VPN (เช่น แอปธนาคารบางตัวที่บล็อก VPN)
• Included applications: เฉพาะแอปที่เลือกเท่านั้นที่ผ่าน VPN
• ในไฟล์ config ส่วน [Interface] ใช้คีย์เฉพาะของแอป Android คือ ExcludedApplications / IncludedApplications (ใช้ package name คั่นด้วย comma)

# ตัวอย่าง config สำหรับ Android (ส่วนนี้ใช้ได้เฉพาะแอป Android)
[Interface]
PrivateKey = <ANDROID_PRIVATE_KEY>
Address = 10.8.0.10/32
DNS = 10.8.0.1
# ไม่ให้แอปเหล่านี้ผ่าน VPN (excluded applications)
ExcludedApplications = com.android.chrome, com.example.bankapp

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

2.4.4 ข้อจำกัดด้าน Battery และ Background

• PersistentKeepalive ที่ถี่ทำให้อุปกรณ์ตื่นบ่อย แนะนำ 25 วินาทีเฉพาะเมื่ออยู่หลัง NAT และต้องการให้ฝั่งอื่นติดต่อเข้ามาได้
• ถ้าอุปกรณ์เป็นฝ่ายเริ่มติดต่อเสมอ (เช่น เปิดแอปแล้วจึงใช้ VPN) อาจ ไม่ตั้ง keepalive เพื่อประหยัดแบตเตอรี่
• ระบบปฏิบัติการอาจ suspend แอปใน background (เช่น Doze mode) ควรยกเว้นแอป WireGuard จาก battery optimization หากต้องการให้ tunnel เสถียร

🧪 ตัวอย่าง 2.4: สคริปต์สร้าง QR code ของ config มือถือ (ใช้ qrencode) ดูในไฟล์ตัวอย่าง

2.5 BSD และระบบอื่น (BSD and Other Systems)

2.5.1 FreeBSD

# ติดตั้ง tools
pkg install -y wireguard-tools

# โหลดโมดูล kernel (บนรุ่นที่มี if_wg) และให้โหลดตอนบูต
kldload if_wg
sysrc kld_list+="if_wg"

# ตั้งค่า interface ผ่าน rc.conf (ตัวอย่าง)
sysrc wireguard_enable="YES"
sysrc wireguard_interfaces="wg0"

# เก็บ config ไว้ที่ /usr/local/etc/wireguard/wg0.conf แล้วเริ่ม
service wireguard start wg0

2.5.2 OpenBSD

OpenBSD มี wg(4) ใน base system ตั้งค่าด้วย ifconfig / hostname.if(5)

# ไฟล์ /etc/hostname.wg0  (ต้อง chmod 640 หรือ 600, owner root)
wgkey <OPENBSD_PRIVATE_KEY>
wgport 51820
wgpeer <PEER_PUBLIC_KEY> wgendpoint 203.0.113.10 51820 wgaip 10.8.0.0/24
inet 10.8.0.2 255.255.255.0
up

# นำ config ไปใช้ทันทีโดยไม่ต้องรีบูต
sh /etc/netstart wg0

# ดูสถานะ
ifconfig wg0

2.5.3 NetBSD

ใช้ผ่าน pkgsrc: net/wireguard-go และ net/wireguard-tools (userspace implementation) ตั้งค่า TUN device แล้วรัน wireguard-go wg0

2.5.4 pfSense และ OPNsense (แนะนำเบื้องต้น)

• pfSense: ติดตั้ง WireGuard เป็น package ผ่าน Package Manager (เวอร์ชันที่รองรับขึ้นกับรุ่น CE/Plus)
• OPNsense: ใช้ปลั๊กอิน/ส่วนประกอบ WireGuard (ในรุ่นใหม่บางรุ่นรวมมากับระบบ) ตั้งค่า Instance (Local) และ Peer (Endpoint) ผ่าน Web UI
• ต้องเพิ่มกฎ firewall บน interface WAN (อนุญาต UDP port) และบน interface ของ WireGuard
• รายละเอียดการตั้งค่าอยู่ในหัวข้อ 6.1

🧪 ตัวอย่าง 2.5: ไฟล์ config ตัวอย่างสำหรับ FreeBSD และ OpenBSD ดูในไฟล์ตัวอย่าง

2.6 การรันใน Container (Running in Containers)

2.6.1 Docker: capability ที่ต้องใช้

# docker-compose.yml: WireGuard server อย่างง่าย (ใช้ image ของ linuxserver.io)
services:
  wireguard:
    image: lscr.io/linuxserver/wireguard:latest
    container_name: wireguard
    cap_add:
      - NET_ADMIN        # จำเป็น: จัดการ interface
      - SYS_MODULE       # จำเป็นเฉพาะกรณี host ยังไม่โหลดโมดูล
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Bangkok
      - SERVERURL=vpn.example.com   # ชื่อ/IP สาธารณะของเซิร์ฟเวอร์
      - SERVERPORT=51820
      - PEERS=3                     # สร้าง client 3 ชุดอัตโนมัติ
      - PEERDNS=auto
      - INTERNAL_SUBNET=10.13.13.0
    volumes:
      - ./config:/config
      - /lib/modules:/lib/modules:ro
    ports:
      - 51820:51820/udp
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1
    restart: unless-stopped

# วิธีใช้:
#   docker compose up -d
#   docker compose logs wireguard | tail      # ดู QR code ของ peer1 ใน log
#   cat config/peer_peer1/peer_peer1.conf     # ไฟล์ config ของ client

2.6.2 ข้อควรระวัง Kernel Module กับ Host

• Container ใช้ kernel ของ host ร่วมกัน จึงโหลดโมดูลได้เฉพาะที่ host รองรับ
• ถ้า host เป็น kernel 5.6+ ให้ ตัด SYS_MODULE ออก เพื่อลดสิทธิ์ (least privilege)
• บน host ที่เป็น NAS/ระบบปิด (เช่น Synology รุ่นเก่า) อาจไม่มีโมดูล ต้องใช้ userspace
• โหมด rootless Docker/Podman สร้าง interface ในเครือข่ายของ host ไม่ได้ ต้องใช้ userspace + TUN

2.6.3 Rootless / Userspace Mode ด้วย wireguard-go

# รัน container แบบ userspace ด้วย wireguard-go (ไม่ต้องมีโมดูล kernel)
# ต้องมี /dev/net/tun และ capability NET_ADMIN
docker run -d --name wg-userspace \
  --cap-add NET_ADMIN \
  --device /dev/net/tun:/dev/net/tun \
  -e WG_QUICK_USERSPACE_IMPLEMENTATION=wireguard-go \
  -v "$PWD/wg0.conf:/etc/wireguard/wg0.conf:ro" \
  -p 51820:51820/udp \
  --entrypoint sh \
  alpine:3.20 -c "apk add --no-cache wireguard-tools wireguard-go iptables && wg-quick up wg0 && sleep infinity"

# ตรวจสอบผลลัพธ์
docker exec wg-userspace wg show
# ตัวอย่างผลลัพธ์: interface: wg0, public key: ..., listening port: 51820

🧪 ตัวอย่าง 2.6: ไฟล์ docker-compose.yml และ userspace-run.sh ดูในไฟล์ตัวอย่าง

ส่วนที่ 3 การตั้งค่าพื้นฐาน (Basic Configuration)

3.1 การสร้างกุญแจ (Key Generation)

3.1.1 คำสั่งที่ใช้

# ตั้ง umask ให้ไฟล์ที่สร้างอ่านได้เฉพาะเจ้าของ (permission 600)
umask 077

# สร้าง private key แล้วคำนวณ public key ในคำสั่งเดียว
wg genkey | tee server.key | wg pubkey > server.pub

# สร้าง pre-shared key สำหรับคู่ peer หนึ่ง ๆ (ไม่บังคับ)
wg genpsk > server-client1.psk

# ตรวจสอบ permission และขนาด
ls -l server.key server.pub server-client1.psk
wc -c server.key     # ควรได้ 45 (44 ตัวอักษร + newline)

# วิธีใช้: อ่านค่าไปใส่ config
echo "PrivateKey = $(cat server.key)"
echo "PublicKey  = $(cat server.pub)"

3.1.2 การจัดเก็บ Private Key อย่างปลอดภัย

• ตั้ง permission 600 (เจ้าของอ่าน/เขียนเท่านั้น) และเจ้าของเป็น root สำหรับไฟล์ใน /etc/wireguard/
• ใช้ umask 077 ก่อนสร้างกุญแจ เพื่อไม่ให้ไฟล์เคยมี permission กว้างแม้เพียงชั่วขณะ
• อย่า ส่ง private key ผ่านแชต อีเมล หรือ commit เข้า Git (ใช้ secret manager ดูหัวข้อ 8.2)
• ถ้า wg-quick พบ config ที่ group/other อ่านได้ จะแจ้งเตือน (Warning: ... is world accessible)

# ตั้ง permission ของโฟลเดอร์และไฟล์ที่เหมาะสม
sudo install -d -m 700 /etc/wireguard
sudo install -m 600 wg0.conf /etc/wireguard/wg0.conf
sudo ls -ld /etc/wireguard && sudo ls -l /etc/wireguard

3.1.3 แนวปฏิบัติ: 1 Key ต่อ 1 อุปกรณ์

• ห้ามใช้ key เดียวกันร่วมกันหลายอุปกรณ์ เพราะ WireGuard ระบุ peer ด้วย public key เมื่อสองเครื่องใช้ key เดียวกัน endpoint จะ "แย่งกัน" สลับไปมา
• การแยก key ต่ออุปกรณ์ทำให้ revoke ได้เฉพาะเครื่องที่สูญหาย (ดูหัวข้อ 8.2)
• ตั้งชื่อไฟล์ให้บอกเจ้าของและอุปกรณ์ เช่น alice-laptop.key

🧪 ตัวอย่าง 3.1: สคริปต์ gen-keys.sh สร้างกุญแจของทุก peer ในครั้งเดียวและตั้ง permission ดูในไฟล์ตัวอย่าง

3.2 โครงสร้างไฟล์ config (Configuration File Structure)

3.2.1 ภาพรวม

ไฟล์ config ของ wg-quick เป็นรูปแบบ INI มี 2 ส่วนหลัก คือ [Interface] (หนึ่งส่วน) และ [Peer] (ศูนย์ถึงหลายส่วน)

flowchart TD
    CF["ไฟล์ wg0.conf
(Config file)"] --> IF["[Interface]
ตัวตนของเครื่องนี้ (This host)"]
    CF --> P1["[Peer] ที่ 1
เครื่องปลายทาง (Remote peer)"]
    CF --> P2["[Peer] ที่ 2 ... n"]
    IF --> I1["PrivateKey / ListenPort"]
    IF --> I2["Address / DNS / MTU"]
    IF --> I3["Table / FwMark"]
    IF --> I4["PreUp / PostUp / PreDown / PostDown / SaveConfig"]
    P1 --> Q1["PublicKey / PresharedKey"]
    P1 --> Q2["AllowedIPs / Endpoint"]
    P1 --> Q3["PersistentKeepalive"]

3.2.2 ส่วน [Interface]

3.2.3 ส่วน [Peer]

3.2.4 Hook: PreUp, PostUp, PreDown, PostDown, SaveConfig

• แต่ละ hook ใส่ได้หลายบรรทัด และรันตามลำดับที่เขียน
• ตัวแปร %i จะถูกแทนด้วยชื่อ interface (เช่น wg0)
• ใช้กับ NAT/firewall: ตั้งกฎใน PostUp และลบกฎด้วยคำสั่งตรงข้ามใน PostDown (ต้องจับคู่กัน)

[Interface]
PrivateKey = <SERVER_PRIVATE_KEY>
Address = 10.8.0.1/24
ListenPort = 51820
# เปิด NAT เมื่อ interface ขึ้น และล้างเมื่อลง (eth0 = interface ขาออกสู่อินเทอร์เน็ต)
PostUp   = iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

3.2.5 อธิบาย AllowedIPs ให้ชัด

AllowedIPs ทำหน้าที่ สองอย่างในที่เดียว และเป็นแหล่งความสับสนอันดับหนึ่งของผู้เริ่มต้น

กฎสำคัญ:

1. ช่วง AllowedIPs ของ peer ต่าง ๆ ซ้อนทับกันไม่ได้อย่างสมบูรณ์: ถ้า IP หนึ่งปรากฏใน AllowedIPs ของสอง peer จะถูกย้ายไปผูกกับ peer ที่ตั้งค่าล่าสุด
2. 0.0.0.0/0 หมายถึง "ส่งทุกอย่างผ่าน peer นี้" (default route) ควรมี peer เดียว เท่านั้นที่มีค่านี้
3. ใน config ของ client AllowedIPs ของ server คือ "สิ่งที่ client จะส่งผ่าน VPN"; ใน config ของ server AllowedIPs ของ client คือ "IP ที่ client คนนั้นมีสิทธิ์ใช้เป็น source" (ปกติคือ /32 ของ client)

🧪 ตัวอย่าง 3.2: ไฟล์ config อ้างอิงที่ใส่ comment ทุกตัวเลือก (reference.conf) ดูในไฟล์ตัวอย่าง

3.3 Tunnel แรกแบบ Point-to-Point (First Point-to-Point Tunnel)

3.3.1 สถานการณ์และสถาปัตยกรรม

เชื่อมสองเครื่อง คือ Node A (มี public IP 203.0.113.10) และ Node B (อยู่หลัง NAT ได้) ผ่าน tunnel network 10.8.0.0/24

flowchart LR
    subgraph A["Node A (เซิร์ฟเวอร์ Server)"]
        A1["eth0: 203.0.113.10"]
        A2["wg0: 10.8.0.1/24
ListenPort 51820"]
    end
    subgraph B["Node B (ไคลเอนต์ Client)"]
        B1["eth0: 192.168.1.50 (หลัง NAT)"]
        B2["wg0: 10.8.0.2/24"]
    end
    A2 <-- "UDP 51820 (เข้ารหัส Encrypted)" --> B2
    A1 --- A2
    B1 --- B2

3.3.2 การออกแบบ Addressing ของ Tunnel Network

ควรเลือกช่วง private ที่ ไม่ชนกับเครือข่ายที่เกี่ยวข้อง (LAN ที่บ้าน, ออฟฟิศ, Wi-Fi สาธารณะที่มักใช้ 192.168.0.0/24, 192.168.1.0/24, 10.0.0.0/24) จึงนิยมเลือกช่วงที่ไม่ค่อยถูกใช้ เช่น 10.8.0.0/24, 10.77.0.0/24, 172.30.50.0/24

จำนวนที่อยู่ที่ใช้งานได้ในเครือข่าย IPv4 prefix /p:

• H_usable = จำนวน host address ที่ใช้งานได้
• p = ความยาว prefix (เช่น 24 สำหรับ /24)
• 32 = จำนวน bit ทั้งหมดของ IPv4 address
• ลบ 2 = ตัด network address และ broadcast address

ตัวอย่างการคำนวณ: ต้องรองรับพนักงาน 40 คน คนละ 2 อุปกรณ์ = 80 peer + server 1 + สำรอง 20% ≈ 100 address ต้องการ H ≥ 100 ดังนั้น 2^32−p − 2 ≥ 100 → 2^32−p ≥ 102 → 32−p ≥ 7 (เพราะ 2⁷ = 128) → p ≤ 25 เลือก /25 (126 address) หรือ /24 เพื่อเผื่อโต

หมายเหตุ: บน interface ของ WireGuard ปกติตั้ง client เป็น /32 ในฝั่ง server (AllowedIPs) และตั้ง interface ของ client เป็น /24 หรือ /32 ตามรูปแบบการใช้งาน

3.3.3 ขั้นตอนทีละขั้น

ขั้นที่ 1: สร้างกุญแจบนทั้งสองเครื่อง

# บน Node A
umask 077 && wg genkey | tee /etc/wireguard/a.key | wg pubkey > /etc/wireguard/a.pub
# บน Node B
umask 077 && wg genkey | tee /etc/wireguard/b.key | wg pubkey > /etc/wireguard/b.pub
# คัดลอกเฉพาะ "public key" ข้ามเครื่อง (ห้ามส่ง private key)

ขั้นที่ 2: เขียน config บน Node A (/etc/wireguard/wg0.conf)

[Interface]
# Node A: ฝั่งที่มี public IP คอยรับ connection
PrivateKey = <NODE_A_PRIVATE_KEY>
Address = 10.8.0.1/24
ListenPort = 51820

[Peer]
# Node B
PublicKey = <NODE_B_PUBLIC_KEY>
# อนุญาตเฉพาะ IP ของ Node B ใน tunnel
AllowedIPs = 10.8.0.2/32

ขั้นที่ 3: เขียน config บน Node B

[Interface]
# Node B: ฝั่งที่เริ่มติดต่อ (อยู่หลัง NAT ได้)
PrivateKey = <NODE_B_PRIVATE_KEY>
Address = 10.8.0.2/24

[Peer]
# Node A
PublicKey = <NODE_A_PUBLIC_KEY>
AllowedIPs = 10.8.0.1/32
Endpoint = 203.0.113.10:51820
# อยู่หลัง NAT ให้ส่ง keepalive เพื่อรักษา mapping
PersistentKeepalive = 25

ขั้นที่ 4: เปิด tunnel และเปิดพอร์ต

# เปิดพอร์ตบน Node A (ตัวอย่างใช้ ufw)
sudo ufw allow 51820/udp

# เปิด tunnel บนทั้งสองเครื่อง
sudo wg-quick up wg0

ขั้นที่ 5: ทดสอบ

# บน Node B: ping Node A ผ่าน tunnel
ping -c 3 10.8.0.1

# ดูสถานะ (ต้องเห็น latest handshake และ transfer)
sudo wg show

# ตัวอย่างผลลัพธ์ที่คาดหวังของ wg show บน Node B:
#   interface: wg0
#     public key: (public key ของ B)
#     private key: (hidden)
#     listening port: 49321
#
#   peer: (public key ของ A)
#     endpoint: 203.0.113.10:51820
#     allowed ips: 10.8.0.1/32
#     latest handshake: 4 seconds ago
#     transfer: 1.20 KiB received, 1.05 KiB sent
#     persistent keepalive: every 25 seconds

3.3.4 ข้อควรระวัง

• ถ้า latest handshake ไม่ปรากฏ แสดงว่าไม่เกิด handshake ให้ตรวจ key, endpoint, firewall (ดูหัวข้อ 9.4)
• ใช้ ping ทดสอบหลังมี handshake เท่านั้น การ ping ครั้งแรกอาจช้าเพราะต้องเจรจา key ก่อน
• ห้ามให้ Address ของ tunnel ชนกับ subnet LAN ที่เครื่องนั้นต่ออยู่

🧪 ตัวอย่าง 3.3: สคริปต์ทดลองบนเครื่องเดียวด้วย network namespace (lab-p2p-netns.sh) พร้อมผลลัพธ์ที่คาดหวัง ดูในไฟล์ตัวอย่าง

3.4 เครื่องมือจัดการ (Management Tools)

3.4.1 wg เทียบกับ wg-quick

# คำสั่งที่ใช้บ่อยของ wg
sudo wg show                  # สถานะทุก interface
sudo wg show wg0 latest-handshakes   # เวลา handshake ล่าสุดของทุก peer (epoch)
sudo wg showconf wg0          # แสดง config ปัจจุบัน (รูปแบบที่ wg เข้าใจ)
sudo wg set wg0 peer <PUBKEY> allowed-ips 10.8.0.5/32   # เพิ่ม/แก้ peer แบบสด (ไม่ต้อง restart)
sudo wg set wg0 peer <PUBKEY> remove                    # ลบ peer สด ๆ

# โหลด config ใหม่โดยไม่ตัด tunnel ที่ใช้อยู่ (hot reload)
sudo wg syncconf wg0 <(sudo wg-quick strip wg0)

3.4.2 ตั้งค่า Manual ด้วย ip (ไม่ใช้ wg-quick)

# 1) สร้าง interface ชนิด wireguard
sudo ip link add dev wg0 type wireguard

# 2) กำหนด IP address ให้ interface
sudo ip address add 10.8.0.2/24 dev wg0

# 3) ตั้งค่า WireGuard (key, peer) ด้วย wg ; ไฟล์ b.key ต้องมี permission 600
sudo wg set wg0 \
    private-key /etc/wireguard/b.key \
    peer <NODE_A_PUBLIC_KEY> \
    allowed-ips 10.8.0.1/32 \
    endpoint 203.0.113.10:51820 \
    persistent-keepalive 25

# 4) เปิด interface
sudo ip link set up dev wg0

# 5) (ถ้าต้องการ) เพิ่ม route ไปยังเครือข่ายหลัง peer
sudo ip route add 192.168.20.0/24 dev wg0

# ปิดและลบ
sudo ip link set down dev wg0 && sudo ip link del dev wg0

# หมายเหตุ: AllowedIPs ไม่สร้าง route ให้ใน kernel โดยอัตโนมัติ (wg-quick เป็นผู้เพิ่ม route ให้)

3.4.3 เปิด/ปิด Tunnel และ systemd

# เปิด/ปิดแบบชั่วคราว
sudo wg-quick up wg0
sudo wg-quick down wg0

# ให้ tunnel เริ่มอัตโนมัติเมื่อบูต (unit template ชื่อ wg-quick@<interface>)
sudo systemctl enable --now wg-quick@wg0

# ตรวจสถานะ และดู log
systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 --no-pager | tail -n 20

# รีโหลด config โดยไม่ตัด tunnel (แนะนำใช้กับ production)
sudo systemctl reload wg-quick@wg0     # ในบางแพ็กเกจมี ExecReload ที่ใช้ wg syncconf

3.4.4 การรัน Tunnel อัตโนมัติเมื่อบูต

1. วาง config ที่ /etc/wireguard/wg0.conf (permission 600)
2. systemctl enable wg-quick@wg0
3. ตรวจให้ network พร้อมก่อน: unit template มี After=network-online.target อยู่แล้ว แต่หากใช้ Endpoint เป็นชื่อโดเมน ต้องแน่ใจว่า DNS ใช้ได้ตอนบูต
4. ทดสอบด้วยการรีบูต แล้วตรวจ wg show

🧪 ตัวอย่าง 3.4: ไฟล์ wg0.conf + สคริปต์ตั้งค่า manual (manual-setup.sh) ดูในไฟล์ตัวอย่าง

3.5 Network Manager Integration

3.5.1 NetworkManager

# นำเข้าไฟล์ config เป็น connection ของ NetworkManager
sudo nmcli connection import type wireguard file /etc/wireguard/wg0.conf

# เปิด/ปิด connection
nmcli connection up wg0
nmcli connection down wg0

# ให้เชื่อมต่ออัตโนมัติ
nmcli connection modify wg0 connection.autoconnect yes

# ดูรายละเอียด
nmcli connection show wg0 | grep -i wireguard

ข้อสังเกต: NetworkManager จัดการ route และ DNS เอง ไม่รัน PostUp/PostDown ของ wg-quick ดังนั้น config ที่พึ่ง hook (เช่น NAT) ควรใช้ wg-quick หรือ systemd unit แยก

3.5.2 systemd-networkd

สร้างสองไฟล์: .netdev (ประกาศ interface) และ .network (ตั้ง address/route)

# /etc/systemd/network/99-wg0.netdev
[NetDev]
Name=wg0
Kind=wireguard
Description=WireGuard tunnel wg0

[WireGuard]
# ใช้ไฟล์กุญแจแยก เพื่อไม่ฝัง secret ในไฟล์ .netdev
PrivateKeyFile=/etc/systemd/network/wg0.key
ListenPort=51820

[WireGuardPeer]
PublicKey=<PEER_PUBLIC_KEY>
AllowedIPs=10.8.0.2/32
# Endpoint=203.0.113.10:51820      # ใส่เมื่อเป็นฝ่ายเริ่มติดต่อ
# PersistentKeepalive=25

# /etc/systemd/network/99-wg0.network
[Match]
Name=wg0

[Network]
Address=10.8.0.1/24

# เพิ่ม route ไปเครือข่ายหลัง peer (ถ้ามี)
[Route]
Destination=192.168.20.0/24

# ตั้งเจ้าของไฟล์กุญแจให้ systemd-networkd อ่านได้ แต่ผู้ใช้อื่นอ่านไม่ได้
sudo install -m 0640 -o root -g systemd-network wg0.key /etc/systemd/network/wg0.key

# นำไปใช้
sudo networkctl reload
networkctl status wg0

3.5.3 netplan

# /etc/netplan/90-wireguard.yaml  (ตรวจเวอร์ชัน netplan ที่รองรับ key แบบไฟล์)
network:
  version: 2
  tunnels:
    wg0:
      mode: wireguard
      addresses: [10.8.0.1/24]
      port: 51820
      key:
        private: /etc/wireguard/server.key   # path ของไฟล์หรือค่า key (แนะนำให้ใช้ไฟล์)
      peers:
        - keys:
            public: <PEER_PUBLIC_KEY>
          allowed-ips: [10.8.0.2/32]
          # endpoint: 203.0.113.10:51820

sudo chmod 600 /etc/netplan/90-wireguard.yaml
sudo netplan generate && sudo netplan apply

3.5.4 ifupdown (Debian แบบดั้งเดิม)

# /etc/network/interfaces.d/wg0
# หมายเหตุ: ไฟล์ที่ใช้กับ "wg setconf" ต้องเป็นรูปแบบ pure WireGuard
# (ไม่มี Address, DNS, PostUp ฯลฯ ซึ่งเป็นส่วนขยายของ wg-quick)
auto wg0
iface wg0 inet static
    address 10.8.0.1/24
    pre-up ip link add dev wg0 type wireguard
    pre-up wg setconf wg0 /etc/wireguard/wg0-pure.conf
    post-down ip link del dev wg0

# สร้างไฟล์ pure config จาก wg0.conf ที่มีส่วนขยายของ wg-quick
sudo sh -c 'wg-quick strip wg0 > /etc/wireguard/wg0-pure.conf' && sudo chmod 600 /etc/wireguard/wg0-pure.conf
sudo ifup wg0

3.5.5 เปรียบเทียบวิธีจัดการ

🧪 ตัวอย่าง 3.5: ชุดไฟล์ .netdev/.network, netplan และ ifupdown ดูในไฟล์ตัวอย่าง

ส่วนที่ 4 Network, Firewall และ DNS (Networking, Firewall and DNS)

4.1 IP Forwarding และ NAT (IP Forwarding and NAT)

4.1.1 เปิด IP Forwarding

เครื่องที่ทำหน้าที่เป็น gateway (ส่งต่อแพ็กเก็ตระหว่าง wg0 กับ interface อื่น) ต้องเปิด IP forwarding ใน kernel

# เปิดแบบชั่วคราว (หายเมื่อรีบูต)
sudo sysctl -w net.ipv4.ip_forward=1
sudo sysctl -w net.ipv6.conf.all.forwarding=1

# เปิดถาวร: เขียนไฟล์ใน /etc/sysctl.d/
sudo tee /etc/sysctl.d/99-wireguard.conf >/dev/null <<'EOF'
# เปิดการส่งต่อแพ็กเก็ต IPv4 และ IPv6 สำหรับ WireGuard gateway
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
EOF
sudo sysctl --system

# ตรวจสอบ (ต้องได้ค่า 1)
sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding

4.1.2 Masquerade ด้วย iptables / nftables

Masquerade คือการ NAT แบบแปลง source address ของแพ็กเก็ตเป็น address ของ interface ขาออก (เหมาะกับ IP ที่เปลี่ยนได้)

# แบบ iptables (eth0 = ขาออกสู่อินเทอร์เน็ต, 10.8.0.0/24 = tunnel network)
sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -i wg0 -o eth0 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT

# แบบ nftables: /etc/nftables.d/wireguard-nat.nft
table inet wg_filter {
    chain forward {
        type filter hook forward priority 0; policy drop;
        # อนุญาตการตอบกลับของ connection ที่มีอยู่
        ct state established,related accept
        # อนุญาตจาก tunnel ออกอินเทอร์เน็ต
        iifname "wg0" oifname "eth0" accept
    }
}
table ip wg_nat {
    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        # แปลง source ของ traffic จาก tunnel ที่ออก eth0
        ip saddr 10.8.0.0/24 oifname "eth0" masquerade
    }
}
# วิธีใช้:
#   sudo nft -f /etc/nftables.d/wireguard-nat.nft
#   sudo nft list ruleset | grep -A3 masquerade

4.1.3 เมื่อใดต้อง NAT และเมื่อใดควร Route ตรง ๆ

4.2 Firewall

4.2.1 เปิดพอร์ต UDP ของ WireGuard

เปิดเฉพาะ UDP ตาม ListenPort (ค่า convention คือ 51820) ที่ฝั่งซึ่งต้องรับ connection

# ufw
sudo ufw allow 51820/udp comment 'WireGuard'
sudo ufw route allow in on wg0 out on eth0     # อนุญาตการ forward จาก tunnel สู่อินเทอร์เน็ต
sudo ufw status verbose

# firewalld
sudo firewall-cmd --permanent --add-port=51820/udp
sudo firewall-cmd --permanent --zone=trusted --add-interface=wg0   # หรือสร้าง zone เฉพาะ
sudo firewall-cmd --permanent --add-masquerade                     # ถ้าต้องการ NAT
sudo firewall-cmd --reload

# iptables
sudo iptables -A INPUT -p udp --dport 51820 -j ACCEPT

# nftables (ในตาราง inet filter ที่มีอยู่)
sudo nft add rule inet filter input udp dport 51820 accept

4.2.2 ภาพรวม Packet Flow ผ่าน Netfilter Hooks

flowchart TD
    IN["แพ็กเก็ตเข้า (Packet in)
UDP 51820 จาก eth0"] --> PRE["PREROUTING
(raw, mangle, nat)"]
    PRE --> RT1{"ปลายทางคือเครื่องนี้?
(Local destination?)"}
    RT1 -- "ใช่ (Yes)" --> INPUT["INPUT
(กฎ UDP 51820 อนุญาตที่นี่)"]
    INPUT --> WGD["WireGuard ถอดรหัส
(Decrypt)"]
    WGD --> INNER["แพ็กเก็ตชั้นใน src ใน AllowedIPs
(Inner packet)"]
    INNER --> PRE2["PREROUTING (ผ่าน wg0)"]
    PRE2 --> RT2{"ส่งต่อไปที่อื่น?
(Forward?)"}
    RT2 -- "ใช่ (Yes)" --> FWD["FORWARD
(นโยบายระหว่าง peer ตั้งที่นี่)"]
    FWD --> POST["POSTROUTING
(MASQUERADE ตั้งที่นี่)"]
    POST --> OUT["ออกจาก eth0 หรือ interface อื่น
(Packet out)"]
    RT2 -- "ไม่ (No)" --> LOCALIN["INPUT ของ wg0
(บริการบนเครื่องนี้ เช่น DNS)"]

4.2.3 ตัวอย่างกฎ: จำกัดสิทธิ์ระหว่าง Peer ด้วย Firewall

อย่าพึ่ง AllowedIPs เพียงอย่างเดียว เพราะ AllowedIPs ควบคุมแค่ "ใครใช้ source IP อะไรได้" ไม่ได้ควบคุม "ใครเข้าถึงพอร์ตใดของใคร" ควรใช้ firewall ร่วมด้วย (defense in depth)

# /etc/nftables.d/wg-policy.nft : นโยบายเข้มงวดสำหรับ hub
# - client (10.8.0.0/24) ห้ามคุยกันเอง (client isolation)
# - ผู้ดูแล (10.8.0.2) เข้าถึง client ทุกเครื่องได้
# - ทุกเครื่องเข้าถึงเฉพาะเซิร์ฟเวอร์ภายใน 192.168.10.5 พอร์ต 443
table inet wg_policy {
    set admins { type ipv4_addr; elements = { 10.8.0.2 } }

    chain forward {
        type filter hook forward priority 0; policy drop;
        ct state established,related accept

        # ผู้ดูแลเข้าถึงทุกเครื่องใน tunnel ได้
        iifname "wg0" oifname "wg0" ip saddr @admins accept

        # ห้าม client คุยกันเอง (traffic ที่เข้าและออก wg0 ตัวเดียวกัน)
        iifname "wg0" oifname "wg0" counter drop

        # client ใช้ได้เฉพาะ HTTPS ไปเซิร์ฟเวอร์ภายใน
        iifname "wg0" oifname "eth1" ip daddr 192.168.10.5 tcp dport 443 accept
    }
}
# วิธีใช้:
#   sudo nft -f /etc/nftables.d/wg-policy.nft
#   sudo nft list chain inet wg_policy forward
#   ทดสอบจาก client: curl -k https://192.168.10.5 (ผ่าน) / ping 10.8.0.3 (ถูก drop)

🧪 ตัวอย่าง 4.2: ชุดกฎ ufw, firewalld, nftables และสคริปต์ทดสอบ (test-policy.sh) ดูในไฟล์ตัวอย่าง

4.3 Routing ขั้นสูง (Advanced Routing)

4.3.1 Full Tunnel เทียบกับ Split Tunnel

4.3.2 wg-quick กับ Policy Routing

เมื่อ AllowedIPs เป็น 0.0.0.0/0 (default route) การใส่ default route ลง wg0 ตรง ๆ จะทำให้ UDP ที่เข้ารหัสแล้ว วนกลับเข้า wg0 อีก (routing loop) เพราะแพ็กเก็ตไปยัง Endpoint ก็ตรงกับ 0.0.0.0/0 ด้วย wg-quick แก้ปัญหานี้ด้วย fwmark และ routing table แยก

flowchart TD
    A["แอปส่งแพ็กเก็ตไปที่ 1.1.1.1
(App sends to 1.1.1.1)"] --> R1{"มี fwmark 51820?
(Has fwmark 51820?)"}
    R1 -- "ไม่มี (No)" --> T1["ใช้ตาราง 51820
default dev wg0"]
    T1 --> W["WireGuard เข้ารหัส
แล้วส่ง UDP ไป Endpoint
พร้อมติด fwmark 51820"]
    W --> R2{"มี fwmark 51820?"}
    R2 -- "มี (Yes)" --> T2["ข้ามตาราง 51820
ใช้ main table: default via eth0"]
    T2 --> NET["ออกอินเทอร์เน็ตทาง eth0
(No loop)"]

คำสั่งที่ wg-quick ใช้เบื้องหลัง (เขียนเองได้เมื่ออยากควบคุมละเอียด):

# 1) ให้ WireGuard ติด fwmark ที่แพ็กเก็ต UDP ขาออกของตัวเอง
sudo wg set wg0 fwmark 51820

# 2) สร้าง default route ใน "ตารางแยก" (table 51820) ชี้ไป wg0
sudo ip -4 route add 0.0.0.0/0 dev wg0 table 51820

# 3) แพ็กเก็ตที่ "ไม่มี" fwmark นี้ ให้ใช้ตาราง 51820 (ส่งเข้า VPN)
sudo ip -4 rule add not fwmark 51820 table 51820

# 4) route ที่เจาะจงกว่า default ใน main table ยังใช้ได้ (เช่น LAN) โดยไม่ถูกบังคับเข้า VPN
sudo ip -4 rule add table main suppress_prefixlength 0

# ตรวจสอบผลลัพธ์
ip -4 rule show
ip -4 route show table 51820
# ตัวอย่างผลลัพธ์:
#   0:      from all lookup local
#   32764:  from all lookup main suppress_prefixlength 0
#   32765:  not from all fwmark 0xca6c lookup 51820
#   32766:  from all lookup main
#   default dev wg0 scope link

หมายเหตุ: 0xca6c คือเลขฐานสิบหกของ 51820 (51,820 = 0xCA6C) และ IPv6 ใช้คำสั่งชุดเดียวกันด้วย ip -6

4.3.3 Policy-based Routing และหลาย Routing Table

Policy-based routing (PBR) คือการเลือกเส้นทางตามเงื่อนไขอื่นนอกจาก IP ปลายทาง (เช่น source IP, fwmark, interface) ผ่านคำสั่ง ip rule

# ตัวอย่าง: ให้เครื่อง 192.168.1.50 (ใน LAN) ออกอินเทอร์เน็ตผ่าน VPN เท่านั้น
# คนอื่นใน LAN ออกทาง ISP ตามปกติ
# 1) ตั้ง Table = off ใน [Interface] เพื่อไม่ให้ wg-quick แตะ routing เอง
# 2) สร้างตาราง 100 และกำหนดกฎ
sudo ip route add default dev wg0 table 100
sudo ip rule add from 192.168.1.50/32 table 100 priority 1000

# ตรวจสอบ
ip rule show | grep 1000
ip route show table 100

# ลบกฎ
sudo ip rule del from 192.168.1.50/32 table 100 priority 1000

4.3.4 การกัน Routing Loop ของ Endpoint

อาการ: เปิด full tunnel แล้ว handshake ไม่สำเร็จ หรือหลุดทันที เพราะแพ็กเก็ตที่ไปยัง Endpoint ถูกส่งเข้า wg0

🧪 ตัวอย่าง 4.3: สคริปต์ pbr-demo.sh ทดลอง policy routing ด้วย namespace ดูในไฟล์ตัวอย่าง

4.4 DNS

4.4.1 การตั้ง DNS = และผลต่อ resolvconf / systemd-resolved

เมื่อกำหนด DNS = 10.8.0.1 ใน [Interface] wg-quick จะเรียก resolvconf -a wg0 -m 0 -x (หรือ resolvectl ถ้ามี systemd-resolved) เพื่อเพิ่ม DNS server ของ tunnel และลบเมื่อ tunnel ลง

# ตรวจว่าระบบใช้ตัวจัดการ DNS ใด
ls -l /etc/resolv.conf       # ถ้าชี้ไป ../run/systemd/resolve/stub-resolv.conf = systemd-resolved
which resolvconf resolvectl

# ดูสถานะ DNS ต่อ interface หลังเปิด tunnel
resolvectl status wg0

# ทดสอบ DNS ผ่าน tunnel โดยเจาะจง server
dig @10.8.0.1 example.com +short

4.4.2 Split DNS (เฉพาะโดเมนภายใน)

Split DNS คือการส่งคำถาม DNS เฉพาะโดเมนภายใน (เช่น corp.example.com) ไปยัง DNS ของ tunnel ส่วนโดเมนอื่นใช้ DNS ปกติ

# ตัวอย่างบน client ที่ใช้ systemd-resolved (ไม่ใส่ DNS= ใน [Interface] เพื่อกันการแย่ง DNS ทั้งหมด)
[Interface]
PrivateKey = <CLIENT_PRIVATE_KEY>
Address = 10.8.0.2/24
# ตั้ง DNS เฉพาะ interface wg0 เมื่อ tunnel ขึ้น: "~" นำหน้า = routing-only domain
PostUp   = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~corp.example.com ~internal.lan
PostDown = resolvectl revert %i

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
AllowedIPs = 10.8.0.0/24, 192.168.10.0/24
Endpoint = vpn.example.com:51820
PersistentKeepalive = 25

# วิธีทดสอบ
resolvectl query fileserver.corp.example.com    # ควรถูก resolve ผ่าน wg0
resolvectl query www.example.org                # ควรใช้ DNS เดิม (ไม่ผ่าน wg0)

4.4.3 DNS Leak และการป้องกัน

DNS leak คือการที่คำถาม DNS ถูกส่งออกนอก tunnel (ไปยัง DNS ของ ISP/Wi-Fi) ทั้งที่ผู้ใช้คิดว่าใช้ full tunnel อยู่ ทำให้เปิดเผยโดเมนที่เข้าถึง

สาเหตุที่พบบ่อย:

1. ไม่ได้ตั้ง DNS = ใน full tunnel
2. ระบบมี DNS หลายตัว และใช้ตัวของ interface เดิมก่อน (ลำดับ/metric)
3. IPv6 DNS ยังรั่วเพราะ AllowedIPs ไม่มี ::/0
4. แอป/เบราว์เซอร์ใช้ DNS-over-HTTPS ของตนเองโดยไม่ผ่านระบบ

แนวทางป้องกัน:

• ตั้ง DNS = ให้ชี้ DNS ภายใน tunnel
• ใช้ AllowedIPs = 0.0.0.0/0, ::/0 เพื่อให้ IPv6 ผ่าน tunnel ด้วย
• ใช้ firewall บล็อก DNS (พอร์ต 53/853) ที่ไม่ผ่าน wg0 (ดูตัวอย่าง kill switch หัวข้อ 5.2)

4.4.4 ใช้ร่วมกับ Pi-hole / AdGuard Home / Unbound

ให้บริการ DNS ฟังที่ address ของ tunnel (10.8.0.1) แล้วให้ client ใช้ DNS = 10.8.0.1

# ตัวอย่าง Unbound: /etc/unbound/unbound.conf.d/wg.conf
server:
    interface: 10.8.0.1              # ฟังเฉพาะบน address ของ tunnel
    access-control: 10.8.0.0/24 allow   # อนุญาตเฉพาะ client ใน tunnel
    access-control: 0.0.0.0/0 refuse
    hide-identity: yes
    hide-version: yes
    prefetch: yes

sudo systemctl restart unbound
dig @10.8.0.1 example.com +short       # ทดสอบจาก client

# Pi-hole: ตั้ง "Interface settings" ให้ฟังที่ wg0 (Allow only local requests หรือเลือก wg0)
# AdGuard Home: ตั้ง Listen interfaces ที่ wg0 / 10.8.0.1 ใน Settings > DNS settings

🧪 ตัวอย่าง 4.4: ไฟล์ตัวอย่าง Unbound และสคริปต์ทดสอบ DNS leak (dns-leak-check.sh) ดูในไฟล์ตัวอย่าง

4.5 MTU และ MSS

4.5.1 ที่มาของ Overhead

MTU (Maximum Transmission Unit) คือขนาดแพ็กเก็ต IP ที่ใหญ่ที่สุดที่ส่งได้โดยไม่ต้อง fragment เมื่อ WireGuard ห่อแพ็กเก็ต จะเพิ่มส่วนหัว จึงต้องลด MTU ของ wg0 ลง

• MTU_wg = MTU ของ interface wg0 (byte)
• MTU_link = MTU ของ link ที่ส่ง UDP จริง (ปกติ Ethernet = 1500)
• H_ip = ส่วนหัว IP ชั้นนอก (20 สำหรับ IPv4, 40 สำหรับ IPv6)
• H_udp = 8 byte
• H_wg = 16 byte
• H_tag = 16 byte (Poly1305)

ตัวอย่างการคำนวณ:

ค่าเริ่มต้น 1420 ปลอดภัยสำหรับกรณีที่ transport เป็น IPv6 บน Ethernet (และ IPv4 ด้วย) ส่วน 1280 คือ MTU ขั้นต่ำของ IPv6 หากตั้งต่ำกว่านี้ IPv6 จะใช้งานบน interface นั้นไม่ได้

4.5.2 อาการของ MTU ผิด

• เว็บบางหน้าโหลดค้าง (หน้าเล็กได้ หน้าใหญ่ค้าง)
• SSH เชื่อมได้แต่ค้างตอนแสดงผลข้อความยาว หรือตอนโอนไฟล์
• ping แพ็กเก็ตเล็กผ่าน แต่แพ็กเก็ตใหญ่ไม่ผ่าน
• TLS handshake ค้างหลังส่ง ClientHello (ข้อความ Certificate ใหญ่เกิน MTU)

# ทดสอบหา MTU สูงสุดที่ผ่านจริงด้วยการห้าม fragment (-M do)
# ขนาด payload สูงสุด = MTU - 28 (IP 20 + ICMP 8)
# ลองที่ MTU 1420 -> payload 1392
ping -c 3 -M do -s 1392 10.8.0.1       # ถ้าผ่าน MTU ของเส้นทาง >= 1420
ping -c 3 -M do -s 1393 10.8.0.1       # ถ้าไม่ผ่านแปลว่า 1420 เป็นเพดานพอดี
# ตัวอย่างข้อความเมื่อเกิน: "ping: local error: message too long, mtu=1420"

ตัวอย่างการคำนวณ: ถ้า ping -s 1372 ผ่านแต่ -s 1373 ไม่ผ่าน → path MTU = 1372 + 28 = 1400 → ตั้ง MTU ของ wg0 ให้พอดี 1400 − 80 = 1320 (กรณี IPv6 transport) หรือ 1400 − 60 = 1340 (กรณี IPv4 transport)

4.5.3 MSS Clamping

MSS (Maximum Segment Size) คือขนาด payload TCP สูงสุดต่อ segment ในการจับมือ TCP แต่ละฝั่งประกาศ MSS ของตน ถ้า MSS ใหญ่เกิน MTU ของ tunnel จะเกิดปัญหาเมื่อ ICMP "Fragmentation needed" ถูกบล็อก MSS clamping คือการให้ router แก้ค่า MSS ใน SYN ให้พอดีกับ MTU ของ tunnel

• MSS = ขนาด payload TCP สูงสุดต่อ segment
• MTU = MTU ของ interface wg0
• H_ip = ส่วนหัว IP ของแพ็กเก็ตชั้นใน (20 สำหรับ IPv4, 40 สำหรับ IPv6)
• H_tcp = ส่วนหัว TCP ขั้นต่ำ 20 byte

แทนค่า: MTU = 1420 → MSS (IPv4) = 1420 − 20 − 20 = 1380; MSS (IPv6) = 1420 − 40 − 20 = 1360

# iptables: ปรับ MSS ให้พอดีกับ PMTU ของ interface ขาออกอัตโนมัติ
sudo iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
sudo iptables -t mangle -A FORWARD -i wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# แบบกำหนดค่าตายตัว (ถ้า MTU = 1420, IPv4)
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380

# nftables: ปรับ MSS ตาม MTU ของ route
table inet wg_mss {
    chain forward {
        type filter hook forward priority mangle; policy accept;
        tcp flags syn tcp option maxseg size set rt mtu
    }
}

🧪 ตัวอย่าง 4.5: สคริปต์ find-mtu.sh ค้นหา MTU ที่เหมาะสมแบบอัตโนมัติ ดูในไฟล์ตัวอย่าง

4.6 IPv6 และ Dual Stack

4.6.1 Address แบบ Dual Stack

ใช้ ULA (Unique Local Address) ในช่วง fd00::/8 สำหรับ tunnel ภายใน (คล้าย private IPv4) หรือใช้ prefix สาธารณะที่ได้รับจัดสรร

# ตัวอย่าง server แบบ dual stack
[Interface]
PrivateKey = <SERVER_PRIVATE_KEY>
# ใส่ได้หลาย address คั่นด้วย comma
Address = 10.8.0.1/24, fd42:8:0::1/64
ListenPort = 51820
PostUp   = sysctl -w net.ipv6.conf.all.forwarding=1
# กรณีต้องการให้ client ออกอินเทอร์เน็ต IPv6 ผ่าน NAT66 (ถ้า ISP ไม่ให้ prefix เพิ่ม)
PostUp   = ip6tables -t nat -A POSTROUTING -s fd42:8:0::/64 -o eth0 -j MASQUERADE
PostDown = ip6tables -t nat -D POSTROUTING -s fd42:8:0::/64 -o eth0 -j MASQUERADE

[Peer]
PublicKey = <CLIENT_PUBLIC_KEY>
# กำหนดทั้ง IPv4 และ IPv6 ของ client
AllowedIPs = 10.8.0.2/32, fd42:8:0::2/128

หมายเหตุ: ถ้า ISP ให้ prefix IPv6 สาธารณะ (เช่น /56 หรือ /64 ที่ route มาให้) ควร route แทน NAT66 เพื่อคงหลักการ end-to-end

4.6.2 Tunnel ที่ใช้ IPv6 เป็น Transport

• Endpoint ของ IPv6 เขียนใน [ ] เช่น Endpoint = [2001:db8::10]:51820
• WireGuard ห่อแพ็กเก็ตชั้นใน (IPv4 หรือ IPv6) ผ่าน UDP/IPv6 ได้ (overhead เป็น 80 byte)
• ตั้ง MTU 1420 หรือต่ำกว่า (ดูหัวข้อ 4.5)

4.6.3 IPv6-only Network และ NAT64 (โดยสังเขป)

ถ้าเครือข่ายเป็น IPv6-only แต่ต้องการเข้าถึงบริการ IPv4: ใช้ NAT64 + DNS64 (เช่น Tayga หรือ Jool บน gateway) แปลง IPv6 ที่อยู่ในช่วง 64:ff9b::/96 ไปเป็น IPv4 ส่วน WireGuard ทำหน้าที่เป็นเส้นทางที่ปลอดภัยมายัง gateway นั้น (ไม่ได้แปลง protocol เอง)

🧪 ตัวอย่าง 4.6: config แบบ dual stack พร้อมคำสั่งทดสอบ ping -6 และ curl -6 ดูในไฟล์ตัวอย่าง

ส่วนที่ 5 กรณีการใช้งาน (Use Cases)

ส่วนนี้คือหัวใจของบทความ แต่ละกรณีมีโครงสร้างเดียวกัน: สถานการณ์ → สถาปัตยกรรม → config ตัวอย่าง → ข้อควรระวัง → การทดสอบ ค่า IP ทั้งหมดเป็นค่าสมมติ ใช้ <..._PRIVATE_KEY> / <..._PUBLIC_KEY> แทนกุญแจ ให้สร้างของจริงด้วย wg genkey (หัวข้อ 3.1)

5.1 Remote Access (Road Warrior)

5.1.1 สถานการณ์

พนักงานหรือผู้ดูแลระบบอยู่นอกสถานที่ ต้องการเข้าถึงเครือข่ายองค์กร/บ้าน (192.168.10.0/24) อย่างปลอดภัยจากโน้ตบุ๊กและมือถือ Road Warrior คือผู้ใช้ที่เคลื่อนที่และมี IP เปลี่ยนไปเรื่อย ๆ

5.1.2 สถาปัตยกรรม

flowchart LR
    subgraph ROAD["ผู้ใช้เคลื่อนที่ (Road warriors)"]
        C1["โน้ตบุ๊ก Alice
10.8.0.10"]
        C2["มือถือ Alice
10.8.0.11"]
        C3["โน้ตบุ๊ก Bob
10.8.0.20"]
    end
    subgraph SRV["เซิร์ฟเวอร์ VPN (VPN server) 203.0.113.10"]
        S1["wg0: 10.8.0.1/24
UDP 51820"]
    end
    subgraph LAN["เครือข่ายองค์กร (Corporate LAN) 192.168.10.0/24"]
        L1["ไฟล์เซิร์ฟเวอร์
192.168.10.5"]
        L2["เว็บภายใน
192.168.10.6"]
    end
    C1 --> S1
    C2 --> S1
    C3 --> S1
    S1 --> L1
    S1 --> L2

การออกแบบ IP pool (10.8.0.0/24):

การจัดการหลายผู้ใช้: สร้าง [Peer] หนึ่งบล็อกต่ออุปกรณ์ใน server ใช้ AllowedIPs = <IP ของอุปกรณ์>/32 เสมอ และเขียน comment ระบุเจ้าของและวันที่ออก key

5.1.3 Config ตัวอย่าง

Server (/etc/wireguard/wg0.conf):

[Interface]
# เซิร์ฟเวอร์ Road Warrior
PrivateKey = <SERVER_PRIVATE_KEY>
Address = 10.8.0.1/24
ListenPort = 51820
# เปิด NAT เพื่อให้ client เข้าถึง LAN 192.168.10.0/24 ผ่าน eth0 (กรณี LAN ไม่มี route กลับ)
PostUp   = sysctl -w net.ipv4.ip_forward=1
PostUp   = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT
PostUp   = iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

# --- Alice (โน้ตบุ๊ก) ออกเมื่อ 2026-01-10 ---
[Peer]
PublicKey = <ALICE_LAPTOP_PUBLIC_KEY>
PresharedKey = <ALICE_LAPTOP_PSK>
AllowedIPs = 10.8.0.10/32

# --- Alice (มือถือ) ---
[Peer]
PublicKey = <ALICE_PHONE_PUBLIC_KEY>
PresharedKey = <ALICE_PHONE_PSK>
AllowedIPs = 10.8.0.11/32

# --- Bob (โน้ตบุ๊ก) ---
[Peer]
PublicKey = <BOB_LAPTOP_PUBLIC_KEY>
PresharedKey = <BOB_LAPTOP_PSK>
AllowedIPs = 10.8.0.20/32

Client (Alice โน้ตบุ๊ก):

[Interface]
PrivateKey = <ALICE_LAPTOP_PRIVATE_KEY>
Address = 10.8.0.10/32
DNS = 192.168.10.2                  # DNS ภายในองค์กร

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
PresharedKey = <ALICE_LAPTOP_PSK>
# ส่งเฉพาะ traffic ไป tunnel network และ LAN องค์กร (split tunnel)
AllowedIPs = 10.8.0.0/24, 192.168.10.0/24
Endpoint = vpn.example.com:51820
PersistentKeepalive = 25

5.1.4 ข้อควรระวัง

• Address ของ client ตั้งเป็น /32 เมื่อ AllowedIPs ฝั่ง client ระบุ subnet ชัดเจน เพื่อไม่ให้ระบบเพิ่ม route ซ้ำซ้อน
• ถ้า LAN ปลายทางไม่รู้จัก 10.8.0.0/24 ต้อง NAT (ตัวอย่างข้างบน) หรือเพิ่ม route กลับบน router ของ LAN
• กำหนด PSK คนละค่าต่ออุปกรณ์ และบันทึก key ที่ออกแล้วไว้ใน inventory เพื่อ revoke ได้
• อย่าลืมอัปเดต firewall ของ LAN ให้ปฏิบัติต่อ 10.8.0.0/24 เสมือนเครือข่ายภายนอกที่เชื่อถือบางส่วน

5.1.5 การทดสอบ

# บน client: เปิด tunnel แล้วทดสอบ
sudo wg-quick up wg0
ping -c 3 10.8.0.1                 # ถึง server ผ่าน tunnel
ping -c 3 192.168.10.5             # ถึงไฟล์เซิร์ฟเวอร์ใน LAN
curl -sS http://192.168.10.6/ | head -n 3    # ถึงเว็บภายใน

# บน server: ดูว่ามี client เชื่อมกี่คน (handshake ภายใน 3 นาที = ใช้งานอยู่)
sudo wg show wg0 latest-handshakes | awk -v now="$(date +%s)" '{ if (now-$2 < 180) c++ } END { print c+0, "peer(s) active" }'

🧪 ตัวอย่าง 5.1: สคริปต์ add-client.sh สร้าง client config ใหม่พร้อม QR และเพิ่ม peer เข้า server แบบสด ดูในไฟล์ตัวอย่าง

5.2 Full Tunnel VPN (ส่ง traffic ทั้งหมดผ่าน VPN)

5.2.1 สถานการณ์

ผู้ใช้อยู่บน Wi-Fi สาธารณะ (ร้านกาแฟ สนามบิน โรงแรม) ต้องการเข้ารหัส traffic ทั้งหมดและซ่อน IP ต้นทางจริงจากเครือข่ายนั้น

5.2.2 สถาปัตยกรรม

flowchart LR
    U["ผู้ใช้บน Wi-Fi สาธารณะ
(User on public Wi-Fi)"] -- "ทุกอย่างเข้า wg0
(All traffic into wg0)" --> W["เครือข่ายท้องถิ่น (เห็นเฉพาะ UDP เข้ารหัส)
(Local network sees encrypted UDP only)"]
    W --> S["VPN Server
NAT ออกอินเทอร์เน็ต"]
    S --> I["อินเทอร์เน็ต
(Internet)"]

5.2.3 Config ตัวอย่าง

Client (full tunnel + kill switch):

[Interface]
PrivateKey = <CLIENT_PRIVATE_KEY>
Address = 10.8.0.30/32, fd42:8:0::30/128
DNS = 10.8.0.1                       # ใช้ DNS ผ่าน tunnel ป้องกัน DNS leak
# Kill switch: ปฏิเสธทุกแพ็กเก็ตขาออกที่ "ไม่ผ่าน wg0" และ "ไม่ใช่ UDP ของ WireGuard เอง" (ไม่มี fwmark)
PostUp   = iptables  -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PostUp   = ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown  = iptables  -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown  = ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
PresharedKey = <CLIENT_PSK>
# ส่งทั้ง IPv4 และ IPv6 ผ่าน tunnel เพื่อกัน IPv6 leak
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.com:51820
PersistentKeepalive = 25

Server (เพิ่ม NAT สำหรับ IPv4/IPv6):

[Interface]
PrivateKey = <SERVER_PRIVATE_KEY>
Address = 10.8.0.1/24, fd42:8:0::1/64
ListenPort = 51820
PostUp   = sysctl -w net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding=1
PostUp   = iptables  -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
PostUp   = ip6tables -t nat -A POSTROUTING -s fd42:8:0::/64 -o eth0 -j MASQUERADE
PostDown = iptables  -t nat -D POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
PostDown = ip6tables -t nat -D POSTROUTING -s fd42:8:0::/64 -o eth0 -j MASQUERADE

[Peer]
PublicKey = <CLIENT_PUBLIC_KEY>
PresharedKey = <CLIENT_PSK>
AllowedIPs = 10.8.0.30/32, fd42:8:0::30/128

5.2.4 ข้อควรระวัง

• Kill switch ตามตัวอย่างใช้ได้บน Linux; บน Windows แอปทางการมี "Block untunneled traffic" ให้เมื่อ AllowedIPs มี 0.0.0.0/0; บน Android/iOS ใช้ "Always-on VPN + Block connections without VPN"
• ต้อง ไม่บล็อก แพ็กเก็ตที่ไปยัง Endpoint (ตัวอย่างใช้ fwmark เพื่อยกเว้น)
• ตรวจ DNS leak และ IPv6 leak เสมอ ถ้า server ไม่รองรับ IPv6 ออกอินเทอร์เน็ตให้ลบ ::/0 ออกและ ปิด IPv6 บน client หรือบล็อกด้วย firewall แทนที่จะปล่อยให้รั่ว
• Captive portal (หน้า login ของ Wi-Fi) ต้องเปิดก่อนเปิด full tunnel
• ภาระของ server: แบนด์วิดท์รวมของทุก client ใช้ขาออกของ server ทั้งหมด

5.2.5 การทดสอบ

sudo wg-quick up wg0

# 1) IP สาธารณะต้องเป็น IP ของ server ไม่ใช่ IP ของ Wi-Fi
curl -4 -sS https://ifconfig.me ; echo
curl -6 -sS https://ifconfig.me ; echo      # ถ้า server ไม่รองรับ IPv6 ต้อง "ล้มเหลว" (ไม่รั่ว)

# 2) ทดสอบ DNS leak: คำถาม DNS ต้องออกที่ wg0 เท่านั้น (เปิด terminal ที่สองรัน tcpdump)
sudo tcpdump -ni any 'udp port 53' -c 5 &
dig example.com +short

# 3) ทดสอบ kill switch: ปิด tunnel ฝั่ง server (หรือ wg set wg0 peer <KEY> remove) แล้วลอง ping
ping -c 2 -W 2 1.1.1.1      # ต้อง "ไม่ผ่าน" (ถูก REJECT)

🧪 ตัวอย่าง 5.2: ไฟล์ fulltunnel-client.conf และสคริปต์ leak-test.sh ดูในไฟล์ตัวอย่าง

5.3 Split Tunnel

5.3.1 สถานการณ์

ต้องการให้เฉพาะ traffic ภายใน (เซิร์ฟเวอร์องค์กร, subnet ที่บ้าน) ผ่าน VPN ส่วน traffic อินเทอร์เน็ตทั่วไป (YouTube, อัปเดตระบบ) ออกตามปกติเพื่อประหยัดแบนด์วิดท์และลด latency

5.3.2 สถาปัตยกรรม

flowchart TD
    APP["แอปส่ง traffic
(Application traffic)"] --> D{"ปลายทางอยู่ใน AllowedIPs?
(Destination in AllowedIPs?)"}
    D -- "ใช่ (Yes): 10.8.0.0/24, 192.168.10.0/24" --> WG["เข้า wg0 (เข้ารหัส)"]
    D -- "ไม่ใช่ (No)" --> ETH["ออก eth0/wlan0 ตามปกติ
(Normal path)"]

5.3.3 การคำนวณ AllowedIPs แบบ "ทุกอย่างยกเว้น..."

บางครั้งต้องการ "ส่งทุกอย่างผ่าน VPN ยกเว้นเครือข่าย LAN ท้องถิ่น (192.168.0.0/16)" แต่ AllowedIPs ไม่มีตัวดำเนินการ "ยกเว้น" จึงต้องแตก 0.0.0.0/0 ออกเป็นหลายบล็อก CIDR ที่ ไม่ครอบคลุม ช่วงที่ยกเว้น

หลักการ: ถ้ายกเว้นบล็อกเดียวที่ prefix /p ออกจาก 0.0.0.0/0 จะได้บล็อกที่เหลือ p บล็อกพอดี (หนึ่งบล็อกต่อหนึ่งบิตของ prefix ที่ต่างจากบล็อกที่ยกเว้น)

• N_blocks = จำนวนบล็อก CIDR ที่เหลือหลังยกเว้นหนึ่งบล็อก
• p = ความยาว prefix ของบล็อกที่ยกเว้น (เช่น 16 สำหรับ 192.168.0.0/16)

ตัวอย่างการคำนวณ: ยกเว้น 192.168.0.0/16 (p = 16) → ได้ 16 บล็อก ดังนี้

0.0.0.0/1, 128.0.0.0/2, 192.0.0.0/9, 192.128.0.0/11, 192.160.0.0/13, 192.169.0.0/16,
192.170.0.0/15, 192.172.0.0/14, 192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8,
194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4, 224.0.0.0/3

ตรวจสอบ: 192.168.x.x อยู่ระหว่าง 192.168.0.0 ถึง 192.168.255.255 ซึ่งอยู่ในช่องว่างระหว่าง 192.160.0.0/13 (ครอบ 192.160–192.167) กับ 192.169.0.0/16 พอดี จึงไม่ถูกครอบคลุมโดยบล็อกใดเลย

ถ้ายกเว้นทั้ง RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) จะได้ 31 บล็อก

0.0.0.0/5, 8.0.0.0/7, 11.0.0.0/8, 12.0.0.0/6, 16.0.0.0/4, 32.0.0.0/3, 64.0.0.0/2,
128.0.0.0/3, 160.0.0.0/5, 168.0.0.0/6, 172.0.0.0/12, 172.32.0.0/11, 172.64.0.0/10,
172.128.0.0/9, 173.0.0.0/8, 174.0.0.0/7, 176.0.0.0/4, 192.0.0.0/9, 192.128.0.0/11,
192.160.0.0/13, 192.169.0.0/16, 192.170.0.0/15, 192.172.0.0/14, 192.176.0.0/12,
192.192.0.0/10, 193.0.0.0/8, 194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4, 224.0.0.0/3

ใช้สคริปต์ Python ต่อไปนี้คำนวณช่วงใด ๆ ได้เอง

#!/usr/bin/env python3
"""allowedips-calc.py : คำนวณ AllowedIPs แบบ 'ทุกอย่างยกเว้น...'
วิธีใช้: python3 allowedips-calc.py 192.168.0.0/16 10.0.0.0/8
         (ไม่ใส่อาร์กิวเมนต์ = ใช้ค่ายกเว้น RFC 1918 ทั้งสามช่วง)
"""
import ipaddress
import sys

def compute(base, excludes):
    """ตัดช่วง excludes ออกจาก base แล้วคืนรายการ CIDR ที่เหลือ (เรียงลำดับ)"""
    nets = [ipaddress.ip_network(base)]
    for ex in map(ipaddress.ip_network, excludes):
        remaining = []
        for n in nets:
            if n.version != ex.version:
                remaining.append(n)
            elif ex.subnet_of(n):
                remaining.extend(n.address_exclude(ex))   # แตกบล็อกที่มี ex อยู่ข้างใน
            elif n.subnet_of(ex):
                continue                                  # บล็อกนี้อยู่ใน ex ทั้งหมด -> ตัดทิ้ง
            else:
                remaining.append(n)                       # ไม่ทับกันเลย
        nets = remaining
    return sorted(ipaddress.collapse_addresses(nets))

if __name__ == "__main__":
    ex = sys.argv[1:] or ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"]
    result = compute("0.0.0.0/0", ex)
    print("AllowedIPs = " + ", ".join(map(str, result)))
    print(f"# จำนวนบล็อก: {len(result)}", file=sys.stderr)

5.3.4 Split Tunnel รายแอป (Android) และรายโดเมน

รายแอป (Android): ใช้ ExcludedApplications / IncludedApplications (ดูหัวข้อ 2.4.3)

รายโดเมน (Linux): ใช้ dnsmasq + ipset เพื่อรวบรวม IP ของโดเมนที่ต้องการ แล้วติด fwmark ให้ส่งเข้า tunnel ด้วย policy routing

# 1) สร้าง ipset สำหรับเก็บ IP ของโดเมนที่ต้องผ่าน VPN
sudo ipset create vpn_domains hash:ip timeout 3600

# 2) dnsmasq: ทุกครั้งที่ resolve โดเมนเหล่านี้ ให้เพิ่ม IP ที่ได้ลง ipset
#    /etc/dnsmasq.d/vpn-domains.conf
#       ipset=/example.com/internal.example.org/vpn_domains

# 3) ติด fwmark 0x64 ให้แพ็กเก็ตที่ไปยัง IP ใน ipset
sudo iptables -t mangle -A OUTPUT -m set --match-set vpn_domains dst -j MARK --set-mark 0x64

# 4) แพ็กเก็ตที่มี mark 0x64 ใช้ตาราง 100 (default ผ่าน wg0)
#    (ใน [Interface] ของ wg0 ตั้ง Table = off เพื่อไม่ให้ wg-quick แตะ routing)
sudo ip route add default dev wg0 table 100
sudo ip rule add fwmark 0x64 table 100 priority 1000

# ทดสอบ
dig example.com +short
sudo ipset list vpn_domains      # ต้องเห็น IP ของโดเมนอยู่ในเซต
curl -sS https://example.com -o /dev/null -w '%{remote_ip}\n'

ข้อจำกัด: IP ของโดเมนอาจเปลี่ยน (CDN) และการรวม ipset ทำงานเมื่อ client ใช้ resolver ที่เรากำหนดเท่านั้น (ไม่รองรับ DoH ของเบราว์เซอร์)

5.3.5 การทดสอบ

# ดูว่า route แยกกันถูกต้อง
ip route get 192.168.10.5        # ต้องผ่าน dev wg0
ip route get 8.8.8.8             # ต้องผ่าน interface ปกติ (ไม่ใช่ wg0)
curl -sS https://ifconfig.me     # ต้องเป็น IP จริงของท่าน (ไม่ผ่าน VPN)

🧪 ตัวอย่าง 5.3: allowedips-calc.py, config แบบ split tunnel, และสคริปต์ per-domain ดูในไฟล์ตัวอย่าง

5.4 Site-to-Site VPN

5.4.1 สถานการณ์

เชื่อมเครือข่ายสองสาขาเข้าด้วยกัน: Site A (กรุงเทพ, LAN 192.168.10.0/24, public IP คงที่ 203.0.113.10) และ Site B (สงขลา, LAN 192.168.20.0/24, public IP แบบ dynamic) ให้เครื่องใน LAN ทั้งสองคุยกันได้โดยตรง

5.4.2 สถาปัตยกรรม

flowchart LR
    subgraph SA["Site A กรุงเทพ (Bangkok)"]
        HA["Host A
192.168.10.50"] --- GA["Gateway A
LAN 192.168.10.1
wg0 10.200.0.1
Public 203.0.113.10"]
    end
    subgraph SB["Site B สงขลา (Songkhla)"]
        GB["Gateway B
LAN 192.168.20.1
wg0 10.200.0.2
Public dynamic"] --- HB["Host B
192.168.20.60"]
    end
    GA <-- "WireGuard UDP 51820" --> GB

ตารางการ route:

5.4.3 Config ตัวอย่าง

Gateway A (static IP):

[Interface]
PrivateKey = <GATEWAY_A_PRIVATE_KEY>
Address = 10.200.0.1/30                  # /30 พอสำหรับ point-to-point
ListenPort = 51820
# เปิด forwarding และอนุญาตเฉพาะ traffic ระหว่างสอง LAN (ไม่ NAT เพื่อคงเห็น IP จริง)
PostUp   = sysctl -w net.ipv4.ip_forward=1
PostUp   = iptables -A FORWARD -i %i -o eth1 -s 192.168.20.0/24 -d 192.168.10.0/24 -j ACCEPT
PostUp   = iptables -A FORWARD -i eth1 -o %i -s 192.168.10.0/24 -d 192.168.20.0/24 -j ACCEPT
PostDown = iptables -D FORWARD -i %i -o eth1 -s 192.168.20.0/24 -d 192.168.10.0/24 -j ACCEPT
PostDown = iptables -D FORWARD -i eth1 -o %i -s 192.168.10.0/24 -d 192.168.20.0/24 -j ACCEPT

[Peer]
# Gateway B (IP dynamic จึงไม่ใส่ Endpoint; Gateway B เป็นฝ่ายเริ่มติดต่อ)
PublicKey = <GATEWAY_B_PUBLIC_KEY>
PresharedKey = <SITE_PSK>
AllowedIPs = 10.200.0.2/32, 192.168.20.0/24

Gateway B (IP dynamic):

[Interface]
PrivateKey = <GATEWAY_B_PRIVATE_KEY>
Address = 10.200.0.2/30
PostUp   = sysctl -w net.ipv4.ip_forward=1
PostUp   = iptables -A FORWARD -i %i -o eth1 -s 192.168.10.0/24 -d 192.168.20.0/24 -j ACCEPT
PostUp   = iptables -A FORWARD -i eth1 -o %i -s 192.168.20.0/24 -d 192.168.10.0/24 -j ACCEPT
PostDown = iptables -D FORWARD -i %i -o eth1 -s 192.168.10.0/24 -d 192.168.20.0/24 -j ACCEPT
PostDown = iptables -D FORWARD -i eth1 -o %i -s 192.168.20.0/24 -d 192.168.10.0/24 -j ACCEPT

[Peer]
PublicKey = <GATEWAY_A_PUBLIC_KEY>
PresharedKey = <SITE_PSK>
AllowedIPs = 10.200.0.1/32, 192.168.10.0/24
Endpoint = 203.0.113.10:51820
# Gateway B อยู่หลัง NAT/dynamic IP: ส่ง keepalive เพื่อให้ A ส่งหาได้ตลอด
PersistentKeepalive = 25

กรณี static IP ทั้งสองฝั่ง: ใส่ Endpoint ทั้งสองฝั่ง และตั้ง ListenPort คงที่ทั้งสอง ไม่จำเป็นต้องมี keepalive (ยกเว้นอยู่หลัง NAT)

กรณีที่ Gateway ไม่ใช่ default gateway ของ LAN: เพิ่ม static route บน router หลักของ LAN เช่น ip route add 192.168.20.0/24 via 192.168.10.1 (ที่ router หลักของ Site A)

5.4.4 ข้อควรระวัง

• Subnet ของสองไซต์ต้องไม่ชนกัน ถ้าชน (เช่น ทั้งสองใช้ 192.168.1.0/24) ต้องเปลี่ยน subnet ของไซต์ใดไซต์หนึ่ง หรือใช้ NAT 1:1 แปลง subnet
• ตรวจ AllowedIPs ฝั่งตรงข้ามให้ครอบคลุม LAN เสมอ ถ้าลืมจะ ping จาก gateway ได้แต่เครื่องใน LAN ไม่ได้
• ตั้ง MTU ให้เหมาะ (หัวข้อ 4.5) และใช้ MSS clamping บน gateway
• ใช้ firewall จำกัดว่า LAN ฝั่งใดเข้าถึงพอร์ตใดของอีกฝั่ง (ไม่เปิดทั้งหมด)

5.4.5 การทดสอบ

# บน Gateway B
sudo wg-quick up wg0
ping -c 3 10.200.0.1              # ถึง Gateway A ผ่าน tunnel
ping -c 3 192.168.10.1            # ถึง LAN ฝั่ง A (ที่อยู่ eth1 ของ Gateway A)

# บน Host B (192.168.20.60)
ping -c 3 192.168.10.50           # ถึง Host A ข้ามไซต์
traceroute -n 192.168.10.50       # ต้องเห็น hop: 192.168.20.1 -> 10.200.0.1 -> 192.168.10.50

🧪 ตัวอย่าง 5.4: ชุด config site-a.conf / site-b.conf และสคริปต์ทดลองด้วย namespace สามเครื่อง ดูในไฟล์ตัวอย่าง

5.5 Hub-and-Spoke

5.5.1 สถานการณ์

มีหลายสาขาหรือหลายเครื่อง (spoke) ที่ต้องคุยกันเองได้ โดยให้ทุกเครื่องเชื่อมเฉพาะกับ hub กลาง (เช่น VPS หนึ่งเครื่อง) เหมาะกับกรณีที่ spoke หลายตัวอยู่หลัง NAT และไม่สามารถติดต่อกันโดยตรง

5.5.2 สถาปัตยกรรม

flowchart TD
    HUB["Hub 10.9.0.1
Public 203.0.113.10
เปิด forwarding (IP forwarding on)"]
    S1["Spoke 1
10.9.0.2
LAN 192.168.1.0/24"]
    S2["Spoke 2
10.9.0.3
LAN 192.168.2.0/24"]
    S3["Spoke 3
10.9.0.4
(เครื่องเดี่ยว Single host)"]
    S1 <--> HUB
    S2 <--> HUB
    S3 <--> HUB

การไหลของ traffic ระหว่าง spoke: Spoke 1 → Hub → Spoke 2 โดย Spoke 1 ต้องมี route ไปยัง subnet ของ Spoke 2 ผ่าน Hub

5.5.3 Config ตัวอย่าง

Hub:

[Interface]
PrivateKey = <HUB_PRIVATE_KEY>
Address = 10.9.0.1/24
ListenPort = 51820
# Hub ต้องส่งต่อแพ็กเก็ตระหว่าง spoke (ภายใน wg0 ตัวเดียว) จึงเปิด forwarding
PostUp   = sysctl -w net.ipv4.ip_forward=1
# อนุญาตเฉพาะการ forward ภายใน wg0 (ไม่ให้ออก eth0)
PostUp   = iptables -A FORWARD -i %i -o %i -j ACCEPT
PostDown = iptables -D FORWARD -i %i -o %i -j ACCEPT

[Peer]
# Spoke 1 (และ LAN ของมัน)
PublicKey = <SPOKE1_PUBLIC_KEY>
AllowedIPs = 10.9.0.2/32, 192.168.1.0/24

[Peer]
# Spoke 2 (และ LAN ของมัน)
PublicKey = <SPOKE2_PUBLIC_KEY>
AllowedIPs = 10.9.0.3/32, 192.168.2.0/24

[Peer]
# Spoke 3
PublicKey = <SPOKE3_PUBLIC_KEY>
AllowedIPs = 10.9.0.4/32

Spoke 1 (ส่วนที่ชี้ไป Hub):

[Interface]
PrivateKey = <SPOKE1_PRIVATE_KEY>
Address = 10.9.0.2/24
PostUp = sysctl -w net.ipv4.ip_forward=1       # ถ้าทำหน้าที่เป็น gateway ของ LAN ตัวเอง

[Peer]
PublicKey = <HUB_PUBLIC_KEY>
# "ทุกอย่างในเครือข่ายของ hub" รวมถึง spoke อื่นและ LAN ของ spoke อื่น
AllowedIPs = 10.9.0.0/24, 192.168.2.0/24
Endpoint = 203.0.113.10:51820
PersistentKeepalive = 25

หลักการสำคัญ: AllowedIPs ใน Spoke 1 ของ peer "Hub" ครอบคลุม IP ของ spoke อื่น (10.9.0.0/24) จึงเข้ารหัสส่งไป Hub; ที่ Hub แพ็กเก็ตถูกถอดรหัส (ผ่านเพราะ src 10.9.0.2 อยู่ใน AllowedIPs ของ Spoke 1) แล้ว kernel ของ Hub ค้นหา route ไปยัง 10.9.0.3 พบว่าผ่าน wg0 จึงส่งเข้ารหัสต่อด้วย key ของ Spoke 2

5.5.4 ข้อดี/ข้อเสีย และการคำนวณ Latency

• L_AB = latency (RTT) ระหว่าง Spoke A กับ Spoke B ผ่าน Hub
• L_AH = RTT ระหว่าง A กับ Hub
• L_HB = RTT ระหว่าง Hub กับ B
• t_proc = เวลาประมวลผลที่ Hub (ถอดรหัส-เข้ารหัสซ้ำ มักน้อยกว่า 1 ms)

ตัวอย่าง: A–Hub = 20 ms, Hub–B = 30 ms, t_proc ≈ 0.5 ms → L_AB ≈ 50.5 ms ขณะที่เส้นทางตรง A–B (ถ้าเชื่อมได้) อาจเหลือ ~15 ms ดังนั้นควรวาง Hub ในภูมิภาคกลางระหว่าง spoke

แบนด์วิดท์ที่ Hub: ถ้ามีสอง spoke คุยกันที่ 100 Mbit/s ทิศทางเดียว Hub ต้องรับ 100 และส่ง 100 Mbit/s (รวม 200 Mbit/s ผ่าน NIC) และต้องเข้ารหัส/ถอดรหัสเท่ากัน

5.5.5 การทดสอบ

# จาก Spoke 1 ไป Spoke 2 (ผ่าน Hub)
ping -c 3 10.9.0.3
traceroute -n 10.9.0.3          # คาดหวัง: 10.9.0.1 (hub) -> 10.9.0.3

# บน Hub ดูว่า traffic ผ่านจริง
sudo wg show wg0 transfer
sudo tcpdump -ni wg0 icmp -c 6   # เห็น ICMP จาก 10.9.0.2 ไป 10.9.0.3 ทั้งขาเข้าและขาออก

🧪 ตัวอย่าง 5.5: ชุด config hub + 3 spoke และสคริปต์ทดลองด้วย namespace ดูในไฟล์ตัวอย่าง

5.6 Full Mesh

5.6.1 สถานการณ์

ต้องการให้ทุกเครื่องเชื่อมถึงกันโดยตรง (latency ต่ำสุด ไม่มี single point of failure) เหมาะกับคลัสเตอร์เซิร์ฟเวอร์ที่มี public IP หรือกลุ่มเล็ก

5.6.2 สถาปัตยกรรมและปัญหา Scaling

flowchart LR
    A["Node A"] --- B["Node B"]
    A --- C["Node C"]
    A --- D["Node D"]
    B --- C
    B --- D
    C --- D

• N_tunnels = จำนวน tunnel ทั้งหมดในเครือข่าย
• n = จำนวน node (peer) ทั้งหมด
• แต่ละ node ต้องมี peer จำนวน n − 1 (จึงมีบล็อก [Peer] n − 1 ตัวต่อ node)

ตัวอย่างการคำนวณ: n = 50 → N = 50 × 49 ÷ 2 = 1,225 tunnel; การเพิ่ม node ที่ 51 ต้องแก้ config ของ ทั้ง 50 เครื่องเดิม และสร้างใหม่ 50 tunnel (N กลายเป็น 1,275) นี่คือเหตุผลที่ต้องใช้เครื่องมือช่วยจัดการ

5.6.3 การจัดการด้วยเครื่องมือ

#!/usr/bin/env python3
"""mesh-gen.py : สร้าง config ทั้ง full mesh จากรายชื่อ node
วิธีใช้:  python3 mesh-gen.py nodes.csv outdir/
รูปแบบ nodes.csv (ไม่มี header):  ชื่อ,IP ใน tunnel,Endpoint (ว่างได้ถ้าอยู่หลัง NAT)
  node1,10.7.0.1,203.0.113.11:51820
  node2,10.7.0.2,203.0.113.12:51820
  node3,10.7.0.3,
"""
import csv, os, subprocess, sys

def sh(cmd, inp=None):
    """รันคำสั่งและคืนค่า stdout (ใช้เรียก wg genkey / pubkey / genpsk)"""
    return subprocess.run(cmd, input=inp, capture_output=True, text=True, check=True).stdout.strip()

def main(csv_path, outdir):
    os.makedirs(outdir, exist_ok=True)
    nodes = []
    for name, ip, endpoint in csv.reader(open(csv_path)):
        priv = sh(["wg", "genkey"])
        nodes.append({"name": name, "ip": ip, "ep": endpoint.strip(),
                      "priv": priv, "pub": sh(["wg", "pubkey"], priv)})
    # สร้าง PSK หนึ่งค่าต่อหนึ่งคู่ (i < j)
    psk = {(i, j): sh(["wg", "genpsk"]) for i in range(len(nodes)) for j in range(i + 1, len(nodes))}
    for i, me in enumerate(nodes):
        lines = ["[Interface]", f"PrivateKey = {me['priv']}", f"Address = {me['ip']}/24"]
        if me["ep"]:
            lines.append(f"ListenPort = {me['ep'].rsplit(':', 1)[1]}")
        for j, peer in enumerate(nodes):
            if i == j:
                continue
            lines += ["", "[Peer]", f"# {peer['name']}", f"PublicKey = {peer['pub']}",
                      f"PresharedKey = {psk[tuple(sorted((i, j)))]}", f"AllowedIPs = {peer['ip']}/32"]
            if peer["ep"]:
                lines.append(f"Endpoint = {peer['ep']}")
            else:
                pass  # peer หลัง NAT ไม่มี endpoint ให้ผู้ที่อยู่หลัง NAT เป็นฝ่ายเริ่ม
            if not me["ep"]:
                lines.append("PersistentKeepalive = 25")   # ตัวเราอยู่หลัง NAT
        path = os.path.join(outdir, f"{me['name']}.conf")
        with open(path, "w") as f:
            f.write("\n".join(lines) + "\n")
        os.chmod(path, 0o600)
        print("สร้างแล้ว:", path)

if __name__ == "__main__":
    main(sys.argv[1], sys.argv[2])

5.6.4 Hybrid: Mesh + Relay สำหรับ Peer หลัง NAT

เมื่อบาง node อยู่หลัง NAT (ไม่มี public endpoint) การเชื่อมตรงทุกคู่ทำไม่ได้ จึงใช้ relay node (node ที่มี public IP) ทำหน้าที่เหมือน hub สำหรับ node เหล่านั้น:

flowchart LR
    subgraph PUB["Node มี Public IP (Public nodes)"]
        P1["P1"] --- P2["P2"]
        P1 --- R["Relay R"]
        P2 --- R
    end
    subgraph NAT["Node หลัง NAT (Nodes behind NAT)"]
        N1["N1"]
        N2["N2"]
    end
    N1 -- "ต่อออกไปหา R" --> R
    N2 -- "ต่อออกไปหา R" --> R

• Node หลัง NAT มี peer เพียงตัวเดียว (R) และตั้ง AllowedIPs ให้ครอบคลุม subnet ทั้งหมดผ่าน R
• R เปิด forwarding และ peer กับ node ทุกตัว
• เครื่องมือ mesh VPN ทำ NAT traversal / hole punching ให้ node หลัง NAT ต่อกันตรงได้เองเมื่อเป็นไปได้ (หัวข้อ 7.2)

5.6.5 การทดสอบ

python3 mesh-gen.py nodes.csv out/
# คัดลอก out/nodeX.conf ไปยังแต่ละเครื่อง แล้ว
sudo wg-quick up wg0

# บนแต่ละ node: ping ทุก node (ควรผ่านทั้งหมดเมื่อ handshake ครบ)
for ip in 10.7.0.1 10.7.0.2 10.7.0.3; do ping -c 1 -W 2 $ip >/dev/null && echo "$ip OK" || echo "$ip FAIL"; done
sudo wg show wg0 latest-handshakes     # ทุก peer ควรมีเวลา handshake ล่าสุด

🧪 ตัวอย่าง 5.6: nodes.csv และ mesh-gen.py ฉบับเต็ม พร้อมสคริปต์ทดลอง 4 namespace ดูในไฟล์ตัวอย่าง

5.7 เชื่อมต่ออุปกรณ์หลัง NAT / CGNAT

5.7.1 สถานการณ์

ISP ให้ IP แบบ CGNAT (Carrier-Grade NAT) หรือไม่เปิด public IP ให้ ทำให้เปิดพอร์ตเข้าบ้านไม่ได้ ตรวจสอบได้โดยเปรียบเทียบ IP ที่ router แสดงบนหน้า WAN กับ IP ที่เห็นจากอินเทอร์เน็ต ถ้าต่างกัน หรืออยู่ในช่วง 100.64.0.0/10 แสดงว่าอยู่หลัง CGNAT

5.7.2 สถาปัตยกรรม: ใช้ VPS เป็น Relay/Hub

flowchart LR
    subgraph HOME["บ้าน หลัง CGNAT (Home behind CGNAT)"]
        H["Home server
wg0 10.10.0.2"]
    end
    subgraph VPS["VPS (Public IP 203.0.113.10)"]
        V["wg0 10.10.0.1
ListenPort 51820"]
    end
    subgraph OUT["ผู้ใช้ภายนอก (Remote user)"]
        U["โน้ตบุ๊ก wg0 10.10.0.3"]
    end
    H -- "ต่อออกไปหา VPS
(outbound UDP)" --> V
    U -- "ต่อไปหา VPS" --> V

หลักการ: ทุกฝ่ายเป็นผู้ ต่อออกไปหา VPS (outbound) ซึ่งผ่าน CGNAT ได้เสมอ ส่วน VPS ส่งข้อมูลกลับมาตามเส้นทางของ mapping ที่เปิดไว้

5.7.3 UDP Hole Punching กับ WireGuard และข้อจำกัด

UDP hole punching คือเทคนิคให้สองฝั่งที่อยู่หลัง NAT ส่ง UDP หากันพร้อมกัน เพื่อให้ NAT ทั้งสองเปิด mapping และคุยตรงกันได้โดยไม่ผ่านตัวกลาง โดยมี server กลางช่วยแลก endpoint ที่สังเกตได้ (เช่น STUN)

• WireGuard เองไม่มี STUN/coordination ในตัว ต้องใช้เครื่องมือเสริม (Tailscale, Netbird หรือสคริปต์เอง) เพื่อแจ้ง endpoint ให้ peer ทั้งสองตั้ง wg set ... endpoint พร้อมกัน
• ใช้ได้ กับ NAT แบบ endpoint-independent mapping (cone NAT)
• ใช้ไม่ได้ (หรือยาก) กับ symmetric NAT (เปลี่ยน port ต่อปลายทาง) และ CGNAT บางแบบ จึงต้องมี relay สำรอง (เช่น DERP ของ Tailscale)
• ตั้ง PersistentKeepalive ให้ถี่พอที่จะรักษา mapping ไว้

5.7.4 Config ตัวอย่าง

VPS (hub/relay):

[Interface]
PrivateKey = <VPS_PRIVATE_KEY>
Address = 10.10.0.1/24
ListenPort = 51820
PostUp   = sysctl -w net.ipv4.ip_forward=1
PostUp   = iptables -A FORWARD -i %i -o %i -j ACCEPT
PostDown = iptables -D FORWARD -i %i -o %i -j ACCEPT

[Peer]
# Home server (หลัง CGNAT) ไม่มี Endpoint: VPS เรียนรู้จากแพ็กเก็ตที่ได้รับ
PublicKey = <HOME_PUBLIC_KEY>
AllowedIPs = 10.10.0.2/32, 192.168.1.0/24

[Peer]
# โน้ตบุ๊กผู้ใช้
PublicKey = <LAPTOP_PUBLIC_KEY>
AllowedIPs = 10.10.0.3/32

Home server:

[Interface]
PrivateKey = <HOME_PRIVATE_KEY>
Address = 10.10.0.2/24
# ทำหน้าที่เป็น gateway ให้ LAN ที่บ้าน เมื่อผู้ใช้ภายนอกเข้ามาที่ 192.168.1.0/24
PostUp   = sysctl -w net.ipv4.ip_forward=1
PostUp   = iptables -t nat -A POSTROUTING -s 10.10.0.0/24 -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.10.0.0/24 -o eth0 -j MASQUERADE

[Peer]
PublicKey = <VPS_PUBLIC_KEY>
AllowedIPs = 10.10.0.0/24
Endpoint = 203.0.113.10:51820
# สำคัญมาก: รักษา NAT mapping ไว้ ไม่ให้ VPS ส่งหา Home ไม่ได้
PersistentKeepalive = 25

โน้ตบุ๊กผู้ใช้:

[Interface]
PrivateKey = <LAPTOP_PRIVATE_KEY>
Address = 10.10.0.3/32

[Peer]
PublicKey = <VPS_PUBLIC_KEY>
# เข้าถึง Home server และ LAN ที่บ้านผ่าน VPS
AllowedIPs = 10.10.0.0/24, 192.168.1.0/24
Endpoint = 203.0.113.10:51820
PersistentKeepalive = 25

5.7.5 PersistentKeepalive ที่เหมาะสม

ค่าที่เหมาะสมต้อง น้อยกว่า NAT timeout ของ UDP ที่สั้นที่สุดในเส้นทาง

• K = ค่า PersistentKeepalive (วินาที)
• T_nat = timeout ของ UDP mapping บนอุปกรณ์ NAT ที่สั้นที่สุด (วินาที)
• หาร 2 = ส่วนเผื่อความปลอดภัยเมื่อแพ็กเก็ตสูญหายหนึ่งครั้ง

ตัวอย่าง: NAT บางตัว timeout 30 วินาที → K ≤ 15 วินาที; NAT ทั่วไปที่ 60–120 วินาที → K = 25 ก็เพียงพอ ค่าที่ถี่เกินจำเป็นสิ้นเปลืองแบตเตอรี่และข้อมูล

5.7.6 ข้อควรระวังและการทดสอบ

• Home server ต้องมี keepalive เสมอ ไม่เช่นนั้นเมื่อไม่มี traffic mapping จะหมดอายุและ VPS ส่งหา Home ไม่ได้
• ถ้า VPS มี firewall เปิดเฉพาะ UDP 51820 เข้า และอนุญาต forward ระหว่าง wg0 ก็เพียงพอ
• เปลี่ยน VPS ต้องอัปเดต Endpoint ทุกเครื่อง

# บน Home server
sudo wg-quick up wg0
sudo wg show wg0              # ต้องเห็น latest handshake กับ VPS ภายใน 25 วินาทีแรก

# จากโน้ตบุ๊กภายนอก: เข้าถึงบริการที่บ้านผ่าน VPS
ping -c 3 10.10.0.2
curl -sS http://192.168.1.20:8123/ -o /dev/null -w '%{http_code}\n'   # ตัวอย่าง Home Assistant (ต้องใช้ NAT ที่ home server)

🧪 ตัวอย่าง 5.7: ชุด config 3 ไฟล์ (vps.conf, home.conf, laptop.conf) ดูในไฟล์ตัวอย่าง

5.8 เข้าถึง Home Lab / Self-hosted Services

5.8.1 สถานการณ์

มี NAS, Home Assistant, Git server (Gitea/Forgejo), media server (Jellyfin) ในบ้าน ต้องการเข้าถึงจากภายนอกอย่างปลอดภัย โดยไม่ต้องเปิดพอร์ตของแต่ละบริการสู่อินเทอร์เน็ต

5.8.2 เปรียบเทียบ: เปิดพอร์ตตรง ๆ กับเข้าผ่าน VPN

5.8.3 การเข้า LAN ทั้งหมดผ่านเครื่อง Gateway เดียว

ตั้ง WireGuard บนเครื่องเดียวใน LAN (เช่น Raspberry Pi หรือ router) ให้เป็น gateway ของ client ภายนอก

flowchart LR
    R["ผู้ใช้ภายนอก
(Remote user)
10.8.0.2"] -- "WireGuard UDP 51820" --> RT["Router บ้าน
Port forward UDP 51820
ไปยัง Pi"]
    RT --> PI["Raspberry Pi (WG gateway)
192.168.1.5 / wg0 10.8.0.1"]
    PI --> NAS["NAS 192.168.1.10"]
    PI --> HA["Home Assistant 192.168.1.20"]
    PI --> GIT["Git server 192.168.1.30"]
    PI --> MED["Media server 192.168.1.40"]

Gateway (Raspberry Pi):

[Interface]
PrivateKey = <PI_PRIVATE_KEY>
Address = 10.8.0.1/24
ListenPort = 51820
# NAT ให้ client ดู LAN เหมือนมาจาก Pi (ไม่ต้องตั้ง route บน router บ้าน)
PostUp   = sysctl -w net.ipv4.ip_forward=1
PostUp   = iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

[Peer]
PublicKey = <PHONE_PUBLIC_KEY>
AllowedIPs = 10.8.0.2/32

Client (มือถือ/โน้ตบุ๊ก):

[Interface]
PrivateKey = <PHONE_PRIVATE_KEY>
Address = 10.8.0.2/32
DNS = 192.168.1.5          # ถ้ารัน Pi-hole/Unbound บน Pi

[Peer]
PublicKey = <PI_PUBLIC_KEY>
AllowedIPs = 10.8.0.0/24, 192.168.1.0/24
Endpoint = home.example.com:51820      # DDNS (หัวข้อ 9.5)
PersistentKeepalive = 25

5.8.4 ข้อควรระวัง

• บน router บ้านต้อง port forward UDP 51820 ไปยัง Pi (หรือ DMZ ไม่แนะนำ) หากอยู่หลัง CGNAT ให้ใช้ 5.7
• ถ้า subnet ที่บ้านเป็น 192.168.1.0/24 ซึ่งตรงกับ Wi-Fi สาธารณะจำนวนมาก จะเกิด subnet ชนกัน ให้เปลี่ยน LAN ที่บ้านเป็นช่วงที่ไม่ธรรมดา (เช่น 192.168.77.0/24)
• แยก VLAN สำหรับอุปกรณ์ IoT และอนุญาตเฉพาะบริการที่จำเป็นผ่าน firewall
• อัปเดต OS/บริการเป็นประจำ แม้จะอยู่หลัง VPN ก็ยังต้องมี authentication ของแอปเอง (defense in depth)

5.8.5 การทดสอบ

# จากนอกบ้าน (ปิด Wi-Fi บ้าน ใช้ 4G) เปิด tunnel แล้ว
curl -sS -o /dev/null -w 'NAS: %{http_code}\n' http://192.168.1.10:5000/
curl -sS -o /dev/null -w 'HA: %{http_code}\n'  http://192.168.1.20:8123/
nmap -Pn -p 22,80,443,8123 192.168.1.20      # ตรวจพอร์ตที่เปิด

🧪 ตัวอย่าง 5.8: ไฟล์ homelab-gateway.conf, homelab-client.conf และสคริปต์เช็กบริการ ดูในไฟล์ตัวอย่าง

5.9 Expose Service ผ่าน VPS (Reverse Tunnel Pattern)

5.9.1 สถานการณ์

ต้องการเปิดบริการที่รันที่บ้าน (เช่น เว็บ blog, Git server สาธารณะ) ให้คนทั่วไปเข้าถึงได้ผ่านโดเมน โดยไม่เปิดเผย IP บ้านและแม้อยู่หลัง CGNAT ใช้ VPS ที่มี public IP เป็น "ประตูหน้า" ส่งต่อ traffic ผ่าน WireGuard มายังเครื่องที่บ้าน

5.9.2 สถาปัตยกรรม

flowchart LR
    USER["ผู้ใช้ทั่วไป (Public user)
https://blog.example.com"] --> V1["VPS 203.0.113.10
Reverse proxy (Nginx/Caddy) หรือ DNAT"]
    V1 -- "WireGuard 10.20.0.1 -> 10.20.0.2" --> H1["Home server 10.20.0.2
บริการ blog พอร์ต 8080"]

มีสองรูปแบบ:

5.9.3 Config ตัวอย่าง

VPS (wg0.conf) พร้อม DNAT:

[Interface]
PrivateKey = <VPS_PRIVATE_KEY>
Address = 10.20.0.1/24
ListenPort = 51820
PostUp   = sysctl -w net.ipv4.ip_forward=1
# DNAT: พอร์ต 2222 ของ VPS -> SSH (22) ที่ home server 10.20.0.2
PostUp   = iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 2222 -j DNAT --to-destination 10.20.0.2:22
PostUp   = iptables -A FORWARD -i eth0 -o %i -p tcp -d 10.20.0.2 --dport 22 -j ACCEPT
PostUp   = iptables -A FORWARD -i %i -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
PostDown = iptables -t nat -D PREROUTING -i eth0 -p tcp --dport 2222 -j DNAT --to-destination 10.20.0.2:22
PostDown = iptables -D FORWARD -i eth0 -o %i -p tcp -d 10.20.0.2 --dport 22 -j ACCEPT
PostDown = iptables -D FORWARD -i %i -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

[Peer]
PublicKey = <HOME_PUBLIC_KEY>
AllowedIPs = 10.20.0.2/32

Home server (wg0.conf):

[Interface]
PrivateKey = <HOME_PRIVATE_KEY>
Address = 10.20.0.2/24

[Peer]
PublicKey = <VPS_PUBLIC_KEY>
# AllowedIPs = 10.20.0.1/32 พอสำหรับ reverse proxy;
# ต้องเพิ่ม 0.0.0.0/0 (หรือช่วงผู้ใช้จริง) ถ้าต้อง "ตอบกลับ" ไปยัง IP ต้นทางจริงผ่านอุโมงค์ (กรณีรักษา source IP)
AllowedIPs = 10.20.0.1/32
Endpoint = 203.0.113.10:51820
PersistentKeepalive = 25

Nginx บน VPS (reverse proxy):

# /etc/nginx/conf.d/blog.conf
server {
    listen 80;
    server_name blog.example.com;

    location / {
        # ส่งต่อไปยังบริการที่บ้านผ่าน tunnel
        proxy_pass http://10.20.0.2:8080;
        # ส่ง IP จริงของผู้ใช้ให้ปลายทางรับรู้
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}
# ขอ certificate TLS: sudo certbot --nginx -d blog.example.com

Caddy บน VPS (ทางเลือกที่ง่ายกว่า มี TLS อัตโนมัติ):

# /etc/caddy/Caddyfile
blog.example.com {
    # Caddy ขอและต่ออายุ certificate ให้เอง และใส่ X-Forwarded-For ให้อัตโนมัติ
    reverse_proxy 10.20.0.2:8080
}

5.9.4 การรักษา Source IP จริงของผู้ใช้

ข้อควรระวัง: อย่าเชื่อ X-Forwarded-For จาก client ภายนอกโดยตรง ให้ reverse proxy เขียนทับ (overwrite) ค่า header ก่อนส่งต่อ

5.9.5 ข้อควรระวัง

• VPS เป็นจุดเดียวที่เปิดสู่สาธารณะ ให้ใช้ firewall เปิดเฉพาะ 80/443 (และ 51820/udp) และอัปเดตระบบสม่ำเสมอ
• บริการที่บ้านที่เปิดสู่สาธารณะต้องมี authentication และ rate limit ของตัวเอง
• แบนด์วิดท์ upload ของบ้านเป็นคอขวด และ latency เพิ่มจากการวนผ่าน VPS
• ตรวจกฎผู้ให้บริการ VPS เรื่องการ relay traffic

5.9.6 การทดสอบ

# จากอินเทอร์เน็ตภายนอก
curl -I https://blog.example.com
ssh -p 2222 user@203.0.113.10           # ต้องเข้าถึง home server (DNAT)

# บน VPS: ตรวจ NAT และ conntrack
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L 2>/dev/null | grep 10.20.0.2 | head
# บน Home: ดูว่า log ของบริการเห็น IP ผู้ใช้จริง (จาก header)

🧪 ตัวอย่าง 5.9: ไฟล์ vps-dnat.conf, nginx-blog.conf, Caddyfile ดูในไฟล์ตัวอย่าง

5.10 ใช้บริการ Commercial VPN ผ่าน WireGuard

5.10.1 สถานการณ์

ผู้ให้บริการอย่าง Mullvad, ProtonVPN, IVPN ฯลฯ เปิดให้ดาวน์โหลดไฟล์ config WireGuard เพื่อใช้กับอุปกรณ์ใดก็ได้ (router, Raspberry Pi, Linux) โดยไม่ต้องใช้แอปของผู้ให้บริการ

5.10.2 การนำ config ไปใช้เอง

1. เข้าเว็บผู้ให้บริการ สร้างไฟล์ WireGuard config (เลือกประเทศ/เซิร์ฟเวอร์)
2. ตรวจ [Interface]: PrivateKey, Address (ผู้ให้บริการกำหนดให้), DNS
3. ตรวจ [Peer]: PublicKey ของ server, Endpoint, AllowedIPs = 0.0.0.0/0, ::/0
4. บันทึกเป็น /etc/wireguard/vpn-provider.conf (permission 600) แล้ว wg-quick up vpn-provider

# ตัวอย่างโครงสร้าง config ที่ผู้ให้บริการออกให้ (ค่าทั้งหมดสมมติ)
[Interface]
PrivateKey = <PROVIDER_ISSUED_PRIVATE_KEY>
Address = 10.66.12.34/32, fc00:bbbb:bbbb:bb01::1:c22/128
DNS = 10.64.0.1

[Peer]
PublicKey = <PROVIDER_SERVER_PUBLIC_KEY>
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = 198.51.100.7:51820

5.10.3 สร้าง Gateway ที่ส่งทั้งเครือข่ายออกผ่านผู้ให้บริการ

ติดตั้งบน Raspberry Pi/เครื่อง Linux ให้ทำหน้าที่เป็น gateway ของอุปกรณ์ในบ้าน แล้วส่ง traffic ออกผ่าน commercial VPN

flowchart LR
    LAN["อุปกรณ์ใน LAN
(LAN devices)
192.168.1.0/24"] --> GW["Gateway (Linux)
eth0: 192.168.1.2"]
    GW -- "wg0 (VPN provider)" --> PROV["Commercial VPN server"]
    PROV --> NET["อินเทอร์เน็ต (Internet)"]

# /etc/wireguard/vpn-provider.conf บน gateway
[Interface]
PrivateKey = <PROVIDER_ISSUED_PRIVATE_KEY>
Address = 10.66.12.34/32
# ไม่ให้ wg-quick ใส่ default route เอง เพื่อเราจะทำ policy routing สำหรับ LAN
Table = off
PostUp   = sysctl -w net.ipv4.ip_forward=1
# ส่ง traffic จาก LAN เข้าตาราง 200 (default ผ่าน wg0)
PostUp   = ip route add default dev %i table 200
PostUp   = ip rule add from 192.168.1.0/24 table 200 priority 1000
# NAT traffic ของ LAN ที่ออก wg0
PostUp   = iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o %i -j MASQUERADE
# Kill switch: ห้าม LAN ออกอินเทอร์เน็ตทาง eth0 ตรง ๆ ถ้า VPN ล่ม
PostUp   = iptables -I FORWARD -s 192.168.1.0/24 -o eth0 -j REJECT
PostDown = iptables -D FORWARD -s 192.168.1.0/24 -o eth0 -j REJECT
PostDown = iptables -t nat -D POSTROUTING -s 192.168.1.0/24 -o %i -j MASQUERADE
PostDown = ip rule del from 192.168.1.0/24 table 200 priority 1000
PostDown = ip route del default dev %i table 200

[Peer]
PublicKey = <PROVIDER_SERVER_PUBLIC_KEY>
AllowedIPs = 0.0.0.0/0
Endpoint = 198.51.100.7:51820
PersistentKeepalive = 25

วิธีใช้: ตั้ง default gateway ของอุปกรณ์ใน LAN (หรือที่ DHCP) ให้ชี้มาที่ 192.168.1.2 แล้วทดสอบด้วย curl https://ifconfig.me บนอุปกรณ์ LAN

5.10.4 Multi-hop (Chaining หลาย Tunnel)

Multi-hop คือการส่ง traffic ผ่านหลาย server ต่อกัน (เข้า server A แล้วออกที่ server B) เพื่อกระจายความไว้วางใจ ผู้ให้บริการบางรายมีให้เลือกในตัว หรือทำเองได้โดยซ้อน tunnel: ส่ง UDP ของ tunnel ที่สองผ่าน tunnel แรก

# wg-entry.conf : hop 1 (ทางเข้า) ใช้ Table = off แล้วให้ route เฉพาะไปยัง endpoint ของ hop 2
[Interface]
PrivateKey = <ENTRY_PRIVATE_KEY>
Address = 10.66.1.2/32
Table = off
[Peer]
PublicKey = <ENTRY_SERVER_PUBLIC_KEY>
AllowedIPs = 0.0.0.0/0
Endpoint = 198.51.100.7:51820

# wg-exit.conf : hop 2 (ทางออก) endpoint ของ exit จะถูกส่งผ่าน wg-entry
[Interface]
PrivateKey = <EXIT_PRIVATE_KEY>
Address = 10.66.2.2/32
# ให้ UDP ที่ไป exit server ผ่านอุโมงค์ entry
PostUp = ip route add 192.0.2.20/32 dev wg-entry
[Peer]
PublicKey = <EXIT_SERVER_PUBLIC_KEY>
AllowedIPs = 0.0.0.0/0
Endpoint = 192.0.2.20:51820

ข้อแลกเปลี่ยน:

• ได้ privacy สูงขึ้น (ไม่มี node เดียวที่รู้ทั้ง "ใครเป็นผู้ใช้" และ "เข้าเว็บอะไร") แต่ latency บวกกันและ MTU ลดลงเพิ่มอีก 80 byte ต่อชั้น (1420 → 1340)
• ตั้ง MTU ของ wg-exit ให้ไม่เกิน MTU ของ wg-entry ลบ 80

5.10.5 การทดสอบ

sudo wg-quick up vpn-provider
curl -sS https://ifconfig.me ; echo           # ต้องเป็น IP ของผู้ให้บริการ
curl -sS https://am.i.mullvad.net/connected 2>/dev/null || true   # หน้าตรวจของผู้ให้บริการบางราย
dig +short myip.opendns.com @resolver1.opendns.com                # ตรวจว่า DNS ออกทางผู้ให้บริการ

🧪 ตัวอย่าง 5.10: vpn-provider.conf (เทมเพลต), wg-entry.conf / wg-exit.conf ดูในไฟล์ตัวอย่าง

5.11 ทำ Egress Gateway / Exit Node

5.11.1 สถานการณ์

ต้องการให้เครื่องหนึ่ง (เช่น VPS ในต่างประเทศ) เป็น ทางออกอินเทอร์เน็ต ของเครื่องอื่น และเลือก "ตำแหน่ง" ทางออกได้ (เช่น ออกที่ญี่ปุ่นสำหรับบริการหนึ่ง ออกที่สิงคโปร์สำหรับอีกบริการ) รวมถึงแยกตามอุปกรณ์หรือ subnet

5.11.2 สถาปัตยกรรม

flowchart LR
    subgraph CLIENTS["อุปกรณ์ใน LAN (LAN devices)"]
        D1["TV 192.168.1.101"]
        D2["โน้ตบุ๊ก 192.168.1.102"]
        D3["เซิร์ฟเวอร์ 192.168.1.103"]
    end
    GW["Gateway
Policy routing"]
    D1 --> GW
    D2 --> GW
    D3 --> GW
    GW -- "wg-jp (ออกญี่ปุ่น)" --> JP["Exit JP 198.51.100.11"]
    GW -- "wg-sg (ออกสิงคโปร์)" --> SG["Exit SG 198.51.100.12"]
    GW -- "eth0 ปกติ (Direct)" --> ISP["ISP"]

5.11.3 Config ตัวอย่าง: แยกทางออกตามอุปกรณ์ด้วย Policy Routing

# /etc/wireguard/wg-jp.conf (Gateway -> Exit JP) ; wg-sg.conf ใช้โครงเดียวกันเปลี่ยน key/endpoint/ตาราง
[Interface]
PrivateKey = <GW_PRIVATE_KEY_FOR_JP>
Address = 10.31.0.2/32
Table = off                                 # เราควบคุม routing เอง
PostUp   = ip route add default dev %i table 101
PostUp   = ip rule add from 192.168.1.101/32 table 101 priority 1101
PostUp   = iptables -t nat -A POSTROUTING -s 192.168.1.101/32 -o %i -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 192.168.1.101/32 -o %i -j MASQUERADE
PostDown = ip rule del from 192.168.1.101/32 table 101 priority 1101
PostDown = ip route del default dev %i table 101

[Peer]
PublicKey = <EXIT_JP_PUBLIC_KEY>
AllowedIPs = 0.0.0.0/0
Endpoint = 198.51.100.11:51820
PersistentKeepalive = 25

# Exit node (ทั้ง JP และ SG ใช้โครงเดียวกัน): ทำ NAT ออกอินเทอร์เน็ต
[Interface]
PrivateKey = <EXIT_PRIVATE_KEY>
Address = 10.31.0.1/24
ListenPort = 51820
PostUp   = sysctl -w net.ipv4.ip_forward=1
PostUp   = iptables -t nat -A POSTROUTING -s 10.31.0.0/24 -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.31.0.0/24 -o eth0 -j MASQUERADE

[Peer]
PublicKey = <GW_PUBLIC_KEY>
AllowedIPs = 10.31.0.2/32

ตารางสรุปการแยก traffic:

5.11.4 ข้อควรระวังและการทดสอบ

• ตรวจกฎหมายและข้อกำหนดของบริการที่ใช้ (บริการสตรีมมิงมักห้ามการหลบเลี่ยงภูมิภาค)
• ตั้ง kill switch ต่ออุปกรณ์ (REJECT ถ้า interface ไม่ขึ้น) เพื่อไม่ให้ traffic รั่วออก ISP
• DNS ต้องส่งผ่านเส้นทางเดียวกัน ไม่เช่นนั้นเว็บอาจตรวจพบตำแหน่ง DNS ที่ไม่ตรง

# ตรวจ policy ที่ gateway
ip rule show | sort -n | head
ip route show table 101
# ทดสอบจาก TV หรือจำลองด้วย curl --interface (บน gateway)
curl --interface 192.168.1.2 -sS https://ifconfig.me          # ออก ISP
# บนอุปกรณ์ 192.168.1.101: curl https://ifconfig.me  ต้องได้ IP ของ Exit JP

🧪 ตัวอย่าง 5.11: wg-jp.conf, wg-sg.conf, exit-node.conf และสคริปต์ rules-table.sh ดูในไฟล์ตัวอย่าง

5.12 Multiple Tunnels, Failover และ Load Balancing

5.12.1 สถานการณ์

ต้องการความต่อเนื่องของ VPN: ถ้า server หลักล่ม ให้ย้ายไป server สำรองอัตโนมัติ หรือกระจายโหลดไปหลาย tunnel

5.12.2 สถาปัตยกรรม

flowchart TD
    C["Client / Gateway"] --> W1["wg-primary
Server 1 (metric 10)"]
    C --> W2["wg-backup
Server 2 (metric 20)"]
    W1 --> N["เครือข่ายปลายทาง (Target network)"]
    W2 --> N
    HC["Health check script
ตรวจ handshake และ ping
(Handshake and ping check)"] -.-> C

5.12.3 รันหลาย Interface พร้อมกัน

ใช้ไฟล์ wg-primary.conf และ wg-backup.conf ที่มี Table = off และจัดการ route เอง

# เปิดทั้งสอง interface
sudo wg-quick up wg-primary
sudo wg-quick up wg-backup

# สร้าง default route สองเส้นใน main table ด้วย metric ต่างกัน (metric ต่ำ = ใช้ก่อน)
sudo ip route add default dev wg-primary metric 10
sudo ip route add default dev wg-backup  metric 20
ip route show default
# ตัวอย่างผลลัพธ์:
#   default dev wg-primary scope link metric 10
#   default dev wg-backup scope link metric 20

5.12.4 Failover ระหว่าง Endpoint สำรอง

WireGuard รองรับ Endpoint ได้ตัวเดียวต่อ peer จึงทำ failover โดยสคริปต์ตรวจสุขภาพแล้วสลับ endpoint หรือสลับ route

#!/usr/bin/env bash
# wg-failover.sh : ตรวจสุขภาพ tunnel หลัก ถ้า handshake เก่าเกินกำหนดให้สลับ route ไปสำรอง
# วิธีใช้: sudo ./wg-failover.sh   (รันด้วย systemd timer ทุก 15 วินาที)
set -euo pipefail

PRIMARY="wg-primary"                 # interface หลัก
BACKUP="wg-backup"                   # interface สำรอง
PRIMARY_PEER="<PRIMARY_PEER_PUBLIC_KEY>"
PROBE_IP="10.31.0.1"                 # ที่อยู่ภายใน tunnel ใช้ ping ทดสอบ
MAX_AGE=180                          # handshake เก่ากว่านี้ (วินาที) ถือว่าล่ม

# เวลา handshake ล่าสุดของ peer หลัก (epoch; 0 = ยังไม่เคย)
last=$(wg show "$PRIMARY" latest-handshakes | awk -v k="$PRIMARY_PEER" '$1==k {print $2}')
now=$(date +%s)
age=$(( now - ${last:-0} ))

# ทดสอบ ping ผ่าน interface หลัก
if ping -c 2 -W 2 -I "$PRIMARY" "$PROBE_IP" >/dev/null 2>&1 && [ "$age" -lt "$MAX_AGE" ]; then
  # หลักปกติ: ให้ metric ของหลักต่ำสุด
  ip route replace default dev "$PRIMARY" metric 10
  logger -t wg-failover "primary OK (handshake age ${age}s)"
else
  # หลักล่ม: ให้ route ของสำรองเป็นหลัก
  ip route replace default dev "$BACKUP" metric 5
  logger -t wg-failover "primary DOWN (age ${age}s) -> using $BACKUP"
fi

# /etc/systemd/system/wg-failover.timer
[Unit]
Description=รัน wg-failover ทุก 15 วินาที
[Timer]
OnBootSec=30
OnUnitActiveSec=15
[Install]
WantedBy=timers.target
# และ /etc/systemd/system/wg-failover.service ให้ ExecStart=/usr/local/bin/wg-failover.sh
# เปิดใช้: sudo systemctl enable --now wg-failover.timer

5.12.5 Routing Metric, ECMP และ Health Check

• Metric: route ที่ metric ต่ำกว่าถูกเลือกก่อน (ใช้ทำ primary/backup)
• ECMP (Equal-Cost Multi-Path): กระจาย flow ไปหลายเส้นทางที่ cost เท่ากัน (กล่าวเบื้องต้น) ตั้งได้ด้วย ip route add default nexthop dev wg-a weight 1 nexthop dev wg-b weight 1 โดย kernel กระจายตาม hash ของ flow (ไม่ใช่ต่อแพ็กเก็ต) จึงไม่เกิดการสลับลำดับ

# ตัวอย่าง ECMP สองเส้นทางที่น้ำหนักเท่ากัน
sudo ip route replace default \
  nexthop dev wg-a weight 1 \
  nexthop dev wg-b weight 1
ip route show default

# ปรับให้ hash ใช้ L4 (พอร์ต) ด้วยเพื่อกระจายได้ดีขึ้น
sudo sysctl -w net.ipv4.fib_multipath_hash_policy=1

ตัวอย่างการคำนวณ: ความพร้อมใช้งานรวมของสอง tunnel อิสระ

• A_total = ความพร้อมใช้งานรวมของระบบที่มี failover
• A₁, A₂ = ความพร้อมใช้งานของ tunnel หลักและสำรอง (ค่าระหว่าง 0 ถึง 1) โดยสมมติว่าล้มเหลวอย่างอิสระต่อกัน

แทนค่า: A₁ = A₂ = 0.99 (99%) → A_total = 1 − (0.01)(0.01) = 1 − 0.0001 = 0.9999 (99.99%) เวลาล่มต่อปีลดจาก ≈ 87.6 ชั่วโมง (1% ของ 8,760) เหลือ ≈ 0.88 ชั่วโมง (≈ 53 นาที) แต่ต้องคิดเวลาตรวจจับและสลับด้วย (เช่น ทุก 15 วินาที + MAX_AGE)

5.12.6 การทดสอบ

# จำลอง primary ล่ม: บล็อก UDP ไปยัง server หลัก
sudo iptables -I OUTPUT -d <PRIMARY_SERVER_IP> -p udp --dport 51820 -j DROP
sleep 30; ip route show default            # ควรเห็น backup ถูกเลือก
journalctl -t wg-failover -n 5 --no-pager
# คืนค่า
sudo iptables -D OUTPUT -d <PRIMARY_SERVER_IP> -p udp --dport 51820 -j DROP

🧪 ตัวอย่าง 5.12: wg-primary.conf, wg-backup.conf, wg-failover.sh, unit ของ systemd ดูในไฟล์ตัวอย่าง

5.13 เข้าถึงอุปกรณ์ IoT / Embedded / Raspberry Pi

5.13.1 สถานการณ์

มีอุปกรณ์ภาคสนามจำนวนมาก (Raspberry Pi เก็บข้อมูลเซนเซอร์, gateway ในฟาร์ม, ตู้คอนโทรล) ที่อยู่หลัง SIM/4G แบบ NAT ต้องการเข้าไป SSH/ดึงข้อมูล/อัปเดตระยะไกล ESP-class (ESP32) บางรุ่นมีไลบรารี WireGuard ให้ใช้ แต่ทรัพยากรจำกัด จึงนิยมใช้ Raspberry Pi หรือ gateway ที่รัน Linux เป็นตัวกลาง ให้ MCU เชื่อมผ่าน LAN ท้องถิ่น

5.13.2 สถาปัตยกรรม

flowchart LR
    subgraph FIELD["ภาคสนาม (Field sites) หลัง 4G NAT"]
        P1["Pi-001
10.40.1.1"]
        P2["Pi-002
10.40.1.2"]
        GWF["Edge gateway
10.40.2.1
(ESP32/MCU หลายตัวต่อ LAN)"]
    end
    subgraph CORE["ศูนย์กลาง (Core) 203.0.113.10"]
        SRV["Collector/Hub
wg0 10.40.0.1/16
รับ connection จากทุกอุปกรณ์"]
    end
    OPS["ผู้ดูแล (Operator)
10.40.0.10"]
    P1 --> SRV
    P2 --> SRV
    GWF --> SRV
    OPS --> SRV

5.13.3 การจัดการ Key จำนวนมาก

การออกแบบ addressing สำหรับอุปกรณ์จำนวนมาก: ใช้ 10.40.0.0/16 (65,534 address) แบ่งตามชนิดหรือสาขา:

ต้นทุนหน่วยความจำและการตั้งค่า: แต่ละ peer ใช้หน่วยความจำของ kernel เพียงเล็กน้อย (หลักหลายร้อย byte ถึงกิโลไบต์) การมี peer หลักพันถึงหมื่นรายการทำงานได้บน server ทั่วไป แต่การโหลดผ่าน wg-quick ช้าลง ควรใช้ wg set/wg syncconf เพิ่ม peer แทนการรีสตาร์ท interface

#!/usr/bin/env bash
# provision-devices.sh : ออก key และ config ให้อุปกรณ์จำนวนมากจากไฟล์รายชื่อ
# วิธีใช้:  ./provision-devices.sh devices.txt out/  (ไฟล์รายชื่อ: บรรทัดละ  "ชื่ออุปกรณ์ IP")
#   เช่น  pi-001 10.40.1.1
set -euo pipefail
LIST="$1"; OUT="$2"
SERVER_PUB="$(cat server.pub)"                 # public key ของ collector
ENDPOINT="vpn.example.com:51820"
umask 077; mkdir -p "$OUT"

: > "$OUT/server-peers.conf"                   # ไฟล์ [Peer] ทั้งหมดสำหรับ server
while read -r name ip; do
  [ -z "${name:-}" ] && continue
  key=$(wg genkey); pub=$(echo "$key" | wg pubkey)
  # ไฟล์ของอุปกรณ์ (ฝังลงอุปกรณ์ตอน flash/provision)
  cat > "$OUT/$name.conf" <<EOF
[Interface]
PrivateKey = $key
Address = $ip/32

[Peer]
PublicKey = $SERVER_PUB
AllowedIPs = 10.40.0.0/24
Endpoint = $ENDPOINT
PersistentKeepalive = 60
EOF
  # ส่วน [Peer] สำหรับ server (ผูกด้วย /32 ของอุปกรณ์เท่านั้น)
  printf '[Peer]\n# %s\nPublicKey = %s\nAllowedIPs = %s/32\n\n' "$name" "$pub" "$ip" >> "$OUT/server-peers.conf"
  echo "ออกให้ $name ($ip)"
done < "$LIST"
echo "นำ $OUT/server-peers.conf ไปต่อท้าย /etc/wireguard/wg0.conf ของ server"

5.13.4 ข้อจำกัดทรัพยากรและ Remote Maintenance

• CPU ต่ำ (Pi Zero, ARM เก่า): ChaCha20-Poly1305 ทำงานได้ดีกว่า AES ซอฟต์แวร์บนซีพียูที่ไม่มี instruction เฉพาะ จึงเหมาะกับ IoT
• แบตเตอรี่/ข้อมูลมือถือ: ใช้ PersistentKeepalive ยาวขึ้น (เช่น 60–120 วินาที) หรือไม่ใช้ หากอุปกรณ์เป็นฝ่ายเริ่มส่งข้อมูลเป็นรอบ
• จุดล้มเหลว: ตั้ง hardware watchdog และ timer รีสตาร์ท wg-quick@wg0 ถ้า handshake เก่าเกินกำหนด
• การอัปเดตระยะไกล: ใช้ tunnel เป็นเส้นทางให้ ssh, rsync, ansible (หัวข้อ 11.1)
• ความปลอดภัยทางกายภาพ: private key ถูกเก็บในอุปกรณ์ที่ผู้อื่นเข้าถึงได้ ใช้ AllowedIPs แคบที่สุด และ firewall บน collector จำกัดสิทธิ์ของแต่ละอุปกรณ์ (อุปกรณ์เข้าถึงเฉพาะบริการรับข้อมูล ไม่ใช่อุปกรณ์อื่น)

# /etc/systemd/system/wg-watchdog.service บนอุปกรณ์ภาคสนาม: รีสตาร์ท tunnel ถ้าติดต่อ collector ไม่ได้
[Unit]
Description=รีสตาร์ท WireGuard ถ้า handshake เก่าเกิน 5 นาที
[Service]
Type=oneshot
ExecStart=/bin/sh -c 'age=$(( $(date +%%s) - $(wg show wg0 latest-handshakes | awk "{print \\$2}" | head -n1) )); [ "$age" -gt 300 ] && systemctl restart wg-quick@wg0 || true'

5.13.5 การทดสอบ

# บน collector: ดูอุปกรณ์ที่ออนไลน์ (handshake ภายใน 3 นาที) และจำนวนทั้งหมด
sudo wg show wg0 latest-handshakes | awk -v now="$(date +%s)" '
  { total++; if (now-$2 < 180) online++ } END { printf "online %d / total %d\n", online, total }'
ssh pi@10.40.1.1 'uptime; wg show wg0 | head -n 4'

🧪 ตัวอย่าง 5.13: provision-devices.sh พร้อมไฟล์ devices.txt ตัวอย่าง 5 เครื่อง ดูในไฟล์ตัวอย่าง

5.14 Developer และ DevOps Workflow

5.14.1 สถานการณ์

นักพัฒนาต้องเข้าถึง staging API, ฐานข้อมูล, Kubernetes API และเครื่องภายใน โดยไม่เปิดสู่อินเทอร์เน็ต เดิมใช้ bastion/jump host (SSH) ที่ต้องจัดการ key ของผู้ใช้บนเครื่องกลาง WireGuard ช่วยทดแทนได้ด้วยการให้เครื่องนักพัฒนาอยู่ใน private network โดยตรง

5.14.2 สถาปัตยกรรม

flowchart LR
    DEV["เครื่องนักพัฒนา (Developer)
10.50.0.10"] --> GW["WireGuard Gateway
10.50.0.1"]
    CI["CI/CD runner
10.50.0.200"] --> GW
    GW --> API["Staging API
172.20.1.10:8443"]
    GW --> DB["PostgreSQL
172.20.2.20:5432"]
    GW --> K8S["Kubernetes API
172.20.3.5:6443"]

5.14.3 Config ตัวอย่างและการกำหนดสิทธิ์

นโยบายแบบละเอียดด้วย nftables ที่ gateway:

# /etc/nftables.d/dev-access.nft
table inet dev_access {
    set devs { type ipv4_addr; elements = { 10.50.0.10-10.50.0.99 } }
    set ci   { type ipv4_addr; elements = { 10.50.0.200 } }

    chain forward {
        type filter hook forward priority 0; policy drop;
        ct state established,related accept

        # นักพัฒนา: เข้า API, K8s API และ DB แบบอ่านอย่างเดียวผ่านพอร์ตที่กำหนด
        ip saddr @devs ip daddr 172.20.1.10 tcp dport 8443 accept
        ip saddr @devs ip daddr 172.20.3.5  tcp dport 6443 accept
        ip saddr @devs ip daddr 172.20.2.20 tcp dport 5432 accept
        # CI runner: เข้า API และ K8s API เท่านั้น (ไม่แตะ DB)
        ip saddr @ci   ip daddr { 172.20.1.10, 172.20.3.5 } tcp dport { 8443, 6443 } accept
    }
}

Client ของนักพัฒนา (split tunnel เฉพาะ subnet ภายใน):

[Interface]
PrivateKey = <DEV_PRIVATE_KEY>
Address = 10.50.0.10/32
DNS = 172.20.0.2
PostUp   = resolvectl dns %i 172.20.0.2; resolvectl domain %i ~svc.internal
PostDown = resolvectl revert %i

[Peer]
PublicKey = <GATEWAY_PUBLIC_KEY>
AllowedIPs = 10.50.0.0/24, 172.20.0.0/16
Endpoint = vpn.example.com:51820
PersistentKeepalive = 25

ใช้ร่วมกับ SSH, Git, kubectl:

# SSH ไปเครื่องภายในได้โดยตรง ไม่ต้อง ProxyJump
ssh deploy@172.20.1.10

# Git server ภายใน
git clone ssh://git@172.20.4.5/team/project.git

# kubectl ชี้ไปยัง API server ผ่าน tunnel (IP ภายใน)
kubectl --server=https://172.20.3.5:6443 get nodes

# ตัวอย่าง ~/.ssh/config : ใช้ชื่อสั้นและไม่ต้อง jump
# Host stg
#     HostName 172.20.1.10
#     User deploy

CI/CD runner: ติดตั้ง WireGuard ใน job ของ CI (เช่น GitHub Actions self-hosted runner หรือ container) โดยเก็บ private key เป็น secret ของ CI (ไม่ commit)

# ตัวอย่างขั้นตอนใน pipeline (เช่น GitHub Actions) ที่ต่อ VPN ก่อน deploy
# เก็บ WG_CONF (ทั้งไฟล์ config) เป็น secret ของ repository
steps:
  - name: ติดตั้ง WireGuard และเปิด tunnel
    run: |
      sudo apt-get update && sudo apt-get install -y wireguard-tools resolvconf
      echo "${{ secrets.WG_CONF }}" | sudo tee /etc/wireguard/ci.conf >/dev/null
      sudo chmod 600 /etc/wireguard/ci.conf
      sudo wg-quick up ci
  - name: ทดสอบการเข้าถึง
    run: curl -fsS https://172.20.1.10:8443/healthz -k
  - name: ปิด tunnel (ทำเสมอ แม้ขั้นตอนก่อนหน้าล้ม)
    if: always()
    run: sudo wg-quick down ci || true

5.14.4 ข้อควรระวังและการทดสอบ

• ใช้ key ต่อบุคคล/ต่ออุปกรณ์ และ revoke เมื่อพนักงานออก (หัวข้อ 5.15)
• WireGuard ไม่มี audit log ของ "ใครเปิด session อะไร" ในตัว ให้ใช้ log ของ firewall/proxy ปลายทางช่วย
• ตรวจ subnet ชน ระหว่าง Docker/Kubernetes/VPC ที่ใช้ช่วง 172.17.0.0/16, 10.244.0.0/16 กับ tunnel ของท่าน
• Bastion ยังมีประโยชน์เรื่อง session recording ถ้าต้องการบันทึกการใช้งานตามนโยบาย

nc -zv 172.20.2.20 5432 && psql "host=172.20.2.20 user=dev dbname=app" -c 'select 1'
kubectl --server=https://172.20.3.5:6443 get ns

🧪 ตัวอย่าง 5.14: ไฟล์ dev-access.nft, dev-client.conf และ workflow ของ CI ดูในไฟล์ตัวอย่าง

5.15 Remote Work สำหรับทีมขนาดเล็ก–กลาง

5.15.1 สถานการณ์

บริษัทมีทีมหลายแผนก (Engineering, Finance, HR, ผู้รับเหมา) ต้องการให้ทำงานจากที่บ้านโดยเข้าถึงเฉพาะทรัพยากรที่เกี่ยวข้อง ตามหลัก least privilege และมีขั้นตอน onboard/offboard ที่ชัดเจน

5.15.2 การออกแบบ Subnet ต่อทีม/บทบาท

flowchart TD
    GW["WireGuard Gateway
wg0 10.60.0.1/16"]
    GW --> ENG["Engineering 10.60.1.0/24
เข้าถึง: Git, CI, Staging"]
    GW --> FIN["Finance 10.60.2.0/24
เข้าถึง: ERP, ไฟล์บัญชี"]
    GW --> HR["HR 10.60.3.0/24
เข้าถึง: ระบบ HR"]
    GW --> CON["ผู้รับเหมา Contractors 10.60.9.0/24
เข้าถึง: เฉพาะโปรเจกต์ที่ได้รับสิทธิ์"]
    GW --> ADM["ผู้ดูแล Admins 10.60.0.0/28
เข้าถึง: ทุกอย่างผ่านการอนุมัติ"]

การเข้าถึงขึ้นกับ firewall ที่ gateway ไม่ใช่ AllowedIPs ของ client ซึ่งอาจตั้งกว้างได้เพราะ client ควบคุมเอง:

# /etc/nftables.d/team-policy.nft : นโยบาย least privilege ตามกลุ่ม
table inet team_policy {
    set eng { type ipv4_addr; flags interval; elements = { 10.60.1.0/24 } }
    set fin { type ipv4_addr; flags interval; elements = { 10.60.2.0/24 } }
    set hr  { type ipv4_addr; flags interval; elements = { 10.60.3.0/24 } }
    set con { type ipv4_addr; flags interval; elements = { 10.60.9.0/24 } }
    set adm { type ipv4_addr; flags interval; elements = { 10.60.0.0/28 } }

    chain forward {
        type filter hook forward priority 0; policy drop;
        ct state established,related accept
        ip saddr @adm accept
        ip saddr @eng ip daddr { 172.20.1.0/24, 172.20.4.0/24 } accept
        ip saddr @fin ip daddr 172.20.5.0/24 accept
        ip saddr @hr  ip daddr 172.20.6.0/24 accept
        ip saddr @con ip daddr 172.20.1.50 tcp dport { 22, 443 } accept
        # ห้ามคุยระหว่างกลุ่มและระหว่างเครื่องในกลุ่มเดียวกัน (isolation) -- ตกไปที่ policy drop
        log prefix "WG-DENY " counter drop
    }
}

5.15.3 การ Onboard / Offboard ผู้ใช้

flowchart LR
    REQ["ขอสิทธิ์ (Request)
ผ่านระบบ ticket"] --> APP["หัวหน้าอนุมัติ
(Approval)"]
    APP --> GEN["สร้าง key และ IP
ตามกลุ่ม (Provision)"]
    GEN --> SEND["ส่งไฟล์/QR ผ่านช่องทางปลอดภัย
(Secure delivery)"]
    SEND --> USE["ใช้งาน (Active)"]
    USE --> REV["ทบทวนทุกไตรมาส
(Quarterly review)"]
    REV --> OFF["Offboard: ลบ peer
และ revoke (Remove peer)"]

#!/usr/bin/env bash
# user-lifecycle.sh : onboard / offboard ผู้ใช้บน WireGuard server
# วิธีใช้:
#   sudo ./user-lifecycle.sh add alice-laptop 10.60.1.10 "Alice Eng laptop"
#   sudo ./user-lifecycle.sh remove alice-laptop
#   sudo ./user-lifecycle.sh list
set -euo pipefail
IF=wg0; DB=/etc/wireguard/peers.db        # รูปแบบ DB: ชื่อ|public key|IP|หมายเหตุ|วันที่ออก
cmd=${1:?usage}; name=${2:-}; ip=${3:-}; note=${4:-}
umask 077; touch "$DB"

case "$cmd" in
  add)
    key=$(wg genkey); pub=$(echo "$key" | wg pubkey); psk=$(wg genpsk)
    # เพิ่ม peer แบบสด (ไม่ตัด session ของคนอื่น)
    wg set "$IF" peer "$pub" preshared-key <(echo "$psk") allowed-ips "$ip/32"
    echo "$name|$pub|$ip|$note|$(date +%F)" >> "$DB"
    # เขียนลง config ถาวรด้วย
    printf '\n# %s (%s) ออกเมื่อ %s\n[Peer]\nPublicKey = %s\nPresharedKey = %s\nAllowedIPs = %s/32\n' \
      "$name" "$note" "$(date +%F)" "$pub" "$psk" "$ip" >> /etc/wireguard/$IF.conf
    # สร้าง config ให้ผู้ใช้
    cat > "/root/$name.conf" <<EOF
[Interface]
PrivateKey = $key
Address = $ip/32
DNS = 172.20.0.2
[Peer]
PublicKey = $(cat /etc/wireguard/server.pub)
PresharedKey = $psk
AllowedIPs = 10.60.0.0/16, 172.20.0.0/16
Endpoint = vpn.example.com:51820
PersistentKeepalive = 25
EOF
    echo "สร้าง /root/$name.conf แล้ว (ส่งผ่านช่องทางปลอดภัย แล้วลบไฟล์นี้)"
    ;;
  remove)
    pub=$(awk -F'|' -v n="$name" '$1==n {print $2}' "$DB")
    [ -n "$pub" ] || { echo "ไม่พบ $name"; exit 1; }
    wg set "$IF" peer "$pub" remove                       # ตัดสิทธิ์ทันที
    sed -i "/^$name|/d" "$DB"
    echo "ลบ $name ออกจาก runtime แล้ว ต้องลบบล็อก [Peer] ที่ตรงกันใน /etc/wireguard/$IF.conf ด้วย"
    ;;
  list)
    column -t -s'|' "$DB"
    ;;
esac