Vì sao Port-Share khiến mọi khách truy cập trang web trông như localhost

Mọi dòng trong nhật ký truy cập đều hiển thị cùng một địa chỉ loopback, trong khi trang tự tải được và chứng chỉ được xác thực đúng. Không có gì hỏng theo nghĩa không thể truy cập, và đó là lý do tình trạng này tồn tại hàng tháng. Thứ hỏng là việc quy gán: phần phía sau của web ghi lại địa chỉ của bước đã chuyển tiếp kết nối, và mọi quyết định về sau tin vào nhật ký đều thừa hưởng cùng một câu trả lời sai.

Các bước kiểm tra dưới đây đi từ dây cáp vào bên trong. Hãy dừng ở bước đầu tiên giải thích được giá trị bạn thấy, vì mỗi bước sau đều giả định các bước trước đã đúng. Không bước nào đòi bạn đoán cấu hình phần trước.

Hãy theo hai kết nối, không phải dòng nhật ký

Port-Share ghép hai giao thức trên một bộ lắng nghe TCP. OpenVPN kiểm tra những byte đầu của kết nối đến, giữ lại khi nó trông giống giao thức của chính nó, và giao mọi thứ khác cho một đích thứ hai. Đích đó thường là máy chủ web trên cùng máy chủ, nên ổ cắm mà máy chủ web chấp nhận có tiến trình OpenVPN làm đối tác.

ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'

Lệnh đầu cho biết ai sở hữu bộ lắng nghe công khai. Lệnh thứ hai cho thấy các kết nối đến cổng phía sau, và địa chỉ đối tác của chúng chính là thứ nhật ký truy cập sẽ in ra. Nếu đối tác đó là loopback thì nhật ký là chính xác và thông tin đã mất sớm hơn một lớp. Đổi tên trường trong nhật ký hay bật một mô-đun IP khách hàng sẽ không khôi phục được địa chỉ mà kết nối chưa bao giờ mang.

Đây là bước kiểm tra quyết định mọi thứ còn lại. Nếu đối tác của phía sau là địa chỉ của trình duyệt thì chia sẻ cổng không phải vấn đề của bạn, mà định dạng nhật ký mới là.

Chuyển tiếp ở tầng vận chuyển không phải là chèn tiêu đề

Bộ chuyển tiếp di chuyển byte. Nó không phân tích HTTP, nên không thể chèn tiêu đề vào một yêu cầu mà nó chưa bao giờ đọc như một yêu cầu, và không thể thêm gì vào một luồng TLS mà nó cho đi qua nguyên vẹn. Một mô-đun chờ tiêu đề proxy sẽ tiếp tục chờ thứ mà không thành phần nào tạo ra.

Hai cơ chế có thể mang địa chỉ gốc, và cả hai đều cần sự đồng thuận ở cả hai đầu. Giao thức PROXY thêm một tiêu đề nhỏ vào đầu kết nối, và phía sau phải được cấu hình để chờ nó; phía sau không chờ sẽ coi những byte đó là đầu yêu cầu và thất bại theo cách khó hiểu. Các tiêu đề proxy đáng tin như X-Forwarded-For hoạt động khi một proxy hiểu HTTP đặt chúng và phía sau được cho biết những đối tác nào được phép khẳng định chúng.

Không cái nào tự động, và không cái nào an toàn theo mặc định. Phía sau tin vào bất kỳ tiêu đề chuyển tiếp đến nào sẽ để khách hàng tự chọn địa chỉ của mình, biến một điểm không chính xác trong nhật ký thành cách vượt qua kiểm soát truy cập. Hãy chạy minh họa một lần trên máy chủ thử trước khi tin bất kỳ tiêu đề nào trên đường sản xuất.

curl -sS -H 'X-Forwarded-For: 127.0.0.1' https://site.example.com/health
grep -F '127.0.0.1' /var/log/nginx/access.log | tail -n 3

Thư mục ánh xạ nguồn tùy chọn

