EAP ผ่านเกตเวย์ VPN: ใครเป็นผู้สิ้นสุดวิธีการ

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

สองเส้นทางการตรวจสอบสิทธิ์ที่ดูเหมือนกันในบันทึก

ในเส้นทางแรก เกตเวย์ VPN เก็บชื่อผู้ใช้และรหัสผ่านแล้วส่ง RADIUS Access-Request พร้อมแอตทริบิวต์รหัสผ่าน เซิร์ฟเวอร์ตรวจสอบสิทธิ์เปรียบเทียบกับที่เก็บของตนแล้วตอบรับหรือปฏิเสธ ไคลเอนต์ไม่เคยรันวิธี EAP เพราะไม่มีใครขอ

ในเส้นทางที่สอง ไคลเอนต์และเซิร์ฟเวอร์ตรวจสอบสิทธิ์รันวิธี EAP ตั้งแต่ต้นจนจบ และเกตเวย์ส่งแอตทริบิวต์ EAP-Message ระหว่างกัน เกตเวย์ยังคงสิ้นสุดบทสนทนา RADIUS ภายนอก แต่ตรรกะของวิธีอยู่ที่ปลายทั้งสอง

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

วิธีทำงานอยู่ที่ไหนจริง ๆ

RFC 3579 กำหนดรูปแบบการส่งผ่าน: NAS บรรทุกแพ็กเก็ต EAP ในแอตทริบิวต์ RADIUS และไม่ต้องมีโค้ดเฉพาะวิธีสำหรับ EAP แต่ละชนิด ดังนั้นเกตเวย์จึงรองรับ PEAP และ EAP-TLS ได้โดยไม่ต้องใช้งานอย่างใดอย่างหนึ่ง

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

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

NAS ต้องรองรับอะไร

การส่งผ่านย้ายข้อกำหนดจากโค้ดวิธีไปยังการรองรับตัวนำ เกตเวย์ต้องบรรทุก EAP ผ่านโปรโตคอล VPN ของตนได้ และไคลเอนต์ RADIUS บนนั้นต้องส่งและรับแอตทริบิวต์ EAP-Message ขนาดที่เกี่ยวข้องได้

สำหรับ IKEv2 นั้น EAP เป็นส่วนหนึ่งของโฟลว์การตรวจสอบสิทธิ์ที่กำหนดไว้ และการตรวจสอบตัวตนและความไว้วางใจของเซิร์ฟเวอร์มาจากโฟลว์นั้น ป้าย PEAP ที่ยืมมาจากการติดตั้ง 802.1X ไม่ได้ถ่ายโอนโดยอัตโนมัติ เพราะการเจรจารอบ ๆ แตกต่างกัน

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

อ่านความพยายามหนึ่งครั้งก่อนเปลี่ยนนโยบาย

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

บนเกตเวย์ Linux การดักจับที่พอร์ต RADIUS แสดงแอตทริบิวต์ที่อยู่บนสาย:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

จากนั้นเปรียบเทียบจุดปฏิเสธ ความล้มเหลวที่เกตเวย์ก่อนแพ็กเก็ต RADIUS ใด ๆ หมายความว่าไคลเอนต์และเกตเวย์ไม่ตกลงเรื่องวิธี การปฏิเสธ RADIUS ที่มีแอตทริบิวต์ EAP หมายความว่าปลายทั้งสองรันวิธีและหนึ่งในนั้นปฏิเสธผลลัพธ์

วางแผนการย้ายเป็นการเปลี่ยนแปลงเดียวตั้งแต่ต้นจนจบ

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

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

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