Routing Table เมื่อใช้ VPN บน Linux ทำงานอย่างไร

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

บทความนี้อธิบาย routing ของ VPN บน Linux ตั้งแต่พื้นฐาน คุณจะได้อ่าน ip route เป็น คาดเดาได้ว่า VPN แบบ full tunnel ทำอะไรกับตาราง และเข้าใจ policy routing ซึ่งเป็นกลไกที่ไคลเอนต์สมัยใหม่ใช้อยู่เบื้องหลัง เนื้อหาไม่ผูกกับผู้ให้บริการรายใด ใช้ได้กับ WireGuard, OpenVPN และอุโมงค์ชนิดอื่น ถ้าต้องการแนวคิดของตัวอุโมงค์เอง อ่าน อุโมงค์ VPN คืออะไร

ตาราง routing ตัดสินอะไร

แพ็กเก็ตขาออกทุกตัวมีที่อยู่ปลายทาง และเคอร์เนลต้องเลือกอินเทอร์เฟซ และมักต้องเลือก next hop ด้วย โดยดูจากตาราง routing หลักการแกนกลางง่ายมาก ในบรรดาเส้นทางทั้งหมดที่ช่วงปลายทางครอบคลุมที่อยู่ของแพ็กเก็ต ให้เลือกเส้นที่จำเพาะที่สุด /24 ชนะ /16 และ /32 ชนะทุกอย่าง ถ้ายาวเท่ากัน เส้นที่ metric ต่ำกว่าชนะ

หลักนี้เรียกว่า longest-prefix match และเป็นรากฐานทั้งหมดของ routing ใน VPN ไคลเอนต์ VPN ไม่ได้ยึดอะไรไป มันเพียงเพิ่มเส้นทางที่จำเพาะกว่าหรือน่าเลือกกว่าที่มีอยู่เดิม

อ่านตารางของคุณก่อนเปิด VPN

เริ่มจากตารางตอนปิด VPN รัน ip route show จะเห็นประมาณนี้

default via 192.168.1.1 dev wlp3s0 proto dhcp metric 600
192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.42

อ่านทีละบรรทัด

• default via 192.168.1.1 dev wlp3s0 หมายถึง "อะไรที่ไม่ตรงกับเส้นอื่น ส่งไปที่เราเตอร์ 192.168.1.1 ผ่านอินเทอร์เฟซ Wi-Fi"
• 192.168.1.0/24 dev wlp3s0 scope link หมายถึงที่อยู่ในเครือข่ายบ้านเข้าถึงตรง ๆ บนสาย ไม่ผ่านเราเตอร์
• metric 600 ใช้ตัดสินเมื่อสองเส้นจำเพาะเท่ากัน ค่าต่ำกว่าได้รับเลือก

จากนั้นรัน ip -6 route show ด้วย หลายคนป้องกัน IPv4 แล้วลืมว่าตาราง IPv6 แยกกัน ซึ่งเป็นต้นเหตุของ IPv6 leak ความต่างของสองตระกูลนี้อธิบายไว้ใน IPv4 เทียบกับ IPv6 กับ VPN สุดท้าย คำสั่งที่มีประโยชน์ที่สุดคือ ip route get 8.8.8.8 มันรายงานชัด ๆ ว่าเคอร์เนลจะใช้อินเทอร์เฟซ เกตเวย์ และที่อยู่ต้นทางใดสำหรับปลายทางนั้น และนับ policy rule เข้าไปด้วย

VPN แบบ full tunnel ทำอะไรกับตาราง

เมื่อเชื่อมต่อ VPN ที่ต้องรับทราฟฟิกทั้งหมด ไคลเอนต์ต้องทำให้อุโมงค์ชนะทุกปลายทาง มีสองเทคนิคที่พบบ่อย

