การปฏิเสธการเชื่อมต่อไม่ใช่ปัญหาใบรับรอง: คู่มือปฏิบัติการ VPN

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

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

อ่านข้อผิดพลาดที่ชั้นซึ่งสร้างมันขึ้นมา

ECONNREFUSED จาก connect หมายถึงความพยายามขนส่งถูกปฏิเสธ: มีบางสิ่งตอบกลับด้วย reset หรือสแตกแจ้งพอร์ตที่เข้าถึงไม่ได้ ปัญหาใบรับรองไม่สามารถทำให้เกิดข้อผิดพลาดนั้นได้ เพราะแฮนด์เชก TLS ไม่เริ่มทำงานหากไม่มีการเชื่อมต่อในชั้นขนส่ง ถ้าคุณเห็นการปฏิเสธ ไคลเอนต์ไม่เคยไปถึงขั้นนำเสนอใบรับรอง ข้อเท็จจริงเดียวนี้ตัดการเพิกถอนออกจากสาเหตุ

ตรงกันข้ามก็จริง ใบรับรองที่ถูกเพิกถอนให้การเชื่อมต่อ TCP ที่สมบูรณ์และแฮนด์เชกที่ล้มเหลว ซึ่งบันทึกบนเซิร์ฟเวอร์เป็นข้อผิดพลาดการตรวจสอบ

การปฏิเสธ TCP: ไม่มีใครรับฟัง

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

ตรวจตระกูลที่อยู่ด้วย บริการที่ผูกกับ 127.0.0.1 หรือ IPv6 เท่านั้นจะปฏิเสธไคลเอนต์ที่แปลงเป็นอีกที่อยู่หนึ่ง

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

UDP ไม่มีแฮนด์เชกให้ปฏิเสธ

OpenVPN บน UDP ไม่สร้างการเชื่อมต่อในความหมายของ TCP จึงไม่มีอะไรให้ปฏิเสธตอน connect บน Linux ข้อผิดพลาดที่ซ็อกเกต UDP แสดงอาจมาจาก ICMP port-unreachable ที่สร้างโดยดาตาแกรมก่อนหน้า หน้าคู่มือ udp(7) อธิบายพฤติกรรมแบบอะซิงโครนัสนั้น

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

CRL ถูกตรวจสอบที่ใดจริง ๆ

CRL ถูกสอบถามระหว่างแฮนด์เชก TLS หลังจากอีกฝ่ายนำเสนอใบรับรองของตน และเฉพาะเมื่อการกำหนดค่าเซิร์ฟเวอร์อนุญาต ตัวเลือก crl-verify ของ OpenVPN ชี้ไปที่ไฟล์ และความล้มเหลวปรากฏในบันทึกเซิร์ฟเวอร์เป็นข้อผิดพลาดการตรวจสอบที่ระบุชื่อใบรับรอง

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

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

คู่มือสั้น ๆ สำหรับครั้งหน้า

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

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