MSCHAPv2 ไม่ใช่โปรโตคอล VPN: ถามเรื่องอุโมงค์ก่อน

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

การพิสูจน์ตัวตนวิ่งอยู่ภายในอุโมงค์

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

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

สามตำแหน่งที่วิธีเดียวกันปรากฏ

ใน PPP ขั้นตอนการพิสูจน์ตัวตนรอจนกว่าจะมีลิงก์ และ RFC 2759 นิยาม MS-CHAPv2 ว่าเป็นขั้นตอนนั้น จึงเป็นเหตุให้วิธีนี้ปรากฏใน L2TP และในการติดตั้ง PPTP รุ่นเก่ากว่า อุโมงค์สิ้นสุดก่อนและการเจรจา PPP เกิดขึ้นภายในนั้น ดังนั้นขั้น PPP ที่ล้มเหลวอาจทำให้อุโมงค์ดูเหมือนถูกสร้างแล้วในบันทึกของเซิร์ฟเวอร์ อ่านสองขั้นนั้นแยกจากกันก่อนสรุปว่าข้อมูลรับรองถูกปฏิเสธ ดังนั้นไคลเอนต์ที่ตั้งค่าสำหรับ L2TP อาจถูกต้องสมบูรณ์และยังคงเป็นไคลเอนต์ผิดสำหรับเกตเวย์ที่พูดได้แค่ IKEv2

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

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

คำตอบที่คุณต้องการจริงๆ

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

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

อย่าผ่อนการตรวจสอบเกตเวย์

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

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

ปรับโปรไฟล์ให้ตรง แล้วพิสูจน์แต่ละขั้น

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

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