ASA hairpin: ออกสู่อินเทอร์เน็ตหรือขา VPN ระหว่างไซต์?

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

สองขา หนึ่งอินเทอร์เฟซ

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

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

same-security-traffic permit intra-interface

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

ขา A: ไคลเอนต์ต้องการอินเทอร์เน็ต

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

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

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

ส่วนที่เหลือของขาเป็นเรื่องปกติ: เส้นทางเริ่มต้นหรือเส้นทางเฉพาะที่ใช้ได้จากอินเทอร์เฟซภายนอก นโยบายการเข้าถึงที่อนุญาตการไหล และ DNS ที่จัดการตามนโยบายตัวแก้ไขที่คุณเลือก เพิ่ม route-lookup ตรงนี้ด้วยเหตุผลเดียวกับด้านล่าง เนื่องจากอินเทอร์เฟซขาเข้าและขาออกเหมือนกัน

ขา B: ไคลเอนต์ต้องการไซต์ส่วนตัว

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

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

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

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

การทดสอบที่บอกคุณว่าคุณสร้างขาไหน

ใช้การประเมินเส้นทางของ ASA เองแทนการอ่านการกำหนดค่าแล้วหวัง packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed แสดงการตัดสินใจ NAT เส้นทาง และผลลัพธ์ ACL สำหรับการไหลหนึ่ง ทำซ้ำด้วยปลายทางส่วนตัว ถ้าเฟส NAT เขียนการไหลจากส่วนตัวเป็นส่วนตัวใหม่ คุณสร้างขา A สำหรับแพ็กเก็ตที่ต้องการขา B

อีกสองคำสั่งปิดช่องว่าง show nat detail พิมพ์ลำดับกฎที่ packet-tracer ตาม และ show crypto ipsec sa แสดงว่ามีตัวเลือกสำหรับคู่ที่คุณคาดไว้หรือไม่ SA ที่หายไปเป็นเรื่องของการกำหนดค่าตัวเลือกหรือเพียร์ ไม่ใช่สิ่งที่กฎ NAT จะแก้ได้

ตรวจสอบแต่ละขาด้วยทราฟฟิกที่มันให้บริการ

ยอมรับขา A ด้วยคำขอสาธารณะปกติจากไคลเอนต์ และยอมรับขา B ด้วยคำขอไปยังทรัพยากรส่วนตัวที่มีอยู่จริง จากนั้นทำซ้ำแต่ละอันด้วยทรัพยากรที่ถูกปฏิเสธ เพราะ “อนุญาตแล้ว” กับ “อนุมัติโดยนโยบายการเข้าถึง” ไม่ใช่หลักฐานเดียวกัน และ ping ที่เริ่มจากฮับไม่ได้ฝึกเส้นทางไคลเอนต์ใดเลย

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