Không có lời nhắc tên người dùng là một món quà chẩn đoán: PPP chưa khởi động, nên tài khoản, mật khẩu và chính sách miền chưa được hỏi tới. Trong kết nối PPTP hoặc L2TP/IPsec, ứng dụng khách chỉ hỏi thông tin đăng nhập sau khi đường hầm tồn tại và máy chủ đã bắt đầu một phiên PPP. Mọi thứ có thể hỏng trước thời điểm đó là truyền tải, trao đổi khóa hoặc thiết lập đường hầm, một phạm vi nhỏ hơn nhiều so với «VPN bị hỏng».

Lời nhắc thiếu thu hẹp lỗi vào ba giai đoạn

Ghi lại giai đoạn cuối cùng đã thành công một cách nhìn thấy được, vì mỗi giai đoạn có người phụ trách và cách sửa khác nhau. Đoán cài đặt tài khoản khi đang kẹt ở hai giai đoạn trước là cách một buổi chiều biến mất.

StageWhat has to workHow a failure looks
ReachUDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT deviceClient hangs, then reports no response
Key exchangePreshared key or certificate, phase 1 and phase 2 proposalsFast error, or a stall after the client says it is verifying
TunnelL2TP or PPTP control channel, then PPP startsConnects, then closes with no prompt
User authPPP credentials and an address pool with roomPrompt appears, then a rejection

Ứng dụng khách hết thời gian mà không có lời nhắc chưa bao giờ nhận được liên kết IPsec, nên lỗi nằm ở IKE hoặc ở việc gói tin của bạn có tới được cổng vào hay không. Cái báo rằng đang xác minh thông tin đăng nhập rồi rơi xuống đã đi xa hơn thông điệp gợi ý. Lời nhắc theo sau là từ chối là xác thực PPP, và điều đó thuộc một bài về tài khoản, không phải bài này.

Giai đoạn một: giao thức mà tường lửa âm thầm bỏ rơi

PPTP cần TCP 1723 cho kênh điều khiển và giao thức IP 47 cho đường dữ liệu, và hai thứ đi riêng. Nhiều mạng chuyển tiếp 1723 và bỏ rơi giao thức 47, tạo ra một đường hầm thương lượng được rồi không chở gì cả. Bộ định tuyến làm NAT cũng cần một lối đi hỗ trợ GRE, và đường truy cập chỉ có IPv6 không thể chở PPTP trong bất kỳ cấu hình nào.

L2TP trên IPsec dùng cổng 500 cho IKE và cổng 4500 cho xuyên NAT, rồi bọc chính lưu lượng L2TP vào 1701, trong khi ESP chở tải được bảo vệ khi liên kết tồn tại. Cho phép hai cổng điều khiển nhưng không cho ESP, và bạn nhận đúng triệu chứng trong tiêu đề: tiến trình thấy được, rồi ứng dụng khách chết trước mọi hộp thoại thông tin đăng nhập. Thử từ điểm phát sóng điện thoại là cách rẻ để tách vấn đề ứng dụng khách khỏi vấn đề đường đi.

Giai đoạn hai: một khóa không phải khóa, một đề nghị không được đưa ra

Khóa chia sẻ trước không khớp hỏng nhanh và lặng lẽ, và dạng thường gặp là khóa trông đúng trên màn hình nhưng mang theo một ngắt dòng đã dán hoặc một dấu cách ở cuối. Trên ứng dụng khách Linux hộp thoại không nhất thiết là nguồn sự thật: plugin L2TP của NetworkManager giữ bí mật trong các tệp dưới /etc/ipsec.d/, và một tệp cũ cho mỗi kết nối mà /etc/ipsec.secrets vẫn bao gồm sẽ được dùng thay cho tệp bạn vừa gõ. Sao chép tệp đó tới nơi an toàn, đưa nó ra khỏi đường bao gồm, rồi gõ lại khóa bằng tay.

