ESP คือโปรโตคอล IP 50 ไม่ใช่พอร์ต TCP 50: ต้องอนุญาตอะไร
หมายเลขโปรโตคอลกับหมายเลขพอร์ตเป็นคนละเนมสเปซ กฎสำหรับพอร์ต TCP 50 ไม่อนุญาตอะไรเลย และ NAT traversal ย้าย ESP ไปที่ UDP 4500
แบบฟอร์มไฟร์วอลล์ถามหาพอร์ต 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 wire | How it is identified | What the firewall must permit |
|---|---|---|
| IKE negotiation | UDP with a destination port | UDP 500, and 4500 once traversal is detected |
| Native ESP | IP protocol 50 in the outer header | The protocol itself, with no port to name |
| ESP inside UDP | UDP 4500 carrying an ESP payload | The 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 เก็บการแก้กฎและการตรวจเส้นทางเป็นสองข้อสรุปแยกกัน
บันทึกรูปแบบที่คุณสังเกต กฎโปรโตคอลที่คุณเพิ่ม และตัวนับที่คุณเห็นภายหลัง สามบรรทัด และคนถัดไปสามารถแยกข้อผิดพลาดเนมสเปซออกจากข้อผิดพลาดเส้นทางได้ในหนึ่งนาทีแทนที่จะเป็นครึ่งวัน