VPN คืออะไร? สถาปัตยกรรม IPsec และ WireGuard

Underlay, Overlay และตำแหน่งปลายอุโมงค์

Underlay คือเครือข่ายกายภาพที่ส่งแพ็กเก็ตจริง ได้แก่ เราเตอร์ของ ISP ผู้ให้บริการ Transit และจุดแลกเปลี่ยนอินเทอร์เน็ต ส่วน Overlay คือลิงก์เสมือนแบบจุดต่อจุดที่ VPN สร้างขึ้นระหว่างปลายอุโมงค์สองฝั่ง เราเตอร์ใน Underlay มองเห็นเพียงแพ็กเก็ตชั้นนอก และไม่จำเป็นต้องรู้เส้นทางไปยังเครือข่ายส่วนตัวที่อยู่ข้างใน

ตำแหน่งของปลายอุโมงค์เป็นตัวกำหนดรูปแบบการออกแบบ ใน Site-to-Site VPN อุโมงค์สิ้นสุดที่ Firewall หรือเราเตอร์ของแต่ละสถานที่ เครื่องในแลนส่งข้อมูลแบบไม่เข้ารหัสไปยัง Default Gateway ตามปกติโดยไม่ต้องติดตั้งซอฟต์แวร์ VPN ส่วน Remote Access VPN อุโมงค์สิ้นสุดภายในอุปกรณ์ของผู้ใช้ผ่านการ์ดเครือข่ายเสมือน ดังนั้น Gateway ต้องกำหนดอย่างชัดเจนว่าผู้ใช้แต่ละคนเข้าถึงอะไรได้บ้างหลังเชื่อมต่อ

หน้าที่สี่ประการของ VPN องค์กร

VPN ที่ใช้งานจริงประกอบด้วยหน้าที่สี่อย่างที่แยกจากกัน หากขาดข้อใดข้อหนึ่ง อุโมงค์จะใช้งานไม่ได้หรือไม่ปลอดภัย

• การห่อแพ็กเก็ต (Encapsulation): นำแพ็กเก็ตต้นฉบับรวม IP Header ไปใส่ในแพ็กเก็ตใหม่ที่มี Header ชั้นนอกซึ่งส่งต่อบนอินเทอร์เน็ตได้ ทำให้ IP ส่วนตัวตาม RFC 1918 ข้ามอินเทอร์เน็ตได้
• การเข้ารหัส (Encryption): ใช้อัลกอริทึมแบบสมมาตร เช่น AES-GCM หรือ ChaCha20-Poly1305 เปลี่ยนแพ็กเก็ตภายในให้เป็นข้อมูลที่อุปกรณ์ระหว่างทางอ่านไม่ได้
• ความถูกต้องและการป้องกันการส่งซ้ำ: ใช้ Authentication Tag หรือ HMAC ตรวจจับการแก้ไข และใช้หน้าต่างลำดับหมายเลขปฏิเสธแพ็กเก็ตที่ถูกส่งซ้ำ ตามที่ RFC 4303 กำหนดสำหรับ ESP
• การควบคุมการเข้าถึง: การยืนยันตัวตนของอีกฝ่ายไม่ได้แปลว่าอนุญาตทุกอย่าง Gateway ปลายทางยังต้องบังคับใช้กฎ Firewall และหลักสิทธิ์น้อยที่สุดกับทราฟฟิกที่ถอดรหัสแล้ว

ขอบเขตความปลอดภัย: Gateway ถึง Gateway ไม่ใช่ปลายทางถึงปลายทาง

ในแบบ Site-to-Site การเข้ารหัสมีอยู่เฉพาะช่วงระหว่าง Gateway A กับ Gateway B เท่านั้น ส่วนช่วงแลนจากเครื่องลูกข่ายไปยัง Gateway A และจาก Gateway B ไปยังเซิร์ฟเวอร์ยังเป็นข้อมูลที่ไม่เข้ารหัสบนเครือข่ายภายใน

หากภัยคุกคามที่ต้องรับมือรวมถึงคนใน การเคลื่อนที่ข้ามเครือข่ายภายในของผู้โจมตี หรือสวิตช์ที่ใช้ร่วมกัน ต้องปกป้องที่ระดับแอปพลิเคชันด้วย เช่น HTTPS/TLS สำหรับเว็บและ API หรือ SIP over TLS และ SRTP สำหรับเสียง VPN เพิ่มเส้นทางที่ปลอดภัยระหว่างสถานที่ แต่ไม่ได้ทดแทนการเข้ารหัสระดับแอปพลิเคชันบนแลน

ขาไป: จากเครื่องลูกข่าย A ถึงเซิร์ฟเวอร์ B

เครื่องลูกข่าย A สร้างแพ็กเก็ตจาก 10.10.10.11 ไปยัง 10.20.20.20 เช่น TCP SYN ไปพอร์ต 443 ปลายทางอยู่นอกเครือข่ายตนเอง แพ็กเก็ตจึงถูกส่งไปที่ Gateway A ซึ่งประมวลผลตามสถาปัตยกรรม IPsec ใน RFC 4301 แล้ว Gateway B ทำขั้นตอนย้อนกลับ

