กำหนดเส้นทางหนึ่งบัญชี Linux ผ่าน OpenVPN ด้วยกฎ UID

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

ตัวอย่างด้านล่างสมมติว่ามีบัญชีเบราว์เซอร์เฉพาะที่ UID 1500 อุปกรณ์อุโมงค์ tun-office ที่ถือที่อยู่ท้องถิ่น 10.80.0.11 และ VPN ที่อนุญาตปลายทางที่กล่าวถึง ตัวดีมอนเองทำงานนอก UID นั้น

สามเงื่อนไขที่เลือกกลไก

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

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

ตาราง กฎ และตัวป้องกัน

หลังจากตรวจสอบกฎที่มีอยู่และเลือกหมายเลขตารางกับลำดับความสำคัญที่ยังไม่ถูกใช้ โครงสร้างก็สั้น: เส้นทางเริ่มต้นในตารางเฉพาะที่ถือที่อยู่ต้นทางของอุโมงค์ กฎที่ส่งการค้นหาของบัญชีไปยังตารางนั้น และกฎปิดท้ายที่บล็อกเส้นทางสำรอง เมื่อเขียนออกมา นั่นคือการแทนที่เส้นทางแบบ idempotent, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, ตามด้วย ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820

ตัวป้องกันคือ ip -4 rule add priority 12101 uidrange 1500-1500 unreachable และสำคัญกว่าที่ความยาวของมันบอก ถ้าไม่มี เส้นทางที่หายไปในตาราง 51820 จะตกไปที่อัปลิงก์ปกติ และบัญชีจะรั่วทราฟฟิกที่นโยบายตั้งใจดักไว้อย่างเงียบ ๆ ถ้ามี ความล้มเหลวเดียวกันจะกลายเป็นหมดเวลา คือการบล็อกแทนที่จะเป็นเส้นทางสำรอง

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

สิ่งที่การกำหนดเส้นทางตาม UID ละไว้: DNS

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

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

IPv6 ต้องการประโยคของตัวเองในการออกแบบ

กฎข้างต้นครอบคลุมเฉพาะ IPv4 หากข้อกำหนดคืออุโมงค์ IPv4 ที่ไม่มี IPv6 ตรงจากบัญชีนี้ ให้เพิ่มกฎปิดท้ายที่ตรวจทานแล้วเช่น ip -6 rule add priority 12101 uidrange 1500-1500 unreachable แล้วตรวจสอบกฎ IPv6 ก่อนหน้าและข้อยกเว้น loopback ที่คุณต้องการเก็บไว้

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

ตรวจสอบด้วยบัญชีจริง แล้วรับผิดชอบวงจรชีวิต

เปรียบเทียบการค้นหา: ip -4 route get 198.51.100.25 uid 1500 กับปลายทางเดียวกันโดยใช้ UID ปกติ จากนั้นสร้างคำขอที่ได้รับอนุญาตภายใต้บัญชีเฉพาะและตรวจสอบที่อยู่ต้นทางที่ปลายทางไกลมองเห็น ที่อยู่ต้นทางที่ต้องการไม่ใช่ source NAT และจะไม่แทนที่แอปที่ผูกอย่างอื่น ถ้าการค้นหาทั้งสองให้เส้นทางเดียวกัน กฎไม่ได้ทำอย่างที่คุณคิด

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