สวิตช์ตัดการเชื่อมต่อเราเตอร์ที่ครอบคลุม FORWARD, OUTPUT และ IPv6
สวิตช์ตัดการเชื่อมต่อที่มีเฉพาะใน FORWARD ปล่อยให้เราเตอร์รั่วไหลได้เอง และกฎที่มีเฉพาะ IPv4 ก็เปิด IPv6 ไว้ จัดลำดับเชนแล้วทดสอบโดยปิดอุโมงค์
คุณเข้าสู่เราเตอร์ วางชุดกฎสวิตช์ตัดการเชื่อมต่อจากโพสต์ฟอรัม และ LAN หยุดท่องเว็บทันทีที่อุโมงค์ล่ม สองวันต่อมาเราเตอร์ยังคงอัปเดตระเบียน DNS แบบไดนามิกผ่าน WAN ปกติ และแล็ปท็อปของแขกยังเข้าถึงเว็บไซต์ IPv6 ได้ ทั้งสองพฤติกรรมเป็นเรื่องปกติ เพราะกฎที่วางไว้ครอบคลุมเพียงเชนเดียวและตระกูลที่อยู่เดียว และไม่มีสิ่งใดเป็นเราเตอร์ทั้งเครื่อง การไล่เส้นทางของแพ็กเก็ตตามลำดับจะแสดงให้เห็นชัดว่ามีอะไรถูกมองข้ามไป
เริ่มที่เราเตอร์ ไม่ใช่ที่แล็ปท็อป
นโยบายระดับเราเตอร์น่าสนใจสำหรับสำนักงานเล็ก เพราะทุกอุปกรณ์ที่อยู่ข้างหลังสืบทอดพฤติกรรมเดียวกัน และไม่มีใครลืมเปิดสวิตช์ฝั่งไคลเอนต์ได้ ยังให้สถานที่ทดสอบแห่งเดียวหลังการอัปเดตเฟิร์มแวร์ทุกครั้ง สิ่งที่ไม่ได้ให้คือการครอบคลุมทราฟฟิกของเราเตอร์เองหรือตระกูลที่อยู่ที่สองโดยอัตโนมัติ และช่องว่างสองข้อนี้อยู่เบื้องหลังการติดตั้งที่ล้มเหลวส่วนใหญ่
ก่อนแก้ไขสิ่งใด จดข้อเท็จจริงสามข้อลงบนกระดาษ ชื่ออินเทอร์เฟซ WAN ชื่อบริดจ์ LAN และที่อยู่กับพอร์ตของปลายทาง VPN คุณจะต้องใช้ทั้งสามอย่างในกฎ และการเดาชื่ออินเทอร์เฟซเป็นสาเหตุที่พบบ่อยที่สุดที่ทำให้ชุดกฎที่ดูถูกต้องไม่ทำอะไรเลย
ไล่สามเส้นทางที่แพ็กเก็ตไปได้
ทราฟฟิกจากแล็ปท็อปไปยังอินเทอร์เน็ตถูกส่งต่อ จึงผ่านเชน FORWARD ทราฟฟิกที่เราเตอร์สร้างเอง เช่น การส่งต่อ DNS คำค้น NTP การอัปเดต DDNS และช่องควบคุม VPN จะผ่าน OUTPUT ทราฟฟิกการจัดการที่ส่งถึงเราเตอร์มาถึงผ่าน INPUT
ดังนั้นสวิตช์ตัดการเชื่อมต่อที่สร้างไว้เฉพาะใน FORWARD จึงปกป้องไคลเอนต์และไม่มีอะไรอื่น ตารางแสดงให้เห็นว่าทำไมการรั่วไหลในฉากเปิดจึงคาดเดาได้ไม่ใช่เรื่องลึกลับ
| Packet path | Example | Chain that sees it |
|---|---|---|
| LAN client to WAN or tunnel | Browser request | FORWARD |
| Router-originated | DDNS update, NTP | OUTPUT |
| Addressed to the router | SSH from the LAN | INPUT |
ในงานออกแบบส่วนใหญ่คุณไม่จำเป็นต้องมีสวิตช์ตัดการเชื่อมต่อบน INPUT แต่คุณต้องทำให้การเข้าถึงเพื่อจัดการยังทำงานได้ขณะอุโมงค์ล่ม มิฉะนั้นครั้งแรกที่ VPN ล้มเหลว คุณจะต้องขับรถไปที่สำนักงานพร้อมสายคอนโซล
จัดลำดับกฎเพื่อให้อุโมงค์ยังคงขึ้นได้
สวิตช์ตัดการเชื่อมต่อที่ใช้งานได้คือรายการอนุญาตที่ลงท้ายด้วยการปฏิเสธ และลำดับคือสิ่งที่ทำให้มันเป็นสวิตช์ตัดการเชื่อมต่อไม่ใช่อิฐ อนุญาตลูปแบ็ก ปลายทาง VPN การตอบกลับของโฟลว์ที่สร้างแล้ว และอินเทอร์เฟซอุโมงค์ก่อน แล้วปฏิเสธส่วนที่เหลือเป็นลำดับสุดท้าย
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 51820 -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j REJECTณ จุดนี้ปลายทางต้องเป็นที่อยู่ ไม่ใช่ชื่อโฮสต์ เมื่อการปฏิเสธสุดท้ายบล็อก DNS กฎที่ระบุชื่อโฮสต์ของผู้ให้บริการจะถูกแปลงไม่ได้อีกต่อไป และ อุโมงค์จะไม่เริ่มอีกเลยหลังรีบูต หากผู้ให้บริการหมุนเวียนปลายทาง ให้แปลงชื่อก่อนใช้นโยบายและรีเฟรชกฎนั้นจากสคริปต์เดียวกัน
สะท้อนรูปแบบเดียวกันใน FORWARD สำหรับทราฟฟิกไคลเอนต์ และวางกฎการจัดการที่ชัดเจนไว้เหนือการปฏิเสธ รักษากฎการจัดการนั้นให้แคบแต่เข้าถึงได้ และยืนยันด้วยการเปิดเซสชัน SSH ที่สองก่อนปิดเซสชันแรก การล็อกตัวเองออกระหว่างเปลี่ยนสวิตช์ตัดการเชื่อมต่อเป็นเรื่องปกติพอที่จะต้องวางแผน บนเราเตอร์ที่รัน WireGuard ค่า allowed-ips ของเพียร์เป็นตัวกำหนดว่าอะไรเข้าอุโมงค์ ขณะที่กฎเหล่านี้กำหนดว่าอะไรได้รับอนุญาตให้ออกโดยไม่มีอุโมงค์
IPv6 ต้องการประตูหน้าของตัวเอง
ทั้งหมดข้างต้นเป็น IPv4 หาก LAN ของคุณมี IPv6 ที่ใช้งานได้และอุโมงค์พาเฉพาะ IPv4 ทุกอุปกรณ์ที่ถูกครอบคลุมยังมีเส้นทางตรงสู่อินเทอร์เน็ตที่กฎใหม่ของคุณมองไม่เห็น แล็ปท็อปแบบ dual-stack จะเลือกเส้นทางนั้นอย่างยินดี และสวิตช์ตัดการเชื่อมต่อจะดูเสียเฉพาะกับคนที่ทดสอบด้วย IPv4
ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPTลำดับก็สำคัญที่นี่เช่นกัน การอนุญาตลูปแบ็กต้องมาก่อนการปฏิเสธ WAN ไม่เช่นนั้นบริการภายในบนเราเตอร์จะเริ่มล้มเหลวอย่างแปลกประหลาด หากเครือข่ายไม่ใช้ IPv6 เลย การปิดใช้งานบน WAN และ LAN ง่ายกว่าและไม่เหลืออะไรให้ลืม
ไคลเอนต์ VPN บางตัวติดตั้งเส้นทางเริ่มต้นเฉพาะ IPv4 และปล่อยค่าเริ่มต้น IPv6 ที่มีอยู่ไว้ไม่แตะต้อง ตรวจสอบตารางเส้นทางหลังอุโมงค์เชื่อมต่อ แทนที่จะสมมติว่าไคลเอนต์จัดการแล้ว
พิสูจน์ด้วยการปิดอุโมงค์
หยุดอุโมงค์จากเราเตอร์และทดสอบจากสามที่ตามลำดับนี้
# systemctl stop wg-quick@wg0
# ip route get 203.0.113.1
# curl -m 5 -sS http://example.com || echo blocked
# iptables -vnL OUTPUT | head
# ip6tables -vnL OUTPUT | headการค้นหาเส้นทางบอกคุณว่าแพ็กเก็ตจะไปที่ไหน และตัวนับบอกคุณว่ากฎของคุณเคยตรงกันหรือไม่ กฎที่ไม่มีแพ็กเก็ตเลยหลังการทดสอบที่ล้มเหลวไม่ได้ปกป้องอะไร และสาเหตุปกติคือชื่ออินเทอร์เฟซที่ต่างจากที่คุณพิมพ์ ทดสอบทราฟฟิกที่เราเตอร์สร้างอย่างชัดเจน เพราะการทดสอบฝั่ง LAN ไม่สามารถใช้ OUTPUT ได้
ตัดสินใจโหมดความล้มเหลวก่อนที่คุณจะต้องใช้ fail-closed ทำให้ไคลเอนต์ออฟไลน์จนกว่าอุโมงค์จะกลับมา ส่วน fail-open คืนการเข้าถึง WAN ปกติและทำลายจุดประสงค์สำหรับทราฟฟิกที่คุณใส่ใจ เส้นทาง blackhole ไปยังพูล VPN ที่มีเมตริกสูงเป็นชั้นที่สองที่มีประโยชน์สำหรับการออกแบบ fail-closed เพราะมันอยู่รอดเมื่อเส้นทางอุโมงค์หายไปแทนที่จะถอยกลับไปใช้ค่าเริ่มต้น
ยอมรับการตั้งค่าก็ต่อเมื่อไคลเอนต์ LAN คำขอที่เราเตอร์สร้าง และคำขอ IPv6 ล้มเหลวทั้งหมดขณะอุโมงค์ปิด และทั้งสามทำงานได้อีกครั้งเมื่ออุโมงค์ขึ้น