นโยบาย VPN แบบสอง WAN ต้องจับคู่กับแพ็กเก็ตใด

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

ตั้งชื่อบทสนทนาทั้งสอง

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

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

ค้นหาว่านโยบายของคุณเห็นแพ็กเก็ตได้จริงที่ใด

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

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

ยืนยันการขนส่งที่คุณเจรจาไว้

สำหรับ IPsec ที่ห่อหุ้มใน UDP RFC 3948 วาง ESP ไว้ภายใน UDP และใช้เครื่องหมายที่ไม่ใช่ ESP เพื่อให้ IKE แยกแยะได้บนพอร์ตที่ใช้ร่วมกัน ESP ธรรมดาเป็นโปรโตคอล IP ไม่ใช่พอร์ต TCP หรือ UDP ดังนั้นกฎไฟร์วอลล์ที่เขียนตามหมายเลขพอร์ตจะไม่จับคู่เลย ความแตกต่างนี้กำหนดว่านโยบาย WAN ของคุณต้องใช้กฎ UDP กฎโปรโตคอล หรือทั้งสองอย่าง

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

ตรวจสอบเส้นทางกลับก่อนผูกมัด

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

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

ตรวจสอบทั้งสองชั้นด้วยการดักจับสองครั้ง

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

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

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