การให้อุปกรณ์เครื่องเดียวออกผ่าน VPN ของเราเตอร์ต้องใช้สามกฎ ไม่ใช่สวิตช์

บน VPN ของเราเตอร์ไม่มีสวิตช์แยกตามอุปกรณ์ สวิตช์ที่คุณกำลังมองหาจริง ๆ คือทางลัดที่เขียนกฎ policy routing แทนคุณ ทันทีที่แล็ปท็อปหนึ่งเครื่อง ช่วงพอร์ตหนึ่งช่วง รายการที่อยู่หนึ่งรายการ หรือเซกเมนต์ LAN หนึ่งเซกเมนต์ต้องใช้ทันเนล ขณะที่ทุกอย่างที่เหลือยังอยู่บน WAN คุณกำลังสร้าง policy route ไม่ใช่เปิดใช้งานฟีเจอร์ งานนี้มีสามส่วนที่เคลื่อนไหวได้ และแต่ละส่วนล้มเหลวต่างกัน ตารางที่ทำเครื่องหมายแต่ไม่มีเส้นทางดูเหมือนความเงียบ เครื่องหมายที่ใส่ในเชนผิดดูเหมือนไม่มีอะไรเกิดขึ้น และกฎ NAT ที่หายไปดูเหมือนทันเนลที่เชื่อมต่อได้แต่ไม่พาอะไรไปเลย อีกสองส่วนหายไปเพราะไม่เคยปรากฏในกฎ mangle นั่นคือ DNS และ IPv6

ความเชื่อผิด: ทันเนลคือการตั้งค่าของไคลเอนต์

ไคลเอนต์ VPN ฝั่งเราเตอร์ทำสิ่งหนึ่งได้ดี: มันใส่ 0.0.0.0/0 ลงในตารางเส้นทางหลักและชี้ไปที่ทันเนล WireGuard ได้มาจาก AllowedIPs OpenVPN และได้จาก redirect-gateway ที่เซิร์ฟเวอร์ผลักมา ทั้งสองเปลี่ยนเส้นทางของทุกโฮสต์หลังเราเตอร์ การจำกัด AllowedIPs หรือเพิ่ม route-nopull เปลี่ยนสิ่งที่ไคลเอนต์ติดตั้ง แต่ไม่เปลี่ยนว่าใครได้รับผลจากการติดตั้ง เพราะไคลเอนต์ไม่เคยเห็นอุปกรณ์ มันเห็นแค่แพ็กเก็ต

การเลือกตามต้นทางหรือปลายทางเป็นการตัดสินใจด้านเส้นทาง จึงอยู่ในชั้นนโยบายของเราเตอร์ ได้แก่ กฎ mangle กับตารางที่สองบน RouterOS, MARK กับ ip rule บน OpenWrt หรือ DD-WRT หรือกฎไฟร์วอลล์ที่เกตเวย์เป็นทันเนลบน pfSense สูตรไคลเอนต์ WireGuard ของ Netgate คือสิ่งที่ควรอ่านก่อนเดา เพราะบนแพลตฟอร์มนั้นเกตเวย์ของกฎ การกำหนดอินเทอร์เฟซ และรายการ NAT ขาออกต้องตรงกันก่อนที่ไคลเอนต์เพียงตัวเดียวจะใช้ทันเนล

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

ส่วนที่หนึ่ง: ทันเนลที่ไม่ใช่เส้นทางเริ่มต้น

บน RouterOS ให้เพิ่มไคลเอนต์โดยไม่มีเส้นทางเริ่มต้นและให้ตารางของตัวเองแก่ทันเนล เส้นทางแรกคือค่าเริ่มต้นที่ทำเครื่องหมาย เส้นทางที่สองคือครึ่งของความล้มเหลว

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

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

RouterOS 7 แยกสิ่งที่ 6.x รวมไว้ด้วยกัน คุณประกาศตารางด้วย /routing table add name=vpn fib แล้วอ้างอิงด้วยชื่อบนเส้นทางและในกฎ mangle สคริปต์ 6.x ที่เขียน routing-mark โดยไม่ประกาศตารางจะโหลดได้สะอาดและไม่ตรงกับอะไรเลย อีกกรณีคลาสสิกคือ 0.0.0.0/1 สองครึ่ง หรือค่าเริ่มต้นสองรายการที่ระยะทางเท่ากันในตารางเดียว เคอร์เนลเลือกหนึ่งรายการ และพฤติกรรมอาจเปลี่ยนหลังรีบูต

