VPN แบบใช้เส้นทางเทียบกับแบบใช้นโยบายระหว่างไซต์: ต่างกันอย่างไร
IPsec แบบใช้นโยบายเลือกทราฟฟิกด้วยตัวเลือก ส่วนแบบใช้เส้นทางส่งผ่านอินเทอร์เฟซอุโมงค์ ทั้งสองยังต้องมีกฎไฟร์วอลล์และเส้นทางย้อนกลับ
การออกแบบทั้งสองปกป้องทราฟฟิกเดียวกันด้วยกลไก IPsec เดียวกัน และต่างกันที่สิ่งซึ่งตัดสินใจว่าแพ็กเก็ตใดจะเข้าไปในอุโมงค์ ในการเชื่อมต่อแบบใช้นโยบาย ตัวเลือกทราฟฟิกที่เจรจาไว้ทำหน้าที่นั้น ในการเชื่อมต่อแบบใช้เส้นทาง เส้นทางที่ชี้ไปยังอินเทอร์เฟซอุโมงค์ทำหน้าที่นั้น การสับสนระหว่างสองอย่างนี้ทำให้เกิดกระทู้สนับสนุนที่คุ้นเคย ซึ่งอุโมงค์รายงานว่าสร้างเสร็จแล้วแต่แอปพลิเคชันกลับไปไม่ถึงอะไรเลย ความแตกต่างนี้สำคัญที่สุดเมื่อคุณเพิ่มเครือข่าย เดินโปรโตคอลเส้นทาง หรือดีบักเส้นทางที่แอบออกทางออกผิด
สองวิธีในการตัดสินใจว่าอะไรเข้าไปในอุโมงค์
VPN แบบใช้นโยบายสร้างนโยบายความปลอดภัยที่ตรงกับคำนำหน้าต้นทางและปลายทาง แล้วเข้ารหัสทุกสิ่งที่เข้ากันได้ คู่ตรงข้ามต้องเจรจาตัวเลือกที่เข้ากันได้ ดังนั้น ขอบเขตที่แท้จริงจึงกลายเป็นจุดตัดของสิ่งที่ทั้งสองฝ่ายเสนอ สิ่งใดนอกจุดตัดนั้นไม่ได้รับการป้องกัน ไม่ว่าเส้นทางจะว่าอย่างไร
VPN แบบใช้เส้นทาง สร้างอินเทอร์เฟซที่เป็นตัวแทนของอุโมงค์ และปล่อยให้ตารางเส้นทางส่งทราฟฟิกเข้าไป IKE เดมอนยังติดตั้งสถานะและนโยบายต่ออินเทอร์เฟซ และนั่นคือรายละเอียดที่ผู้คนข้ามไปเมื่อตัดสินใจว่าเส้นทางแทนที่การเข้ารหัสแล้ว การออกแบบทั้งสองเข้ารหัสด้วย IPsec ต่างกันเพียงกลไกการเลือก
อ่านการเปรียบเทียบด้านล่างเป็นชุดลายเซ็นของความล้มเหลว ไม่ใช่ตารางคะแนน เพราะไม่มีคอลัมน์ใดชนะด้วยตัวเอง
| Aspect | Policy-based | Route-based |
|---|---|---|
| What selects traffic | Negotiated selectors | A route into the tunnel interface |
| Adding a network | Edit selectors on both peers | Add a route, widen the selector once |
| Dynamic routing | Awkward to run over the tunnel | Runs over the interface directly |
| Typical failure | Tunnel up, host outside the selector | Tunnel up, no route or wrong source |
แบบใช้นโยบาย: ตัวเลือกคือสัญญา
ตัวเลือกมีการเจรจา ไม่ใช่แค่กำหนดค่า เสนอ 10.10.0.0/16 ฝั่งหนึ่งและ 10.10.1.0/24 อีกฝั่ง จากนั้นสมาคมจะครอบคลุมสิ่งที่การเจรจาตกลงไว้ ขณะที่โฮสต์อื่นทั้งหมดอยู่ข้างนอก
อ่านสถานะที่ติดตั้งแทนไฟล์การกำหนดค่า บนคู่ตรงข้าม Linux ตารางของเคอร์เนลเองคือความจริงพื้นฐาน และแสดงให้เห็นว่าอะไรอยู่รอดจากการเจรจา นโยบายที่ระบุคำนำหน้าที่ถูกต้องแต่ไม่มีสถานะที่ตรงกันหมายความว่าสมาคมไม่เคยขึ้นมา สถานะที่จับคู่กับนโยบายสำหรับคำนำหน้าผิดคือปัญหาตรงกันข้าม และมันสร้างอุโมงค์ที่ดูสุขภาพดีขณะที่ซับเน็ตหนึ่งไปไม่ถึงอะไรเลย
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasเปรียบเทียบเอาต์พุตทั้งสองกับคำนำหน้าที่ยouคิดว่ากำลังป้องกัน การเปรียบเทียบครั้งเดียวนั้นแก้ปัญหาส่วนใหญ่เกี่ยวกับอุโมงค์ที่ทำงานได้แต่เซิร์ฟเวอร์เข้าถึงไม่ได้ นอกจากนี้ยังชี้ว่าควรเปลี่ยนฝั่งใด เพราะความไม่ตรงกันมักเห็นได้ทางเดียวเท่านั้น
แบบใช้เส้นทาง: อินเทอร์เฟซคือสัญญา
อินเทอร์เฟซ XFRM ให้ชื่อและอัตลักษณ์แก่อุโมงค์ และทราฟฟิกไปถึงได้เพราะตารางเส้นทางบอกเช่นนั้น คำนำหน้าปลายทางหลายรายการจึงกลายเป็นปัญหาเส้นทางแทนที่จะเป็นปัญหาตัวเลือก และโปรโตคอลเส้นทางสามารถประกาศได้ นั่นคือกำไรที่แท้จริง ไม่ใช่การเข้ารหัส
อินเทอร์เฟซไม่ได้ขจัดความจำเป็นของนโยบาย เดมอนติดตั้งกฎต่ออินเทอร์เฟซที่ผูกกับอัตลักษณ์ของอินเทอร์เฟซ ดังนั้นแพ็กเก็ตที่มาถึงอินเทอร์เฟซผิดยังคงล้มเหลว ที่อยู่ต้นทางที่คู่ตรงข้ามไม่ยอมรับก็ล้มเหลวเช่นกัน แม้มีเส้นทางที่สมบูรณ์แบบ แบบใช้เส้นทางหมายถึงเส้นทางตัดสินการเข้า ไม่ใช่ว่านโยบายหายไป
sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10เฝ้าดูตัวนับของอินเทอร์เฟซเมื่อเส้นทางเข้าที่แล้ว เส้นทางมีอยู่แต่ตัวนับยังเป็นศูนย์หมายความว่าไม่มีสิ่งใดถูกจับคู่เข้าอุโมงค์ ซึ่งมักชี้ไปที่สถานะที่ขาดหายไปมากกว่าเส้นทางที่ขาดหายไป
จุดที่การออกแบบทั้งสองแตกต่างกันจริง
การเพิ่มเครือข่ายเป็นการทดสอบที่สะอาดที่สุดว่าการออกแบบใดเหมาะกับคุณ การออกแบบแบบใช้เส้นทางเพิ่มเส้นทางหนึ่งเส้นและขยายตัวเลือกไม่เกินหนึ่งครั้ง ส่วนการออกแบบแบบใช้นโยบายแก้ไขคู่คำนำหน้าบนคู่ตรงข้ามทั้งสองและเจรจาใหม่ ซับเน็ตที่มั่นคงสองวงทำให้การแก้ไขนั้นเป็นเรื่องจิ๊บจ๊อย และยี่สิบวงทำให้กลายเป็นโครงการ
ไม่มีแบบใดแทนไฟร์วอลล์ได้ และการเปรียบเทียบมักหยุดก่อนจุดนี้ ตัวเลือกที่กว้างหรือเส้นทางที่กว้างตัดสินว่าอะไรถูกเข้ารหัส ไม่ใช่ว่าอะไรได้รับอนุญาต
พฤติกรรม MTU ก็ต่างกันในทางปฏิบัติ การห่อหุ้มลดเพย์โหลดที่ใช้ได้ และอินเทอร์เฟซแบบใช้เส้นทางมี MTU ของตัวเอง ดังนั้นการตรึง MSS ที่เกตเวย์ทั้งสองจึงหลีกเลี่ยงอาการหลุมดำที่คำตอบเล็กมาถึงแต่คำตอบใหญ่หายไป อุโมงค์แบบใช้นโยบายเจอกำแพงเดียวกันจากอีกด้าน เพราะตัวเลือกไม่บอกอะไรเกี่ยวกับขนาดแพ็กเก็ต ตั้งค่าตรึงอย่างตั้งใจแทนที่จะโทษคู่ตรงข้าม
ย้ายระบบโดยไม่สูญเสียเส้นทางย้อนกลับ
บันทึกคู่คำนำหน้าที่มีอยู่ก่อนเปลี่ยนสิ่งใด จากนั้นย้ายเส้นทางแอปพลิเคชันหนึ่งเส้นและเฝ้าดูตั้งแต่ต้นจนจบ อุโมงค์ที่สร้างขึ้นไม่ใช่อุโมงค์ที่ส่งต่อ และความแตกต่างปรากฏในทิศทางของการตอบกลับ
เมื่อคู่ตรงข้ามเชื่อมต่อได้แต่โฮสต์ใน LAN ไม่ได้ ให้ตรวจสอบเส้นทางย้อนกลับและที่อยู่ต้นทางที่โฮสต์ปลายทางจะใช้ โฮสต์ที่มีสองอินเทอร์เฟซอาจตอบกลับจากอันที่ผิด และไม่มีการเปลี่ยนตัวเลือกใดซ่อมได้ จับทราฟฟิกที่ทั้งสองปลายก่อนแก้ไขอัลกอริทึม
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-connsรักษาเส้นทางบริหารที่ไม่ขึ้นกับอุโมงค์ขณะทำงาน การย้อนกลับทำได้ง่ายกว่าเมื่อการเข้าถึงของเกตเวย์เองไม่ได้โดยสารอยู่บนการเชื่อมต่อที่คุณกำลังดีบัก