• ค้นหาเส้นทาง: Gateway A พบว่าเครือข่าย 10.20.20.0/24 ต้องออกทางอินเทอร์เฟซอุโมงค์เสมือน
• ตรวจนโยบาย: ฐานข้อมูลนโยบายความปลอดภัย (SPD) ระบุว่าทราฟฟิกนี้ต้องได้รับการปกป้อง (PROTECT)
• ค้นหา SA: ฐานข้อมูล Security Association (SAD) ให้กุญแจ อัลกอริทึม และหมายเลข SPI ของ Child SA ขาออก
• ห่อแพ็กเก็ต: เข้ารหัสแพ็กเก็ตภายในทั้งก้อน เพิ่ม ESP Header, ESP Trailer และค่าตรวจสอบความถูกต้อง (ICV) แล้วเติม Header ชั้นนอกจาก 203.0.113.10 ไปยัง 198.51.100.20
• ข้ามอินเทอร์เน็ต: เราเตอร์ระหว่างทางเห็นเฉพาะ Header ชั้นนอก ซึ่งเป็น ESP แบบปกติ (IP Protocol 50) หรือ ESP ห่อใน UDP พอร์ต 4500 เมื่อใช้ NAT-T
• แกะแพ็กเก็ต: Gateway B หา SA ขาเข้าจาก SPI ตรวจ ICV และหน้าต่างป้องกันการส่งซ้ำ ถอดรหัส ตรวจนโยบาย Firewall แล้วส่งแพ็กเก็ตต้นฉบับไปยัง 10.20.20.20

ขากลับและความสมมาตรของเส้นทาง

เซิร์ฟเวอร์ B ตอบกลับจาก 10.20.20.20 ไปยัง 10.10.10.11 แพ็กเก็ตตอบกลับต้องไปถึง Gateway B ได้ ไม่ว่าจะเพราะ Gateway B เป็น Default Gateway ของเซิร์ฟเวอร์ หรือเพราะเซิร์ฟเวอร์มีเส้นทางเฉพาะไปยัง 10.10.10.0/24 ที่ชี้มาที่ Gateway B

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

ระนาบควบคุม (IKE) และระนาบข้อมูล (ESP)

ระนาบควบคุมคือ IKE ซึ่งปัจจุบันใช้ IKEv2 ทำหน้าที่ยืนยันตัวตนของทั้งสองฝั่ง แลกเปลี่ยน Diffie-Hellman ตกลงอัลกอริทึมและ Traffic Selector ตลอดจนสร้าง เปลี่ยนกุญแจ และลบ Security Association โดย IKE ใช้ UDP พอร์ต 500 และเปลี่ยนไปใช้ UDP พอร์ต 4500 เมื่อตรวจพบ NAT

ระนาบข้อมูลคือ ESP (Encapsulating Security Payload, IP Protocol 50, RFC 4303) ให้ทั้งการรักษาความลับ การยืนยันแหล่งที่มา ความถูกต้อง และการป้องกันการส่งซ้ำของแต่ละแพ็กเก็ต ส่วน AH (Authentication Header, IP Protocol 51) ให้ความถูกต้องโดยไม่เข้ารหัส แต่ AH ครอบคลุมฟิลด์ใน IP Header ชั้นนอกด้วย จึงใช้ไม่ได้เมื่อมี NAT แก้ไขที่อยู่ ปัจจุบันจึงแทบไม่มีการใช้ AH

IKE SA, Child SA, SPD และ SAD

โครงสร้างข้อมูลสี่อย่างขับเคลื่อนการทำงานของ IPsec การรู้ว่าปัญหาอยู่ที่ส่วนใดช่วยจำกัดขอบเขตการแก้ปัญหาได้เร็วขึ้นมาก

• IKE SA: ช่องทางควบคุมที่ยืนยันตัวตนและเข้ารหัสแล้วระหว่างสองฝั่ง ใช้สำหรับเปลี่ยนกุญแจ ตรวจสอบว่าอีกฝ่ายยังทำงานอยู่ และเจรจา Child SA
• Child SA (IPsec SA): ชุดกุญแจและอัลกอริทึมที่ใช้กับข้อมูลจริง ทำงานทิศทางเดียวและถูกสร้างเป็นคู่ คือขาเข้าหนึ่งตัวและขาออกหนึ่งตัว แต่ละตัวมี SPI ของตนเอง
• ฐานข้อมูลนโยบาย (SPD): กฎที่อ้างอิงที่อยู่ โปรโตคอล และพอร์ต พร้อมการกระทำสามแบบ คือ ปกป้อง (PROTECT) ปล่อยผ่าน (BYPASS) หรือทิ้ง (DISCARD)
• ฐานข้อมูล SA (SAD): เก็บ SA ที่ใช้งานอยู่ ค้นหาแพ็กเก็ตขาเข้าด้วย SPI และเก็บกุญแจ อัลกอริทึม และตัวนับป้องกันการส่งซ้ำ

Tunnel Mode เทียบกับ Transport Mode

Tunnel Mode เข้ารหัสแพ็กเก็ต IP ต้นฉบับทั้งก้อนและเพิ่ม IP Header ชั้นนอกใหม่ เป็นตัวเลือกปกติของ Site-to-Site VPN เพราะที่อยู่ภายในถูกซ่อนอยู่ในส่วนที่เข้ารหัส และ IP ส่วนตัวสามารถข้ามอินเทอร์เน็ตได้

Transport Mode แทรก ESP Header ต่อจาก IP Header เดิม และปกป้องเฉพาะข้อมูลส่วนบรรทุก ที่อยู่ต้นฉบับจึงยังมองเห็นได้ เหมาะกับการปกป้องระหว่างเครื่องต่อเครื่อง และมักใช้เป็นชั้นล่างของ GRE over IPsec หรือ L2TP/IPsec ซึ่งมีโปรโตคอลอื่นทำหน้าที่ Header ของอุโมงค์อยู่แล้ว

IKE_SA_INIT, IKE_AUTH และ CREATE_CHILD_SA

ในกรณีปกติ อุโมงค์พร้อมใช้งานหลังการแลกเปลี่ยนแบบถามตอบสองรอบ รวมสี่ข้อความ แต่อาจมีรอบเพิ่มเมื่อมี Cookie Challenge เมื่อกลุ่ม Diffie-Hellman ถูกปฏิเสธ เมื่อใช้ EAP หรือเมื่อมีการแลกเปลี่ยนขั้นกลางเพิ่มเติม สี่ข้อความจึงเป็นจำนวนขั้นต่ำ ไม่ใช่กฎตายตัว