แทนที่ default ไคลเอนต์ลบ default route เดิมแล้วเพิ่ม default dev tun0 ง่ายแต่ทำให้เส้นทางกลับไปเครือข่ายจริงหายไป จึงต้องมีกฎแยกสำหรับตัวเซิร์ฟเวอร์

กลเม็ดครึ่ง default ไคลเอนต์หลายตัวปล่อย default เดิมไว้ แล้วเพิ่มสองเส้นที่รวมกันครอบคลุมทั้งพื้นที่ที่อยู่

0.0.0.0/1 dev tun0
128.0.0.0/1 dev tun0

แต่ละเส้นเป็น /1 ซึ่งจำเพาะกว่า default แบบ /0 จึงชนะการจับคู่ prefix ยาวสุด เมื่อ VPN หยุด ไคลเอนต์ลบสองบรรทัดนี้ default เดิมก็กลับมาทำงาน ไม่มีอะไรต้องกู้คืน ลองดูบนเครื่องคุณ เชื่อมต่อ รัน ip route show แล้วหาคู่นี้

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

203.0.113.10 via 192.168.1.1 dev wlp3s0

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

Policy routing, fwmark และตารางเสริม

การตั้งค่า WireGuard สมัยใหม่เลี่ยงการแก้ตารางหลักเลย เมื่อ config บอกว่าให้ส่งทราฟฟิก IPv4 ทั้งหมดผ่านอุโมงค์ สคริปต์มาตรฐานจะสร้างตารางแยกและกฎบางข้อ ดูได้ด้วย ip rule show

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
32767:  from all lookup default

และตารางเสริมด้วย ip route show table 51820 ซึ่งมี default dev wg0 ตรรกะนี้เรียบร้อยมาก

1. ซอฟต์แวร์อุโมงค์ติดเครื่องหมายไฟร์วอลล์ที่แพ็กเก็ตเข้ารหัสของตัวเอง ในที่นี้คือ 0xca6c ซึ่งเท่ากับ 51820 ฐานสิบ
2. กฎที่ priority 32765 บอกว่าแพ็กเก็ตที่ไม่มีเครื่องหมายนั้นต้องไปดูตาราง 51820 ซึ่ง default ชี้เข้าอุโมงค์
3. แพ็กเก็ตที่มีเครื่องหมายข้ามกฎนี้ไปตกที่ตารางหลัก จึงไปถึงเซิร์ฟเวอร์ผ่านเครือข่ายจริง ไม่ต้องมี host route
4. กฎที่ 32764 ให้ตารางหลักตอบก่อนเฉพาะเส้นทางที่จำเพาะกว่า default เช่นเครือข่ายภายใน การเข้าถึง LAN จึงยังใช้ได้

ถ้าเจอเส้นทางลึกลับที่ไม่ปรากฏใน ip route show ให้ดู ip rule show และตารางที่มีหมายเลข เพราะ ip route show เฉย ๆ พิมพ์เฉพาะตารางหลัก

ตัวอย่างลงมือทำ เฉพาะซับเน็ตของออฟฟิศ

อุโมงค์ไม่จำเป็นต้องรับทุกอย่าง สมมติคุณทำงานที่บ้านและเครือข่ายของนายจ้างคือ 10.20.0.0/16 เข้าถึงผ่านอุโมงค์ที่ 10.8.0.1 คุณต้องการให้ทราฟฟิกของออฟฟิศเข้าอุโมงค์ ส่วนที่เหลือใช้เน็ตของตัวเอง เส้นทางที่เกี่ยวข้องคือ

10.20.0.0/16 via 10.8.0.1 dev tun0
default via 192.168.1.1 dev wlp3s0

