NGINX sẽ ghi địa chỉ nguồn nào cho một máy khách VPN?
Xác định những gì NGINX thấy bên cạnh OpenVPN trên cùng một máy chủ: địa chỉ đường hầm bên trong, địa chỉ công cộng khi ra ngoài hay một peer được chuyển tiếp, tùy theo đường đi.
Ba địa chỉ máy khách xuất hiện trong một cấu hình NGINX và OpenVPN trên cùng một máy chủ, mỗi địa chỉ ứng với một đường mà yêu cầu có thể đi. Trình duyệt truy cập địa chỉ đường hầm, trình duyệt truy cập địa chỉ công cộng và chương trình đi ra qua đường internet của cổng kết nối đều trông khác nhau tại socket đang lắng nghe. Hãy xác định bạn đang nhìn đường nào trước khi diễn giải dòng nhật ký. Quyết định phụ thuộc vào đích mà máy khách đã dùng, ngoại lệ mà nó giữ cho điểm cuối VPN bên ngoài và việc có gì đó dịch gói tin trên đường đi hay không.
Quyết định theo đích đến, không theo việc người dùng là ai
Bắt đầu từ địa chỉ mà yêu cầu được gửi tới, vì chính địa chỉ đó chọn đường đi. Một yêu cầu tới địa chỉ đường hầm của máy chủ đến trên giao diện đường hầm với địa chỉ bên trong của máy khách làm nguồn. Một yêu cầu tới địa chỉ công cộng của máy chủ thường đến trên giao diện hướng ra internet với địa chỉ công cộng của máy khách, ngay cả khi cùng chiếc máy tính xách tay đó đang có một đường hầm được thiết lập vào lúc ấy. Vì vậy, việc thuộc nhóm VPN là thuộc tính của đường đi gói tin, không phải thuộc tính đi theo người dùng.
| Path the request took | Source the site normally records |
|---|---|
| Client reaches the site at its tunnel address, 10.24.0.1 | Client inner address, 10.24.0.20 |
| Client reaches another internet site through the gateway | Gateway public egress address, 192.0.2.44 |
| Client reaches the gateway's public address through the endpoint exception | Client's own public access address |
Chính hàng thứ ba đó là hàng đáng kiểm tra trước tiên khi một người dùng VPN xuất hiện trong nhật ký với địa chỉ không liên quan gì đến đường hầm. Nó cũng giải thích vì sao hai người dùng trên cùng một hồ sơ có thể tạo ra các mục khác nhau: mạng truy cập của họ khác nhau, và không gì trong đường hầm ghi đè lên điều đó.
Vì sao điểm cuối bên ngoài tạo ra đường công cộng thứ hai
Máy khách phải đến được địa chỉ công cộng của cổng kết nối để thiết lập đường hầm, nên phải tồn tại một tuyến tới địa chỉ đó ở ngoài đường hầm. Khi máy khách chuyển toàn bộ lưu lượng vào trong, một cách triển khai hợp lý vẫn giữ một tuyến máy chủ rõ ràng tới địa chỉ công cộng của máy chủ để tránh đường hầm phụ thuộc vào chính nó. Ngoại lệ đó không phân biệt dịch vụ, nên mọi yêu cầu tới cùng địa chỉ công cộng đều đi theo nó, kể cả yêu cầu của trình duyệt tới một trang được lưu trữ trên cổng kết nối.
Đây là cơ chế đằng sau phần lớn các báo cáo khó hiểu trong lĩnh vực này, và nó thuộc về cách triển khai máy khách chứ không phải máy chủ. Vì vậy hai máy khách có cùng hồ sơ có thể hành xử khác nhau. Bỏ ngoại lệ để »sửa« nhật ký sẽ kéo cả đường hầm xuống theo, nên hãy giữ nó và thiết kế xoay quanh nó.
Đọc socket, bảng và định dạng nhật ký cùng nhau
Ba quan sát sẽ xác định bạn đang nhìn đường nào: socket lắng nghe ở đâu, giao diện nào trả lời đích đến và định dạng nhật ký thực sự ghi lại điều gì. Nếu bộ lắng nghe chỉ gắn với địa chỉ đường hầm, một yêu cầu công cộng hoàn toàn không thể tới được nó, điều này loại ngay hai hàng. Nếu việc tra cứu cho máy khách trả về thiết bị đường hầm, yêu cầu đã đến với nguồn bên trong và nhật ký phải cho thấy điều đó.
ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44Sau đó hãy đọc định dạng thay vì dòng. Một trường được nuôi bằng tiêu đề chuyển tiếp ghi lại một lời khẳng định, không phải peer của socket, và lời khẳng định chỉ có ý nghĩa khi peer trực tiếp là một proxy đáng tin cậy. Ghi cả hai giá trị vào nhật ký sẽ kết thúc các tranh luận về sau, vì peer trực tiếp và địa chỉ được thay thế là hai sự thật khác nhau và chỉ một trong số đó đến từ mạng.
log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.confChọn điểm vào bạn muốn và làm cho DNS đồng ý
Nếu trang web chỉ dành cho đường hầm, hãy đặt cho nó một tên phân giải thành địa chỉ đường hầm đối với máy khách VPN và áp dụng chính sách trên socket lắng nghe. Một câu trả lời DNS chia tách trả về 10.24.0.1 cho tên nội bộ là một quyết định định tuyến khoác áo một chi tiết phân giải tên. Nếu trang web cũng phải công cộng, hãy giữ hai tên hoặc hai cổng và để nhật ký cho bạn biết cái nào đã phục vụ yêu cầu.
Các quy tắc cho phép tuân theo cùng logic đó. Cho phép nhóm đường hầm không cấp quyền cho một yêu cầu công cộng và sẽ không điền địa chỉ bên trong trên một kết nối đến qua internet. Trộn cả hai điểm vào dưới một tên biến nguồn được ghi lại thành tác dụng phụ của việc định tuyến máy khách thay vì một lựa chọn thiết kế.
Xác minh đường đi, rồi đến chính sách
Xác nhận đường đi bằng một lần bắt gói trên cổng kết nối và một yêu cầu do bạn kiểm soát. Một lần bắt gói trên thiết bị đường hầm và một trên giao diện công cộng cho thấy cái nào đã mang byte, và thứ tự các gói cho bạn biết có xảy ra việc dịch địa chỉ ở giữa hay không.
tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5Sau đó xác minh quyền truy cập theo cả hai chiều: điểm vào có tên dự kiến hoạt động với máy khách dự kiến, và một đường công cộng không được phê duyệt sẽ bị từ chối chứ không chỉ chậm. Một trang web dội IP chung chứng minh điều gì đó về lối ra internet của cổng kết nối và không chứng minh gì về trang này trên cùng máy chủ. Khi một trang và một WebSocket không khớp nhau, hãy so sánh URL, họ địa chỉ và câu trả lời DNS của chúng trước khi chạm vào cấu hình máy chủ.