แอปผูกกับอินเทอร์เฟซอยู่หรือไม่? เส้นทาง VPN ของมันไม่ใช่ค่าเริ่มต้น

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

การผูกสามแบบที่ต่างกัน ผลลัพธ์สามแบบที่ต่างกัน

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

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

พิจารณาว่าแอปตั้งค่าอะไรจริง ๆ

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

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

เราเตอร์ตามนโยบายอ่านต้นทาง

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

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

อุโมงค์แยกและโปรเซสช่วย

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

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

ทดสอบเส้นทางของแอปเอง

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

เอกสารอ้างอิงซ็อกเก็ตของ Linux บันทึก SO_BINDTODEVICE และข้อกำหนดของมัน อ่านการกำหนดค่าของแอปเองก่อน ทำการค้นหาซ้ำในบริบทเดียวกัน แล้วจึงตัดสินว่าต้องเปลี่ยนเส้นทางหรือการผูก