ส่วนที่สอง: ทำเครื่องหมายก่อนการค้นหาเส้นทาง

ตัวเลือกเป็นตัวกำหนดว่าแพ็กเก็ตใดเข้าตารางนั้น RouterOS มักเริ่มด้วยรายการที่อยู่สำหรับนโยบายปลายทาง หรือที่อยู่ต้นทางสำหรับนโยบายอุปกรณ์

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

เฟิร์มแวร์ลินุกซ์ทำแบบเดียวกันด้วยเครื่องหมาย netfilter และกฎที่พาแพ็กเก็ตที่ทำเครื่องหมายเข้าตารางที่คุณเติมไว้

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

เชนไม่ใช่การเลือกสไตล์ เมื่อแพ็กเก็ตถึง FORWARD การค้นหาเส้นทางเกิดขึ้นแล้ว MARK หรือ DROP ตรงนั้นจึงได้แค่เขียนใหม่หรือทิ้ง เครื่องหมายต้องลงที่ PREROUTING สำหรับทราฟฟิกที่ส่งต่อ และที่ OUTPUT สำหรับทราฟฟิกที่เราเตอร์สร้างเอง ซึ่งเป็นที่อยู่ของ DNS, NTP และการตรวจอัปเดตของเราเตอร์ เส้นทางขาออกนั้นคือเหตุผลปกติที่การตั้งค่าแบบทันเนลทั้งหมดยังตอบจากรีโซลเวอร์ของ ISP ในการทดสอบการรั่วไหล

นโยบายรายอุปกรณ์ต้องมีการจับคู่ที่ไม่เลื่อนไป เราจองที่อยู่ใน DHCP หรือจับคู่อินเทอร์เฟซกับเซกเมนต์เฉพาะ ที่อยู่ที่ย้ายไปอุปกรณ์อื่นในภายหลังจะใช้ทันเนลกับไคลเอนต์ผิดตัวอย่างเงียบ ๆ บริดจ์แยกตาม SSID ที่มีซับเน็ตของตัวเองคือเวอร์ชันที่ทนกว่าของแนวคิดเดียวกัน และยังให้ที่อยู่แก่กฎ IPv6 ด้วย

ส่วนที่สาม: NAT, DNS และข้อยกเว้น LAN

ทราฟฟิกที่ออกผ่านทันเนลต้องมีที่อยู่ต้นทางที่อีกฝั่งจะตอบกลับ จำกัดการแปลที่อยู่ให้แคบลงที่อินเทอร์เฟซของทันเนล ได้แก่ out-interface=VPN_NAME บน RouterOS, -o tun0 บนลินุกซ์ และรายการ NAT ขาออกที่ตรงกันบน pfSense กฎ masquerade ที่ไม่มีขอบเขตนั้นจะเขียนทราฟฟิกที่คุณตั้งใจปล่อยไว้ใหม่ และอาการคืออุปกรณ์ที่ไม่ได้อยู่ในทันเนลสูญเสียที่อยู่สาธารณะ

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

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

เมื่อกฎตรงแต่แอปยังใช้ WAN

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

IPv6 คือทางอ้อมอันเงียบงัน อุปกรณ์มีตระกูลที่อยู่ที่สองพร้อมเส้นทางเริ่มต้นและชุดกฎของตัวเอง และการจับคู่เฉพาะที่อยู่ IPv4 นั้นเป็นเพียงครึ่งหนึ่งของนโยบาย ให้ใช้ตัวเลือกเดียวกันกับ ip6tables หรือสิ่งที่เทียบเท่าอย่าง nftables หรือปิด IPv6 บนเซกเมนต์นั้นอย่างตั้งใจ ไม่ใช่โดยอุบัติเหตุ

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

ตรวจสอบด้วยอุปกรณ์สองเครื่องและการรีบูต

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

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

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