ทำไมนโยบายความปลอดภัย IPsec จึงไม่ใช่รายการในตารางเส้นทาง

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

เริ่มจากผลการค้นหา ไม่ใช่ตาราง

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

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

จับคู่ตัวเลือกทั้งสองฝั่ง

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

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

การตรงกันของนโยบายไม่ใช่สถานะที่ติดตั้งแล้ว

นโยบายที่ตรงกันบอกเพียงว่าแพ็กเก็ตต้องได้รับการป้องกัน เคอร์เนลยังต้องมีความเชื่อมโยงด้านความปลอดภัยเพื่อทำการป้องกัน แสดงรายการด้วย ip xfrm state หรือด้วย swanctl --list-sas เมื่อ strongSwan เป็นผู้เจรจา และอ่านตัวเลือกกับตัวนับในแต่ละรายการ

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

สิ่งที่อุโมงค์แบบอิงเส้นทางยังต้องการ

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

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

ตัดสินความเป็นเจ้าของก่อนแก้ไขอะไร

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

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