Policy-Based Routing ใน VPN คืออะไร

การเลือกเส้นทางแบบปกติเรียบง่าย แพ็กเก็ตมีที่อยู่ปลายทาง ระบบค้นหาที่อยู่นั้นในตารางเส้นทาง เลือกเส้นทางที่ตรงที่สุด แล้วส่งแพ็กเก็ตออกทางอินเทอร์เฟซนั้น การตัดสินใจขึ้นกับแค่ว่าแพ็กเก็ตกำลังไปที่ไหน Policy-Based Routing เปลี่ยนเรื่องนี้ ระบบจะดูข้อเท็จจริงอื่นเกี่ยวกับแพ็กเก็ตก่อน เช่น อุปกรณ์ไหนส่งมา ใช้พอร์ตอะไร หรือติดป้ายอะไรไว้ แล้วเลือกตารางเส้นทางตามกฎเหล่านั้น

สำหรับผู้ใช้ VPN เรื่องนี้สำคัญ เพราะเป็นวิธีที่เราเตอร์หรือเครื่อง Linux ตัดสินว่า "แล็ปท็อปเครื่องนี้ใช้ VPN ส่วนสมาร์ททีวีเครื่องนั้นไม่ใช้" หรือ "ทราฟฟิกแบบนี้เข้าอุโมงค์ ที่เหลือออกทางตรง" บทความนี้อธิบายแนวคิดเบื้องหลัง Policy-Based Routing สำหรับ VPN ส่วนประกอบของมัน ตัวอย่างใช้งานจริง จุดที่อาจพลาด และวิธีทดสอบ เนื้อหาอยู่ที่ชั้นการจัดเส้นทางเท่านั้น สำหรับแนวคิดทั่วไปเรื่องการยกเว้นแอป ดู Split Tunneling คืออะไร และสำหรับกฎเฉพาะบนเราเตอร์ ดู Split Tunneling บนเราเตอร์

ปัญหาที่การจัดเส้นทางแบบปกติแก้ไม่ได้

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

ลองนึกถึงเราเตอร์ประจำบ้านที่มีการเชื่อมต่อ VPN หนึ่งเส้นและอุปกรณ์หลายเครื่อง

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

การเลือกเส้นทางตามปลายทางแสดงเรื่องนี้ไม่ได้ เพราะทั้งสี่เครื่องอาจไปปลายทางเดียวกัน สิ่งที่ต่างคือต้นทาง คืออุปกรณ์ หรือวัตถุประสงค์ของทราฟฟิก นั่นคือช่องว่างที่ Policy-Based Routing เติมเต็ม

Policy-Based Routing ทำงานอย่างไร

แนวคิดมีสามส่วนที่ทำงานร่วมกัน

1. จับคู่ (Match) กฎอธิบายว่ามันใช้กับแพ็กเก็ตแบบไหน เกณฑ์ที่พบบ่อยได้แก่

• ที่อยู่ IP ต้นทางหรือช่วงของที่อยู่ ซึ่งมักระบุอุปกรณ์หรือกลุ่มอุปกรณ์
• ที่อยู่ปลายทางหรือช่วงของที่อยู่
• โปรโตคอลและพอร์ต เช่น TCP 443 หรือ UDP 123
• อินเทอร์เฟซขาเข้า เช่น เครือข่าย Wi-Fi หรือ VLAN ใดวงหนึ่ง
• เครื่องหมายไฟร์วอลล์ (firewall mark) ซึ่งเป็นป้ายเล็ก ๆ ที่ไฟร์วอลล์ติดไว้ก่อนหน้า

2. เลือกตาราง (Select a table) เมื่อกฎตรงกัน ระบบใช้ตารางเส้นทางเฉพาะแทนตารางหลัก ตารางหนึ่งอาจส่งทุกอย่างไปที่อินเทอร์เฟซ VPN อีกตารางส่งไปที่เกตเวย์ปกติ

3. จัดเส้นทาง (Route) แพ็กเก็ตเดินตามตารางที่เลือก ทราฟฟิกที่ตรงกฎจึงเข้า VPN ส่วนที่เหลือไปตามเส้นทางเริ่มต้น

ตัวอย่างบน Linux มีหน้าตาแบบด้านล่าง แสดงเพื่อให้เห็นรูปร่างของแนวคิดเท่านั้น

