สิ่งที่ต้องบันทึกสำหรับ VPN แบบไซต์ทูไซต์: ตัวเลือกและขอบเขต

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

ค่าที่กำหนดไว้ไม่ใช่ค่าที่เจรจาแล้ว

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

เก็บทั้งสองคอลัมน์พร้อมวันที่ที่คุณสังเกต ตัวเลือกที่กำหนดไว้คือสิ่งที่คุณตั้งใจ ส่วนที่เจรจาแล้วคือสิ่งที่เคอร์เนลบังคับใช้อยู่ตอนนี้ เมื่อทั้งสองต่างกัน ความต่างนั้นอธิบายความล้มเหลวที่คาดไม่ถึงได้บ่อยกว่าบั๊กการกำหนดเส้นทางมาก

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

อุโมงค์แบบอิงเส้นทางเลือกต่างออกไป

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

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

การแปลงที่อยู่เป็นส่วนหนึ่งของตารางเดียวกัน

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

นี่คือรายละเอียดที่ทำให้อุโมงค์ที่ทำงานอยู่พังหลังการเปลี่ยนแปลง NAT: ตัวเลือกยังตรงกับคำนำหน้าต้นฉบับ อีกฝ่ายได้รับคำนำหน้าที่แปลงแล้ว และเส้นทางขากลับชี้ไปยังที่อยู่ที่ไม่มีอยู่แล้ว ไม่มีอะไรบันทึกข้อผิดพลาดในขณะที่ทั้งสองหยุดตรงกัน

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

แนบข้อกำหนดด้านบริการ

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

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

เปลี่ยนบันทึกให้เป็นแผนการทดสอบ

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

swanctl --list-sas

โครงห้าบรรทัดมักเพียงพอที่จะทำให้บันทึกซื่อตรง ฉบับด้านล่างใส่ในตั๋วเปลี่ยนแปลงได้โดยไม่ถูกตัด:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

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