ทันเนลแบบเต็มใน strongSwan ต้องมี 0.0.0.0/0 ทั้งสองฝั่ง

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

ตรวจสอบตัวเลือกของไคลเอนต์ก่อน

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

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

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

ตรวจสอบตัวเลือกของเกตเวย์ในฝั่งของมันเอง

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

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

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

ipsec.conf แบบเก่าใช้บทบาทซ้ายและขวาด้วยคีย์ต่างกัน และบรรทัด rightsubnet ไม่ใช่ตัวแทนโดยตรงของค่า swanctl เก็บไวยากรณ์ทั้งสองไว้ในไฟล์แยกแทนการวางซ้อนกัน การผสมทั้งสองในไดเรกทอรีเดียวคือวิธีที่การเชื่อมต่อที่ใช้งานได้ย้อนกลับอย่างเงียบ ๆ หลังรีบูต

ตรวจสอบ child SA ที่เจรจาแล้ว ไม่ใช่ไฟล์

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

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

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

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

ตรวจสอบการส่งต่อและเส้นทางขากลับ

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

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

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

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

ตรวจสอบสิ่งที่ทันเนลยังไม่ครอบคลุม

คู่ตัวเลือกครอบคลุม IPv4 และไม่มีอย่างอื่น IPv6, DNS และนโยบายระดับแอปพลิเคชันใด ๆ เป็นการตัดสินใจแยกต่างหากที่ตัวเลือก IPv4 แบบกว้างเพิกเฉยอย่างเงียบ ๆ ทันเนลที่พาทุกแพ็กเก็ต IPv4 ยังสามารถรั่วทุกการค้นหาชื่อได้

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

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

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