โปรไฟล์ WireGuard สำหรับเกตเวย์ IPsec: สิ่งที่ควรถามแทน

การหมดเวลาของแฮนด์เชกกับเกตเวย์ที่ไม่ตอบสนองมักหมายถึงโปรโตคอลสองตัวที่ไม่เคยพบกัน ไคลเอนต์ WireGuard พูด Noise ขณะที่เกตเวย์ IPsec รอ IKE ที่อยู่และพอร์ตที่ถูกต้องไม่ได้เปลี่ยนสิ่งนั้น

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

คำขอที่หนึ่ง: เวอร์ชันโปรโตคอล

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

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

คำขอที่สอง: วิธีการรับรองความถูกต้องของไคลเอนต์

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

คีย์ส่วนตัวของ WireGuard ไม่ใช่สิ่งเหล่านั้นเลย มันคือคีย์ Curve25519 ที่ใช้ในการแฮนด์เชกหนึ่งครั้งที่เฉพาะเจาะจง การแปลงใดก็ไม่ทำให้มันกลายเป็นใบรับรองหรือข้อมูลรับรอง EAP เครื่องมือที่อ้างตรงกันข้ามกำลังเปลี่ยนชื่อไฟล์หรือสร้างสิ่งที่ไม่เกี่ยวข้อง

ข้อกำหนด IKEv2 ใน RFC 7296 อธิบายว่าการใช้งานเวอร์ชันนั้นต้องรองรับอะไร เป็นเอกสารอ้างอิงสำหรับคำตอบที่คลุมเครือของผู้ดูแล ไม่ใช่คู่มือการตั้งค่าไคลเอนต์

คำขอที่สาม: ตัวตนที่เชื่อถือได้และปลายทาง

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

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

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

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

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

เมื่อโปรโตคอลทั้งสองต้องอยู่ร่วมกัน

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

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

สิ่งที่มันไม่ใช่คือการแปลงที่โปร่งใส ทราฟฟิกที่มาทาง WireGuard จะถูกสร้างใหม่เข้าไปในอุโมงค์ IPsec และนโยบายทุกข้อระหว่างกลางมีผลกับมัน

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