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

ข้อความข้อผิดพลาดคือการวินิจฉัย

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

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

ถ้าความล้มเหลวแตกต่างกันระหว่างการลอง แสดงว่าคุณมีทางเลือกที่สาม: มีมากกว่าหนึ่งโหนดอยู่หลังชื่อเดียวกัน

การตรวจสอบชื่อ: ไคลเอนต์เปรียบเทียบอะไร

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

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName

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

การหมดอายุ: นาฬิกาของใครถูกอ่าน

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

เปรียบเทียบวันที่ของใบรับรองกับ UTC บนไคลเอนต์ก่อนสรุปอะไร:

openssl x509 -in cert.pem -noout -dates
date -u

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

ทำไมการแก้อย่างหนึ่งจึงเปิดเผยอีกอย่าง

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

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

รายละเอียดนั้นคือสิ่งที่เปลี่ยนตั๋วที่ไม่แน่นอนให้กลายเป็นตั๋วที่ทำซ้ำได้

พิสูจน์ด้วยการเชื่อมต่อใหม่

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

เก็บขั้นตอนข้อผิดพลาดที่แน่นอนและรายละเอียดใบรับรองไว้กับตั๋ว

บันทึกนั้นคือสิ่งที่กันไม่ให้คนถัดไปรีเซ็ตรหัสผ่านบัญชีเพราะปัญหาใบรับรอง ตัวตนและความใช้ได้เป็นคำถามแยกกัน และ RFC 5280 คือเอกสารอ้างอิงว่าสิ่งที่สองถูกประเมินอย่างไร

บทความที่เกี่ยวข้อง