Wi-Fi สำหรับแขกยังคงใช้เส้นทางหลัก: มอบทางออกของตัวเองให้มัน

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

อาการ: แขกยังออกผ่าน WAN

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

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

ขั้นที่ 1: เซกเมนต์จริง ไม่ใช่แค่ชื่อ

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

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

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

ขั้นที่ 2: เลือกอุโมงค์ตามต้นทาง

ตารางเส้นทางถูกเลือกตามปลายทาง ดังนั้นกฎที่ว่า «ส่ง 0.0.0.0/0 ไปยังอุโมงค์» จึงใช้กับทุกคน การกำหนดเส้นทางตามนโยบายเพิ่มมิติที่สอง: เลือกตารางตามที่อยู่ต้นทาง บนเราเตอร์ที่ใช้ Linux นั่นคือกฎเพิ่มเติมบวกตารางเฉพาะ และลำดับสำคัญเพราะกฎแรกที่ตรงกันจะชนะ:

ip rule add from 192.168.60.0/24 lookup 100 priority 1000
ip route add default dev wg0 table 100
ip route get 1.1.1.1 from 192.168.60.10

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

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

ขั้นที่ 3: เส้นทางตอบกลับและการแปลที่อยู่

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

nft add rule ip nat POSTROUTING ip saddr 192.168.60.0/24 oifname "wg0" masquerade

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

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

ทดสอบการแยกตัว ไม่ใช่แค่การท่องเว็บ

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

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

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

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