Cách phục vụ máy chủ phát triển webpack trên địa chỉ VPN

Một máy chủ phát triển trả lời trên máy tính xách tay và không nơi nào khác thường bị liên kết với địa chỉ sai. Máy chủ chấp nhận kết nối nhưng từ chối trang thường không vượt qua kiểm tra tên máy chủ. Đó là những lỗi khác nhau với cách sửa khác nhau, và việc chọn cấu hình đúng phụ thuộc vào ai phải truy cập không gian làm việc và bằng cách nào.

Ba câu hỏi quyết định câu trả lời: ai kết nối, địa chỉ nào người đó truy cập được, và tải lại trực tiếp có phải hoạt động cho người đó không.

Bắt đầu bằng socket, không phải tệp cấu hình

Đọc xem tiến trình đang chạy thực sự được liên kết với gì trong cùng ngữ cảnh mạng đã khởi động nó, vì một container hoặc không gian tên có thể sở hữu socket mà shell của máy chủ không thấy. Cột lắng nghe trả lời câu hỏi đầu tiên: chỉ đường dẫn cục bộ, một giao diện cụ thể, hay mọi giao diện.

ss -ltn '( sport = :8080 )'
ss -ltnp | grep node

Địa chỉ loopback là mặc định an toàn và vô dụng với máy khách từ xa. Liên kết ký tự đại diện thì tiện và mở cổng trên mọi giao diện có tuyến, rộng hơn mức hầu hết mọi người định trên một máy cũng mang đường hầm. Địa chỉ cụ thể là lựa chọn ở giữa, và nó chỉ hoạt động nếu giao diện sở hữu địa chỉ đó tại thời điểm socket được tạo. Sự khác biệt quan trọng vì hai trong ba liên kết này trông giống nhau trong trình duyệt và hoạt động hoàn toàn khác khi có giao diện thứ hai.

Hãy theo quan sát đó trước khi chạm vào tuyến hoặc quy tắc tường lửa. Nếu tiến trình lắng nghe ở địa chỉ sai, không có định tuyến chính sách nào đưa máy khách tới đó.

Chọn địa chỉ liên kết theo người phải truy cập

Nếu chỉ bạn trên máy này cần trang, hãy giữ liên kết loopback và dừng. Nếu một đồng nghiệp trên cùng đường hầm cần trang, hãy liên kết địa chỉ của giao diện đường hầm và để tường lửa chỉ cho phép nguồn đó. Xuất bản máy chủ phát triển ra ngoài những người đang tích cực kiểm thử nó là thói quen mà cuối cùng sẽ phơi bày không gian làm việc ra internet.

Nếu trình duyệt bên trong container cần truy cập máy chủ, địa chỉ liên kết phải là địa chỉ mà mạng của container định tuyến tới được, và thường đó không phải địa chỉ mà máy chủ tự phân giải cho mình. Quyết định trường hợp trước khi sửa cấu hình, vì ba trường hợp tạo ra ba giá trị khác nhau và chỉ một là đúng. Đoán ở đây tốn nhiều thời gian hơn bất kỳ phần nào khác của việc thiết lập.

Sau đó đặt địa chỉ theo dạng mà trình khởi chạy của bạn thực sự đọc. Tệp cấu hình và một script dựng máy chủ theo lập trình không dùng cùng các tùy chọn:

devServer: {
  host: "10.77.0.20",
  port: 8080,
  allowedHosts: ["dev.corp.example"],
}

Địa chỉ trong đoạn đó chỉ là ví dụ và đại diện cho địa chỉ VPN mà máy chủ sở hữu. Nếu dự án dựng máy chủ bằng new WebpackDevServer(options, compiler) hãy truyền tùy chọn qua đối số hàm tạo thay vào đó, vì thuộc tính riêng devServer trong cấu hình webpack không được xem xét trên đường đó. Sự khác biệt giữa tệp cấu hình và Node API bắt được những người sao chép đoạn mã vào dự án không bao giờ đọc nó. Tài liệu dev-server tách hai kiểu khởi chạy và là tài liệu tham chiếu để đối chiếu với phiên bản đang dùng.

Khớp kiểm tra tên máy chủ với những tên bạn chấp thuận

Kiểm tra tên máy chủ tồn tại để ngăn một trang được phục vụ từ tên do kẻ tấn công kiểm soát nói chuyện với máy chủ phát triển của bạn qua trình duyệt. Tắt nó bằng allowedHosts: "all" sẽ loại bỏ lớp bảo vệ đó, và sự tiện lợi hiếm khi đáng giá trên một máy có thể truy cập các dịch vụ nội bộ. Việc kiểm tra rất rẻ để đáp ứng đúng khi bạn biết trình duyệt sẽ gửi những tên nào.

Liệt kê các tên chính xác bạn sẽ dùng, bao gồm tên riêng phân giải tới địa chỉ đường hầm. Nếu máy khách phân giải một tên tới địa chỉ khác với địa chỉ bạn đã liên kết, bạn có vấn đề phân giải tên chứ không phải cấu hình máy chủ, và thêm tên vào danh sách cho phép sẽ không sửa được. Xác nhận phân giải từ máy khách, không phải từ máy chủ.

Giữ ba cơ chế riêng biệt trong đầu: địa chỉ liên kết quyết định giao diện nào nhận kết nối, danh sách cho phép quyết định tiêu đề Host nào được chấp nhận, và xác thực quyết định ai được vào. Chỉ cái thứ ba là kiểm soát truy cập, và máy chủ phát triển thường không có cái nào. Địa chỉ đường hầm cũng không phải cơ chế xác thực, vì bất kỳ ai định tuyến tới đó đều đã ở trong ranh giới mà bạn dựa vào.

Xác minh trang và socket tải lại trực tiếp cùng nhau

Tải một yêu cầu mới từ máy khách dự định với lược đồ đã cấu hình, và đọc kết quả thay vì bộ nhớ đệm. Với HTTPS, giữ tên máy chủ mong đợi và xác thực chứng chỉ, vì cảnh báo của trình duyệt không phải là kiểm thử chấp nhận thành công. Một trang hiển thị trong khi tải lại trực tiếp âm thầm thất bại là kiểu thành công một phần phổ biến nhất ở đây, và rất dễ bỏ sót khi kiểm tra nhanh.

curl -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" http://dev.corp.example:8080/
curl -sS -i http://10.77.0.20:8080/ | head -n 5

Sau đó mở chẩn đoán mạng của trình duyệt và quan sát kết nối WebSocket. Một trang có thể tải qua một tên máy chủ, cổng và lược đồ trong khi socket tải lại dùng cái khác, nên phải kiểm tra riêng cả hai. Chỉ cấu hình URL máy khách được ghi tài liệu khi đường dẫn triển khai thật sự cần giá trị khác, và ưu tiên sửa đường dẫn hơn là dạy máy khách một cách lách.

Ghi lại địa chỉ của bộ lắng nghe, tên được chấp nhận, nguồn được phép và cả hai kết quả vào ghi chú dự án. Bản ghi đó tồn tại cho người tiếp theo khởi động không gian làm việc và tự hỏi tại sao trang tải được nhưng không bao giờ làm mới.