เกิดข้อผิดพลาด 868 กับการมีที่อยู่ IP? Windows แก้อะไรก่อน

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

ไคลเอนต์แปลงชื่อก่อนจะเชื่อมต่อ

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

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

ชื่อใด เมื่อฟิลด์แสดงที่อยู่

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

Get-VpnConnection -Name "Work VPN" |
    Select-Object Name, ServerAddress, TunnelType

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

Resolve-DnsName vpn.example.com

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

รูปแบบการเชื่อมต่อใหม่ของ Windows 7

กระทู้เบื้องหลังข้อผิดพลาดนี้อธิบายเครื่องที่เชื่อมต่อได้ครั้งหนึ่งแล้วล้มเหลวในการพยายามครั้งหลังด้วย 868 โดยไม่มีอะไรเปลี่ยนในโปรไฟล์ ผู้ร่วมรายงานว่า การรีสตาร์ทบริการ Remote Access Connection Manager หรือการออกและลงชื่อเข้าใช้อีกครั้งช่วยคืนการเชื่อมต่อชั่วคราว นั่นเป็นวิธีเลี่ยง ไม่ใช่สาเหตุรากที่พิสูจน์แล้ว

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

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

สิ่งที่ต้องเก็บรวบรวมสำหรับผู้ดูแลระบบ

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

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

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