การเข้าถึงไคลเอนต์ IKEv2 บน IP เสมือนที่จัดสรรให้

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

อุโมงค์ไม่ได้แก้ที่อยู่ต้นทาง

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

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

อ่านนโยบายที่ติดตั้งไว้ ไม่ใช่ไฟล์กำหนดค่า

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

ipsec statusall
ip xfrm policy

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

ไคลเอนต์ต้องรอฟังตรงที่แพ็กเก็ตมาถึง

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

ss -ltnp 'sport = :9090'
iptables -S INPUT

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

ทดสอบทิศทางใหม่แยกต่างหาก

คำขอที่สำเร็จจากไคลเอนต์ไปยังเซิร์ฟเวอร์ไม่เคยทดสอบเส้นทางนี้ สร้างคำขอจากเกตเวย์และสังเกตทั้งสองด้าน

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

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

ทำการทดสอบซ้ำหลังเปลี่ยนคีย์หรือเชื่อมต่อใหม่ เพราะ VIP อาจเปลี่ยน เส้นทางที่ใช้ได้เพียงถึงเซสชันถัดไปไม่ใช่เส้นทางที่ใช้งานได้