proxy_redirect không kết nối NGINX với máy chủ VPN của bạn

Tên chứa từ redirect, nên nó bị dán vào một khối location khi không thể tiếp cận backend phía sau VPN. Không có gì thay đổi, và kết luận hiển nhiên là chỉ thị này hỏng hoặc cần một cú pháp khác. Điều thực sự xảy ra đơn giản hơn và kém vẻ vang hơn: proxy_redirect làm việc trên một phản hồi đã quay về, và trong triển khai này không có yêu cầu nào đi xa đến thế.

Hai chỉ thị, hai thời điểm trong một yêu cầu

Một yêu cầu HTTP qua proxy ngược đi qua nhiều quyết định theo thứ tự, và hai chỉ thị nằm ở hai đầu đối lập của chuỗi đó. Một chỉ thị chọn nơi yêu cầu đi tới. Chỉ thị kia sửa một số tiêu đề trong phản hồi quay về.

Thứ tự đó là toàn bộ câu trả lời. Nếu dòng thứ hai không bao giờ chạy vì dòng đầu thất bại, chỉ thị thứ hai không bị cấu hình sai, nó đơn giản là không thể tiếp cận. Dù viết lại dòng thứ hai bao nhiêu lần, phản hồi mà nó lẽ ra phải sửa cũng không xuất hiện. Chẩn đoán từ dòng đầu ra ngoài, và hành vi khó hiểu rút lại thành một tuyến bị thiếu hoặc một kết nối bị từ chối.

Chọn upstream là việc của proxy_pass

Giả sử NGINX chạy trên một máy chủ đầu vào công khai và tiếp cận ứng dụng tại 10.40.0.20:8080 qua VPN của nó. Đoạn chọn ứng dụng đó trông như sau, bên trong một khối server có sẵn:

location / {
    proxy_pass http://10.40.0.20:8080;
}

Dùng scheme, địa chỉ và cổng thật, và coi đây là một đoạn chứ không phải một lần triển khai. Máy chủ đầu vào cũng phải giữ tuyến VPN, đường chuyển tiếp được phép và lưu lượng trả về hoạt động tới dịch vụ đó, vì một proxy tiếp cận địa chỉ trên giấy vẫn cần sự đồng ý của kernel.

Tài liệu tham chiếu của mô-đun proxy tách việc chọn upstream khỏi việc viết lại tiêu đề phản hồi, và lưu ý rằng một giá trị proxy_pass có chứa URI thay đổi cách tiền tố location khớp được thay thế. Thêm hoặc bớt thành phần đường dẫn mà không kiểm tra URL mà ứng dụng mong đợi là cách chắc chắn để tạo ra 404 trông như lỗi định tuyến.

proxy_redirect sửa những phản hồi làm lộ địa chỉ riêng tư

Khi lưu lượng đã chảy, backend có thể trả lời bằng tiêu đề Location nêu địa chỉ riêng tư của nó. Trình duyệt theo tiêu đề đó rời khỏi điểm vào công khai và cố tiếp cận thứ mà nó không thể phân giải. Một bản viết lại phản hồi được cấu hình có chủ đích ánh xạ URL riêng tư lên URL công khai:

proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;

Thay cả hai vế bằng giá trị thật. Hiểu cả phạm vi hẹp: văn bản của các tiêu đề Location và Refresh khớp sẽ được viết lại, còn URL nhúng trong HTML, JavaScript hoặc tệp đã tải xuống thì không.

Nếu một ứng dụng tạo liên kết tuyệt đối ở mọi nơi, giải pháp bền vững là cấu hình URL bên ngoài của chính ứng dụng, không phải danh sách quy tắc viết lại ngày càng dài trên proxy. Thêm quy tắc cho tới khi đầu ra trông đúng sẽ tạo ra một cấu hình hỏng ngay ở trang đầu tiên mà không ai kiểm thử. Một thiết lập đúng của ứng dụng thay thế toàn bộ bộ sưu tập.

Điều mà viết lại tiêu đề không thể sửa

Một số vấn đề lân cận trông như vấn đề chuyển hướng nhưng không phải. Tiêu đề Host gửi tới upstream có thể cần khớp với máy chủ ảo của backend. Một upstream TLS có thể cần tên máy chủ cụ thể cùng xác minh chứng chỉ, và viết lại tiêu đề phản hồi không giúp gì cho cả hai.

Phạm vi cookie và thuộc tính tên miền thuộc về ứng dụng và cấu hình của nó. Proxy có thể vứt hoặc viết lại tiêu đề cả ngày mà vẫn tạo ra một phiên hỏng ở yêu cầu thứ hai, vì cookie được cấp cho một máy chủ mà trình duyệt chưa từng truy cập. Lỗi đó trông như ngắt quãng, và đó là lý do nó tồn tại lâu như vậy trong hàng đợi phiếu. Đọc tên miền của cookie thường kết thúc cuộc điều tra trong một phút.

Cũng hãy giữ xác thực và việc chọn backend trong phạm vi ứng dụng dự định. Một proxy ngược công khai nên phơi bày một ứng dụng qua VPN của máy chủ thay vì trở thành cổng chung tới mọi địa chỉ riêng tư mà máy chủ đó có thể tiếp cận. Một location chung duy nhất chuyển tiếp mọi thứ người gọi yêu cầu biến một dịch vụ đã phơi bày thành bản đồ mạng riêng của bạn. Đặt tên upstream một cách rõ ràng và giữ nó ở đó.

Kiểm thử theo thứ tự yêu cầu di chuyển

Xác nhận ba điều theo thứ tự: NGINX đã chọn location dự định, đã hoàn tất một yêu cầu tới backend, và trình duyệt đã theo bất kỳ chuyển hướng nào sau đó và tải các tài nguyên con. Mỗi bước có dòng log riêng, và đọc chúng theo thứ tự biến một 502 mơ hồ thành phát hiện cụ thể.

Sự khác biệt bạn cần là giữa một kết nối upstream thất bại và một trình duyệt bị gửi tới tên riêng tư không thể tiếp cận. Cái đầu xuất hiện trong log lỗi của proxy; cái sau xuất hiện như một yêu cầu không bao giờ đến, với trình duyệt phàn nàn về một máy chủ mà nó không thể phân giải. Hai vấn đề khác nhau, hai tệp khác nhau, và chỉ một trong hai có liên quan tới proxy_redirect.