การตอบกลับของ VPN บน Linux หายไป? ตรวจสอบ rp_filter และเส้นทาง

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

การตรวจสอบแหล่งที่มากำหนดอะไร

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

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

อ่านโหมดที่มีผลจริง ไม่ใช่แค่ฟิลด์เดียว

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

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

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

หาความไม่สอดคล้องก่อนเปลี่ยนการตรวจ

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

หากเส้นทางย้อนกลับหายไปเฉย ๆ การเพิ่มเส้นทางนั้นแก้ที่สาเหตุแทนที่จะปิดการตรวจ เส้นทางที่หายไป การถูกไฟร์วอลล์ปฏิเสธ และตัวเลือกทราฟฟิกที่ผิด ล้วนสร้างอาการที่มองเห็นเหมือนกัน และมีเพียงหนึ่งเดียวที่เกี่ยวกับการตรวจสอบแหล่งที่มา

อย่าปิดการตรวจสอบแหล่งที่มาแบบทั่วโลกเป็นปฏิกิริยาแรก เพราะนั่นแลกการวินิจฉัยที่เฉพาะเจาะจงกับการเปลี่ยนพฤติกรรมในวงกว้างที่คุณต้องจดจำภายหลัง

การปรับแบบเลือกได้ที่คุณปกป้องได้

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

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

แยก IPv4 และ IPv6 ออกจากกัน

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

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