# Table 100 sends traffic into the VPN interface
ip route add default dev vpn0 table 100

# Rule: traffic from the work laptop uses table 100
ip rule add from 192.168.1.20 lookup 100 priority 1000

เฟิร์มแวร์ของเราเตอร์ห่อแนวคิดเดียวกันไว้ในหน้าจอ เลือกอุปกรณ์ เลือก "ใช้ VPN" หรือ "ไม่ผ่าน VPN" แล้วระบบเขียนกฎที่เทียบเท่าให้ ช่วงที่อยู่ส่วนตัวในตัวอย่างเหล่านี้มาจากชุดที่สงวนไว้ตามคำอธิบายใน RFC 1918

ลำดับและความสำคัญของกฎ

กฎถูกตรวจตามลำดับ กฎแรกที่ตรงจะชนะ ซึ่งทำให้ลำดับความสำคัญเป็นแนวคิดที่สำคัญที่สุดอย่างเดียวของ Policy Routing

ตัวอย่างสั้น ๆ สำหรับเครือข่ายในบ้าน

1. ลำดับ 100 ทราฟฟิกไปเครือข่ายภายใน (192.168.1.0/24) ใช้ตารางหลัก เพื่อให้เครื่องพิมพ์และเซิร์ฟเวอร์ในบ้านยังเข้าถึงได้
2. ลำดับ 200 ทราฟฟิกจากแล็ปท็อปที่ทำงานใช้ตาราง VPN
3. ลำดับ 300 ทราฟฟิกจากโทรศัพท์ที่ใช้ VPN เมื่อร้องขอ ใช้ตาราง VPN เฉพาะเมื่อมีเครื่องหมายที่กำหนด
4. ลำดับ 32766 ทุกอย่างที่เหลือใช้ตารางหลัก คือการเชื่อมต่อปกติ

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

เปรียบเทียบชนิดการจับคู่

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

กฎที่ใช้ต้นทางเป็นเกณฑ์เข้าใจง่ายที่สุด อุปกรณ์บน "Wi-Fi VPN" ใช้อุโมงค์ อุปกรณ์บน Wi-Fi ปกติไม่ใช้ หลายบ้านเลือกแบบนี้เพราะไม่ต้องคิดรายแอป

Policy Routing เทียบกับแนวคิดใกล้เคียง

คนมักถามว่าต่างจากแนวคิดอื่นอย่างไร

• Split Tunneling ระดับแอป แอปบนโทรศัพท์หรือคอมพิวเตอร์เป็นผู้ตัดสิน มักตามชื่อโพรเซส ส่วน Policy Routing ตัดสินที่ชั้นเครือข่าย จึงใช้ได้กับอุปกรณ์ที่ติดตั้งแอป VPN ไม่ได้ เช่น ทีวีหรือเครื่องเกม
• เส้นทางแบบคงที่ (static route) เส้นทางตายตัวไปยังปลายทางหนึ่ง ส่งช่วงที่อยู่เข้าอุโมงค์ได้ แต่เลือกตามอุปกรณ์ที่ส่งไม่ได้
• เราเตอร์ VPN เทียบกับแอป VPN Policy Routing เป็นส่วนหนึ่งที่ทำให้การตั้งค่าบนเราเตอร์ยืดหยุ่น ดูการเปรียบเทียบกว้างกว่านี้ที่ เราเตอร์ VPN กับแอป VPN
• Zero Trust หรือการเข้าถึงรายแอปพลิเคชัน ทำงานในระดับตัวตนและแอปพลิเคชัน เป็นแนวทางอีกแบบหนึ่งโดยสิ้นเชิง

ตัวอย่างการใช้งานจริง

ลองนึกถึงครอบครัวหนึ่งที่มีเราเตอร์รองรับกฎนโยบายและตั้งค่า VPN ไว้บนเราเตอร์แล้ว

• แล็ปท็อปที่ทำงานของพ่อ 192.168.1.20
• โทรศัพท์ของแม่ 192.168.1.30
• สมาร์ททีวี 192.168.1.40
• เครื่องเก็บข้อมูล NAS 192.168.1.50

เป้าหมายคือ แล็ปท็อปอยู่ในอุโมงค์ตลอดเวลา โทรศัพท์อยู่ในอุโมงค์เฉพาะเมื่อเชื่อม Wi-Fi ชื่อ "Private" ทีวีไม่ใช้อุโมงค์เลย และทุกเครื่องเข้าถึง NAS ได้

