ขั้นตอน VPN ใดที่ล้มเหลว: IPsec, การควบคุม L2TP หรือการยืนยันตัวตน PPP
หาขั้นตอนสุดท้ายที่สำเร็จแล้วแก้ไขเฉพาะชั้นนั้น: IPsec ช่องควบคุม L2TP การยืนยันตัวตน PPP หรือการกำหนดที่อยู่
คุณเปลี่ยนรหัสผ่านแล้วไม่มีอะไรขยับ เพราะความล้มเหลวไม่เคยอยู่ที่ PPP L2TP/IPsec รายงานข้อผิดพลาดการเชื่อมต่อเดียวสำหรับการส่งต่อห้าแบบที่ต่างกันมาก และแต่ละแบบมีการซ่อมของตัวเอง จงทำงานย้อนกลับ: หาขั้นตอนสุดท้ายที่สำเร็จและเปลี่ยนเฉพาะสิ่งหลังจากนั้น ลำดับด้านล่างยังกำหนดว่าคุณเก็บหลักฐานใดก่อน
ตอบคำถามสี่ข้อตามลำดับ
บังคับให้มีความพยายามใหม่ เพราะไคลเอนต์บางตัวยังแสดงข้อผิดพลาดเดิมจนกว่าโปรไฟล์จะถูกตัดและเชื่อมต่อใหม่ จากนั้นตอบว่า: มีสมาคมความปลอดภัย IPsec หรือไม่ มีการเชื่อมต่อควบคุม L2TP และการเรียกเกิดขึ้นหรือไม่ PPP ไปถึงคำตัดสินการยืนยันตัวตนหรือไม่ และ IPCP ให้ที่อยู่กับไคลเอนต์หรือไม่ ไม่ ตัวแรกคือขั้นตอนที่คุณแก้ ทุกอย่างหลังจากนั้นยังไม่ได้ทดสอบ ชื่อผู้ใช้ที่ถูกปฏิเสธจึงไม่พิสูจน์อะไรเมื่อไม่เคยมีสมาคมเลย
ซิงโครไนซ์นาฬิกาที่ปลายทั้งสองก่อนเปรียบเทียบ การลองใหม่ที่ล้าง IPsec และล้มเหลวที่ PPP ดูเหมือนความล้มเหลวเดียวเมื่อไคลเอนต์แสดงเฉพาะข้อความสุดท้ายและบันทึกของเซิร์ฟเวอร์ยังเก็บความพยายามก่อนหน้าไว้ อ่านตามตราเวลา ไม่ใช่ตามบรรทัดที่ดังก้องที่สุด
เมื่อมีเพียงภาพหน้าจอของผู้ใช้ ให้พึ่งการแยกที่ถูกที่สุด: คีย์ที่แชร์ล่วงหน้าผิดและ xl2tpd ที่ไม่เคยตอบจะสร้างข้อความเดียวกันในกล่องโต้ตอบ Windows แต่แบบหนึ่งต้องเปลี่ยนความลับทั้งสองปลาย อีกแบบต้องเริ่มเดมอนหรือตั้งกฎไฟร์วอลล์บนเซิร์ฟเวอร์เอง อุปกรณ์ตรงกลางไม่สามารถทิ้ง 1701 ภายในได้เมื่อ IPsec โหมดขนส่งห่อหุ้มแล้ว จึงไม่ต้องตามหาตัวกรองเส้นทางที่ไม่มีอยู่
แต่ละชั้นเป็นเจ้าของอะไรจริง ๆ
IPsec ปกป้องแพ็กเก็ตระหว่าง peers สองตัว L2TP บรรทุกเซสชัน PPP ภายในเส้นทางที่ป้องกันนั้น จึงเป็นเหตุให้ RFC 3193 ระบุโหมดขนส่งแทนอุโมงค์ของตัวเอง ป้ายของไคลเอนต์บอก L2TP ดังนั้นอุโมงค์และการเข้าสู่ระบบจึงรู้สึกเหมือนกลไกเดียว ไม่ใช่: การเชื่อมต่อควบคุม L2TP ยืนยันตัวตนปลายอุโมงค์ในที่ที่การติดตั้งเปิดใช้ และ PPP ยืนยันตัวตนผู้ใช้แยกต่างหากด้วย CHAP, PAP หรือ MS-CHAPv2 ตามนโยบายของเซิร์ฟเวอร์
การแยกนี้อธิบายความลับสองอย่างที่ผู้คนสับสนเสมอ คีย์ที่แชร์ล่วงหน้ายืนยันตัวตน peers ของ IPsec ชื่อผู้ใช้และรหัสผ่านระบุตัวผู้ใช้ต่อ PPP การพิมพ์ความลับที่แชร์ของ Windows ซ้ำบนโปรไฟล์ที่ยืนยันด้วยใบรับรองไม่เปลี่ยนอะไรในขั้นที่ล้มเหลว และการแก้รหัสผ่าน PPP ไม่สามารถให้ช่องทางที่ป้องกันซึ่งหายไปได้ การยับยั้งเดียวกันใช้กับการตรวจสอบตัวตน: อย่าปิดตัวตนของ peer หรือการตรวจสอบใบรับรองเพื่อให้ได้อุโมงค์ เพราะสิ่งที่เชื่อมต่อตอนนั้นคือเส้นทาง ไม่ใช่ peer
การยืนยันตัวตนก็ไม่ใช่จุดสิ้นสุดของ PPP หลังจากผู้ใช้ได้รับการยอมรับ IPCP เจรจาที่อยู่ของไคลเอนต์และตัวเลือก DNS กับ WINS ที่เซิร์ฟเวอร์ยินดีให้ ไคลเอนต์อาจผ่าน CHAP หรือ MS-CHAPv2 แล้วยังคงไม่มีที่อยู่ ซึ่งเป็นความล้มเหลวภายใน PPP ไม่ใช่ปัญหาเส้นทาง L2TP เปล่า ๆ ที่ไม่มี IPsec ยังใช้ได้และไม่ถูกป้องกัน การเชื่อมต่อที่สำเร็จจึงไม่เคยพิสูจน์ว่าทราฟฟิกถูกป้องกัน ตรวจสอบว่าเซิร์ฟเวอร์บังคับอะไร ไม่ใช่ป้ายของไคลเอนต์
ตัดสินจากขั้นตอนแรกที่ขาดหาย
อ่านตารางตามรายการแรกที่ขาดหาย จากซ้ายไปขวา คอลัมน์ขวาคืองานเดียวที่คุ้มค่าในขณะนั้น ทุกอย่างทางซ้ายได้รับการพิสูจน์แล้ว และการทดสอบซ้ำจะเผาหน้าต่างเวลาหยุดโดยไม่เพิ่มข้อมูล
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
สามแถวสมควรได้รับคำเตือน แถว 1701 คือที่ที่ไคลเอนต์ Windows หลัง NAT มักลงเอย: สมาคมเสร็จสิ้น แล้วไม่มีอะไรมา และสาเหตุคือการห่อหุ้มไม่ใช่รหัสผ่านแย่ แถว IPCP คือแถวที่อ่านผิดว่าเป็นปัญหาเส้นทาง เพราะ Windows ห่อที่อยู่ที่ขาดหายไว้ในข้อผิดพลาด 720 และไอคอนถาดเพียงบอกว่าการเชื่อมต่อล้มเหลว ความล้มเหลวนั้นอยู่หลังการยืนยันตัวตนและก่อนการกำหนดเส้นทาง แถวสุดท้ายไม่ใช่ความล้มเหลว IPsec เลย แม้ไอคอนจะบอกว่าตัดการเชื่อมต่อ
คำสั่งที่แยกชั้น
บนเซิร์ฟเวอร์ Linux ที่ใช้ strongSwan swanctl --list-sas แสดงรายการสมาคมที่สร้างขึ้นพร้อมตัวตนของ peer และ ipsec statusall ครอบคลุมโฮสต์ strongSwan และ libreswan รุ่นเก่า ข้างใต้นั้น ip xfrm state แสดงสมาคมจริงของเคอร์เนล ขณะที่ ss -lunp | grep 1701 พิสูจน์ว่า xl2tpd ผูกอยู่ที่ใด เรียก xl2tpd -D บนเบื้องหน้าเพื่อดูการเชื่อมต่อควบคุมและการเรียก และเปิดดีบัก pppd ใน /etc/ppp/options.xl2tpd เพื่อดูวิธีการที่เสนอและคำตอบ
เมื่อบันทึกแสดงการยืนยันตัวตนที่สำเร็จ คำถามถัดไปคือ IPCP เสร็จสมบูรณ์หรือไม่ ตรวจสอบว่า ip range ในส่วน [lns default] ของ /etc/xl2tpd/xl2tpd.conf ยังมีที่อยู่ว่างหรือไม่ และ /etc/ppp/options.xl2tpd มี ms-dns และ ms-wins จริงหรือไม่หากไคลเอนต์คาดหวัง กลุ่มที่ใช้หมดและตัวเลือก DNS ที่ขาดหายดูต่างกันบนสาย: อย่างแรกทิ้งไคลเอนต์ไว้โดยไม่มีที่อยู่และมี 720 อย่างที่สองให้ที่อยู่แต่ไม่มีตัวแก้ชื่อ ชื่อจึงล้มเหลวขณะที่ ping ไปยังที่อยู่ดิบทำงาน ทั้งสองไม่ได้รับการแก้ไขด้วยการพิมพ์รหัสผ่านใหม่
บนไคลเอนต์ ปลั๊กอิน L2TP ของ NetworkManager เขียนบทสนทนา pppd ลงในบันทึก journalctl -u NetworkManager -b จึงมักแยก อุโมงค์ขึ้น การยืนยันตัวตนถูกปฏิเสธ จาก ไม่มีอุโมงค์เลย บน Windows Get-VpnConnection รายงานการตั้งค่าการยืนยันตัวตนจริงของโปรไฟล์ และเหตุการณ์ RasClient ใต้ Application ใน Event Viewer ระบุส่วนประกอบที่ล้มเหลว เมื่อกล่องโต้ตอบคลุมเครือเกินไป ให้เปิดใช้ netsh ras set tracing * enable
การดักจับต้องใช้ความระมัดระวังหนึ่งอย่าง ด้วย IPsec โหมดขนส่ง UDP 1701 ภายในถูกเข้ารหัส การดักจับบนอินเทอร์เฟซภายนอกจึงแสดง ESP หรือ UDP 4500 ภายใต้ NAT-T และไม่แสดง L2TP เลย การไม่มี 1701 ในการดักจับเป็นสิ่งที่คาดไว้และไม่ใช่หลักฐานว่าพอร์ตถูกบล็อก ให้ดูว่าตัวนับ ESP หรือ 4500 เคลื่อนไหวหรือไม่
NAT, MTU และเส้นทาง: ที่ที่สแตกทำให้คุณเข้าใจผิด
NAT ทำให้สมมติฐานแตกก่อนสิ่งใดจะถูกยืนยันตัวตน ESP เป็นโปรโตคอล IP ของตัวเอง อุปกรณ์ที่แปลจึงทิ้งมันเว้นแต่ peers จะห่อหุ้ม UDP 4500 ให้สิ่งนั้น บนเซิร์ฟเวอร์ Windows ที่อยู่หลังเราเตอร์บ้านหรือเกตเวย์ NAT บนคลาวด์เอง ขั้น IPsec ล้มเหลวด้วยข้อผิดพลาด 789 จนกว่า AssumeUDPEncapsulationContextOnSendRule จะถูกตั้งเป็น 2 ใต้คีย์ PolicyAgent และเครื่องรีสตาร์ต และความล้มเหลวยังแยกจากพอร์ตที่ปิดไม่ได้ ไคลเอนต์หลัง NAT ง่ายกว่า: เมื่อเซิร์ฟเวอร์มีที่อยู่สาธารณะ NAT-T บน UDP 4500 พาพวกเขาไปและค่านั้นไม่เกี่ยวข้อง
เมื่อ PPP ขึ้นแล้ว MTU ที่มีหลุมดำเลียนแบบอุโมงค์ที่ตาย: แพ็กเก็ตเล็กผ่านได้ การจับมือ TLS หรือการโหลดหน้าค้าง และไคลเอนต์อาจยังแสดงว่าเชื่อมต่อ ลด MTU ของอินเทอร์เฟซหรือบีบ MSS ที่เกตเวย์ก่อนโทษเซิร์ฟเวอร์ การกำหนดเส้นทางอุโมงค์แยกเป็นตัวหลอกอีกตัว: ซับเน็ตที่ส่งด้วยมาสก์ผิดทำให้อุโมงค์ยังดีและแอปพลิเคชันหนึ่งเข้าถึงไม่ได้ ชื่อโฮสต์ส่วนตัวเพิ่มก้าวของตัวเอง: หากคำค้นออกผ่านตัวแก้ชื่อภายใน ชื่อจะแก้ไม่ได้ก่อนที่จะทดสอบเส้นทางใด ๆ
รายการตรวจสอบก่อนแตะข้อมูลรับรอง
ทำงานตามรายการตามลำดับและหยุดที่รายการแรกที่ล้มเหลว ทุกขั้นตอนมีราคาถูก และแต่ละอย่างตัดการแก้ไขออกทั้งประเภท
- ยืนยันว่าสมาคมมีอยู่ที่ปลายทั้งสอง จับคู่ด้วยตัวตนของ peer ไม่ใช่ป้ายเชื่อมต่อ
- ยืนยันว่า UDP 1701 ไปถึง xl2tpd สมาคมที่ไม่มีการเรียกคือความล้มเหลวของคุณ
- อ่านคำตัดสินของ PPP และถ้ายืนยันแล้ว ผลของ IPCP ก่อนสันนิษฐานว่ารหัสผ่านผิด
- ตอนนี้เท่านั้นให้ป้อนข้อมูลรับรองใหม่ในรูปแบบที่เซิร์ฟเวอร์คาดหวัง เพราะคำนำหน้าโดเมนเปลี่ยนบัญชี
- หากยังล้มเหลว ให้ดักจับปลายทั้งสองด้วยตราเวลาที่จัดแนวแล้วและเปรียบเทียบทีละขั้น
การหยุดที่ขั้นสองหมายถึงปัญหเส้นทางหรือการห่อหุ้ม และการแก้รหัสผ่านไม่ทำให้มันขยับ การหยุดที่ขั้นสามหมายถึงบันทึกระบุวิธีการหรือกลุ่มที่อยู่ที่ต้องแก้แล้ว ไม่ว่าอย่างไรการเปลี่ยนแปลงถัดไปคือสิ่งที่คุณให้เหตุผลได้ และคุณหยุดวนเวียนกับการตั้งค่าที่ไม่เคยเกี่ยวข้อง