ไคลเอนต์ VPN ลบเส้นทางที่คุณเพิ่ม? ใช้ตารางนโยบาย

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

ตัวเฝ้าดูอธิบายเส้นทางที่หายไป

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

ip route show
ip route add 192.168.2.0/24 dev enp0s31f6
sleep 5; ip route show

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

ตารางที่สองมองไม่เห็นสำหรับตัวเฝ้าดู

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

การแลกเปลี่ยนคือการบำรุงรักษา วัตถุสองอย่างอาจแยกจากกัน และตำแหน่งของกฎในรายการสำคัญพอ ๆ กับเส้นทางในตารางที่มันเลือก

สร้างข้อยกเว้นแล้วทำให้มันชนะ

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

ip rule add to 192.168.2.0/24 table 110 pref 30010
ip route add 192.168.2.0/24 dev enp0s31f6 table 110
ip route get 192.168.2.50

ip route get แก้ไขเส้นทางที่เคอร์เนลจะใช้ รวมถึงอุปกรณ์และที่อยู่ต้นทาง มันไม่พิมพ์ตัวระบุตาราง ดังนั้นจับคู่กับ ip rule show เมื่อคุณต้อง ยืนยันว่าตารางใดชนะ เมื่อรวมกันแล้วทั้งสองตอบคำถามเดียวที่สำคัญ: ทราฟฟิกไปยังที่อยู่นั้นออกจากที่ที่คุณตั้งใจหรือไม่?

รูปแบบอื่นของแนวคิดเดียวกัน

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

ip rule add iif wlan0 table 10
ip route add default dev tun0 table 10

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

ถือว่ากฎเป็นสิ่งที่ใช้ครั้งเดียว

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

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

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