ทำไม L2TP/IPsec จึงต้องใช้ UDP 1701 ควบคู่กับ IPsec

ไฟร์วอลล์ที่อนุญาต IKE และ ESP แต่ไม่อนุญาต UDP 1701 ทำให้การเชื่อมต่อ L2TP แตกออกในลักษณะที่ดูเหมือนปัญหาเรื่องข้อมูลรับรอง เหตุผลคือ L2TP เป็นโปรโตคอลที่สองที่วิ่งอยู่ภายในตัวแรก IPsec ทำหน้าที่ขนส่งและตรวจสอบสิทธิ์การแลกเปลี่ยน และ L2TP ก็เดินอุโมงค์ของตัวเองบน UDP 1701 ซึ่งสแตกในเครื่องยังต้องส่งมอบให้ได้ การรู้ว่าเฮดเดอร์แต่ละตัวปรากฏที่ใดช่วยอธิบายว่าอุปกรณ์ใดต้องการกฎใด

สองโปรโตคอล สองชุดพอร์ต

การเชื่อมต่อ L2TP/IPsec ใช้ IKE บน UDP 500 ใช้การข้าม NAT บน UDP 4500 ในจุดที่มีการแปลที่อยู่ และใช้ ESP เป็นโปรโตคอล IP 50 ในจุดที่ไม่มี ตัว L2TP เองเป็นโปรโตคอลอุโมงค์บน UDP 1701 และทำงานหลังจากที่ IPsec ตรวจสอบสิทธิ์คู่ตรงข้ามแล้ว สองครึ่งล้มเหลวคนละแบบ และบรรทัดบันทึกที่รายงานเรื่องนี้มาจากองค์ประกอบที่ต่างกัน ชุดกฎที่ครอบคลุมเพียงครึ่งแรกจะสร้างการเชื่อมต่อที่เจรจาได้แล้วตายในขั้นอุโมงค์

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

ห่อชั้นนอกอธิบายพอร์ต

บนสาย การเชื่อมต่อ L2TP/IPsec มักแสดง IKE บน 500 และ ESP ที่ถูกห่อบน 4500 เฮดเดอร์ UDP 1701 อยู่ภายในเพย์โหลดที่ได้รับการป้องกัน จึงเป็นเหตุผลว่าทำไมการดักจับบนอินเทอร์เฟซภายนอกจึงไม่เห็นมัน โฮสต์ภายในยังต้องส่งดาต้าแกรมนั้นไปยังดีมอน L2TP และการส่งมอบเกิดขึ้นหลังการถอดห่อ ดังนั้นกฎ 1701 จึงเป็นของไฟร์วอลล์ของปลายทางเอง แม้ว่าอุปกรณ์กลางใดจะไม่เคยเห็นพอร์ตนี้เลย

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

ตรวจเส้นทางตามลำดับ

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

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

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

สิ่งที่การสแกนพอร์ตบอกไม่ได้

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

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