SSTP chiếm cổng 443: vì sao Apache không khởi động

Apache ngừng trả lời trên 443 vào buổi chiều ai đó bật các kết nối VPN đến, và nhật ký lỗi của nó đổ lỗi cho bind thay vì việc đặt trước phía sau. Windows Routing and Remote Access bật SSTP ngay lúc đó, và trình lắng nghe SSTP đòi TCP 443 qua ngăn xếp HTTP trước khi bất kỳ máy khách nào được xác thực. Yêu cầu vẫn giữ nguyên kể cả khi thiếu chứng chỉ, sai tên hoặc mọi handshake bị từ chối, nên một VPN mà không ai vào được vẫn chiếm cổng. Hãy đọc bảng lắng nghe trước; PID sở hữu 443 quyết định bản sửa nào dưới đây còn mở với bạn.

Việc đặt trước sống lâu hơn chứng chỉ hỏng

SSTP bọc PPP trong một phiên TLS, vì thế nó cần 443 và vì thế nó đi qua các proxy bỏ rơi đường hầm khác. Trình lắng nghe không phải socket mà dịch vụ VPN tự mở cho mình: SstpSvc đăng ký nó với trình điều khiển HTTP của nhân, nên cổng vẫn được đặt trước chừng nào dịch vụ còn chạy. Bản đăng ký đó không bao giờ hỏi chứng chỉ, nghĩa là tên hết hạn, subject không khớp hoặc hoàn toàn không có chứng chỉ đều để 443 bị chiếm. Sau đó lỗi chia làm hai hướng: handshake bị từ chối rơi vào nhật ký System dưới RasSstp, còn máy chủ web chỉ có thể báo rằng nó không bind được.

netstat -aon | findstr :443
tasklist /svc /fi "PID eq <pid>"

Dòng đầu trả về PID sở hữu; dòng thứ hai nêu tên dịch vụ phía sau, và câu trả lời thường là dịch vụ HTTP hoặc ngăn xếp RRAS. Khi tasklist trả lời bằng một tiến trình máy chủ dùng chung, hãy đọc cột dịch vụ thay vì đoán từ tên tiến trình.

Cảnh báo RasSstp chỉ đáng đọc sau đó, vì chúng mô tả một handshake thất bại và không nói gì về việc đặt trước đã gây ra xung đột. Một điểm cuối VPN từ chối mọi máy khách vẫn sở hữu cổng. Hãy coi nhật ký là câu hỏi thứ hai, không phải câu hỏi đầu tiên.

IIS chia sẻ trình điều khiển, Apache mở socket

IIS giao các binding của mình cho cùng trình điều khiển nhân mà SSTP dùng, và trình điều khiển đó tách các kết nối đến theo tên máy chủ và tiền tố URL, nên có thể bảo cả hai dịch vụ hãy muốn 443 mà không dịch vụ nào hỏng. Apache và nginx làm ngược lại: chúng gọi bind trên socket của riêng mình, và hệ điều hành từ chối vì địa chỉ đã bị chiếm. Không có gì sai trong cả hai cấu hình; khác biệt nằm ở API nào sở hữu cổng. Đó cũng là lý do bật VPN làm đổ một trang trên một máy chủ và để nguyên một trang giống hệt trên máy chủ khác.

Sự bất đối xứng này quyết định hình dạng của việc sửa. Nếu IIS đã là cửa trước, xung đột trở thành câu hỏi về tiền tố, binding và chứng chỉ. Nếu Apache là cửa trước, hoặc nó rời khỏi 443, hoặc trình lắng nghe SSTP rời đi, và phần tiếp theo bao quát cả hai nước đi.

Chọn dịch vụ nào giữ 443

Cổng của trình lắng nghe sống trong một giá trị đăng ký duy nhất, một DWORD thập phân dưới khóa tham số của Sstpsvc. Đổi giá trị, khởi động lại Routing and Remote Access, và xác nhận từ bảng lắng nghe rằng cổng cũ đã trống.

reg query "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort /t REG_DWORD /d 4443 /f
Restart-Service RemoteAccess

Chọn một cổng mà không thứ gì khác trên máy chủ muốn, và nhập nó ở dạng thập phân: reg add lưu DWORD đúng như khi viết, nên một giá trị định dạng thập lục phân sẽ rơi thành cổng khác. Nếu truy vấn báo giá trị không tồn tại, dòng thứ hai tạo nó. Restart-Service RemoteAccess ngắt mọi người đang kết nối, điều đáng để lên kế hoạch. Sau đó chạy lại kiểm tra lắng nghe, vì một mục cũ trên 443 nghĩa là dịch vụ đã giữ đăng ký cũ.

Chuyển trình lắng nghe có một cái giá mà việc sửa đăng ký không cho thấy. Máy khách SSTP thông thường quay số 443, nên mỗi hồ sơ máy khách cần cổng mới, và luồng không còn giống yêu cầu web đối với bất cứ thứ gì kiểm tra đường đi. Trên mạng chỉ chịu được lưu lượng giống HTTPS, điều đó bỏ đi phần lớn lý do chọn SSTP. Một nhóm máy khách nhỏ và được quản lý hấp thụ được điều này; cơ sở người dùng công khai hoặc BYOD thì không.

Nước đi còn lại giữ 443 ở IIS và coi Apache là backend mà proxy chuyển tiếp tới. Nó giữ mặc định của SSTP và để cổng có một chủ sở hữu, đổi lại là phần đầu được chuyển tiếp, địa chỉ máy khách mà ứng dụng không còn thấy trực tiếp và một backend phải nói giao thức mà proxy thực sự gửi.

Chứng minh chủ sở hữu, chứng chỉ và handshake theo thứ tự

Một kết nối TCP hoàn tất chỉ chứng minh rằng có một trình lắng nghe và không gì khác, vì thế quét cổng có thể trông khỏe mạnh trong khi đường hầm vẫn hỏng. Bốn giai đoạn hỏng theo các cách khác nhau, và bản sửa nhắm vào giai đoạn bạn không làm hỏng thường làm xung đột sâu hơn. Hãy xử lý theo thứ tự và dừng ở chỗ câu trả lời rẽ nhánh.

netstat -aon | findstr :443
certutil -store My
Get-WinEvent -LogName System -ProviderName RasSstp -MaxEvents 20

Dòng đầu nêu PID đang giữ 443, và đó phải là dịch vụ bạn vừa cấu hình. Dòng thứ hai liệt kê chứng chỉ máy với subject của chúng, nên một tên không khớp với địa chỉ trong hồ sơ máy khách sẽ lộ ra ngay. Truy vấn sự kiện trả về các bản ghi SSTP gần đây, và một handshake không bao giờ tới được xác thực PPP để lại bản ghi khác với bản được xác thực rồi bị từ chối. Giai đoạn cuối chỉ thấy trên máy khách, nơi mục đó báo đã kết nối hoặc nêu lỗi PPP.

Khi một máy chủ phải làm cả hai việc, hãy chọn chủ sở hữu 443 một cách có chủ đích và ghi lại lựa chọn, vì nếu không người tiếp theo bật một tính năng sẽ phát hiện lại xung đột này. Tách vai trò vẫn là câu trả lời sạch hơn: một máy chủ web công khai và một điểm cuối truy cập từ xa mang các chu kỳ vá, chứng chỉ và khởi động lại riêng, và các chu kỳ đó gặp nhau theo lịch của chúng. Dù thế nào, hãy để lại trong ghi chú bàn giao việc kiểm tra lắng nghe, đường dẫn đăng ký và cổng đã chọn.