แอปที่ผูกกับที่อยู่ VPN ยังคงใช้เส้นทางผิด

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

ส่วนที่เหลือของคู่มือนี้คือลำดับการตรวจสอบที่ผมใช้ พร้อมคำสั่งที่ให้ข้อมูลสังเกตแต่ละอย่าง

การผูกตัดสินอะไรจริง ๆ

การผูกกำหนดที่อยู่ภายในให้กับซ็อกเก็ต จากนั้นเคอร์เนลจะทำการค้นหาเส้นทางเดียวกันกับที่มันจะทำอยู่แล้ว เว้นแต่กฎนโยบายจะเปลี่ยนว่าการค้นหานั้นอ่านตารางใด

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

เอกสารอ้างอิงซ็อกเก็ต IP ของ Linux อธิบายความหมายของการผูก ครึ่งหนึ่งเรื่องการกำหนดเส้นทางอยู่ใน ip-rule และ ip-route และทั้งสองเป็นคู่มือแยกกันด้วยเหตุผล

ยืนยันว่าที่อยู่เป็นของเนมสเปซนี้

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

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

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

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

คำสั่งเดียวตอบคำถามที่การผูกไม่ได้ตอบ:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

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

จากนั้น ip rule show บอกคุณว่ามีกฎใดจะเลือกตารางอื่นหรือไม่ ลำดับความสำคัญมีความหมายที่นี่ เพราะกฎแรกที่ตรงกันจะชนะ และกฎที่ดักจับทุกอย่างเหนือกฎของคุณจะทำให้กฎของคุณมองไม่เห็น

ติดตั้งกฎนโยบายเฉพาะเมื่อนั่นคือการออกแบบ

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

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

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

ย้อนกลับด้วย ip rule del และ ip route flush table 100 สิ่งใดก็ตามที่เพิ่มด้วยวิธีนี้จะหายไปเมื่อรีบูต เว้นแต่ผู้จัดการจะเขียนมันไว้ ซึ่งเป็นทั้งคุณสมบัติด้านความปลอดภัยและเหตุผลที่จะไม่เก็บสำเนาเดียวไว้ในประวัติเชลล์ของคุณ

ตรวจสอบด้วยข้อมูลสังเกตสามอย่าง

บันทึกต้นทางที่แอปขอ เส้นทางที่การค้นหาเลือก และต้นทางที่เซิร์ฟเวอร์เห็นจริง

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

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