PersistentKeepalive ของ WireGuard ควรตั้งอย่างไร

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

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

PersistentKeepalive คืออะไรกันแน่

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

PersistentKeepalive เป็นค่าตั้งเสริมระดับ peer มีหน่วยเป็นวินาที ถ้าตั้งเป็น 25 เมื่อ peer ไม่ได้ส่งอะไรเลยเป็นเวลา 25 วินาที มันจะส่งแพ็กเก็ตเปล่าที่ผ่านการยืนยันตัวตนไปยังอีกฝั่ง แพ็กเก็ตนี้ไม่มีข้อมูลผู้ใช้ หน้าที่เดียวของมันคือให้อุปกรณ์ทุกตัวระหว่างทางที่จับเวลาไว้ได้เห็นว่าเส้นทางนี้ยังมีการใช้งานอยู่

ตัวอย่างการตั้งค่าฝั่งไคลเอนต์แบบสั้น ๆ เป็นดังนี้

[Peer]
PublicKey = (public key ของเซิร์ฟเวอร์)
Endpoint = vpn.example.net:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

ค่า 0 หมายถึงปิด และ 0 คือค่าเริ่มต้น ค่าตั้งแต่ 1 ถึง 65535 คือเปิดและส่งตามช่วงเวลานั้น คนส่วนใหญ่ใช้ 25 ซึ่งเป็นค่าที่เอกสารของโครงการ WireGuard แนะนำสำหรับ peer ที่อยู่หลัง NAT และด้านล่างเราจะอธิบายว่าทำไม 25 จึงเป็นจุดประนีประนอมที่ดี

อย่าสับสนกับพฤติกรรมในตัวของ WireGuard อยู่แล้ว ตัวโปรโตคอลจะส่ง keepalive สั้น ๆ เองหลังจากได้รับข้อมูลแล้วไม่มีอะไรจะตอบกลับประมาณ 10 วินาที เพื่อให้ผู้ส่งรู้ว่าอุโมงค์ยังปกติ แต่แบบนั้นเกิดเฉพาะหลังมีข้อมูลวิ่งมาแล้ว ส่วน PersistentKeepalive คือค่าที่ทำให้ peer เป็นฝ่ายส่งก่อน และส่งต่อเนื่องแม้ทุกอย่างจะเงียบมานานแล้ว

ทำไมอุโมงค์ที่ว่างจึงตาย เรื่องของตัวจับเวลา NAT และไฟร์วอลล์

เราเตอร์ที่บ้าน เครือข่ายมือถือ และไฟร์วอลล์ของออฟฟิศเกือบทั้งหมดทำ NAT หรือการแปลงที่อยู่เครือข่าย เมื่อมือถือของคุณส่งแพ็กเก็ต UDP ออกไป เราเตอร์จะสร้างรายการชั่วคราวในตารางว่า "คำตอบจากเซิร์ฟเวอร์นั้นที่พอร์ตนั้นเป็นของอุปกรณ์เครื่องนี้" รายการนี้เองที่ทำให้แพ็กเก็ตขากลับหาทางกลับมาหาคุณได้

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

เมื่อรายการหายไป อาจเกิดสองอย่าง

1. แพ็กเก็ตขาออกของคุณยังไปได้ ครั้งถัดไปที่คุณส่งอะไรสักอย่าง เราเตอร์ก็สร้างการแมปใหม่ อาจเป็นพอร์ตด้านนอกคนละเลข WireGuard รับมือเรื่องนี้ได้ดี เพราะเรียนรู้ที่อยู่ใหม่ของ peer จากแพ็กเก็ตที่ยืนยันตัวตนแล้ว
2. แพ็กเก็ตขาเข้าถูกทิ้ง ถ้าอีกฝั่งต้องส่งก่อน เช่น เซิร์ฟเวอร์ที่จะส่งข้อมูลมายังโน้ตบุ๊กของคุณ เราเตอร์ไม่มีรายการรองรับจึงทิ้งแพ็กเก็ตนั้นไป จากฝั่งคุณ อุโมงค์จึงดูเหมือนตายจนกว่าคุณจะส่งอะไรออกไปเอง

