L2TP/IPsec ผ่าน NAT: อะไรพังจริงและเพราะอะไร

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

ตำนานคือคำถามที่ผิด

คำถามที่มีประโยชน์ไม่ใช่ «NAT ทำให้สิ่งนี้พังหรือไม่» แต่เป็น «ส่วนไหนของการแลกเปลี่ยนที่ถูกแปล และอุปกรณ์ที่แปลทำอะไรกับมัน» L2TP/IPsec เป็นโพรโทคอลแบบชั้น IKE เจรจา ESP ป้องกัน และ L2TP พา PPP อยู่ภายในการป้องกันนั้น อุปกรณ์แปลที่อยู่มีผลต่อแต่ละชั้นต่างกัน และสามารถแยกอาการเสียได้ถ้ามองที่ขั้นตอนการเจรจาแทนที่จะมองที่กล่องข้อผิดพลาด

เราเตอร์ที่ท่องเว็บได้สำเร็จพิสูจน์เพียงว่า TCP ที่มีการแปลพอร์ตต้นทางทำงานได้ ไม่ได้บอกอะไรเกี่ยวกับ UDP 500, UDP 4500 หรือโพรโทคอล 50 และการติดตั้งนี้ขึ้นอยู่กับสามสิ่งนั้น

ขั้นที่ 1: IKE ต้องได้รับคำตอบเสียก่อน

การแลกเปลี่ยนแรกไปยังผู้ตอบบน UDP 500 ถ้าไม่มีคำตอบกลับมา อย่างอื่นก็ไม่สำคัญ กุญแจที่แชร์ไว้ล่วงหน้า ข้อเสนอ และข้อมูลรับรองยังไม่ได้ถูกอ่าน จับตาดูคำขอและคำตอบแทนการเดาจากเวลาหมดของไคลเอนต์:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

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

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

ขั้นที่ 2: การห่อหุ้มเปลี่ยนสิ่งที่ไฟร์วอลล์เห็น

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

การแลกเปลี่ยน IKE เองก็สามารถย้ายไป UDP 4500 หลังตรวจพบ NAT ซึ่งทำให้คนที่อนุญาตเพียง 500 ประหลาดใจ อนุญาตทั้งสองพอร์ตทั้งสองทิศทางบนเส้นทาง และจำไว้ว่าไฟร์วอลล์แบบมีสถานะเก็บโฟลว์ไว้เพียงตราบเท่าที่เห็นทราฟฟิก

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

ขั้นที่ 3: การแมปหมดอายุและอุโมงค์ตาย

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

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

การเปลี่ยนที่อยู่ WAN ให้ผลลัพธ์เดียวกันจากอีกทิศทาง การแมปถูกสร้างใหม่รอบที่อยู่ใหม่ และสมาคมความปลอดภัยเก่าชี้ไปยังทูเพิลที่ไม่มีอยู่แล้ว พฤติกรรมการเชื่อมต่อใหม่เป็นของการใช้งานฝั่งไคลเอนต์ จึงเป็นเหตุผลที่ «เชื่อมต่อใหม่หลังรีบูตเราเตอร์» ทำงานบนไคลเอนต์หนึ่งและอีกตัวต้องสลับด้วยมือ

การโฮสต์หลัง NAT ระดับผู้ให้บริการเป็นปัญหาอีกแบบหนึ่ง

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

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

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