IKE บน TCP 4500: ตรวจสอบทั้งสองฝั่งก่อนกฎพอร์ต
การห่อหุ้ม TCP ถูกเจรจาโดยทั้งสองฝั่ง ไม่ใช่กฎไฟร์วอลล์เป็นผู้ให้ ตรวจสอบตัวรับฟัง การดักจับ และสี่ขั้นตอนการยอมรับตามลำดับ
ตั๋วสนับสนุนมักมาถึงเมื่อการเปลี่ยนแปลงไฟร์วอลล์ได้รับการอนุมัติแล้วแต่ทันเนลยังคงปฏิเสธที่จะขึ้น นี่คือผลลัพธ์ที่คาดไว้เมื่อมีคุณสมบัติเพียงฝั่งเดียว: การห่อหุ้ม TCP ตาม RFC 9329 ต้องถูกนำไปใช้งานและกำหนดค่าที่ทั้งสองฝั่ง และข้อตกลงเกิดขึ้นภายในการเชื่อมต่อก่อนที่ทราฟฟิกที่ได้รับการป้องกันจะเคลื่อนที่ การเปิดพอร์ตเป็นการโฆษณาตัวรับฟังที่อาจไม่มีอยู่ และตัวรับฟังที่ไม่มีการกำหนดค่าที่ตรงกันในอีกฝั่งจะยอมรับการเชื่อมต่อแล้วเงียบไป ลำดับด้านล่างวางการตรวจสอบราคาถูกไว้ก่อน
รู้ว่าตัวเลือกเพิ่มอะไรจริง ๆ
IPsec แบบดั้งเดิมขนส่งเพย์โหลดที่เข้ารหัสเป็น โปรโตคอล IP 50 โดยไม่มีหมายเลขพอร์ตที่ต้องอนุญาต NAT traversal ห่อแพ็กเก็ตเหล่านั้นใน UDP ไปยังพอร์ต 4500 ซึ่งเป็นเหตุผลที่กฎไฟร์วอลล์จำนวนมากกล่าวถึงพอร์ตนั้น RFC 9329 เพิ่มการแสดงสตรีม: แพ็กเก็ต IKE และ IPsec ทั้งคู่เดินทางภายในการเชื่อมต่อ TCP เดียว โดยปกติไปยังพอร์ต 4500
สตรีมไม่ใช่บริการเว็บ การเชื่อมต่อ TCP ไปยัง 4500 ไม่ได้บอกอะไรเกี่ยวกับ HTTP, TLS หรือความเป็นมิตรกับพร็อกซี และพร็อกซี HTTP ในเส้นทางมักจะทำให้การจัดกรอบแตกแทนที่จะพามันไป
การตรวจสอบล่วงหน้าก่อนแตะไฟร์วอลล์
มาตรฐานวาง TCP เป็นทางเลือกสำรองสำหรับเครือข่ายที่ทิ้งเส้นทาง UDP ไม่ใช่แทนที่มัน ขอข้อเท็จจริงสองอย่างจากผู้ขายแต่ละราย: ชื่อคุณสมบัติที่แน่นอนและเวอร์ชันที่ใช้ RFC 9329 แทนตัวแปรที่เป็นกรรมสิทธิ์ ป้ายเช่น IPsec over TCP ถูกใช้กับดีไซน์ที่ไม่เกี่ยวข้อง ดังนั้นขอเอกสารอ้างอิงและคีย์การกำหนดค่าที่เปิดใช้งาน หากไม่มีคำตอบทั้งสองอย่าง อย่าสมมติสิ่งใดเกี่ยวกับความเข้ากันได้บนสาย
พิสูจน์ในห้องแล็บที่ทั้งสองฝั่งเป็นของคุณ เกตเวย์ที่ตอบบน TCP 4500 แต่ไม่เคยทำ IKE ให้เสร็จคือลายเซ็นของตัวรับฟังที่ไม่มี การห่อหุ้มที่ตรงกันในอีกฝั่ง และการค้นพบที่นั่นถูกกว่ามากกว่าในช่วงหน้าต่างการเปลี่ยนแปลง
ฝั่งผู้ตอบ: มีอะไรฟังอยู่หรือไม่
เริ่มจากซ็อกเก็ต ss -ltnp | grep 4500 แสดงว่ามีตัวรับฟัง TCP หรือไม่ และโปรเซสใดเป็นเจ้าของ การไม่มีบรรทัดจบการสอบสวนที่การกำหนดค่าเกตเวย์ไม่ใช่ที่เครือข่าย
หากซ็อกเก็ตอยู่ ให้สังเกตการจับมือแทนการเดาจากฝั่งไคลเอนต์: tcpdump -ni any 'tcp port 4500' การจับมือสามทางที่เสร็จสมบูรณ์ตามด้วยความเงียบหมายถึงสตรีมถูกยอมรับและการแลกเปลี่ยน IKE ภายในล้มเหลว ในขณะที่ SYN ที่ไม่มีคำตอบชี้ไปที่การกรองหรือที่อยู่ผิด
เปรียบเทียบกับเส้นทาง UDP ในหน้าต่างการดักจับเดียวกันเพื่อไม่ให้สับสน: tcpdump -ni any 'udp port 4500 or proto 50' ทราฟฟิกบนโปรโตคอล 50 หรือพอร์ต UDP 4500 ขณะที่คุณเชื่อว่าใช้ TCP หมายความว่าทั้งสองฝั่งไม่เคยตกลงเรื่องทางสำรอง ดักจับที่เกตเวย์ด้วยหากทำได้ เพราะการดักจับฝั่งไคลเอนต์ไม่สามารถแสดงสิ่งที่ปลายไกลส่งมา
ยอมรับในสี่ขั้นตอนแยกกัน
ปฏิบัติต่อการขึ้นเสมือนสี่ผลลัพธ์ แต่ละอย่างล้มเหลวได้ด้วยเหตุผลต่างกัน และการผ่านหรือล้มเหลวเพียงครั้งเดียวซ่อนว่าอันไหน ดังนั้นหยุดที่ขั้นตอนแรกที่ล้มเหลวแล้วเริ่มใหม่จากด้านบน
| Stage | What you check | What it proves |
|---|---|---|
| 1 | TCP connection established to 4500 | A listener exists and the path permits it |
| 2 | IKE_SA authenticated in the gateway log | Both peers agreed on the encapsulation |
| 3 | CHILD_SA installed, visible with ip xfrm state | Keys exist for the protected traffic |
| 4 | A new application exchange succeeds | The data path works, not just the control path |
ขั้นตอนที่สี่คือขั้นที่ถูกข้าม เซสชันที่มีอยู่อาจทำงานต่อบนสถานะที่แคชไว้ ดังนั้นเปิดการเชื่อมต่อใหม่ไปยังโฮสต์หลังเกตเวย์ก่อนปิดการเปลี่ยนแปลง หากขั้นตอนที่สองล้มเหลวในขณะที่ขั้นแรกผ่าน ความไม่ลงรอยอยู่ที่ข้อเสนอหรือการตั้งค่าการห่อหุ้ม ไม่ใช่ไฟร์วอลล์
การย้อนกลับ และค่าใช้จ่ายของการเปิดทิ้งไว้
วางแผนการย้อนกลับก่อนการเปลี่ยนแปลง: ปิดตัวเลือกการห่อหุ้มที่ทั้งสองฝั่งและยืนยันว่าทันเนลกลับมาผ่าน UDP เก็บกฎ TCP ไว้หนึ่งรอบการทบทวนเผื่อต้องใช้ทางสำรองอีกครั้ง แล้วจึงลบออก ตัวรับฟังที่ไม่ได้ใช้บน 4500 คือพื้นที่ผิวที่ไม่มีความคุ้มค่าในการดำเนินงาน
สังเกตลายเซ็นประสิทธิภาพเมื่อมันเริ่มแบกงานจริง TCP ใน TCP เพิ่มชั้นการยืนยันที่หยุดเมื่อสูญหายเพียงครั้งเดียว และสตรีมที่แชร์การเชื่อมต่อเดียวอาจบล็อกกันเอง ดังนั้นวัดแอปพลิเคชันที่จะใช้ทันเนลแทนการ ping
รายการยอมรับ
ยืนยันชื่อและเวอร์ชันของคุณสมบัติที่ทั้งสองฝั่ง ตัวรับฟังฝั่งผู้ตอบ การดักจับที่แสดงการจับมือเสร็จสมบูรณ์ และสี่ขั้นตอนที่บันทึกพร้อมการประทับเวลา เพิ่มเหตุผลของทางสำรองในบันทึกการเปลี่ยนแปลงเพื่อให้วิศวกรคนถัดไปรู้ว่าทำไมจึงมี TCP อยู่ ฝึกซ้อมการย้อนกลับก่อนที่คุณจะต้องใช้
หากขั้นตอนใดล้มเหลว ให้แก้ไขเฉพาะขั้นตอนนั้น การเปลี่ยนชุดรหัสหรือการตั้งค่าตัวตนเพื่อไล่ปัญหาการขนส่งมักเพิ่มความล้มเหลวที่สองซึ่งไม่เกี่ยวข้องบนความล้มเหลวแรก