กรณีที่สองคือสิ่งที่ทำให้ปวดหัว ข้อความแชทมาช้า รีโมตเดสก์ท็อปไม่ตื่น มือถือไม่ได้รับสายผ่านอุโมงค์ แล้วปัญหาก็หายทันทีที่คุณเปิดหน้าเว็บ นั่นคือลายเซ็นของการแมป NAT ที่หมดอายุ และ keepalive ป้องกันได้โดยต่ออายุรายการก่อนที่ตัวจับเวลาจะหมด

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

ใครต้องตั้ง และใครไม่ต้อง

กฎจำง่าย ๆ คือ ตั้ง PersistentKeepalive ที่ peer ซึ่งอยู่หลัง NAT และต้องติดต่อเข้าได้ขณะว่าง

สถานการณ์	ควรตั้ง keepalive ไหม	เหตุผล
มือถือหรือโน้ตบุ๊กต่อออกไปหาเซิร์ฟเวอร์ VPN ใช้เล่นเว็บเป็นหลัก	มักไม่จำเป็น	ทราฟฟิกของคุณเองช่วยต่ออายุการแมปอยู่แล้ว
โน้ตบุ๊กที่ต้องรับข้อมูลที่ถูกส่งมา ขณะหน้าจอไม่ได้ใช้งาน	ควรตั้งที่โน้ตบุ๊ก	เซิร์ฟเวอร์เข้าถึงคุณไม่ได้เมื่อการแมปหมดอายุ
เซิร์ฟเวอร์ในบ้านหรือ NAS หลังเราเตอร์ที่ต้องเข้าถึงจากข้างนอกผ่านอุโมงค์	ควรตั้งที่อุปกรณ์หลัง NAT	ต้องเปิดเส้นทางไว้ตลอด
เซิร์ฟเวอร์ที่มี IP สาธารณะคงที่	โดยปกติไม่ต้อง	ไม่มีอะไรด้านหน้าที่ลืมการแมป
สอง peer อยู่หลัง NAT ทั้งคู่และเชื่อมผ่าน peer สาธารณะ	ตั้งทั้งสองฝั่งไปยัง peer สาธารณะ	แต่ละฝั่งต้องรักษาการแมปของตัวเอง
อุโมงค์ที่คุณเปิดใช้เป็นช่วงสั้น ๆ เอง	มักไม่ต้อง	ทุกครั้งที่เริ่มใหม่จะได้การแมปใหม่

สังเกตว่า keepalive แก้เรื่องการเข้าถึงได้ ไม่ใช่เรื่องความเร็ว หาก VPN ช้า ให้ดูทำไม VPN ถึงช้าแทน

เลือกค่าอย่างไร ทำไมจึงเป็น 25 วินาที

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

• ยาวเกินไป ถ้าตั้ง 120 วินาที คุณอาจชนะเราเตอร์ที่เก็บการแมป 180 วินาที แต่แพ้เราเตอร์ที่ลืมใน 30 วินาที อุโมงค์จะใช้ได้บางเครือข่ายและพังบางเครือข่าย ซึ่งเป็นรูปแบบที่ตามแก้ยากที่สุด
• สั้นเกินไป ถ้าตั้ง 5 วินาที อุโมงค์รอดเกือบทุกที่ แต่คุณส่งแพ็กเก็ตพิเศษทุก 5 วินาที ตลอด 24 ชั่วโมง มือถือต้องปลุกวิทยุหลายร้อยครั้งต่อชั่วโมงโดยไม่จำเป็น
• ประมาณ 25 ต่ำกว่าตัวจับเวลา 30 วินาทีที่อุปกรณ์บางตัวใช้กับ UDP ที่ไม่มีการตอบกลับ แต่ก็ห่างพอที่ต้นทุนต่ำ ถ้าเจอเครือข่ายดื้อที่ยังตัดอยู่ ลอง 15 หรือ 20 ก็สมเหตุสมผล การลดต่ำกว่านั้นแทบไม่คุ้ม