• IKE_SA_INIT: ทั้งสองฝั่งตกลงอัลกอริทึม (การเข้ารหัส ความถูกต้อง PRF และกลุ่ม Diffie-Hellman) แลก Nonce และค่าสำหรับสร้างกุญแจ ตรวจจับ NAT และสร้างกุญแจที่ใช้ปกป้อง IKE SA
• IKE_AUTH: ภายในช่องทางที่ปกป้องแล้ว แต่ละฝั่งส่งตัวตนของตน (IDi และ IDr) พิสูจน์ด้วยลายเซ็นจากใบรับรองหรือกุญแจที่ตกลงไว้ล่วงหน้า และเจรจา Traffic Selector สำหรับ Child SA คู่แรก
• CREATE_CHILD_SA: ใช้ภายหลังเพื่อเพิ่ม Child SA หรือเปลี่ยนกุญแจของ SA เดิมโดยไม่ต้องยืนยันตัวตนใหม่ทั้งหมด

Pre-Shared Key เทียบกับใบรับรอง X.509

Pre-Shared Key (PSK) คือรหัสลับชุดเดียวกันที่ตั้งไว้ทั้งสองฝั่ง ใช้ง่ายเมื่อมีอุโมงค์ไม่กี่เส้น แต่การใช้กุญแจเดียวกันกับหลายสาขาทำให้เพิกถอนสิทธิ์รายสาขาไม่ได้ และกุญแจที่อ่อนแอเสี่ยงต่อการคาดเดาหรือรั่วไหล จึงควรใช้ค่าแบบสุ่มที่มีความยาวเพียงพอและแยกกุญแจตามคู่เชื่อมต่อ

ใบรับรองดิจิทัลทำให้แต่ละ Gateway มีกุญแจส่วนตัวของตนเองพร้อมใบรับรองจากผู้ออกใบรับรองที่เชื่อถือ ขยายระบบได้ดีกว่า ไม่ต้องแจกจ่ายรหัสลับร่วม และเพิกถอนสิทธิ์สาขาใดสาขาหนึ่งผ่าน CRL หรือ OCSP ได้โดยไม่กระทบสาขาอื่น แลกกับภาระการดูแล PKI ทั้งการออก การต่ออายุ และการตรวจสอบการเพิกถอน

อัลกอริทึม: การเข้ารหัส ความถูกต้อง PRF และ Diffie-Hellman

RFC 8247 (สำหรับ IKEv2) และ RFC 8221 (สำหรับ ESP) ระบุว่าอัลกอริทึมใดต้องรองรับ ควรรองรับ หรือไม่ควรใช้ และมีการปรับปรุงเป็นระยะ ควรตรวจสอบฉบับล่าสุดและข้อกำหนดด้านการกำกับดูแลขององค์กร แทนการคัดลอกรายการอัลกอริทึมเก่ามาใช้

• การเข้ารหัส: อัลกอริทึมแบบ AEAD เช่น AES-GCM รวมการเข้ารหัสและการตรวจความถูกต้องไว้ในขั้นตอนเดียว และเป็นตัวเลือกหลักในปัจจุบัน
• ความถูกต้อง: ต้องกำหนดแยกเฉพาะเมื่อใช้อัลกอริทึมที่ไม่ใช่ AEAD เช่น AES-CBC ร่วมกับ HMAC-SHA2-256-128
• PRF: ใช้สร้างกุญแจจากผลลัพธ์ Diffie-Hellman และ Nonce เช่น PRF_HMAC_SHA2_256
• กลุ่ม Diffie-Hellman: กลุ่ม 14 (MODP 2048 บิต) และกลุ่มเส้นโค้งวงรี เช่น 19, 20 หรือ Curve25519 (กลุ่ม 31) เป็นตัวเลือกที่พบบ่อย ส่วนกลุ่มเก่าขนาดเล็กอย่าง 1, 2 และ 5 ควรปิดการใช้งาน

การเปลี่ยนกุญแจ การยืนยันตัวตนซ้ำ และ Perfect Forward Secrecy

การเปลี่ยนกุญแจ (Rekey) สร้างกุญแจใหม่และ SA ใหม่ก่อนที่ SA เดิมจะหมดอายุ ทราฟฟิกจึงไหลต่อได้โดยไม่สะดุด ส่วนการยืนยันตัวตนซ้ำ (Reauthentication) ทำมากกว่านั้น คือสร้าง IKE SA ใหม่และตรวจสอบข้อมูลประจำตัว เช่น ใบรับรอง อีกครั้ง

Perfect Forward Secrecy (PFS) ทำการแลกเปลี่ยน Diffie-Hellman ใหม่ทุกครั้งที่สร้างหรือเปลี่ยนกุญแจ Child SA ช่วยจำกัดความเสียหายเมื่อกุญแจรั่วในภายหลัง ทราฟฟิกที่ปกป้องด้วยกุญแจจากการแลกเปลี่ยนครั้งก่อนซึ่งเป็นอิสระต่อกัน จะไม่ถูกเปิดเผยเพียงเพราะกุญแจชุดใหม่หรือข้อมูลประจำตัวระยะยาวรั่ว PFS จึงเป็นมาตรการลดความเสี่ยงที่แข็งแรง แต่ไม่ใช่หลักประกันต่อการโจมตีทุกรูปแบบ

ค่าที่ต้องตรงกันทั้งสองฝั่งและค่าที่เป็นนโยบายเฉพาะเครื่อง

