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

สองเนมสเปซที่ใช้ตัวเลขเล็ก ๆ ร่วมกัน

ส่วนหัว IP มีฟิลด์โปรโตคอลที่ระบุสิ่งที่ตามมา: 6 สำหรับ TCP, 17 สำหรับ UDP, 1 สำหรับ ICMP, 50 สำหรับ ESP, 51 สำหรับ AH ส่วนหัว TCP หรือ UDP มีหมายเลขพอร์ตซึ่งเลือกโปรเซสบนโฮสต์ปลายทาง โปรโตคอล 50 กับพอร์ต TCP 50 เป็นค่าที่ไม่เกี่ยวข้องกัน แต่กล่องโต้ตอบอาจทำให้ดูเหมือนใช้แทนกันได้

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

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

ESP แบบดั้งเดิม แล้วจึงเป็นทางเลือกที่ห่อหุ้ม

ESP แบบดั้งเดิมถูกส่งโดยตรงเป็นโปรโตคอล IP ซึ่งทั้งมีประสิทธิภาพและไม่สะดวกพอ ๆ กัน มีประสิทธิภาพเพราะไม่มีส่วนหัวเพิ่ม และไม่สะดวกเพราะอุปกรณ์ใดที่แปลที่อยู่และพอร์ตไม่สามารถติดตามได้ NAT traversal มีอยู่เพื่อแก้ปัญหานี้ โดยห่อแพ็กเก็ต ESP ไว้ใน UDP เพื่อให้ตัวแปลมีพอร์ตให้เขียนใหม่

Form on the wireHow it is identifiedWhat the firewall must permit
IKE negotiationUDP with a destination portUDP 500, and 4500 once traversal is detected
Native ESPIP protocol 50 in the outer headerThe protocol itself, with no port to name
ESP inside UDPUDP 4500 carrying an ESP payloadThe UDP port pair, which translation devices can track

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

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

อ่านว่าการเชื่อมต่อใช้รูปแบบใดจริง

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

ip xfrm state | grep -A3 encap
tcpdump -ni any 'ip proto 50 or udp port 4500'

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

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

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

เขียนกฎในเนมสเปซที่ถูกต้อง

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

nft add rule inet filter input ip protocol esp accept
nft add rule inet filter input udp dport { 500, 4500 } accept

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

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

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

บทความที่เกี่ยวข้อง