ข้อผิดพลาด PPTP 800 กับ 812 และการหลุดการเชื่อมต่อหลังผ่านไปหนึ่งนาที
ข้อผิดพลาด 800 ข้อผิดพลาด 812 และอุโมงค์ PPTP ที่ตายหลังผ่านไปหนึ่งนาทีเป็นความผิดพลาดสามอย่างแยกกัน จับคู่อาการแต่ละอย่างกับชั้นที่ล้มเหลวจริง
ข้อความข้อผิดพลาดสามข้อจากไคลเอนต์ PPTP หนึ่งตัวมักอธิบายความผิดพลาดสามอย่างที่แตกต่างกัน ข้อผิดพลาด 800 หมายความว่าอุโมงค์ไม่เคยถูกสร้างขึ้น ข้อผิดพลาด 812 หมายความว่าเซิร์ฟเวอร์ปฏิเสธวิธีการพิสูจน์ตัวตน และการหลุดหลังผ่านไปหนึ่งนาทีคือตัวจับเวลา keepalive ที่ตัดสินว่าเพื่อนที่แข็งแรงได้จากไปแล้ว แต่ละขั้นล้มเหลวด้วยเหตุผลของตัวเอง ดังนั้นแต่ละขั้นจึงต้องมีการตรวจสอบของตัวเอง
ข้อผิดพลาด 800 หมายความว่าอุโมงค์ไม่เคยถูกสร้างขึ้น
Windows แสดงข้อผิดพลาด 800 เมื่อไม่สามารถสร้างอุโมงค์ได้เลย และข้อความเกี่ยวกับเซิร์ฟเวอร์ที่เข้าถึงไม่ได้หรือพารามิเตอร์ความปลอดภัยที่ไม่เหมาะสมเป็นบทสรุปไม่ใช่การวินิจฉัย PPTP ต้องการสองสิ่งแยกจากกันจากเครือข่ายก่อนที่จะตรวจสอบข้อมูลรับรองใด ๆ TCP 1723 พาแชนเนลควบคุม และโปรโตคอล IP 47 คือ GRE พาเพย์โหลดที่ถูกห่อหุ้ม
ทดสอบเส้นทางภายนอกนั้นจากนอก LAN ของคุณเอง เพราะการเชื่อมต่อที่ทำงานในออฟฟิศไม่ได้พิสูจน์อะไรเกี่ยวกับขอบ:
$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB
ถ้า 1723 ตอบกลับและแคปเจอร์ยังว่างเปล่าขณะที่ไคลเอนต์พยายามเชื่อมต่อ เส้นทางกำลังทิ้งโปรโตคอล 47 เราเตอร์ที่ส่งต่อ 1723 แต่ปิด passthrough ของ PPTP ให้รูปแบบนั้นพอดี: แฮนด์เชค TCP เสร็จสิ้น จากนั้นแพ็กเก็ต GRE ก็หายไป ความล้มเหลวจึงดูเหมือนปัญหาข้อมูลรับรองแม้จะไม่มีการพยายามล็อกอิน
ชี้การส่งต่อไปยังที่อยู่ LAN ปัจจุบันของเซิร์ฟเวอร์ เปิด passthrough ของ PPTP ในจุดที่เราเตอร์เสนอ และลองอีกครั้งจากจุดภายนอกเดียวกัน เมื่อ GRE ถูกกรองต้นทางและคุณเปลี่ยนไม่ได้ SSTP บน TCP 443 หรือ L2TP/IPsec บน UDP 500 และ 4500 มีโอกาสดีกว่าการเปลี่ยนแปลงใด ๆ ที่คุณทำได้ฝั่ง Windows
ข้อผิดพลาด 812 คือเซิร์ฟเวอร์ปฏิเสธวิธีการพิสูจน์ตัวตนของคุณ
ข้อผิดพลาด 812 กลับมาหลังอุโมงค์ขึ้นแล้ว จึงรู้สึกเหมือนปัญหารหัสผ่าน เซิร์ฟเวอร์ปฏิเสธวิธีการพิสูจน์ตัวตนที่เจรจาสำหรับการเชื่อมต่อ ไม่จำเป็นต้องเป็นรหัสผ่านเอง บนไคลเอนต์ เปิดรายการ VPN ไปที่แท็บความปลอดภัย ตั้งค่าประเภทเป็น Point-to-Point Tunneling Protocol เลือกรายการโปรโตคอลแบบชัดเจน และทำเครื่องหมาย Microsoft CHAP เวอร์ชัน 2
คุณสามารถอ่านการตั้งค่าปัจจุบันได้โดยไม่ต้องคลิกผ่านกล่องโต้ตอบ:
$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2
เซิร์ฟเวอร์ที่ต้องการ MS-CHAP v2 จะปฏิเสธไคลเอนต์ที่ถูกทิ้งไว้บน PAP หรือบนประเภทอัตโนมัติที่เจรจาบางอย่างที่อ่อนกว่า และข้อผิดพลาดมาถึงก่อนที่จะประเมินรหัสผ่านของผู้ใช้ใด ๆ รูปแบบบัญชีเป็นอีกครึ่งหนึ่งของการปฏิเสธเดียวกัน ในกรณีหนึ่ง Windows ส่งข้อมูลระบุตัวตนบัญชี Microsoft ในรูปแบบ MicrosoftAccount\[email protected] ขณะที่เซิร์ฟเวอร์ต้องการบัญชีภายในหรือบัญชีโดเมน การพิมพ์ SERVERNAME\username บอก Windows ว่าจะปรึกษาที่เก็บบัญชีใด และลบข้อผิดพลาดนั้น กรอกชื่อด้วยมือแทนที่จะปล่อยให้ข้อมูลรับรองที่บันทึกไว้เล่นรูปแบบก่อนหน้าซ้ำ
การหลุดหลังผ่านไปหนึ่งนาทีคือการตัดสินใจของ keepalive
เมื่ออุโมงค์เชื่อมต่อ ปล่อยทราฟฟิกผ่านไปเล็กน้อย แล้วจึงตัดการเชื่อมต่อ ให้ดูพฤติกรรมการสะท้อน LCP ของเซิร์ฟเวอร์ก่อนแตะไคลเอนต์ เดมอนขอให้เพื่อนยืนยันเป็นระยะว่ายังอยู่ หากมีคำตอบเข้ามาน้อยเกินไปภายในงบประมาณที่กำหนด เซสชันจะถูกฉีกทิ้งแม้ผู้ใช้ยังมีลิงก์ที่ใช้งานได้
บนเซิร์ฟเวอร์ Linux pptpd ค่าเหล่านั้นอยู่ใน /etc/ppp/options.pptpd และการซ่อมตามปกติคือขยายงบประมาณไม่ใช่ทำให้ช่วงเวลาสั้นลง:
# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd
การพลาดสามสิบครั้งในช่วงห้าวินาทีให้อภัยการหยุดชั่วคราวสั้น ๆ แทนที่จะประกาศว่าเพื่อนจากไป การลดจำนวนลงเหลือหนึ่งหรือสองทำให้ jitter ปกติบนเส้นทางที่แปลแล้วกลายเป็นการตัดการเชื่อมต่อประมาณทุกนาที หากเซิร์ฟเวอร์ของคุณเป็น Windows RRAS ไม่ใช่ pptpd ให้ดูการหมดเวลาของเซสชัน PPP และนโยบายตัดการเชื่อมต่อเมื่อไม่มีการใช้งานแทน ค่าเหล่านั้นอยู่ที่อื่น และการแก้ไฟล์ pppd ที่ไม่มีอยู่จะไม่เปลี่ยนอะไร
ซับเน็ตที่ทับซ้อนกันทำให้เส้นทางข้อมูลแตก
อุโมงค์ PPTP สามารถพิสูจน์ตัวตนได้อย่างสะอาดและยังไปไม่ถึงไหนเมื่อทั้งสองไซต์ใช้ช่วงส่วนตัวเดียวกัน ตัวอย่างเช่น 192.168.1.0/24 ที่ออฟฟิศและที่บ้าน ไคลเอนต์ไม่สามารถบอกได้ว่าที่อยู่หนึ่ง ๆ หมายถึงโฮสต์ใด และสแตกบางตัวปฏิเสธที่จะติดตั้งเส้นทางเลยแทนที่จะเลือกอันหนึ่ง
ถือว่านั่นเป็นข้อบกพร่องด้านการออกแบบและเปลี่ยนหมายเลขฝั่งหนึ่ง หรือมอบช่วงการเข้าถึงที่แปลไว้โดยเจตนาให้ไคลเอนต์ การดีบักไคลเอนต์ PPTP แก้พื้นที่ที่อยู่ซึ่งมีอยู่สองครั้งไม่ได้ และอาการจะยังดูเหมือนการหลุดแบบสุ่ม
เริ่มจากขั้นที่ล้มเหลว: GRE สำหรับ 800 วิธีการและสตริงบัญชีสำหรับ 812 การตั้งค่าการสะท้อนสำหรับอุโมงค์ที่ตายตามกำหนดการ