ทางออกแยก: พูล VPN บน usb0 ทราฟฟิกของเกตเวย์บน eth0

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

ยืนยันว่าแอดเดรสต้นทางยังอยู่จนถึงการตัดสินใจเลือกเส้นทาง

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

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

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

สร้างตารางที่เลือกไว้ให้ครบถ้วน

ตารางไม่ใช่เส้นทางเริ่มต้นที่มีเพื่อนคู่ใจ ต้องมีเส้นทางพอให้ทุกการค้นหาแก้ได้ภายในตาราง รวมถึงเส้นทางที่เชื่อมต่อสำหรับซับเน็ต WAN เพื่อให้ฮอปถัดไปเข้าถึงได้ สำหรับพูล 10.77.0.0/24 บน tun1 แอดเดรส WAN 203.0.113.20/24 ที่มีฮอปถัดไป 203.0.113.1 และตาราง 600:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

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

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

แยกทราฟฟิกของตัวผู้รับฟังเองออกจากนโยบาย

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

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

ลำดับก็สำคัญเมื่อเทียบกับอย่างอื่นบนเครื่อง บริดจ์ Docker, VPN ตัวที่สอง และกฎใด ๆ ที่มีอยู่ก่อนจากอิมเมจของผู้ให้บริการล้วนเพิ่มลำดับความสำคัญ ดังนั้น อ่านรายการกฎทั้งหมดแทนการถือว่าลำดับความสำคัญ 100 อยู่ลำพัง

ทำให้การส่งต่อและการแปลสอดคล้องกับเส้นทาง

การเลือกเส้นทางเลือกอัปลิงก์ แต่ไม่ได้ให้สิทธิ์ในการส่งต่อ เคอร์เนลต้องเปิดการส่งต่อ IPv4 และไฟร์วอลล์ต้องยอมรับทิศทางจากไคลเอนต์ไปยัง WAN รวมถึงทราฟฟิกขากลับ ตารางที่ถูกต้องพร้อมเชน FORWARD ที่ทิ้งโฟลว์ให้อาการเดียวกับเส้นทางที่หายไป จึงต้องตรวจทั้งสองอย่างในการตรวจครั้งเดียวกัน

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

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

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

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

ตัดสินใจว่าจะเกิดอะไรขึ้นเมื่อ usb0 หายไป

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

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

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