ครอบครัวตั้งกฎสี่ข้อตามลำดับ ข้อแรก ทุกอย่างที่ไป 192.168.1.0/24 ใช้ตารางหลัก ข้อสอง ทุกอย่างจาก 192.168.1.20 ใช้ตาราง VPN ข้อสาม ทุกอย่างที่เข้ามาทาง Wi-Fi Private ใช้ตาราง VPN ข้อสี่ ที่เหลือใช้ตารางหลัก และเพิ่มอีกหนึ่งรายการคือกฎไฟร์วอลล์ที่ทิ้งทราฟฟิกจาก 192.168.1.20 และ Wi-Fi Private หากอินเทอร์เฟซ VPN ล่ม ซึ่งทำหน้าที่เป็น kill switch

ผลลัพธ์คือ แล็ปท็อปได้รับการปกป้องเสมอ โทรศัพท์เลือกตาม Wi-Fi ทีวีใช้งานเหมือนเดิม และ NAS ยังเข้าถึงได้ ครอบครัวทดสอบโดยเปิดหน้าตรวจ IP บนแต่ละเครื่อง และยืนยันว่าที่อยู่ที่แสดงตรงกับที่คาดไว้

Policy Routing พลาดที่ไหนได้บ้าง

ความล้มเหลวส่วนใหญ่เงียบ เครือข่ายยังใช้งานได้ แต่ไม่ตามที่ตั้งใจ

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

วิธีทดสอบนโยบาย

1. ตรวจรายการกฎ อ่านกฎและตารางเส้นทางที่ใช้งานอยู่ตามลำดับ และยืนยันว่าตรงกับเจตนา
2. ทดสอบทีละอุปกรณ์ เปิดหน้าตรวจ IP บนแต่ละเครื่อง และเทียบกับที่คาดไว้
3. ทดสอบ DNS ใช้ การทดสอบ DNS รั่ว กับอุปกรณ์ที่ควรอยู่ในอุโมงค์
4. ทดสอบ IPv6 ใช้เว็บไซต์ที่รายงาน IPv6 และยืนยันว่าไม่มีที่อยู่ที่ไม่คาดคิด
5. ปิดอุโมงค์เอง ตัด VPN โดยตั้งใจ แล้วยืนยันว่าอุปกรณ์ที่ได้รับการป้องกันใช้อินเทอร์เน็ตไม่ได้ แทนที่จะวิ่งออกทางการเชื่อมต่อปกติ
6. ทดสอบการเข้าถึงในบ้าน สั่งพิมพ์ เปิด NAS และแคสต์ไปที่ทีวี ขณะที่นโยบายทำงานอยู่
7. รีบูตเราเตอร์ ยืนยันว่ากฎและอุโมงค์กลับมาตามลำดับที่ถูกต้อง

ข้อจำกัดและนิสัยที่ดี

Policy Routing ทรงพลัง และก็ออกแบบเกินจำเป็นได้ง่ายเช่นกัน ควรยึดหลักไม่กี่ข้อ

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

สรุป

Policy-Based Routing ให้เราเตอร์หรือคอมพิวเตอร์เลือกเส้นทางของแพ็กเก็ตด้วยกฎเกี่ยวกับต้นทาง พอร์ต อินเทอร์เฟซ หรือเครื่องหมาย แทนที่จะดูแค่ปลายทาง สำหรับ VPN มันคือกลไกเบื้องหลังการส่งอุปกรณ์หรือทราฟฟิกบางส่วนเข้าอุโมงค์ ขณะที่ส่วนอื่นใช้การเชื่อมต่อปกติ ประเด็นสำคัญคือลำดับของกฎ ระบบกันพลาดเมื่ออุโมงค์หลุด พฤติกรรม DNS และ IPv6 ที่สอดคล้องกัน และการทดสอบทีละอุปกรณ์ ให้เก็บกฎไว้น้อยและอ่านง่าย และตรวจสอบจริงแทนที่จะเชื่อว่ามันทำงาน

หากพาส VPN แบบจ่ายล่วงหน้าช่วยให้คุณทดสอบการตั้งค่าแบบนี้ได้ ดูตัวเลือกที่มีที่ หน้าราคา