Nửa còn lại của giai đoạn này là đề nghị. Hai đầu phải thống nhất cùng một bộ thuật toán giai đoạn 1 — mã hóa, toàn vẹn và nhóm Diffie-Hellman — và các phép biến đổi ESP khớp nhau cho giai đoạn 2, nếu không liên kết sẽ không hình thành. Một cổng vào chỉ cung cấp 3DES, SHA1 và MODP1024 sẽ từ chối ứng dụng khách được cấu hình cho thuật toán mạnh hơn, và nhật ký của nó nêu tên phép biến đổi bị từ chối. Nhật ký nêu tên sự không khớp nếu bạn đọc nó thay vì khởi động lại dịch vụ một lần nữa. Thay vì sao chép chuỗi thuật toán từ một chủ đề diễn đàn, hãy hỏi cổng vào xem nó thực sự sẽ thương lượng những phép biến đổi nào: ike-scan trỏ tới địa chỉ của nó trả về các phép biến đổi mà nó sẽ thương lượng. Nếu đề nghị duy nhất là loại mã hóa mà chính sách của bạn không còn cho phép, bản sửa nằm ở cổng vào, không phải ở việc hạ cấp ứng dụng khách.

Trên Windows, khóa và phương thức xác thực sống trong hồ sơ VPN, và sự không khớp xuất hiện trước lời nhắc thông tin đăng nhập chứ không phải sau. Khi bên nhận là Windows Server, hãy xác nhận vai trò truy cập từ xa đã được cài, chứng chỉ khớp với tên mà ứng dụng khách kết nối tới, và không có bộ lọc cổng nào hẹp hơn các giao thức ở trên.

Giai đoạn ba: đường hầm tồn tại và PPP không bao giờ khởi động

Khi IKE hoàn tất mà lời nhắc vẫn không xuất hiện, hãy xem tiến trình nền của đường hầm thay vì tường lửa. L2TP cần một thứ lắng nghe trên UDP 1701 — xl2tpd hoặc kl2tpd trên Linux, dịch vụ truy cập từ xa trên Windows — và một dịch vụ đã cài nhưng dừng trông từ phía ứng dụng khách y hệt một gói bị bỏ. Kiểm tra bên lắng nghe trước khi mở lại các quy tắc bạn đã xác minh. Sau đó PPP phải thương lượng, và lần trao đổi LCP đầu tiên là nơi một thất bại im lặng thường hạ cánh.

Một cái bẫy ở giai đoạn này hoàn toàn không phải lỗi mạng: Windows chỉ cho phép một kết nối thuộc một loại VPN nhất định tại một thời điểm, nên lần thử thứ hai trả về lỗi 937, «một kết nối khác cùng loại đang được dùng». Đó là quy tắc cục bộ, và cách vòng qua là thiết bị khác, loại đường hầm khác, hoặc chia sẻ kết nối duy nhất đã tồn tại.

Đọc nhật ký theo thứ tự giai đoạn thay vì đoán

Dừng ứng dụng khách, khởi động lại, và đọc các thành phần theo thứ tự chúng ghi nhật ký. Tức là trước tiên tiến trình nền IPsec — strongSwan hoặc Libreswan, và ipsec --version cho bạn biết cái nào — rồi tiến trình nền L2TP, rồi pppd. Thành phần nào ghi cuối cùng trước khi hỏng sẽ đánh dấu giai đoạn cần điều tra, vì mọi thứ đến sau nó trong trình tự đều không hề chạy.

Xác minh bằng một kết nối mới chứ không phải phiên đã lưu, vì ứng dụng khách kết nối lại từ bộ nhớ đệm có thể bỏ qua các phần của quá trình trao đổi và tái tạo một kết quả cũ. Xác nhận khả năng tiếp cận, trao đổi khóa, đường hầm và PPP từng cái một, theo thứ tự đó. Khi ấy lời nhắc thiếu không còn là điều bí ẩn nữa mà trở thành dòng thứ hai của một danh sách bạn thực sự có thể làm theo. Danh sách đó cũng là thứ bạn trao cho nhóm mạng, những người nếu không sẽ được yêu cầu kiểm tra tường lửa vì một lỗi sống trong tiến trình nền chưa khởi động.

Bài viết liên quan