SSTP หมดเวลาหรือใบรับรองผิดพลาด: แยกแยะได้อย่างไร

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

สองความล้มเหลว สองการแลกเปลี่ยนที่ต่างกัน

SSTP บรรทุกอุโมงค์ไว้ในเซสชันรูปร่าง HTTPS จึงอยู่รอดในเครือข่ายที่อนุญาตเฉพาะพอร์ต 443 ไคลเอนต์จบแฮนด์เชก TLS ส่งคำขอ HTTP ด้วยเมธอดเฉพาะของโปรโตคอล แล้วอุโมงค์ก็ทำงานในสตรีมนั้น ความล้มเหลวในขั้นใดขั้นหนึ่งหยุดการเชื่อมต่อ และมีเพียงขั้นหลัง ๆ ที่เกี่ยวกับข้อมูลรับรอง

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

บรรทัดในบันทึกมักบอกว่าคุณอยู่ในสามกรณีใด จึงคุ้มที่จะบันทึกไว้ก่อนการเปลี่ยนแปลงครั้งแรก

การหมดเวลาหมายถึงขั้นตอนหนึ่งไม่เคยจบ

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

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

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

การหมดเวลาก่อนจะมีการตอบกลับใด ๆ จากอีกฝั่งไม่ได้บอกอะไรเกี่ยวกับบัญชี และการเปลี่ยนรหัสผ่านตอนนั้นเพียงเพิ่มตัวแปรหนึ่งตัว

ข้อผิดพลาดใบรับรองหมายถึงตัวตนถูกปฏิเสธ

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

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

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

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

จุดที่สองอย่างสับสนกัน

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

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

คำถามเรื่องใบรับรองและคำถามเรื่องการเข้าถึงถูกบันทึกแยกกันด้วยเหตุผล

ทดสอบซ้ำด้วยไคลเอนต์จริง แล้วค่อยเคลื่อนเข้าข้างใน

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

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

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