ทำไม IKEv2 บน Android จึงล้มเหลวบนพอร์ต UDP ที่ไม่มาตรฐาน

เกตเวย์ตอบ IKEv2 บน UDP 4443 ด้วยเหตุผลบางอย่าง โปรไฟล์มีช่องชื่อ Server คุณพิมพ์ชื่อโฮสต์และพอร์ต แล้วโทรศัพท์รายงานว่าไม่สามารถเข้าถึงเซิร์ฟเวอร์หรือไม่สามารถแปลงที่อยู่ได้ ไม่มีอะไรถูกบล็อก แบบฟอร์มเนทีฟของ Android คาดหวังโฮสต์ และเช่นเดียวกันใน Windows พอร์ตที่กำหนดเองเป็นความสามารถของไคลเอนต์ก่อนที่จะเป็นการตั้งค่าเซิร์ฟเวอร์ และมีเพียงไคลเอนต์บางตัวเท่านั้นที่ให้คุณระบุได้ ไล่ทั้งสามส่วนตามลำดับ: ไคลเอนต์บอกอะไรได้บ้าง เซิร์ฟเวอร์ฟังอะไรอยู่ และปลายทั้งสองจัดเฟรมแพ็กเก็ตเหมือนกันหรือไม่

โทรศัพท์ส่งอะไรไปจริง ๆ

สตริง host:port ในช่องที่ออกแบบมาสำหรับชื่อจะถูกแปลงเป็นชื่อ ตัวแปลงไม่คืนอะไรสำหรับ vpn.example.net:4443 และข้อผิดพลาดที่คุณเห็นคือความล้มเหลวในการแปลงชื่อหรือการเข้าถึงไม่ได้ ไม่ใช่หมดเวลาบนพอร์ต ความแตกต่างนี้สำคัญ เพราะการลองใหม่ด้วยชื่อที่สั้นกว่าหรือเครือข่ายอื่นจะไม่มีทางแก้สตริงที่แบบฟอร์มแยกวิเคราะห์ไม่ได้

โปรไฟล์ IKEv2 แบบเนทีฟบน Android เช่นเดียวกับไคลเอนต์ VPN ที่มีมาใน Windows ถูกตรึงไว้กับพอร์ต IKE มาตรฐาน ทั้งสองไม่แสดงช่องพอร์ต และการแก้ไขโปรไฟล์ก็ไม่ได้เพิ่มช่องใด ๆ หากตัวรับฟังของผู้ให้บริการอยู่บน 4443 จริง ไคลเอนต์ที่มีมาจึงเป็นเครื่องมือที่ผิด ไม่ใช่เครื่องมือที่กำหนดค่าไว้ผิด

ใช้ไคลเอนต์ที่แสดงพอร์ต

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

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

เซิร์ฟเวอร์มีสองพอร์ต และทั้งสองต้องตรงกัน

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

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

เมื่อพอร์ตเดียวรับใช้ทั้งสองบทบาท ดีมอนต้องแยก IKE ออกจาก ESP-in-UDP บนซ็อกเก็ตเดียวกัน ซึ่งทำได้ด้วยเครื่องหมายสี่ไบต์ที่ไม่ใช่ ESP และมาก่อนข้อความ IKE นี่คือเหตุผลที่ไคลเอนต์ไม่สามารถเจรจาบนพอร์ตกำหนดเองแล้วดำเนินต่ออย่างเงียบบน 4500 และเป็นเหตุผลที่วลี “แค่เปลี่ยนพอร์ต” ซ่อนข้อกำหนดด้านการจัดเฟรม

การส่งต่อไม่ใช่ตัวรับฟัง

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

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

แยกสามขั้นตอนเมื่อทดสอบ

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

tcpdump -ni eth0 -vv udp port 4443

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