ทำไม PPTP และ L2TP/IPsec จึงหยุดก่อนจะถามชื่อผู้ใช้
การไม่ถามชื่อผู้ใช้หมายความว่า PPP ไม่ได้เริ่มเลย ดังนั้นปัญหาอยู่ที่การขนส่ง การแลกเปลี่ยนคีย์ หรือการตั้งทันเนล ตรวจสอบลำดับขั้นก่อนติดตั้งใหม่
การไม่ถามชื่อผู้ใช้เป็นของขวัญทางการวินิจฉัย: PPP ยังไม่เริ่ม ดังนั้นบัญชี รหัสผ่าน และนโยบายโดเมนยังไม่ถูกสอบถาม ในการเชื่อมต่อ PPTP หรือ L2TP/IPsec ไคลเอนต์จะขอข้อมูลรับรองก็ต่อเมื่อทันเนลมีอยู่และเซิร์ฟเวอร์เริ่มเซสชัน PPP แล้ว ทุกอย่างที่ล้มเหลวได้ก่อนเวลานั้นคือการขนส่ง การแลกเปลี่ยนคีย์ หรือการตั้งทันเนล ซึ่งเป็นพื้นที่เล็กกว่าคำว่า «VPN เสีย» มาก
การไม่มีคำถามทำให้ความผิดพลาดแคบลงเหลือสามขั้น
จดขั้นสุดท้ายที่สำเร็จอย่างเห็นได้ชัด เพราะแต่ละขั้นมีเจ้าของและวิธีแก้ต่างกัน การเดาการตั้งค่าบัญชีขณะติดอยู่ก่อนหน้านั้นสองขั้นคือวิธีที่บ่ายวันหนึ่งหายไป
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
ไคลเอนต์ที่หมดเวลาก่อนโดยไม่มีคำถามไม่เคยได้สมาคม IPsec ดังนั้นความผิดพลาดอยู่ที่ IKE หรือที่ว่าแพ็กเก็ตของคุณไปถึงเกตเวย์หรือไม่ ไคลเอนต์ที่รายงานว่ากำลังตรวจสอบข้อมูลรับรองแล้วล้มลงไปนั้นไปไกลกว่าที่ข้อความบอก คำถามที่ตามด้วยการปฏิเสธคือการพิสูจน์ตัวตน PPP ซึ่งอยู่ในบทความเกี่ยวกับบัญชีไม่ใช่บทความนี้
ขั้นที่หนึ่ง: โปรโตคอลที่ไฟร์วอลล์ทิ้งอย่างเงียบ ๆ
PPTP ต้องใช้ TCP 1723 สำหรับช่องควบคุมและโปรโตคอล IP 47 สำหรับเส้นทางข้อมูล และทั้งสองเดินทางแยกกัน เครือข่ายจำนวนมากส่งต่อ 1723 แต่ทิ้งโปรโตคอล 47 ซึ่งทำให้ได้ทันเนลที่เจรจาได้แต่ไม่บรรทุกอะไรเลย เราเตอร์ที่ทำ NAT ก็ต้องมีทางผ่านที่รองรับ GRE และเส้นทางเข้าถึงแบบ IPv6 เท่านั้นไม่สามารถบรรทุก PPTP ได้ในทุกการตั้งค่า
L2TP บน IPsec ใช้พอร์ต 500 สำหรับ IKE และพอร์ต 4500 สำหรับข้าม NAT จากนั้นห่อหุ้มทราฟฟิก L2TP เองไว้ใน 1701 ขณะที่ ESP บรรทุกเพย์โหลดที่ป้องกันแล้วเมื่อสมาคมเกิดขึ้น อนุญาตพอร์ตควบคุมทั้งสองแต่ไม่อนุญาต ESP คุณจะได้อาการตามหัวข้อพอดี คือมีความคืบหน้าที่มองเห็นได้ แล้วไคลเอนต์ก็ตายก่อนกล่องขอข้อมูลรับรอง การทดสอบจากฮอตสปอตมือถือเป็นวิธีถูก ๆ ในการแยกปัญหาของไคลเอนต์ออกจากปัญหาของเส้นทาง
ขั้นที่สอง: คีย์ที่ไม่ใช่คีย์ ข้อเสนอที่ไม่ถูกเสนอ
คีย์ที่แชร์ล่วงหน้าที่ไม่ตรงกันล้มเหลวอย่างรวดเร็วและเงียบ และรูปแบบที่พบบ่อยคือคีย์ที่ดูถูกต้องบนหน้าจอแต่มีการขึ้นบรรทัดใหม่ที่ติดมาหรือมีช่องว่างท้าย บนไคลเอนต์ Linux กล่องโต้ตอบไม่ใช่แหล่งความจริงเสมอไป: ปลั๊กอิน L2TP ของ NetworkManager เก็บความลับไว้ในไฟล์ใต้ /etc/ipsec.d/ และไฟล์เก่าต่อการเชื่อมต่อที่ /etc/ipsec.secrets ยังรวมอยู่จะถูกใช้แทนไฟล์ที่คุณเพิ่งพิมพ์ คัดลอกไฟล์นั้นไปยังที่ปลอดภัย เอามันออกจากเส้นทางการรวม แล้วพิมพ์คีย์ใหม่ด้วยมือ
อีกครึ่งหนึ่งของขั้นนี้คือข้อเสนอ ทั้งสองฝั่งต้องตกลงชุดอัลกอริทึมเฟส 1 เดียวกัน คือ การเข้ารหัส ความสมบูรณ์ และกลุ่ม Diffie-Hellman และการแปลง ESP ที่ตรงกันสำหรับเฟส 2 มิฉะนั้นสมาคมจะไม่เกิดขึ้นเลย เกตเวย์ที่เสนอเพียง 3DES, SHA1 และ MODP1024 จะปฏิเสธไคลเอนต์ที่ตั้งค่าไว้อัลกอริทึมที่แข็งแรงกว่า และบันทึกของมันจะระบุชื่อการแปลงที่ถูกปฏิเสธ บันทึกจะระบุความไม่ตรงกันถ้าคุณอ่านมันแทนที่จะรีสตาร์ตบริการอีกครั้ง แทนที่จะคัดลอกสตริงอัลกอริทึมจากกระทู้ฟอรัม ให้ถามเกตเวย์ว่าจะเจรจาการแปลงใดจริง ๆ: ike-scan ที่เล็งไปยังที่อยู่ของมันจะคืนค่าการแปลงที่จะเจรจา ถ้าข้อเสนอเดียวคือการเข้ารหัสที่นโยบายของคุณไม่อนุญาตแล้ว การแก้ไขอยู่ที่เกตเวย์ ไม่ใช่ที่การลดระดับไคลเอนต์
ใน Windows คีย์และวิธีการพิสูจน์ตัวตนอยู่ในโปรไฟล์ VPN และความไม่ตรงกันจะปรากฏก่อนคำขอข้อมูลรับรองไม่ใช่หลัง เมื่อฝ่ายรับเป็น Windows Server ให้ยืนยันว่าบทบาทการเข้าถึงระยะไกลติดตั้งแล้ว ใบรับรองตรงกับชื่อที่ไคลเอนต์เชื่อมต่อ และไม่มีตัวกรองพอร์ตใดแคบกว่าโปรโตคอลข้างต้น
ขั้นที่สาม: ทันเนลมีอยู่แต่ PPP ไม่เริ่ม
เมื่อ IKE เสร็จสิ้นและคำถามยังไม่ปรากฏ ให้ดูที่เดมอนของทันเนลไม่ใช่ไฟร์วอลล์ L2TP ต้องการสิ่งที่ฟังอยู่บน UDP 1701 คือ xl2tpd หรือ kl2tpd บน Linux บริการเข้าถึงระยะไกลบน Windows และบริการที่ติดตั้งแล้วแต่หยุดอยู่ดูจากฝั่งไคลเอนต์เหมือนแพ็กเก็ตที่ถูกทิ้ง ตรวจสอบผู้ฟังก่อนจะเปิดกฎที่คุณตรวจสอบแล้วอีกครั้ง จากนั้น PPP ต้องเจรจา และการแลกเปลี่ยน LCP ครั้งแรกคือที่ที่ความล้มเหลวเงียบ ๆ มักลงเอย
กับดักหนึ่งในขั้นนี้ไม่ใช่ความผิดพลาดของเครือข่ายเลย: Windows อนุญาตการเชื่อมต่อประเภท VPN ที่กำหนดได้ครั้งละหนึ่งรายการ ดังนั้นความพยายามครั้งที่สองจะคืนข้อผิดพลาด 937 ว่า «การเชื่อมต่อประเภทนี้อีกรายการกำลังใช้งานอยู่» นี่เป็นกฎภายในเครื่อง และทางออกคืออุปกรณ์อื่น ทันเนลชนิดอื่น หรือแบ่งปันการเชื่อมต่อเดียวที่มีอยู่แล้ว
อ่านบันทึกตามลำดับขั้นแทนการเดา
หยุดไคลเอนต์ เริ่มใหม่ แล้วอ่านส่วนประกอบตามลำดับที่มันเขียนบันทึก นั่นคือก่อนอื่นเดมอน IPsec คือ strongSwan หรือ Libreswan และ ipsec --version บอกว่าตัวไหน จากนั้นเดมอน L2TP แล้วจึง pppd ส่วนประกอบใดก็ตามที่เขียนล่าสุดก่อนความล้มเหลวคือขั้นที่ต้องตรวจสอบ เพราะทุกอย่างที่ตามมาหลังจากนั้นในลำดับไม่ได้ทำงานเลย
ตรวจสอบด้วยการเชื่อมต่อใหม่ไม่ใช่เซสชันที่บันทึกไว้ เพราะไคลเอนต์ที่เชื่อมต่อใหม่จากแคชอาจข้ามส่วนของการแลกเปลี่ยนและสร้างผลลัพธ์เก่าขึ้นมาใหม่ ยืนยันการเข้าถึง การแลกเปลี่ยนคีย์ ทันเนล และ PPP ทีละอย่างตามลำดับนั้น แล้วคำถามที่หายไปก็เลิกเป็นปริศนาและกลายเป็นบรรทัดที่สองของรายการที่คุณทำงานผ่านได้จริง รายการนั้นก็คือสิ่งที่คุณส่งให้ทีมเครือข่าย ซึ่งมิฉะนั้นจะถูกขอให้ตรวจไฟร์วอลล์เพราะความผิดพลาดที่อาศัยอยู่ในเดมอนที่ไม่ได้เริ่ม