แพ็กเก็ตไป 10.20.5.9 ตรงกับ /16 จึงเข้าอุโมงค์ ส่วนแพ็กเก็ตไปเว็บสาธารณะตรงเพียง default จึงออกตรง ๆ ใน config ของ WireGuard แนวคิดนี้เขียนเป็น AllowedIPs = 10.20.0.0/16 ซึ่งทำสองหน้าที่ บอกเคอร์เนลว่าปลายทางใดให้ส่งเข้า wg0 และบอก WireGuard ว่าจะรับแพ็กเก็ตต้นทางใดจาก peer นั้น ถ้าตั้ง AllowedIPs = 0.0.0.0/0, ::/0 คือขอ full tunnel แนวคิดที่เกี่ยวกันสำหรับแอปแทนที่จะเป็นเครือข่าย อธิบายไว้ใน Split Tunneling คืออะไร

เช็กลิสต์ไล่หาสาเหตุ

เมื่อ VPN มีปัญหาบน Linux ให้ไล่ตามลำดับนี้

1. รัน ip route get ปลายทาง กับเว็บที่ใช้ไม่ได้ อินเทอร์เฟซตรงกับที่คาดไหม
2. รัน ip rule show และ ip route show table all ถ้าตารางธรรมดาดูไม่มีอะไรผิด
3. รัน ip -6 route show มี default ของ IPv6 ผ่านเส้นจริงที่ข้ามอุโมงค์หรือเปล่า
4. ตรวจ endpoint ยืนยันว่า ip route get ที่อยู่เซิร์ฟเวอร์ ระบุอินเทอร์เฟซจริง ไม่ใช่อุโมงค์
5. ดูซับเน็ตที่ซ้อนทับ ถ้าเครือข่ายบ้านและออฟฟิศใช้ 192.168.1.0/24 ทั้งคู่ เคอร์เนลแยกไม่ออก ให้เปลี่ยนช่วงที่บ้านเป็นช่วงอื่นในบล็อกส่วนตัวตาม RFC 1918
6. ตรวจ sysctl net.ipv4.conf.all.rp_filter การกรอง reverse-path แบบเข้มอาจทิ้งแพ็กเก็ตตอบกลับที่กลับมาทางอินเทอร์เฟซอื่นที่ไม่ใช่เส้นที่ route ชี้
7. ตรวจ MTU แพ็กเก็ตใหญ่หายเงียบขณะที่แพ็กเก็ตเล็กผ่าน เป็นสัญญาณคลาสสิกว่า MTU ของอุโมงค์สูงเกิน ดูเหตุผลที่ path MTU discovery ใน RFC 1191 แล้วลองลดค่าที่อินเทอร์เฟซอุโมงค์

อาการและสาเหตุที่น่าสงสัย

อาการ	สาเหตุที่น่าจะเป็น	ตรวจอะไรก่อน
เชื่อมต่อแล้วแต่ไม่มีเน็ตเลย	ที่อยู่เซิร์ฟเวอร์ถูก route เข้าอุโมงค์	ip route get ของที่อยู่เซิร์ฟเวอร์
เว็บโหลดได้ แต่เครื่องพิมพ์หาย	full tunnel กลืนช่วง LAN	ip route get ของเครื่องพิมพ์
บางเว็บค้าง บางเว็บโหลด	MTU สูงเกินหรือเส้น IPv6 เสีย	ลด MTU ดู ip -6 route
เข้าเครื่องในออฟฟิศไม่ได้	ไม่มีเส้นทางไปช่วงของออฟฟิศ	ip route show ของซับเน็ตนั้น
ใช้ได้เฉพาะหลังรีบูต	เพิ่ม route ด้วยมือแต่ไม่ได้เก็บถาวร	ใส่ไว้ใน config ของ VPN
สองเครือข่ายใช้ช่วงเดียวกัน	ที่อยู่ซ้อนทับ	เปลี่ยนช่วงของเครือข่ายหนึ่ง

ทดสอบการแก้ route อย่างไรไม่ให้ล็อกตัวเองออก

การทดลองเรื่อง routing เป็นวิธีที่ง่ายที่สุดในการตัดการเข้าถึงของตัวเอง โดยเฉพาะเครื่องที่อยู่ไกล มีนิสัยไม่กี่ข้อที่ทำให้ปลอดภัย