ค่าบางอย่างต้องเข้ากันได้ทั้งสองฝั่ง มิฉะนั้นการเจรจาจะล้มเหลว ได้แก่ ชุดอัลกอริทึมที่ตรงกันอย่างน้อยหนึ่งชุด ตัวตนที่อีกฝ่ายยอมรับ ข้อมูลประจำตัวและสายใบรับรองที่ถูกต้อง และ Traffic Selector ที่ฝั่งตอบรับยอมรับ ส่วนค่าอื่นเป็นนโยบายเฉพาะเครื่อง เช่น อายุของ SA ซึ่งต่างกันได้เพราะฝั่งที่ตั้งอายุสั้นกว่าจะเปลี่ยนกุญแจก่อน รวมถึงรอบการตรวจสอบอีกฝ่ายและการจัดคิว

OpenVPN: ช่องทางควบคุม TLS และช่องทางข้อมูล

OpenVPN ใช้เซสชัน TLS เป็นช่องทางควบคุมสำหรับยืนยันตัวตนและแลกกุญแจ และมีช่องทางข้อมูลแยกต่างหากที่เข้ารหัสแพ็กเก็ตในอุโมงค์ด้วยกุญแจที่ได้จากเซสชันนั้น

ควรใช้ UDP เป็นหลัก เมื่อ OpenVPN ทำงานบน TCP แล้ว Underlay สูญเสียแพ็กเก็ต ทั้ง TCP ภายในและ TCP ภายนอกจะส่งซ้ำและชะลอการส่งพร้อมกัน ปัญหานี้มักเรียกว่า TCP Meltdown และอาจทำให้ความเร็วลดลงอย่างรุนแรง จึงควรใช้โหมด TCP เฉพาะเครือข่ายที่บล็อก UDP

WireGuard: การกำหนดเส้นทางด้วยกุญแจ (Cryptokey Routing)

WireGuard ตามเอกสาร Whitepaper ของ Jason Donenfeld ใช้ชุดวิทยาการเข้ารหัสสมัยใหม่แบบตายตัว (Noise Protocol Framework, Curve25519, ChaCha20-Poly1305 และ BLAKE2s) โดยไม่มีการเจรจาอัลกอริทึม แต่ละฝั่งถูกระบุด้วยกุญแจสาธารณะและรายการ AllowedIPs เมื่อส่ง ที่อยู่ปลายทางจะเป็นตัวเลือกว่าส่งให้ใคร เมื่อรับ ที่อยู่ต้นทางหลังถอดรหัสต้องอยู่ใน AllowedIPs ของฝั่งนั้น มิฉะนั้นแพ็กเก็ตจะถูกทิ้ง

เนื่องจาก WireGuard ไม่มีไดเรกทอรีผู้ใช้ ผู้ออกใบรับรอง หรือการส่งค่าตั้งจากศูนย์กลางในตัว การใช้งานระดับองค์กรจึงมักเพิ่มระบบควบคุมสำหรับแจกกุญแจ Single Sign-On และตรวจสภาพอุปกรณ์ และเพราะอัลกอริทึมเป็นแบบตายตัว องค์กรที่มีรายการอัลกอริทึมบังคับควรตรวจสอบว่า WireGuard เป็นไปตามข้อกำหนดนั้นหรือไม่

VPN แบบ TLS และโปรโตคอลรุ่นเก่า

คำว่า "SSL VPN" เป็นชื่อทางการตลาด ไม่ใช่ชื่อโปรโตคอล สิ่งสำคัญคือการตั้งค่า TLS เบื้องหลัง ควรอนุญาตเฉพาะ TLS 1.2 และ TLS 1.3 ตาม RFC 8996 ที่เลิกใช้ TLS 1.0 และ 1.1 และตามคำแนะนำใน RFC 9325

ควรปลดระวางโปรโตคอลรุ่นเก่า PPTP อาศัยการยืนยันตัวตน MS-CHAPv2 ซึ่งถือว่าไม่ปลอดภัยแล้ว จึงไม่ควรนำมาใช้ ส่วน L2TP เพียงอย่างเดียวไม่มีการเข้ารหัส ควรใช้ในรูป L2TP/IPsec เท่านั้นหากจำเป็นต้องใช้

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

Full Tunnel แทนที่ Default Route ของเครื่องลูกข่าย (0.0.0.0/0 และ ::/0 สำหรับ IPv6) ทำให้ทราฟฟิกทั้งหมด รวมถึงการท่องเว็บ วิ่งผ่าน Gateway ขององค์กร ข้อดีคือการตรวจสอบ กรองเนื้อหา ป้องกันข้อมูลรั่วไหล และเก็บบันทึกจากศูนย์กลาง ข้อเสียคือใช้แบนด์วิดท์ขององค์กรมากขึ้น และเพิ่มความหน่วงในการใช้บริการ Cloud เพราะทราฟฟิกต้องอ้อมผ่าน Gateway ก่อนออกอินเทอร์เน็ต

Split Tunnel เพิ่มเส้นทางเฉพาะเครือข่ายขององค์กร เช่น 10.0.0.0/8 หรือ 172.16.0.0/12 ส่วนทราฟฟิกอื่นออกทาง ISP ในพื้นที่โดยตรง ช่วยประหยัดแบนด์วิดท์และให้ผู้ใช้เข้าบริการ Cloud ได้ตรง แต่เครื่องจะเชื่อมทั้งเครือข่ายองค์กรและอินเทอร์เน็ตพร้อมกันโดยศูนย์กลางมองเห็นน้อยลง แนวทาง Remote Access VPN ของ NSA และ CISA ถือว่า Split Tunnel เป็นความเสี่ยงที่ต้องมีเหตุผลรองรับและต้องชดเชยด้วยมาตรการที่ปลายทาง

Policy-based VPN เทียบกับ Route-based VPN

Policy-based VPN (แบบ Crypto Map ดั้งเดิม) จับคู่ทราฟฟิกกับ Selector เช่น เครือข่ายต้นทางและเครือข่ายปลายทาง แล้วเข้ารหัสทุกแพ็กเก็ตที่ตรงเงื่อนไขเมื่อออกจากอินเทอร์เฟซจริง เหมาะกับเครือข่ายคู่เดียวหรือสองคู่ที่คงที่ แต่การเพิ่มเครือข่ายต้องแก้ Selector ทั้งสองฝั่ง ตัวนับรายอุโมงค์มีจำกัด และโดยทั่วไปใช้โปรโตคอลเส้นทางแบบไดนามิกไม่ได้

