Vì sao chỉ PPP CHAP không thể đáp ứng yêu cầu MPPE

Một hồ sơ PPTP đòi hỏi mã hóa thường thất bại ở cùng một chỗ: PPP đồng ý một trao đổi xác thực không bao giờ tạo ra vật liệu khóa mà MPPE cần. Đường hầm trông như nửa sống, mật khẩu được chấp nhận, và liên kết rơi trước khi bất kỳ lưu lượng nào đi qua nó. Việc với tay tới danh sách thả xuống CHAP cho đến khi có thứ gì đó kết nối sẽ che giấu khiếm khuyết thật, và đó là một hợp đồng giữa phương thức xác thực và chính sách bảo vệ. Các kiểm tra bên dưới được sắp xếp để mỗi bước loại trừ một nguyên nhân rẻ hơn bước tiếp theo.

Hai cuộc thương lượng diễn ra trong một kết nối PPTP

PPTP mang một phiên PPP bình thường bên trong đường hầm GRE, và hai bên thương lượng riêng. Lớp ngoài quyết định cách đóng gói gói tin và kênh điều khiển nào tồn tại; phiên PPP bên trong quyết định ai là đối tác và lớp bảo vệ nào nằm trên. Vì vậy một lời nhắc mật khẩu chỉ chứng minh điều gì đó về lớp trong, và một cái bắt tay ngoài đã hoàn tất không chứng minh gì về cả hai. Các hồ sơ thất bại ở đây vì người ta gỡ lỗi đường hầm trong khi bất đồng nằm bên trong PPP.

CHAP thường là trao đổi thách thức-phản hồi trong RFC 1994, được xây trên một bí mật chia sẻ và không gì khác. MS-CHAPv2 là một trao đổi khác với thông điệp khác và đầu ra khác, được chuẩn hóa trong RFC 2759. Từ chung trong hai tên là thứ duy nhất chúng có chung trên dây. Không tên nào cho biết trao đổi tạo ra gì, và đó là phần duy nhất quan trọng.

Đó là lý do một tùy chọn chỉ được dán nhãn CHAP là mơ hồ trong hồ sơ cũ. Khi máy chủ muốn MS-CHAPv2 và máy khách đề nghị CHAP thường, điều khiển liên kết vẫn có thể hoàn tất và mật khẩu vẫn có thể được chấp nhận. Lỗi đến sau đó, khi máy chủ cố lấy khóa bảo vệ từ một trao đổi không tạo ra gì cả.

Ghép phương thức được yêu cầu với những khóa mà nó có thể tạo ra

Khóa MPPE không phải là thuộc tính của PPP nói chung. Với họ Microsoft CHAP, việc dẫn xuất được quy định trong RFC 3079, và nó lấy đầu ra của một trao đổi MS-CHAP làm đầu vào thay vì một bí mật chia sẻ. Các phương thức EAP đến cùng chỗ bằng con đường khác, với máy chủ xác thực trả lại các khóa dưới dạng thuộc tính MS-MPPE-Recv-Key và MS-MPPE-Send-Key. CHAP thường không xuất hiện trên cả hai con đường, và đó là toàn bộ lý do sự không khớp này tồn tại.

Một cấu hình yêu cầu MPPE trong khi từ chối mọi phương thức có thể cung cấp khóa là mâu thuẫn nội tại. pppd giải quyết mâu thuẫn đó bằng cách từ chối liên kết, chứ không phải bằng cách bịa ra khóa, nên kết quả nhìn thấy được là một phiên xác thực rồi kết thúc ở giai đoạn mạng. Thử lại máy khách sẽ không thay đổi điều đó khi máy chủ từ chối những phương thức duy nhất có thể dẫn xuất ra gì đó.

Quy tắc rút ra thì ngắn: nếu hồ sơ yêu cầu MPPE, phương thức phải là một biến thể MS-CHAP hoặc một phương thức EAP mà máy chủ trả lại khóa của nó. Chỉ từ chối MS-CHAPv2 không bắt buộc được điều đó, vì MS-CHAPv1 cũng dẫn xuất khóa và vẫn khả dụng trừ khi bị từ chối riêng; từ chối cả hai để lại CHAP thường và PAP, chúng không dẫn xuất gì và khiến yêu cầu không thể đáp ứng. Hãy nêu rõ phương thức được chấp nhận thay vì liệt kê những phương thức bạn không thích. Bỏ yêu cầu mã hóa để máy khách kết nối là hạ cấp, không phải sửa chữa.

Đọc các tùy chọn của máy chủ trước khi sửa máy khách

