VPN แบบไซต์ถึงไซต์: ทิศทางใดกันแน่ที่ต้องมีกฎ

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

ทราฟฟิกตอบกลับแบบเก็บสถานะเปลี่ยนจำนวนกฎ

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

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

จุดที่ไฟร์วอลล์เห็นแพ็กเก็ตที่ถอดรหัสแล้ว

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

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

การกำหนดเส้นทางแบบอสมมาตรทำลายสมมติฐาน

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

ตรวจสอบเส้นทางของคำตอบก่อนเพิ่มกฎอนุญาตแบบกว้างทั้งสองฝั่ง การยอมรับทุกอย่างบนทุกอินเทอร์เฟซซ่อนข้อผิดพลาดด้านเส้นทางและขยายการเข้าถึงในเวลาเดียวกัน ซึ่งเป็นการผสมผสานที่แย่ที่สุดเท่าที่มี

ตรวจสอบทั้งสองทิศทางด้วยที่อยู่ต้นทางจริง

ทดสอบด้วยที่อยู่ที่ฝั่งไกลเห็นจริง เพราะการแปลงที่อยู่อาจทำให้กฎต้นทางไม่ตรงกับสิ่งใดเลย เรียกการดักจับบนเกตเวย์ทั้งสองพร้อมกัน

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

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

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