Route-based VPN ผูก IPsec เข้ากับอินเทอร์เฟซอุโมงค์เสมือน (VTI) หรืออินเทอร์เฟซ GRE ทราฟฟิกใดที่ตารางเส้นทางส่งเข้าอินเทอร์เฟซนั้นจะถูกเข้ารหัส จึงรองรับ BGP หรือ OSPF บนอุโมงค์ อุโมงค์สำรองที่สลับเส้นทางอัตโนมัติ Multicast ในอุปกรณ์ที่รองรับ และนโยบาย Firewall แบบโซนบนอินเทอร์เฟซอุโมงค์ งานเชื่อมหลายสาขาและ Cloud ส่วนใหญ่จึงใช้แบบ Route-based

DNS ภายใน การรั่วของ DNS และเครื่องที่ใช้ IPv4 กับ IPv6 พร้อมกัน

การแปลงชื่อต้องได้รับความใส่ใจเท่ากับเส้นทาง เพราะอุโมงค์ที่ถูกต้องจะไร้ประโยชน์ หากเครื่องลูกข่ายหาบริการภายในไม่เจอ หรือส่งคำถาม DNS ไปที่อื่นโดยไม่รู้ตัว

• ชื่อภายใน: เครื่องลูกข่ายระยะไกลต้องได้รับ DNS Server ขององค์กรหรือการส่งต่อแบบมีเงื่อนไข เพื่อให้ชื่ออย่าง app.corp.example แปลงเป็นที่อยู่ภายในได้
• DNS รั่ว: ในแบบ Full Tunnel เครื่องที่ยังถาม DNS จากเราเตอร์ที่บ้านหรือ ISP จะเปิดเผยว่าเข้าเว็บใดบ้าง นโยบายของระบบปฏิบัติการ เช่น Name Resolution Policy Table (NRPT) ของ Windows ช่วยบังคับให้คำถามที่ถูกต้องวิ่งผ่าน VPN
• IPv6: หากอุโมงค์ส่งเฉพาะ IPv4 แต่เครือข่ายในพื้นที่ให้ IPv6 ด้วย ทราฟฟิก IPv6 อาจไม่ผ่านอุโมงค์เลย ต้องส่ง IPv6 ผ่าน VPN ด้วย หรือบล็อก IPv6 ที่เครื่องลูกข่ายระหว่างเชื่อมต่อ

NAT Traversal (NAT-T) สำหรับ ESP

PAT หรือ NAPT ทำให้เครื่องภายในหลายเครื่องใช้ IP สาธารณะเดียวกันได้ด้วยการติดตามหมายเลขพอร์ต TCP และ UDP แต่ ESP เป็นโปรโตคอล IP ของตัวเองและไม่มีพอร์ต อุปกรณ์ PAT จึงสร้างการจับคู่ที่เชื่อถือได้ไม่ได้ และทราฟฟิกขากลับจะสูญหาย

IKEv2 ตรวจจับ NAT ระหว่าง IKE_SA_INIT ด้วยข้อมูลตรวจจับ NAT ที่กำหนดใน RFC 7296 หากพบ NAT การสื่อสาร IKE จะย้ายจาก UDP 500 ไป UDP พอร์ต 4500 และแพ็กเก็ต ESP จะถูกห่อใน UDP พอร์ต 4500 ตาม RFC 3948 (ESP-in-UDP) อุปกรณ์ NAT จึงมองเห็นเป็นการสื่อสาร UDP ธรรมดา และมีการส่ง NAT Keepalive เป็นระยะเพื่อไม่ให้การจับคู่หมดอายุเมื่ออุโมงค์ว่าง

การยกเว้น NAT สำหรับทราฟฟิกในอุโมงค์

ระหว่างสาขา เครื่องต่าง ๆ ควรใช้ IP ส่วนตัวจริงของตนเอง เช่น 10.10.10.0/24 ที่สำนักงานใหญ่และ 10.20.20.0/24 ที่สาขา เพื่อให้เส้นทาง บันทึก และนโยบายการเข้าถึงสอดคล้องกัน

Firewall ที่ขอบเครือข่ายมักทำ Source NAT กับทุกอย่างที่ออกอินเทอร์เน็ต หากไม่มีกฎยกเว้น NAT (No-NAT) สำหรับทราฟฟิกระหว่างสาขาที่ถูกประเมินก่อนกฎทั่วไป แพ็กเก็ตจะถูกแปลงเป็น IP สาธารณะ ไม่ตรงกับ Selector หรือนโยบายของอุโมงค์ และไม่เข้าอุโมงค์อย่างถูกต้อง

IP สาธารณะ Double NAT และ CGNAT

อย่างน้อยหนึ่งฝั่งต้องเข้าถึงได้จากภายนอก คือมี IP สาธารณะแบบคงที่ หรือชื่อ Dynamic DNS ที่ติดตาม IP นั้น เพื่อทำหน้าที่ฝั่งตอบรับ อีกฝั่งอยู่หลัง NAT ได้และเป็นฝั่งเริ่มเชื่อมต่อ โดยใช้ NAT Keepalive รักษาการจับคู่ไว้

หากทั้งสองสาขาอยู่หลัง Carrier-Grade NAT (CGNAT ซึ่งมักใช้ช่วง 100.64.0.0/10 ตาม RFC 6598) จะไม่มีฝั่งใดรับการเชื่อมต่อขาเข้าได้ ทางเลือกคือขอ IP สาธารณะจาก ISP ใช้ Relay หรือ Hub บน Cloud ที่ทั้งสองฝั่งเชื่อมออกไปหา หรือใช้บริการ Overlay ที่มีระบบส่งต่อข้อมูลให้

