ทำไมไคลเอนต์ VPN บน LAN ของออฟฟิศจึงทิ้งทุกคำตอบ
แล็ปท็อปที่อยู่ทั้งบน LAN ของออฟฟิศและบนอุโมงค์ในซับเน็ตเดียวกันตอบกลับจากอินเทอร์เฟซผิด การกรองเส้นทางย้อนกลับแบบหลวมอธิบายความเงียบนี้
แล็ปท็อปเครื่องหนึ่งอยู่บน /24 ของออฟฟิศผ่านอีเทอร์เน็ต และยังเข้าร่วมเซิร์ฟเวอร์ OpenVPN ที่อาศัยอยู่ใน /24 เดียวกันด้วย เพื่อนร่วมงานส่ง ping ไปที่ที่อยู่ของอุโมงค์ คำขอมาถึงอย่างชัดเจน แต่ไม่มีอะไรส่งกลับไป บันทึกของอุโมงค์สะอาดและการท่องเว็บยังทำงานได้ ดังนั้นอุโมงค์จึงเป็นผู้ต้องสงสัยที่ผิด การตรวจสอบต้นทาง IPv4 บนเครื่องที่รับนั้นทิ้งแพ็กเก็ตก่อนที่สิ่งใดจะอ่านมัน
การทิ้งเกิดขึ้นก่อนที่สิ่งใดจะอ่านแพ็กเก็ต
การตรวจสอบต้นทางถามคำถามหนึ่งข้อเกี่ยวกับทุกแพ็กเก็ตที่เข้ามา ถ้าโฮสต์นี้ตอบกลับต้นทางนั้น คำตอบจะออกผ่านอินเทอร์เฟซที่แพ็กเก็ตเพิ่งเข้ามาหรือไม่ เมื่อคำตอบคือไม่ เคอร์เนลจะทิ้งแพ็กเก็ตทันทีที่มาถึง ไม่มีซ็อกเก็ตหรือเส้นทางส่งต่อใดเห็นมันเลย ดังนั้นการดักจับบนอุโมงค์ยังคงบันทึกคำขอที่แอปพลิเคชันไม่เคยได้รับ
ไคลเอนต์ที่นี่ถือ 10.66.0.9 บนอุโมงค์ของตน และเซิร์ฟเวอร์ OpenVPN ตอบกลับที่ 192.168.80.10 ภายในคำนำหน้าของออฟฟิศ เพื่อนร่วมงานที่ 192.168.80.25 ส่ง ping ไปที่ที่อยู่ของอุโมงค์ คำขอจึงข้าม LAN เซิร์ฟเวอร์ส่งต่อไปยังอุโมงค์ และมันมาถึงอินเทอร์เฟซอุโมงค์ของไคลเอนต์พร้อมที่อยู่ต้นทางของออฟฟิศ ในตารางเส้นทางของเครื่องนั้น คำนำหน้าของออฟฟิศเป็นของอุปกรณ์อีเทอร์เน็ต ไม่ใช่ของอุโมงค์ การตรวจสอบเปรียบเทียบอินเทอร์เฟซที่มาถึงกับเส้นทาง พบความไม่ตรงกันและทิ้งแพ็กเก็ต เพื่อนร่วมงานจึงเห็นการสูญหายทั้งหมดขณะที่ทั้งสองปลายรายงานอุโมงค์ที่สมบูรณ์
ทิศทางกระจกมีรูปร่างเดียวกัน เมื่อไคลเอนต์เริ่มไปยังออฟฟิศ คำตอบอาจถูกทิ้งทางฝั่งออฟฟิศด้วยเหตุผลเดียวกัน การแก้ไขที่ตรวจสอบเพียงทิศทางเดียวมักกลับมาเป็นตั๋วใบที่สอง
พิสูจน์โหมดที่บังคับใช้ก่อนแตะ sysctl ใด ๆ
อ่านค่าที่มีผลจริงแทนการเชื่อถือค่าเริ่มต้นของดิสทริบิวชัน เพราะการตั้งค่าต่ออินเทอร์เฟซเป็นเพียงครึ่งเดียวของการตัดสินใจ โหมดที่บังคับใช้คือค่าที่สูงกว่าระหว่างค่าอินเทอร์เฟซกับค่าของ all ดังนั้นศูนย์บนอินเทอร์เฟซอุโมงค์ไม่มีความหมายตราบใดที่ all เป็นหนึ่ง การตัดสินใจของโหมดเข้มงวดเป็นการตัดสินใจเรื่องเส้นทาง ดังนั้นให้รันการค้นหาที่เคอร์เนลรันและเปรียบเทียบคำตอบกับอินเทอร์เฟซที่แพ็กเก็ตมาถึงจริง
tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filterจากนั้นทำ ping ซ้ำพร้อมเฝ้าดูตัวนับข้อผิดพลาด ตัวเลขที่เพิ่มขึ้นข้างคำขอที่การดักจับแสดงอยู่แล้วคือลายเซ็นของการทิ้งนี้ ไม่ใช่ของเส้นทางที่หายไป เปิดการบันทึกแพ็กเก็ตดาวอังคารขณะอยู่ที่นั่น เพื่อให้เคอร์เนลระบุต้นทางและอินเทอร์เฟซที่มันปฏิเสธ ด้วยกันทั้งสองตัดการเข้ารหัส ไฟร์วอลล์ และ iroute ที่หายไปออกจากคำอธิบาย
จดเส้นฐานก่อนเปลี่ยนแปลงสิ่งใด ทั้งสองค่า อุปกรณ์ที่การค้นหาเลือก และตัวนับที่คุณเฝ้าดู บันทึกนั้นคือสิ่งที่บอกคุณภายหลังว่าการเปลี่ยนแปลงทำในสิ่งที่คุณคิดหรือไม่
แต่ละโหมดของ rp_filter ยอมรับอะไรจริง ๆ
เคอร์เนลแสดงค่าสามค่าต่ออินเทอร์เฟซ และมันไม่ใช่สามเฉดของกฎเดียว ศูนย์ปิดการตรวจสอบ หนึ่งเข้มงวดและกำหนดให้ต้นทางถูกส่งเส้นทางกลับออกทางอินเทอร์เฟซที่มาถึง สองหลวมและกำหนดเพียงให้มีเส้นทางใด ๆ ไปยังต้นทางในตาราง ไม่ว่ามันจะชี้ไปที่ใด
| Value | Name | Accepts | Still rejects |
|---|---|---|---|
| 0 | off | any source at all | nothing on this check |
| 1 | strict | a source routed back out the arrival interface | a source whose route points elsewhere |
| 2 | loose | a source with any route in the table | a source with no route at all |
แถวที่สำคัญที่นี่คือแถวหลวม และสิ่งที่มันยังคงปฏิเสธ ต้นทางปลอมที่ส่งเส้นทางได้ทุกที่ในตารางของคุณผ่านไป ขณะที่ต้นทางที่ไม่มีเส้นทางเลยยังคงถูกปฏิเสธ บนแล็ปท็อปนี่คือสัมปทานแคบ ๆ บนเราเตอร์ที่ส่งต่อทราฟฟิกของผู้อื่นมันกว้าง โหมดเป็นของโฮสต์ ตัวเลขเดียวกันจึงมีน้ำหนักต่างกันในสองที่
โทโพโลยีนี้ต้องการแถวใดนั้นมาจากตาราง ไม่ใช่จากนิสัย แพ็กเก็ตถูกต้องและต้นทางของมันส่งเส้นทางได้ ดังนั้นตัวหลวมยอมรับและตัวเข้มงวดไม่ยอมรับ ไม่มีสิ่งใดในกรณีนี้เรียกร้องศูนย์ และการเลือกศูนย์จะลบการตรวจสอบที่ไม่เสียค่าใช้จ่ายใด ๆ ที่นี่
เลือกการเปลี่ยนแปลงที่เล็กที่สุดซึ่งขจัดความกำกวม
โหมดหลวมคือการเปลี่ยนแปลงที่เล็กที่สุดที่พอดี และมันคือการลดความเข้มงวดจริง ไม่ใช่สวิตช์ที่ไม่มีอันตราย มีทางเลือกที่ดีกว่าทุกครั้งที่โทโพโลยีอนุญาต ลบการทับซ้อนออก แล้วความกำกวมก็หายไป
ที่ซึ่งคำนำหน้าของออฟฟิศจำเป็นเฉพาะผ่านอีเทอร์เน็ต ให้นำมันออกจากเส้นทางที่โปรไฟล์ดึงมา แล้วที่อยู่จะเข้าถึงได้ทางเดียว เมื่อทั้งสองเส้นทางต้องอยู่ร่วมกันจริง ๆ ให้ปักหมุดต้นทางและอุปกรณ์ด้วยกฎนโยบายแทนการคลายการตรวจสอบบนทุกอินเทอร์เฟซ สิ่งนี้รักษาการกรองที่เข้มงวดสำหรับทุกอย่างอื่นบนเครื่อง และบันทึกข้อยกเว้นไว้ที่ที่วิศวกรคนต่อไปจะมองหา
ไม่ว่าคุณจะเลือกเส้นทางใด ให้บันทึกไว้ใน sysctl drop-in ไม่ใช่ในคำสั่งที่ใช้งานอยู่ ตั้งค่าคีย์ all และ default ไว้ด้วยกัน เพื่อให้การเชื่อมต่อใหม่ไม่สามารถคืนโหมดเข้มงวดอย่างเงียบ ๆ
# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --systemโหมดหลวมยอมสละอะไร และที่ใด
โหมดหลวมยังคงปฏิเสธต้นทางที่ไม่มีเส้นทางใดเข้าถึงได้ และหยุดปฏิเสธต้นทางปลอมที่บังเอิญส่งเส้นทางได้ บนแล็ปท็อปนี่คือสัมปทานแคบ ๆ บนอุปกรณ์ที่ส่งต่อทราฟฟิกที่ไม่ใช่ของมัน ทางเลือกเดียวกันนั้นกว้างกว่ามาก ดังนั้นการตั้งค่าเดียวกันจึงมีความหมายต่างกันมากสองอย่างขึ้นอยู่กับว่ามันทำงานที่ใด
การปิดการตรวจสอบทั้งหมดบนโฮสต์ที่ส่งต่อทราฟฟิกให้ผู้อื่นคือการซ่อมแซมเดียวที่ควรหลีกเลี่ยง ศูนย์ทิ้งการตรวจสอบที่โหมดหลวมรักษาไว้อย่างระมัดระวัง หากโฮสต์ส่งต่อให้ผู้อื่น ให้โต้แย้งเพื่อทางเลือกกฎนโยบายจากส่วนก่อนแทน
ทิ้งบันทึกที่ระบุอินเทอร์เฟซทั้งสอง คำนำหน้าที่ทับซ้อน และการทดสอบที่แน่นอนซึ่งตอนนี้สำเร็จ นั่นมีประโยชน์ต่อวิศวกรคนต่อไปมากกว่าบรรทัดที่บอกว่าปรับการกรองแล้ว