ลองดูตัวอย่าง สมมติโน้ตบุ๊กที่ร้านกาแฟอยู่หลังเราเตอร์ที่เก็บการแมป UDP 60 วินาที ถ้าปิด keepalive คุณเปิดเอกสารแล้ววางโน้ตบุ๊กไว้สองนาที จากนั้นเพื่อนร่วมงานพยายามเข้าบริการที่คุณโฮสต์ผ่านอุโมงค์ การแมปหมดอายุตั้งแต่วินาทีที่ 60 เขาจึงติดต่อไม่ได้ แต่ถ้าตั้ง keepalive 25 การแมปจะถูกต่ออายุที่วินาทีที่ 25, 50, 75 และต่อไปเรื่อย ๆ จึงไม่เคยหมดอายุ เพื่อนร่วมงานเชื่อมต่อได้ทันที

ต้นทุนดาต้าคำนวณง่าย แพ็กเก็ต keepalive มีขนาดเล็ก ประมาณไม่กี่สิบไบต์เมื่อรวมส่วนหัว IP และ UDP หนึ่งแพ็กเก็ตทุก 25 วินาทีเท่ากับราว 3,456 แพ็กเก็ตต่อวัน ถ้าแพ็กเก็ตละราว 100 ไบต์ ก็ประมาณ 350 KB ต่อวัน ซึ่งน้อยกว่าการเปิดเว็บหนึ่งหน้า แพ็กเกจดาต้ามือถือจึงไม่ถูกกินเพราะเรื่องนี้

ต้นทุนที่ต้องแลก แบตเตอรี่ ความเป็นส่วนตัว และสัญญาณรบกวน

keepalive ถูกแต่ไม่ฟรี ควรรู้ข้อแลกเปลี่ยนดังนี้

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

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

สัญญาณรบกวนบนลิงก์แคบ บนลิงก์ที่จำกัดมาก เช่น ดาวเทียมแบบคิดตามปริมาณหรืออินเทอร์เน็ตบนเครื่องบิน แพ็กเก็ตเล็ก ๆ ที่ส่งเป็นระยะก็สะสมในสายตาผู้ให้บริการ ถ้าอยู่บนลิงก์แบบนี้ ให้เปิด keepalive เฉพาะตอนที่ต้องการให้ติดต่อเข้าได้จริง

แก้ปัญหา keepalive คือคำตอบที่ถูกหรือไม่

ก่อนแก้ไขอะไร ให้ตรวจว่าอาการตรงกัน keepalive ช่วยได้เมื่อ

• อุโมงค์ใช้ได้หลังเพิ่งเชื่อมต่อ แล้วเงียบไปหลังไม่มีการใช้งานช่วงหนึ่ง
• อุโมงค์กลับมาทันทีที่คุณส่งทราฟฟิกเอง เช่น เปิดหน้าเว็บหรือสั่ง ping
• ค่าตั้งเดิมใช้ได้ที่บ้าน แต่พังที่ร้านกาแฟ โรงแรม หรือเครือข่ายมือถือบางแห่ง
• เซิร์ฟเวอร์แสดงเวลา handshake ล่าสุดของ peer ที่เก่ามาก ทั้งที่แอปบอกว่าเชื่อมต่ออยู่

ลองตามลำดับนี้

1. ตรวจพื้นฐานก่อน อุปกรณ์ออนไลน์จริงไหม บัญชีหรือแพ็กเกจยังไม่หมดอายุหรือเปล่า ข้อมูลล็อกอินถูกต้องไหม คู่มือปรับปรุงความเสถียรของการเชื่อมต่อ VPNครอบคลุมเรื่องเหล่านี้
2. ดู handshake ล่าสุด เครื่องมือของ WireGuard แสดงเวลาตั้งแต่ handshake ครั้งล่าสุด ค่าที่เก่ามากโดยไม่มีทราฟฟิกชี้ไปที่ปัญหาการแมปหรือตัวกรอง ไม่ใช่คีย์ผิด
3. เปิด PersistentKeepalive = 25 ที่ฝั่งหลัง NAT แล้วเชื่อมต่อใหม่ รอนานเป็นสองเท่าของช่วงว่างที่เคยทำให้พัง
4. ทดสอบเครือข่ายอื่น ถ้าใช้ได้บนเน็ตมือถือแต่ไม่ได้บน Wi-Fi แห่งหนึ่ง สาเหตุอยู่ที่ไฟร์วอลล์หรือตัวจับเวลาของ Wi-Fi นั้น
5. ลดค่าลง เป็น 15-20 เฉพาะเมื่อ 25 ยังไม่พอ และจดไว้ว่าเครือข่ายไหนต้องใช้ค่านี้
6. ตรวจสาเหตุอื่น หากไม่เปลี่ยนแปลง เช่น ปัญหา MTU โหมดประหยัดแบตเตอรี่ที่ปิดแอปเบื้องหลัง หรือไฟร์วอลล์ที่บล็อก UDP ดู VPN handshake เพื่อเข้าใจการแลกเปลี่ยนคีย์และหน้าตาของ handshake ที่ค้าง

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