นโยบาย Firewall สองชั้น

ปกป้องอินเทอร์เฟซภายนอกด้วยการอนุญาตเฉพาะสิ่งที่ VPN ต้องใช้ คือ UDP 500, UDP 4500 และ IP Protocol 50 หากไม่ได้ใช้ NAT-T ตลอดเวลา และจำกัดเฉพาะ IP ของอีกฝั่งที่รู้จักเมื่อทำได้ จากนั้นให้ถือว่าทราฟฟิกที่ออกจากอุโมงค์ยังไม่น่าไว้ใจ ตรวจด้วยนโยบายภายในบนอินเทอร์เฟซหรือโซนของอุโมงค์ และอนุญาตเฉพาะปลายทางและพอร์ตที่แต่ละสาขาหรือกลุ่มผู้ใช้จำเป็นต้องใช้

Point-to-Point, Hub-and-Spoke และ Full Mesh

แต่ละโทโพโลยีแลกกันระหว่างประสิทธิภาพของเส้นทางกับจำนวนอุโมงค์ที่ต้องสร้างและดูแล

• Point-to-Point: อุโมงค์เดียวระหว่างสองสถานที่ เช่น ลิงก์สำรองข้อมูลระหว่าง Data Center
• Hub-and-Spoke: ทุกสาขาเชื่อมเฉพาะกับ Hub ส่วนกลาง จัดการนโยบายได้ที่จุดเดียว แต่ทราฟฟิกระหว่างสาขาต้องอ้อมผ่าน Hub (Hairpinning) ทำให้เพิ่มระยะทางและความหน่วง และ Hub กลายเป็นจุดพึ่งพาสำคัญที่ต้องมีระบบสำรอง
• Full Mesh: ทุกสาขามีอุโมงค์ตรงถึงทุกสาขา ได้เส้นทางสั้นที่สุด แต่จำนวนอุโมงค์เพิ่มตามสูตร N(N-1)/2 คือเพิ่มแบบกำลังสองตามจำนวนสาขา เครือข่ายขนาดใหญ่จึงใช้วิธีแบบไดนามิก เช่น DMVPN หรือ SD-WAN ที่สร้างอุโมงค์ตรงเมื่อต้องใช้

สถานการณ์ที่ 1: เชื่อมสาขาแบบ Site-to-Site

ความต้องการ: เชื่อมสำนักงานใหญ่ (10.10.0.0/16) กับสองสาขา (10.20.0.0/16 และ 10.30.0.0/16) สำหรับระบบ ERP และฐานข้อมูล การออกแบบ: ใช้อุโมงค์ IPsec แบบ Route-based กับ IKEv2 เข้ารหัสแบบ AEAD เช่น AES-256-GCM ใช้กลุ่ม Diffie-Hellman แบบเส้นโค้งวงรี ยืนยันตัวตนด้วยใบรับรอง และใช้ BGP บนอินเทอร์เฟซอุโมงค์เพื่อประกาศเครือข่ายอัตโนมัติและสลับเส้นทางเมื่อลิงก์ขัดข้อง

สถานการณ์ที่ 2: Remote Access สำหรับพนักงานเคลื่อนที่

ความต้องการ: พนักงานที่ใช้ Wi-Fi โรงแรมหรือที่สาธารณะต้องเข้าระบบ ERP และไฟล์เซิร์ฟเวอร์ภายใน การออกแบบ: ใช้ IKEv2 กับ EAP หรือบริการ WireGuard หรือ OpenVPN แบบมีระบบจัดการ เชื่อมกับระบบยืนยันตัวตนขององค์กร บังคับใช้การยืนยันตัวตนหลายปัจจัย แยกกลุ่ม IP สำหรับผู้ใช้ เช่น 172.16.100.0/24 ตรวจสภาพอุปกรณ์ และใช้กฎ Firewall ที่ให้แต่ละกลุ่มเข้าถึงเฉพาะแอปพลิเคชันที่จำเป็น

สถานการณ์ที่ 3: เชื่อม Hybrid Cloud

ความต้องการ: การเชื่อมต่อที่ทนทานระหว่าง Data Center ภายในองค์กรกับ VPC หรือ Virtual Network บน Cloud การออกแบบ: ใช้อุโมงค์ IPsec สองเส้นไปยังปลายทาง VPN Gateway ของผู้ให้บริการ Cloud โดยควรมาจากอุปกรณ์หรือ ISP สองชุด ใช้ BGP ทั้งสองอุโมงค์ และใช้คุณสมบัติ BGP ที่ผู้ให้บริการรองรับ เช่น AS-Path Prepending หรือ MED เพื่อกำหนดเส้นทางหลัก พร้อมทำตามเอกสารของผู้ให้บริการเรื่องอัลกอริทึมและขีดจำกัดที่รองรับ

สถานการณ์ที่ 4: เครือข่ายซ้ำกันและการทำ Twice NAT

ความต้องการ: สำนักงานใหญ่ใช้ 10.10.10.0/24 และพันธมิตรที่เพิ่งเชื่อมต่อใช้ช่วงเดียวกัน ทำให้ทั้งสองฝั่งส่งข้อมูลหากันไม่ได้ ทางแก้ถาวรคือเปลี่ยนหมายเลขเครือข่ายฝั่งใดฝั่งหนึ่ง หากยังทำไม่ได้ ให้แสดงแต่ละฝั่งผ่านอุโมงค์เป็นเครือข่ายเสมือนที่ไม่ซ้ำกัน คือสำนักงานใหญ่เป็น 10.110.10.0/24 และพันธมิตรเป็น 10.210.10.0/24 โดย Gateway แปลงทั้งที่อยู่ต้นทางและปลายทาง (Twice NAT)