• บันทึกสถานะเดิมก่อน รัน ip route show > routes-before.txt และ ip rule show > rules-before.txt ถ้าผิดพลาดก็รู้ว่าต้องคืนค่าอะไร
• เตรียมทางเข้าสำรอง บนเซิร์ฟเวอร์ระยะไกล ให้เปิดคอนโซลหรือเซสชัน SSH ที่สองซึ่งไม่ขึ้นกับเส้นทางที่กำลังแก้ ดีกว่านั้นคือตั้งเวลายกเลิกอัตโนมัติ เช่นรัน sleep 120 && ip route del ... ไว้เบื้องหลัง ให้ความผิดพลาดซ่อมตัวเอง
• เปลี่ยนทีละอย่าง เพิ่มเส้นทางเดียว รัน ip route get กับปลายทางที่ควรได้รับผลและปลายทางที่ไม่ควร แล้วค่อยไปต่อ
• ทำให้ถาวรให้ถูกที่ เส้นทางที่เป็นของอุโมงค์ควรอยู่ใน config ของ VPN เช่นบรรทัด PostUp และ PostDown หรือตัวเลือกเส้นทางของไคลเอนต์ เพื่อให้เกิดและหายไปพร้อมอินเทอร์เฟซ ส่วนเส้นทางของเครือข่ายจริงให้เป็นหน้าที่ของ NetworkManager หรือ systemd-networkd
• อย่าลืมขาตอบกลับ เส้นทางที่ส่งแพ็กเก็ตออกเป็นแค่ครึ่งเดียวของงาน คำตอบต้องกลับมาทางอินเทอร์เฟซเดียวกัน ไม่เช่นนั้นไฟร์วอลล์แบบ stateful และตัวกรอง reverse-path อาจทิ้งแพ็กเก็ต

ขั้นตอนเช็กอย่างรวดเร็วหลังแก้ทุกครั้ง รัน ip route get กับที่อยู่สาธารณะหนึ่งตัวและที่อยู่ใน LAN หนึ่งตัว เปิดเว็บหนึ่งเว็บ ping อุปกรณ์ในบ้านหนึ่งเครื่อง แล้วดู ip -6 route show อีกครั้ง การตรวจห้านาทีช่วยประหยัดการเดาทั้งเย็น

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

• เพิ่ม route ด้วย ip route add แล้วคาดว่าจะอยู่หลังรีบูต ซึ่งไม่อยู่
• ลบ default route เพื่อ "บังคับ" ให้ใช้ VPN แล้วขาดการติดต่อกับเซิร์ฟเวอร์
• อ่านแค่ ip route show แล้วมองไม่เห็น policy rule
• ลืมตาราง IPv6
• ใช้ช่วงที่อยู่ส่วนตัวช่วงเดียวกันที่บ้านและที่ออฟฟิศ
• แก้ route ขณะการเชื่อมต่อทำงานอยู่โดยไม่จดค่าเดิม

สรุป

Routing ของ VPN บน Linux มีแก่นอยู่ที่ตาราง routing การจับคู่ prefix ยาวสุด และในระบบสมัยใหม่คือเครื่องหมายไฟร์วอลล์พร้อมตารางของมันเอง เรียนรู้การอ่าน ip route, ip rule และ ip route get เก็บที่อยู่เซิร์ฟเวอร์ไว้นอกอุโมงค์ จำเรื่อง IPv6 และเลี่ยงซับเน็ตที่ซ้อนกัน แล้วคุณจะอธิบายแพ็กเก็ตที่ไปผิดทางเกือบทุกกรณีได้ในหนึ่งนาที

หากใช้แอป VPNclient ฟรี คู่มือติดตั้งบน Linux แสดงวิธีติดตั้ง และ หน้าราคา แสดงตัวเลือกเมื่อคุณพร้อม