วาดเส้นทางที่ถอดรหัสแล้ว: อุปกรณ์ VPN บังคับใช้นโยบายที่จุดใด
แผนภาพที่หยุดที่ตัวรับฟังแบบเข้ารหัสไม่ได้แสดงนโยบายที่สำคัญ วาดเส้นทางที่ถอดรหัสแล้ว แล้วเปรียบเทียบตำแหน่งตามสิ่งที่คำขอพาดผ่าน
แผนภาพของผู้จำหน่ายมักหยุดที่ตัวรับฟังแบบเข้ารหัส เพราะเป็นส่วนที่มีที่อยู่สาธารณะ คำถามที่กำหนดท่าทีด้านความปลอดภัยคือเกิดอะไรขึ้นหลังการถอดรหัส เมื่อแพ็กเก็ตกลายเป็น IP ธรรมดาและเข้าถึงได้ทุกสิ่งที่ตารางเส้นทางอนุญาต หากไม่มีใครวาดส่วนนั้น ก็ไม่มีใครเป็นเจ้าของ คู่มือด้านล่างวาดส่วนนั้นก่อน แล้วจึงเปรียบเทียบตำแหน่งตามสิ่งที่คำขอที่ถอดรหัสแล้วพาดผ่านจริง
วาดแพ็กเก็ตหลังการถอดรหัส ไม่ใช่ก่อน
เส้นทางภายนอกคือส่วนที่ผู้จำหน่ายจัดทำเอกสาร: จุดปลายสาธารณะ นโยบายการขนส่งที่ยอมรับการเชื่อมต่อ และบริการที่สิ้นสุดการเชื่อมต่อ เส้นทางภายในเริ่มต้นในขณะที่แพ็กเก็ตสูญเสียหัวข้ออุโมงค์ และจากนั้นมีกฎการกำหนดเส้นทางและการกรองที่ไม่มีส่วนเกี่ยวข้องกับอุโมงค์ควบคุม วางทั้งสองไว้ในหน้าเดียวกัน เพราะแผนภาพที่มีเพียงอย่างแรกสื่อเป็นนัยว่าการยอมรับและการอนุญาตเป็นการตัดสินใจเดียว ไม่ใช่เช่นนั้น และช่องว่างระหว่างทั้งสองคือจุดที่ตำแหน่งส่วนใหญ่ผิดพลาด
เขียนส่วนภายในเป็นลำดับที่มีหมายเลขพร้อมประเภทอุปกรณ์ที่ระบุชื่อ ไม่ใช่ลูกศร ลูกศรซ่อนว่าคำขอพาดผ่านตัวกรองหรือไม่ และการผ่านหรือไม่ผ่านคือคำถามทั้งหมด แต่ละขั้นด้านล่างระบุอุปกรณ์และชุดกฎที่ทำงานที่นั่น ตัวกรองที่หายไปจึงปรากฏเป็นช่องว่าง ไม่ใช่สิ่งที่เส้นสื่อเป็นนัย
- ไคลเอนต์ระยะไกล: อุปกรณ์ของผู้ใช้ที่สร้างอุโมงค์
- นโยบายขอบ: ชุดกฎที่ยอมรับการขนส่งภายนอกไปยังตัวรับฟังสาธารณะ
- อุปกรณ์สิ้นสุด: จุดปลาย VPN ที่ถอด encapsulation และส่งแพ็กเก็ตให้ IP ธรรมดา
- ตัวกรองภายใน: ชุดกฎการส่งต่อหรือกลุ่มความปลอดภัยที่จำกัดการรับส่งจากไคลเอนต์ไปยังบริการ
- โฮสต์แอปพลิเคชัน: บริการที่รับคำขอที่ถอดรหัสแล้ว
สองนโยบาย สองเจ้าของ
นโยบายภายนอกตอบว่าใครสร้างอุโมงค์ได้ และแสดงออกในกฎที่ยอมรับการขนส่งไปยังบริการสิ้นสุด นโยบายภายในตอบว่าผู้ใช้ที่ผ่านการรับรองเข้าถึงบริการใดได้ และอาศัยอยู่ในกฎการส่งต่อ กลุ่มความปลอดภัย หรือในแอปพลิเคชันเอง อุปกรณ์เดียวสามารถรองรับทั้งสอง และการออกแบบที่มีหลายอุปกรณ์ก็ยังมีทั้งสอง การเรียกชื่อแยกกันคือสิ่งที่ทำให้คุณบอกได้ว่าอันไหนล้มเหลวเมื่อผู้ใช้เข้าถึงแอปพลิเคชันไม่ได้
การควบคุมการยอมรับเช่นใบรับรองและการรับรองหลายปัจจัยตอบเรื่องตัวตนเท่านั้น ไม่ได้ตัดสินตำแหน่ง และไม่ให้สิทธิ์ตามทรัพยากรเมื่อผู้ใช้อยู่ข้างในแล้ว
ตำแหน่งกำหนดว่าคำขอพาดผ่านพรมแดนใด
สามตำแหน่งเป็นเรื่องปกติ และแต่ละอย่างเปลี่ยนพรมแดนที่คำขอที่ถอดรหัสแล้วพาดผ่าน เปรียบเทียบตามสิ่งที่สิ้นสุดที่นั่น สิ่งที่มองเห็นข้อความธรรมดา การควบคุมใดยังปฏิเสธคำขอได้ และสิ่งใดล้มเหลวพร้อมอุปกรณ์ ตารางด้านล่างใช้สี่คอลัมน์นั้นแทนคำถามทั่วไป เพราะแต่ละคำตอบเป็นการตัดสินใจออกแบบแยกกัน
| Placement | What terminates there | What sees plaintext | Which control can still deny | Failure domain |
|---|---|---|---|---|
| Termination in a dedicated segment | A dedicated VPN endpoint | The endpoint and anything on its segment | The filter between that segment and the application | The segment path can bypass the filter if no rule sits on it |
| Termination on the edge firewall | The firewall's public listener | The firewall, after decapsulation | The firewall's inner rule set | Admission and inspection fail together |
| Termination on the protected LAN | The appliance's LAN leg | Every host on the protected LAN | Only a host control or a downstream gateway | The appliance and the protected hosts fail together |
ตำแหน่งที่สามคือตำแหน่งที่ถอดการบังคับใช้ออกอย่างเงียบ ๆ เพราะส่วนที่อยู่บนเซกเมนต์ที่ได้รับการป้องกันให้เส้นทางตรงแก่อุปกรณ์ซึ่งแผนภาพอาจไม่แสดง ตรวจสอบอินเทอร์เฟซและเส้นทางแทนภาพ: ip route get 10.20.5.10 รายงานว่าแพ็กเก็ตจะออกผ่านอินเทอร์เฟซใด และคำตอบมักไม่ใช่สิ่งที่การออกแบบสันนิษฐาน บทบาทคลาสสิกของไฟร์วอลล์ในการควบคุมการรับส่งระหว่างสถานะ ตามที่อธิบายไว้ในNIST SP 800-41 เป็นการทดสอบที่มีประโยชน์ที่นี่ เพราะอุปกรณ์ที่มีส่วนเชื่อมต่อไม่จำกัดไปยังเครือข่ายที่ได้รับการป้องกันไม่ได้ควบคุมอะไรมากนัก การค้นหาเส้นทางเป็นแผนภาพที่ซื่อสัตย์กว่าแผนภาพในงานนำเสนอ
การบริหารจัดการเป็นของเส้นทางที่ได้รับอนุญาตอย่างชัดแจ้งของตัวเอง การอนุญาตให้ผู้ใช้เข้าถึงแอปพลิเคชันไม่เคยต้องอนุญาตให้เข้าถึงอินเทอร์เฟซควบคุมของอุปกรณ์ และสิทธิ์ทั้งสองควรให้จากกฎที่ต่างกัน ตรวจสอบเส้นทางทั้งสองแยกกัน เพราะกฎที่ใช้ร่วมกันซ่อนว่าอันไหนถูกเปิด
การแปลเปลี่ยนสิ่งที่กฎปลายทางมองเห็น
การแปลต้นทางสะดวกและทำลายข้อมูล หลัง masquerade ไคลเอนต์ทุกตัวดูเหมือนอุปกรณ์ ดังนั้นกฎปลายทางที่เขียนเพื่อแยกผู้ใช้จึงทำไม่ได้อีกต่อไป นี่ไม่ใช่แค่ปัญหาเรื่องบันทึก แต่เป็นปัญหานโยบาย: กฎที่อิงที่อยู่ไคลเอนต์กลายเป็นกฎที่อิงเกตเวย์อย่างเงียบ ๆ หากนโยบายรายผู้ใช้สำคัญ ให้รักษาต้นทางหรือบังคับใช้นโยบายก่อนการแปล
เส้นทางตอบกลับสมควรได้รับการตรวจสอบแบบเดียวกัน บันทึกว่าปลายทางเลือกเส้นทางใดสำหรับแพ็กเก็ตตอบกลับ เพราะการตอบกลับแบบอสมมาตรเลี่ยงการตรวจสอบตามสถานะและสร้างการเชื่อมต่อที่สร้างขึ้นแล้วหยุดชะงัก ทั้งสองทิศทางต้องพาดผ่านพรมแดนที่คุณวาดไว้ มิฉะนั้นพรมแดนก็เป็นเพียงเครื่องประดับ
sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTINGยอมรับการดำเนินการที่อนุญาตหนึ่งอย่างและที่ถูกปฏิเสธหนึ่งอย่าง
ทดสอบจากไคลเอนต์ระยะไกลจริง ไม่ใช่จากโฮสต์บริหารจัดการ เพราะโฮสต์บริหารจัดการมักอยู่ที่ที่ผู้ใช้จะไม่มีวันไปถึง การดำเนินการที่อนุญาตหนึ่งอย่างพิสูจน์ว่าเส้นทางทำงาน และที่ถูกปฏิเสธหนึ่งอย่างพิสูจน์ว่านโยบายทำอะไรสักอย่างจริง รันทั้งสองหลังทุกการเปลี่ยนตำแหน่ง และบันทึกตัวตนต้นทางและปลายทางที่ใช้ การทดสอบที่พิสูจน์เพียงความสำเร็จไม่สามารถแยกกฎที่ถูกต้องออกจากกฎที่หายไปได้
จากนั้นทดสอบกรณีที่เปลี่ยนสถานะ: การเชื่อมต่อใหม่ เซสชันที่อยู่รอดเกินการหมุนคีย์ และความล้มเหลวของอุปกรณ์เอง เปรียบเทียบการอัปเดต ความจุ และการกู้คืนเป็นส่วนหนึ่งของผังเดียวกัน เพราะอุปกรณ์เดียวที่ถือการควบคุมเชิงตรรกะหลายอย่างคือโดเมนความล้มเหลวเดียวที่มีหลายป้ายกำกับ กล่องที่สองก็ไม่เป็นอิสระเมื่อข้อมูลรับรองการบริหารที่ใช้ร่วมกันหรือเส้นทางที่ไม่จำกัดเอาชนะพรมแดนที่มันควรสร้าง
จัดทำเอกสารจุดปลาย เส้นทางที่ถอดรหัสแล้ว และการควบคุมที่จำกัดมัน สามบรรทัดนั้นยังคงมีความหมายไม่ว่าจะเรียกการใช้งานว่าอะไร