เส้นทางเริ่มต้นของ XFRM กลืน IKE และ ESP: รักษาเส้นทางภายนอก

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

ปลายทางสองแห่งที่เกี่ยวข้องใช้แทนกันไม่ได้ การกำหนดเส้นทางต้องบอกเช่นนั้นอย่างชัดเจน

การค้นหาเพียร์ไปที่ใดจริง ๆ

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

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

ip rule show
ip route show table 220
ip -4 route get 198.51.100.44 from 10.40.0.2
ip xfrm policy list

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

ตัวเลือกการยกเว้นบนเกตเวย์สมัยใหม่

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

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

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

มาร์กคือหนึ่งบิตใน fwmark ของแพ็กเก็ตที่ไม่มีสิ่งอื่นใดบนเกตเวย์อ้างสิทธิ์: 0x1 กับมาสก์ 0x1 เป็นตัวเลือกปกติ และต้องตั้งค่าในสองตำแหน่งเพื่อให้การยกเว้นทำงาน Charon ต้องการมันบนซ็อกเก็ต IKE และการตั้งค่ามาร์กขาเข้าและขาออกของการเชื่อมต่อลูกก็ต้องการค่าเดียวกัน เพื่อให้แพ็กเก็ตที่ห่อหุ้มออกไปโดยมีมาร์กด้วย มาสก์ 0x1 แทน 0xffffffff ปล่อยบิตที่เหลือให้ว่าง ซึ่งสำคัญเมื่อระบบย่อยอื่นทำเครื่องหมายแพ็กเก็ตบนโฮสต์เดียวกันอยู่แล้ว เมื่อตั้งค่าทั้งสองแล้ว กฎจะถูกเขียนเป็นการยกเว้น ดังนั้นแพ็กเก็ตที่ทำเครื่องหมายจะข้ามตารางที่มีเส้นทาง XFRM และตกไปยังตารางหลัก:

ip rule add not fwmark 0x1/0x1 lookup 220 pref 1000
ip -4 route get 198.51.100.44 from 10.40.0.2 mark 0x1

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

การติดตั้งอัตโนมัติถือว่าอะไรเกี่ยวกับการสร้าง

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

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

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

เฝ้าดูการต่ออายุครั้งแรก

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

ip -4 route get 198.51.100.44
sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or esp'

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

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