Chia sẻ cổng có một đối số thư mục tùy chọn ghi lại ánh xạ giữa địa chỉ nguồn gốc và kết nối chuyển tiếp, trên những nền tảng đã triển khai tính năng này. Phía web được kỳ vọng sẽ tham chiếu ánh xạ đó; nó không phải tiêu đề, và nó không được chèn vào yêu cầu.

Thiết kế đó đáng để biết vì nó giải thích tại sao một số triển khai báo cáo địa chỉ thật còn số khác thì không, với cấu hình phần trước trông giống hệt nhau. Khác biệt nằm ở phía nhận, và thường nó sống trong một mô-đun hoặc bản vá mà phần lớn máy chủ web đóng gói không bật theo mặc định. Hãy đọc tài liệu của máy chủ web để biết móc chính xác nó cung cấp, và xác nhận mô-đun đã được nạp thay vì giả định.

Nếu đi con đường này, hãy coi đó là một tích hợp gồm hai nửa: ánh xạ do bộ chuyển tiếp ghi và tra cứu do phía sau thực hiện. Xác minh cả hai, và xác nhận thư mục tồn tại qua lần khởi động lại và không tăng vô hạn trên bộ lắng nghe bận rộn.

Quyết định thành phần nào bảo chứng cho địa chỉ

Trước khi thay đổi cấu hình, hãy gọi tên thành phần được phép khẳng định địa chỉ khách hàng và những thành phần được phép tin vào nó. Một câu trả lời được viết ra ngăn chặn sự trôi dạt thường thấy, khi ba lớp khác nhau mỗi lớp tin vào một nguồn khác nhau.

Ba thiết kế bao phủ phần lớn nhu cầu. Hãy tách bộ lắng nghe công khai và bộ lắng nghe web, để máy chủ web thấy các đối tác thật và không tồn tại vấn đề quy gán. Đặt một proxy ngược hiểu HTTP lên trước, kết thúc hoặc phân tích yêu cầu tại đó, và để nó đặt tiêu đề chuyển tiếp cho phía sau chỉ tin vào proxy đó. Hoặc giữ chia sẻ cổng và chấp nhận rằng nhật ký cho thấy bước chuyển tiếp, với các quy tắc truy cập viết theo danh tính ứng dụng thay vì theo địa chỉ.

Điều không hiệu quả là coi một địa chỉ loopback được chuyển tiếp như bằng chứng rằng yêu cầu phát sinh trên chính máy này. Suy luận đó ngược hoàn toàn: địa chỉ có mặt chính vì một thành phần cục bộ đã tạo kết nối. Một quy tắc viết như vậy chấp nhận bất kỳ ai chạm được tới bộ lắng nghe.

Hãy kiểm tra quy tắc, không phải trang

Một trang tải được chứng minh đường chuyển tiếp hoạt động và không nói gì về việc quy gán. Hãy kiểm tra người dùng của địa chỉ: quy tắc truy cập, giới hạn tốc độ, bản ghi kiểm toán, tra cứu địa lý.

curl -sS -o /dev/null -w '%{http_code}\n' https://site.example.com/
tail -n 5 /var/log/nginx/access.log
grep -c '' /var/log/nginx/access.log

So sánh một yêu cầu bên ngoài được cho phép với hồ sơ của cả phần trước và phần sau, và xác nhận rằng quy tắc đáng lẽ phải từ chối vẫn từ chối và quy tắc đáng lẽ phải cho phép vẫn cho phép. Nếu dòng nhật ký đúng nhưng quy tắc vẫn hành xử như thể mọi người đều cục bộ, thì quy tắc đang đọc một trường khác với trường bạn đã sửa.

Kết thúc bằng việc ghi chuỗi quy gán vào ghi chú triển khai: bộ lắng nghe nào, bộ chuyển tiếp nào, tiêu đề hay ánh xạ nào, và phía sau nào được cấu hình để tin vào nó. Người tiếp theo đọc một dòng nhật ký sẽ cần cả bốn, và sự thiếu vắng ghi chú đó chính là cách cùng một phiếu mở lại một năm sau. Hãy giữ nó cạnh cấu hình chứ không phải trong một luồng trò chuyện.