ข้อผิดพลาดที่พบบ่อย

• ตั้ง keepalive ทั้งสองฝั่งตามความเคยชิน เซิร์ฟเวอร์สาธารณะแทบไม่ต้องใช้ มีแต่เพิ่มจำนวนแพ็กเก็ตเป็นสองเท่า
• ตั้งค่ายาวมากเพื่อประหยัดแบตเตอรี่ ช่วงเวลาที่ยาวกว่าตัวจับเวลาของเครือข่ายก็เท่ากับปิด เพียงแต่คาดเดายากกว่า
• ตั้งเป็น 1 หรือ 2 วินาที แทบไม่มีเครือข่ายไหนต้องการ และแบตเตอรี่เสียจริง
• โทษ keepalive ว่าทำให้ช้า มันแทบไม่มีข้อมูล เรื่องความเร็วเป็นอีกหัวข้อหนึ่งในทำไมความเร็วอินเทอร์เน็ตเปลี่ยนเมื่อใช้ VPN
• ลืมว่า NAT อาจมีทั้งของคุณและของผู้ให้บริการ ทั้งเราเตอร์ที่บ้านและ CGNAT ของผู้ให้บริการทิ้งการแมปได้ และคุณควบคุมได้แค่ทราฟฟิกที่ตัวเองส่ง
• สับสนระหว่าง keepalive กับ kill switch หรือการเชื่อมต่อใหม่อัตโนมัติ keepalive แค่รักษาการแมปไว้ ไม่ได้เริ่มอุโมงค์ที่คีย์หรือเซสชันเสียจริงขึ้นมาใหม่

ตารางสรุปแบบเร็ว

คำถาม	คำตอบสั้น
ค่าเริ่มต้น	0 คือปิด
ค่าที่นิยม	25 วินาที
ตั้งที่ไหน	ที่ peer หลัง NAT ซึ่งต้องติดต่อเข้าได้
ต้นทุนดาต้า	ไม่เกินไม่กี่ร้อย KB ต่อวัน
ต้นทุนแบตเตอรี่	น้อยแต่มีจริงบนมือถือ
แก้ได้	อาการหมดเวลาจากสถานะ NAT หรือไฟร์วอลล์
แก้ไม่ได้	ความเร็วช้า Wi-Fi แย่ MTU ผิด บัญชีหมดอายุ

สรุป

PersistentKeepalive เป็นค่าตั้งเล็ก ๆ ของ WireGuard ที่ให้ peer ส่งแพ็กเก็ตเปล่าที่ผ่านการยืนยันตัวตนตามช่วงเวลาคงที่ เพื่อไม่ให้เราเตอร์ NAT และไฟร์วอลล์ลืมอุโมงค์ที่ว่างอยู่ ค่าเริ่มต้นคือปิด 25 วินาทีเป็นค่าที่นิยมสำหรับ peer หลัง NAT กินดาต้าแทบไม่มีแต่เสียแบตเตอรี่บนมือถือเล็กน้อย ใช้เมื่ออุโมงค์เงียบหลังว่างนานและกลับมาทันทีที่คุณส่งทราฟฟิก และมองหาสาเหตุอื่นเมื่อปัญหาคือความเร็ว MTU สถานะบัญชี หรือเครือข่ายที่บล็อก

หากสนใจวิธีลองใช้บนอุปกรณ์ของคุณแบบเติมเงินที่เรียบง่าย เข้าไปดูหน้าราคาได้ตามสะดวก