• เครื่องลูกข่าย A (10.10.10.11) ส่งไปยังที่อยู่เสมือนของพันธมิตร 10.210.10.20
• Gateway A แปลงต้นทางเป็น 10.110.10.11 แล้วส่งเข้าอุโมงค์
• Gateway C แปลงปลายทางเป็นเซิร์ฟเวอร์จริง 10.10.10.20 แล้วส่งต่อ
• เซิร์ฟเวอร์ C ตอบกลับไปยัง 10.110.10.11 และ Gateway C แปลงต้นทางเป็น 10.210.10.20 ก่อนส่งเข้าอุโมงค์
• Gateway A แปลงปลายทางกลับเป็น 10.10.10.11 และส่งคำตอบถึงเครื่องลูกข่าย A

MTU, Path MTU Discovery และการบีบค่า TCP MSS

เส้นทาง Ethernet ทั่วไปรับ MTU ได้ 1,500 ไบต์ การห่อแพ็กเก็ตทำให้แพ็กเก็ตภายในขนาดเต็มใหญ่เกินค่านั้น หากแพ็กเก็ตตั้งบิต DF (ห้ามแบ่งส่วน) เราเตอร์ระหว่างทางจะทิ้งแพ็กเก็ตและควรส่งข้อความ ICMP Fragmentation Needed (IPv4 ชนิด 3 รหัส 4) กลับมา เมื่อ Firewall บล็อกข้อความนี้ Path MTU Discovery จะล้มเหลวและเกิดหลุมดำ คือแพ็กเก็ตเล็ก การ Ping และการเริ่มเชื่อมต่อ TCP ทำงานได้ แต่การโอนไฟล์ใหญ่และการเริ่ม TLS ที่มีใบรับรองขนาดใหญ่กลับค้าง

ตัวอย่างการคำนวณ Overhead ด้านล่างอธิบายสาเหตุ ค่าที่แท้จริงขึ้นกับอัลกอริทึม การใช้ NAT-T รุ่นของ IP และการห่อชั้นอื่น เช่น PPPoE หรือ GRE จึงควรมองเป็นตัวอย่างหนึ่ง ไม่ใช่ค่าคงที่สากล

• IPv4 Header ชั้นนอก 20 ไบต์ และ UDP Header สำหรับ NAT-T อีก 8 ไบต์
• ESP Header (SPI และหมายเลขลำดับ) 8 ไบต์ และ Initialization Vector ของ AES-GCM อีก 8 ไบต์
• ESP Trailer (ความยาวส่วนเติมและ Next Header) 2 ไบต์ บวกส่วนเติม 0 ถึง 3 ไบต์ และ ICV ของ AES-GCM อีก 16 ไบต์
• รวมในตัวอย่างนี้ 62 ถึง 65 ไบต์ แพ็กเก็ตภายในที่ใหญ่ที่สุดบน Underlay 1,500 ไบต์จึงประมาณ 1,435 ไบต์ และ TCP MSS ตามการคำนวณประมาณ 1,395 ไบต์ (หัก IPv4 และ TCP Header รวม 40 ไบต์)
• ในทางปฏิบัติ หลายทีมตั้งค่า MSS ต่ำกว่านั้น ราว 1,350 ถึง 1,380 ไบต์ เพื่อเผื่อ PPPoE (8 ไบต์) GRE, IPv6 ชั้นนอก อัลกอริทึมแบบ CBC หรือ TCP Option ควรวัด MTU ของเส้นทางจริงและยืนยันกับคำแนะนำของผู้ผลิต

ความเร็วและการใช้ฮาร์ดแวร์ช่วยเข้ารหัส

ตัวเลขความเร็ว Firewall ในเอกสารสเปกมักวัดโดยไม่เข้ารหัส ความเร็ว IPsec จะต่ำกว่านั้น และขึ้นกับขนาดแพ็กเก็ต อัลกอริทึม และการมีฮาร์ดแวร์ช่วย เช่น ชุดคำสั่ง AES-NI หรือชิปเข้ารหัสเฉพาะ ควรเลือกขนาด Gateway จากตัวเลข IPsec ของผู้ผลิตที่ขนาดแพ็กเก็ตสมจริง รวมถึงแพ็กเก็ตเสียงขนาดเล็ก ไม่ใช่จากความเร็ว Firewall แบบไม่เข้ารหัส

ความหน่วง การสูญเสียแพ็กเก็ต และการสลับอุโมงค์สำรอง

อุโมงค์ไม่มีทางดีกว่า Underlay ที่รองรับอยู่ ความหน่วงลดความเร็ว TCP ที่ขนาดหน้าต่างเท่าเดิม และการสูญเสียแพ็กเก็ตทำให้ TCP ต้องส่งซ้ำ และทำให้เสียงแบบเรียลไทม์ขาดหาย

การตรวจสอบว่าอีกฝ่ายยังทำงานอยู่ช่วยให้ Gateway รู้เมื่ออีกฝั่งหยุดตอบ IKEv2 มีกลไกนี้ในตัวตาม RFC 7296 ส่วน Dead Peer Detection ใน RFC 3706 เป็นส่วนขยายที่เทียบเท่าสำหรับ IKEv1 เมื่ออีกฝั่งไม่ตอบ Gateway จะลบ SA ที่ค้างอยู่ และในอุโมงค์แบบ Route-based โปรโตคอลเส้นทางแบบไดนามิกหรือ Static Route ที่มีการติดตามสถานะจะย้ายทราฟฟิกไปยังอุโมงค์สำรองหรือ ISP ที่สองได้

สิ่งที่ VPN ไม่ได้ทำ

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

สิทธิ์เท่าที่จำเป็น Zero Trust และ ZTNA