Phần lớn những sự không khớp này hiện ra trên máy chủ trong hai tệp, và đọc chúng rẻ hơn dựng lại máy khách. Trên một điểm cuối PPTP Linux, các cài đặt liên quan sống trong tệp tùy chọn pppd mà pptpd chuyển tiếp. Hãy chạy nó trên máy chủ, không phải từ màn hình trạng thái máy khách. Bắt đầu với những dòng yêu cầu, từ chối hoặc nêu tên một chế độ bảo vệ:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

Đọc đầu ra như một hợp đồng chứ không phải danh sách cờ. Một dòng yêu cầu MPPE trong khi từ chối cả hai biến thể MS-CHAP thì không máy khách nào đáp ứng được, và việc thiếu yêu cầu cho một phương thức MS-CHAP để ngỏ cửa cho những trao đổi không cho khóa. Sau đó kiểm tra ai được phép xác thực, điều mà tệp bí mật quyết định:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

Ghi lại ba giá trị trước khi thay đổi bất cứ điều gì: giao thức ngoài, phương thức xác thực mà máy chủ yêu cầu, và việc bảo vệ là bắt buộc hay tùy chọn. Ba điều đó quyết định mọi quyết định sau này, và đoán chúng từ hộp thoại máy khách là cách một hồ sơ kết thúc ở trạng thái nửa cấu hình. Giữ tệp mở trong khi làm việc, vì phần tiếp theo cần đúng ba giá trị đó.

Định vị lỗi theo giai đoạn PPP

PPP báo lỗi theo giai đoạn, và giai đoạn cho biết điều khoản nào của hợp đồng bị phá. Một liên kết không bao giờ rời khỏi điều khiển liên kết có vấn đề đóng gói hoặc thương lượng, trong khi liên kết xác thực rồi chết thường có vấn đề chính sách hoặc khóa. Một liên kết vẫn đứng và không mang gì đã chuyển sang định tuyến, đó là một cuộc điều tra khác.

Nhật ký giữ các dòng giai đoạn, và chúng hữu ích hơn mức gỡ lỗi cao hơn. Hãy yêu cầu các tiến trình PPP và thông điệp bảo vệ, rồi đọc kết quả xác thực trước mọi thứ khác. Những dòng cuối thường nêu tên điều khoản đã từ chối:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

Trong đầu ra đó, hãy tìm kết quả xác thực trước rồi đến lời phàn nàn rằng bảo vệ đã được yêu cầu nhưng không được thương lượng. Thông điệp thứ hai là chữ ký của mâu thuẫn ở trên, và không lượng thử lại nào xóa được nó khi máy chủ từ chối phương thức duy nhất có thể tạo khóa. Đáng nêu hai cái bẫy: nâng mức gỡ lỗi mà không đọc các dòng giai đoạn tạo ra nhiễu, và bắt vật liệu thách thức hoặc mật khẩu biến một nhiệm vụ cấu hình thành rò rỉ thông tin xác thực. Ghi lại giai đoạn đó trước khi thay đổi bất kỳ tùy chọn nào.

Lập kế hoạch lối ra trước khi điểm cuối cũ bị tắt

MPPE là một cơ chế bảo vệ liên kết mang tính lịch sử, và sự hiện diện của nó không khiến PPTP thành lựa chọn hợp lý cho một triển khai mới. Hướng dẫn hiện hành của Microsoft đã khuyến nghị chống lại PPTP và L2TP/IPsec với khóa chia sẻ trước cho các triển khai truy cập từ xa mới. Giữ một điểm cuối cũ tồn tại là quyết định về một dịch vụ đang có, không phải mẫu cho cái tiếp theo.

Khi điểm cuối phải ở lại, hãy viết hợp đồng: giao thức ngoài, phương thức xác thực được yêu cầu, bảo vệ bắt buộc và phiên bản máy khách thương lượng nó. Khi nó có thể đi, hãy chọn danh tính cổng của bản thay thế, xác thực máy khách của nó và nơi thông tin xác thực sẽ sống trước khi chạm vào hồ sơ cũ. Sau đó lập kế hoạch tuyến, DNS và các tài nguyên mà mỗi người dùng được phép truy cập. Kiểm chứng máy khách dự định theo yêu cầu của chủ sở hữu chứ không phải theo một kết nối đang hoạt động.

Một sự từ chối có chủ đích nên vẫn là từ chối, vì quay lại chế độ không bảo vệ để một bài kiểm tra đạt sẽ biến thất bại chính sách thành phơi nhiễm. Trạng thái hoàn chỉnh là một hợp đồng được hỗ trợ và ghi lại, không phải tập thay đổi nhỏ nhất khiến một kết nối cũ thành công. Hãy để hồ sơ cũ tại chỗ, không dùng và được ghi lại, cho đến khi bản thay thế vượt qua cùng các kiểm tra.