กำหนดเส้นทางเฉพาะบริการเว็บภายในเครื่องหนึ่งบริการให้ออกนอก VPN ตามพอร์ต

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

ตรวจสอบสามเงื่อนไขก่อนเขียนกฎ

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

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

จับคู่คำตอบ ไม่ใช่พอร์ตปลายทางของไคลเอนต์

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

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

สร้างตารางส่งคืนที่สมบูรณ์ก่อนที่กฎจะชี้ไปที่ตารางนั้น

ตารางว่างหมายถึงไม่มีเส้นทาง ซึ่งดูเหมือนบริการที่เสียหายมากกว่านโยบายที่เสียหาย เติมตารางก่อน ด้วยหมายเลขตารางและลำดับความสำคัญที่ไม่มีสิ่งอื่นใดบนโฮสต์อ้างสิทธิ์:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

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

ตัวเลือกสองตัวทำงานจริงที่นี่ iif lo คือวิธีที่เคอร์เนลรายงานแพ็กเก็ตที่โฮสต์สร้างขึ้นเอง กฎจึงไม่สามารถจับทราฟฟิกที่ส่งต่อจากภายนอกได้โดยไม่ตั้งใจ ipproto tcp sport 443 จำกัดให้เหลือการขนส่งเดียวและพอร์ตเดียว ซึ่งแน่นที่สุดเท่าที่ข้อกำหนดอนุญาต ถอดตัวเลือกโปรโตคอลออกแล้วกฎจะจับ UDP 443 ด้วย ซึ่งเป็นบริการอื่นที่มีพฤติกรรมต่างกัน

เก็บคำตอบส่วนตัวไว้ในทันเนล

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

ip -4 route add table 100 throw 10.90.0.0/24

เส้นทาง throw จบการค้นหาในตารางนี้และคืนแพ็กเก็ตให้รายการกฎ นโยบาย VPN ที่ตามมาจึงมีโอกาสของมัน เส้นทางนี้ไม่ได้กำหนดเส้นทางใด ๆ เข้าทันเนลเอง และหากไม่มีกฎใดในภายหลังมีเส้นทางที่ตรงกัน แพ็กเก็ตก็ยังล้มเหลว ตรวจสอบนโยบายถัดไปแทนการถือว่า throw คือการแก้ไข

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

ทดสอบ TCP จากนั้น QUIC จากนั้นรีบูต

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

HTTP/3 ให้บริการผ่าน UDP และจะไม่ถูกจับคู่ด้วยกฎ TCP ตัวรับฟัง QUIC จึงต้องมีตัวเลือกของตัวเอง มิฉะนั้นจะยังใช้ทันเนลขณะที่ HTTPS ทำงาน บันทึกกฎที่คุณเลือกไว้กับคอมโพเนนต์ที่เป็นเจ้าของอินเทอร์เฟซ และยืนยันอีกครั้งหลังเชื่อมต่อใหม่หรือต่ออายุ DHCP เมื่อตัวจัดการที่แข่งขันกันลบเส้นทางขณะรันไทม์หลังรีบูต นั่นคือปัญหาความเป็นเจ้าของที่ต้องแก้ที่ต้นทาง ไม่ใช่เหตุผลที่จะเพิ่มกฎ NAT ที่กว้างกว่าทับลงไป