IPsec ระหว่างโฮสต์สองเครื่อง: การป้องกันเริ่มและสิ้นสุดที่ใด
คู่โฮสต์สามารถป้องกันเฉพาะโฟลว์ที่เลือกได้โดยไม่ต้องมีเกตเวย์ กำหนดปลายทาง นโยบายที่เลือกทราฟฟิก และสิทธิ์ที่ต้องแยกจากกัน
การป้องกันบนคู่โฮสต์เริ่มต้นตรงจุดที่ security association สิ้นสุดลง และนี่คือข้อเท็จจริงที่สัญชาตญาณแบบเกตเวย์มักมองข้าม เซิร์ฟเวอร์แอปพลิเคชันกับเซิร์ฟเวอร์ฐานข้อมูลของมันสามารถป้องกันบทสนทนาของกันเองได้โดยตรง โดยไม่มีอุปกรณ์รวมการเข้าถึงระยะไกลอยู่ในเส้นทาง และขอบเขตการป้องกันก็อยู่ภายในโฮสต์แต่ละเครื่องแทนที่จะอยู่ในไฟร์วอลล์ สิ่งที่ได้มาคือการครอบคลุมแบบ end-to-end สำหรับโฟลว์ที่เลือก สิ่งที่ไม่ได้มาคือการตัดสินใจว่าใครควรอ่านแถวใด
ขอบเขตคือจุดที่ SA สิ้นสุด
RFC 4301 อธิบาย security association แบบ transport mode ว่าเป็นรูปแบบที่มักใช้ระหว่างโฮสต์คู่หนึ่งเพื่อการป้องกันแบบ end-to-end โฮสต์สองเครื่องนั้นถือกุญแจ และแต่ละเครื่องตัดสินใจว่าแพ็กเก็ตใดของตัวเองจะเข้าสู่ association อุโมงค์เกตเวย์สิ้นสุดลงที่อื่นโดยสิ้นเชิงและไปถึงโฮสต์ผ่านส่วนเชื่อมต่อภายในเพิ่มเติม ซึ่งเป็นขอบเขตความเชื่อถือที่แตกต่างออกไป แม้แพ็กเก็ตจะถูกเข้ารหัสตลอดการเดินทางส่วนใหญ่ก็ตาม
อย่างไรก็ตาม host-to-host กับ transport mode ไม่ใช่คำพ้องกัน โฮสต์สองเครื่องสามารถสร้าง association แบบ tunnel mode ระหว่างกันได้อย่างถูกต้องเช่นกัน ดังนั้นจึงควรเลือกโหมดก่อนแล้วจึงอธิบายปลายทาง จดทั้งสองอย่างไว้ในบันทึกการออกแบบข้างที่อยู่ของ peer เพราะผู้ตรวจทานที่รู้เพียงโหมดเดียวจะถือว่าอีกโหมดหนึ่ง
SPD ตัดสินใจเรื่องการป้องกัน เส้นทางตัดสินใจเรื่องทิศทาง
ตารางเส้นทางตอบว่าแพ็กเก็ตไปที่ใด security policy database ตอบว่าทราฟฟิกที่เลือกจะข้ามขอบเขตการป้องกันอย่างไร และตอบเป็นรายทิศทางด้วยตัวเลือกของตัวเอง การแยกส่วนนี้ทำให้เส้นทางที่ใช้งานได้ไปยังฐานข้อมูลไม่ได้พิสูจน์อะไรเลยว่าคำขอได้รับการป้องกัน และยังทำให้ การเจรจาที่สถาปนาแล้ว ไม่ได้พิสูจน์อะไรเลยว่าแอปพลิเคชันเฉพาะนี้ตรงกับมัน เปรียบเทียบตัวเลือกก่อนเปรียบเทียบตัวนับ เพราะตัวนับบรรยายเฉพาะโฟลว์ที่ไปถึงจุดนั้นแล้ว
บน Linux คำสั่ง ip xfrm policy พิมพ์รายการเหล่านั้นพร้อมทิศทาง ลำดับความสำคัญ ตัวเลือก และการกระทำแบบ allow, block หรือ trap ส่วน ip xfrm state แสดง association ที่เป็นผลลัพธ์และตัวนับของมัน การอ่านทั้งสองอย่างร่วมกันคือวิธีหาโฟลว์ที่แอบข้ามอุโมงค์ไปเงียบ ๆ เพราะรายการ allow ที่กว้างกว่าตรงก่อน
ลำดับความสำคัญเป็นส่วนหนึ่งของนโยบาย ไม่ใช่รายละเอียดการทำงาน รายการแคบที่ควรป้องกันพอร์ตฐานข้อมูลแพ้ให้กับรายการที่กว้างกว่าซึ่งมีลำดับความสำคัญสูงกว่า และความล้มเหลวนั้นดูราวกับว่านโยบายไม่เคยถูกตรวจสอบเลย
transport mode ครอบคลุมชั้นถัดไป ไม่ใช่ IP header
| Transport mode | Tunnel mode | |
|---|---|---|
| Original IP header | kept for routing the flow | replaced by an outer header |
| What ESP protects | the carried next-layer payload | the whole inner IP packet |
| Where it terminates | commonly the two hosts | gateway pair, or a host pair |
ใน transport mode ส่วนหัว ESP อยู่ระหว่าง IP header กับ payload และฟิลด์ที่อยู่ในส่วนหัวนั้นยังคงมองเห็นได้จากทุกอุปกรณ์บนเส้นทาง นั่นเป็นเรื่องปกติเมื่อที่อยู่ไม่ใช่ความลับและ payload ต่างหากที่เป็นความลับ แต่เป็นทางเลือกที่ผิดหากคุณต้องซ่อนโครงสร้างภายในด้วย เพราะมีเพียง tunnel mode เท่านั้นที่ห่อส่วนหัวเดิมไว้ในส่วนหัวใหม่
ทั้งสองโหมดสามารถบรรทุกโปรโตคอลชั้นถัดไปได้หลายแบบ และ ESP จะป้องกันสิ่งที่ตัวเลือกตรงเท่านั้น ไม่ใช่ทุกอย่างที่โฮสต์ส่ง
การเลือกแคบกว่าการเชื่อมต่อ
association หนึ่งรายการสามารถบรรทุกโฟลว์ได้หลายโฟลว์ แต่บรรทุกได้เฉพาะโฟลว์ที่นโยบายเลือกเท่านั้น บันทึกอัตลักษณ์ของ peer ที่อยู่ต้นทางและปลายทาง โปรโตคอล และขอบเขตบริการสำหรับความสัมพันธ์ที่คุณตั้งใจ แล้วตัดสินแยกต่างหากว่าทราฟฟิกที่ไม่ตรงนั้นส่งแบบไม่เข้ารหัสได้หรือไม่ ต้องได้รับการป้องกัน หรือต้องถูกทิ้งเมื่อ association ไม่พร้อมใช้งาน การตัดสินใจข้อหลังคือข้อที่สร้างความประหลาดใจ เพราะกฎที่กำหนดให้ป้องกันต้นทางผิดสามารถบล็อกการเข้าถึงเพื่อบริหารจัดการของคุณเองได้อย่างมีประสิทธิภาพพอ ๆ กับการบล็อกผู้บุกรุก
รักษาเส้นทางนอกช่องทางที่ได้รับอนุมัติไว้ระหว่างที่คุณเปลี่ยนการบังคับใช้ และทดสอบมันก่อนที่คุณจะต้องใช้ ไม่ใช่หลังจากที่โฮสต์ทั้งสองเข้าถึงไม่ได้แล้ว
อัตลักษณ์ของเครื่องไม่ใช่สิทธิ์ของแอปพลิเคชัน
IPsec ตรวจสอบสิทธิ์ของ peer ที่กำหนดไว้และป้องกันแพ็กเก็ตที่เลือก มันไม่ได้ตัดสินว่าใครแก้ไขเรกคอร์ดฐานข้อมูลใดได้ และไม่ได้เปลี่ยนอัตลักษณ์ของเซิร์ฟเวอร์ที่เชื่อถือได้ให้เป็นการให้สิทธิ์ทุกอย่างของแอปพลิเคชัน บัญชี บทบาท และการอนุญาตของแอปพลิเคชันยังคงอยู่ที่เดิม และข้อกำหนด TLS ระดับแอปพลิเคชันยังคงมีวัตถุประสงค์ของตัวเองแม้เส้นทางเครือข่ายจะได้รับการป้องกันอยู่แล้ว
ยอมรับการออกแบบด้วยการดำเนินการหนึ่งรายการจากต้นทางที่ตั้งใจไว้ และอีกรายการหนึ่งที่ต้องถูกปฏิเสธ และรวมถึงสิ่งที่จะเกิดขึ้นเมื่อไม่สามารถสถาปนา association ที่ต้องการได้ การทดสอบการเข้าถึงตามปกติบอกคุณว่าแพ็กเก็ตเคลื่อนที่ได้ แต่ไม่ได้บอกว่ามันเคลื่อนที่ภายใต้นโยบายที่คุณเขียน