วิธีจำกัดการเข้าถึงระหว่างสองสำนักงานที่เชื่อมต่อด้วย VPN

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

ทำงานตามลำดับนี้ และอย่าขยายเส้นทางอุโมงค์จนกว่าขั้นตอนนโยบายด้านล่างจะผ่าน

เขียนเมทริกซ์ก่อนแตะเกตเวย์

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

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

บังคับใช้ตรงที่แพ็กเก็ตถูกถอดรหัส

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

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

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT และซับเน็ตที่ทับซ้อนเปลี่ยนกฎ

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

ช่วงที่ทับซ้อนเป็นกับดักอีกอย่าง สองสำนักงานที่ใช้ 192.168.1.0/24 ทั้งคู่ไม่อาจอธิบายในตารางนโยบายเดียวได้โดยไม่แมปฝั่งหนึ่ง และการแมปไม่ใช่สิ่งทดแทนการกำหนดที่อยู่ที่ไม่ชนกัน แก้แผนก่อนเขียนกฎที่คุณจะต้องคลี่ออกภายหลัง

พิสูจน์การปฏิเสธ ไม่ใช่เพียงความสำเร็จ

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

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

ทำให้รายการยังมีชีวิต

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

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