NIST SP 800-207 อธิบายสถาปัตยกรรม Zero Trust ว่าไม่มีความไว้วางใจโดยอัตโนมัติจากตำแหน่งในเครือข่าย และตัดสินสิทธิ์การเข้าถึงทีละคำขอจากตัวตน สภาพอุปกรณ์ และบริบท VPN เป็นองค์ประกอบหนึ่งของสถาปัตยกรรมนี้ได้ แต่ VPN เพียงอย่างเดียวไม่ใช่ Zero Trust

ในทางปฏิบัติหมายถึงการแบ่งเครือข่ายย่อยละเอียด (Microsegmentation) กฎ Firewall รายกลุ่มที่อนุญาตเฉพาะแอปพลิเคชันและพอร์ตที่จำเป็น และสำหรับผู้ใช้ระยะไกลจำนวนมาก ใช้บริการ ZTNA (Zero Trust Network Access) ที่เป็นตัวกลางให้เข้าถึงแอปพลิเคชันทีละตัว แทนการนำอุปกรณ์เข้ามาอยู่ในเครือข่ายภายใน

วงจรชีวิตข้อมูลประจำตัวและการเพิกถอน

กุญแจและใบรับรองต้องมีการกำกับดูแลเช่นเดียวกับรหัสผ่าน

• เก็บกุญแจส่วนตัวของ Gateway ในที่เก็บที่ส่งออกไม่ได้ หรือในโมดูลความปลอดภัยฮาร์ดแวร์ (HSM) เมื่ออุปกรณ์รองรับ
• ติดตามวันหมดอายุของใบรับรองและต่ออายุอัตโนมัติ เพื่อไม่ให้อุโมงค์ล่มโดยไม่คาดคิด
• ตรวจสถานะการเพิกถอนผ่าน CRL หรือ OCSP เพื่อให้พนักงานที่ลาออกและอุปกรณ์ที่สูญหายหรือถูกเจาะหมดสิทธิ์โดยเร็ว

การเสริมความแข็งแรง Gateway การตรวจสภาพอุปกรณ์ และการเก็บบันทึก

VPN Gateway ที่เปิดรับจากอินเทอร์เน็ตเป็นเป้าหมายบ่อย และช่องโหว่ที่เปิดเผยแล้วมักถูกนำไปโจมตีอย่างรวดเร็ว แนวทางการเลือกและเสริมความแข็งแรง Remote Access VPN ของ NSA และ CISA (กันยายน 2021) และ NIST SP 800-77 Rev. 1 แนะนำมาตรการดังนี้

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

การเชื่อม PBX หลายสาขา

การเชื่อม PBX ของสำนักงานใหญ่และสาขาผ่าน VPN ทำให้โทรหาเบอร์ภายในข้ามสาขาได้และรวม Trunk ไว้ที่ศูนย์กลาง ตัวอย่างเช่น PBX สำนักงานใหญ่ที่ 10.10.10.50 สร้าง SIP Trunk กับ PBX สาขาที่ 10.20.20.50 ผ่านอุโมงค์ IPsec ระหว่าง Gateway ของทั้งสองแห่ง สายระหว่างสาขาจึงวิ่งอยู่บนเครือข่ายส่วนตัว

สัญญาณ SIP และเสียง RTP เป็นคนละเส้นทาง

SIP (RFC 3261) ใช้เริ่มและวางสาย โดยทั่วไปใช้ UDP หรือ TCP พอร์ต 5060 จากนั้น RTP (RFC 3550) นำเสียงไปบน UDP พอร์ตแบบไดนามิกที่ตกลงกันใน SDP ช่วงพอร์ตกำหนดโดย PBX หรือโทรศัพท์แต่ละรุ่น หลายระบบตั้งค่าเริ่มต้นไว้ราว 10000 ถึง 20000

ปัญหาคลาสสิกคือเสียงทางเดียวหรือไม่มีเสียง โทรติดและรับสายได้แต่ไม่มีใครได้ยินอะไร สาเหตุที่พบบ่อยคือ นโยบาย Firewall หรืออุโมงค์อนุญาต SIP แต่ไม่อนุญาตช่วงพอร์ต RTP ข้อมูล SDP ประกาศที่อยู่ที่อีกฝั่งเข้าถึงไม่ได้ หรือ SIP ALG บน Gateway แก้ไขแพ็กเก็ตผิดพลาด

คุณภาพเสียง: QoS, DSCP และเส้นทาง

เสียงส่งแพ็กเก็ตเล็กเป็นช่วงเวลาคงที่ เช่น ทุก 20 มิลลิวินาทีสำหรับ G.711 มาตรฐาน ITU-T G.114 แนะนำให้ความหน่วงทางเดียวไม่เกินประมาณ 150 มิลลิวินาทีเพื่อการสนทนาที่ดี ส่วน Jitter ต่ำกว่าราว 30 มิลลิวินาทีและการสูญเสียแพ็กเก็ตต่ำกว่าราว 1 เปอร์เซ็นต์เป็นเป้าหมายทางวิศวกรรมที่ใช้กันทั่วไป ไม่ใช่ขีดจำกัดอย่างเป็นทางการ

ควรติดป้าย DSCP EF (Expedited Forwarding ค่า 46) ให้ RTP ตรวจว่า Gateway คัดลอกค่า DSCP ชั้นในไปยัง Header ชั้นนอกของอุโมงค์ และจัดลำดับความสำคัญในคิวขาออก QoS ได้ผลเฉพาะบนลิงก์ที่เราควบคุมหรือเมื่อผู้ให้บริการยอมรับป้ายนั้น อินเทอร์เน็ตสาธารณะโดยทั่วไปไม่สนใจป้าย DSCP นอกจากนี้ การจัดคิวลำดับความสำคัญหลังเข้ารหัสอาจทำให้ลำดับแพ็กเก็ตสลับกัน จึงควรตรวจว่าหน้าต่างป้องกันการส่งซ้ำกว้างพอบนลิงก์ที่มีทราฟฟิกหนาแน่น