Trang NGINX chỉ dành cho VPN: trình lắng nghe, tường lửa và danh sách cho phép HTTP

Một trang NGINX riêng cần socket VPN được gắn, quy tắc đầu vào máy chủ có phạm vi và danh sách truy cập HTTP nguyên vẹn. Hãy kiểm tra cả ba, không chỉ một khối máy chủ.

Ba quyết định độc lập nằm giữa một trang riêng và internet: socket nào nhận kết nối, đường nào có thể chuyển nó, và máy chủ được chọn trả lời những khách hàng HTTP nào. Một khối máy chủ chỉ đưa ra quyết định đầu tiên. Hãy coi hai quyết định còn lại là các kiểm soát riêng, nếu không trang sẽ trông riêng tư trong khi một lối vào cũ vẫn mở. Phần lớn lỗi NGINX chỉ dành cho VPN đến từ việc chỉ kiểm tra lớp đầu tiên.

Ví dụ dùng cổng Linux OpenVPN tại 10.90.0.1 trên tun0, máy khách trong 10.90.0.0/24, nguồn được giữ nguyên và TCP 8443 dành riêng cho lối vào này. Hãy điều chỉnh giá trị, giữ nguyên các lớp.

Bắt đầu từ socket, không phải tên máy chủ

Gắn trình lắng nghe HTTPS vào địa chỉ đường hầm và một cổng riêng. Một địa chỉ cụ thể dễ lý luận hơn socket ký tự đại diện cộng kiểm tra tên, vì nhân hệ điều hành sẽ không giao cổng cho địa chỉ cục bộ khác.

server {
    listen 10.90.0.1:8443 ssl;
    server_name admin.corp.example;

    ssl_certificate     /etc/nginx/tls/admin-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/admin-key.pem;

    root /srv/private-site;

    allow 10.90.0.0/24;
    deny all;

    location / {
        try_files $uri $uri/ =404;
    }
}

Chứng chỉ phải nêu tên máy chủ dịch vụ mà khách hàng nhập, và chế độ xem DNS riêng phải phân giải máy chủ đó thành địa chỉ đã gắn. server_name chỉ chọn một máy chủ ảo; nó không xác thực bất kỳ ai. Thiếu bản ghi DNS sẽ tạo lỗi chứng chỉ trông giống sự cố TLS. Kiểm tra tên trước khi thay chứng chỉ.

Đọc cấu hình hiệu lực trước khi thêm tệp. Các include và trình lắng nghe ký tự đại diện có thể phục vụ cùng một gốc ở nơi khác, và máy chủ mặc định có thể trả lời các yêu cầu mà khối mới không bao giờ thấy.

Đóng mọi trình lắng nghe khác cho nội dung đó

Liệt kê các chỉ thị listen và so sánh các gốc mà chúng phục vụ. Một khối được thêm cho ứng dụng khác có thể chuyển tiếp đến cùng upstream, và máy chủ mặc định cũ có thể tiếp tục trả lời sau khi máy chủ mới được đặt. Kết quả đó là bản kiểm kê thật, không phải tệp bạn vừa sửa. So sánh từng gốc phục vụ cùng nội dung.

sudo nginx -T | grep -n "listen\|server_name\|root\|proxy_pass"

Kiểm tra cả hai họ địa chỉ. Liên kết IPv4 để socket IPv6 không bị động tới, và bản ghi A mới không thu hồi câu trả lời AAAA cũ vẫn trỏ tới đường công khai.

Ngừng sử dụng máy chủ ảo cũ như một thay đổi riêng. Việc xóa bản sao công khai của khối mới thường là bước thực sự đóng lối vào; trình lắng nghe riêng chỉ thêm lối vào dự định.

Giới hạn phạm vi đường vào tại máy chủ

Địa chỉ lắng nghe giới hạn socket, không giới hạn giao diện đầu vào. Một gói được định tuyến tới địa chỉ đó từ nơi khác vẫn đến như đầu vào cục bộ, vì vậy tường lửa của máy chủ cần tuyên bố riêng về nơi kết nối được phép đến. Đó là lý do chỉ gắn địa chỉ hiếm khi đáp ứng một cuộc kiểm toán.

Với chính sách đầu vào từ chối mặc định và không có quyền rộng hơn cho dịch vụ này, một quy tắc có phạm vi nêu tên đường hầm, dải nguồn, đích và cổng cùng lúc:

sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 8443

Đọc thứ tự tường lửa hiệu lực trước khi áp dụng. Một chấp nhận rộng trước đó có thể vô hiệu hóa hạn chế, và một loại bỏ cuối trước đó có thể khiến quyền này không bao giờ đạt tới. Đừng xóa các quy tắc không liên quan và đừng tắt tường lửa để ví dụ khớp.

Quy tắc đó là đầu vào máy chủ, không phải tuyến đến một máy LAN khác, và trình lắng nghe OpenVPN bên ngoài của cổng vẫn là dịch vụ riêng. Nếu trang từng công khai, hãy lên kế hoạch cách ngừng lối vào cũ và cách xử lý các phiên hiện có.

Giữ danh sách HTTP nguyên vẹn khi vị trí thay đổi

NGINX đánh giá các mục allow và deny theo thứ tự, và danh sách cấp máy chủ ở trên cho phép nhóm đã khai báo trước deny cuối cùng. Mô-đun truy cập cũng ghi nhận rằng một vị trí xác định bất kỳ mục truy cập nào sẽ dùng danh sách riêng thay vì danh sách cha. Thứ tự quan trọng như chính các mục.

Việc đặt lại đó là hồi quy thường gặp. Một vị trí tải lên, API hoặc sức khỏe mới thêm một mục sẽ âm thầm thay thế hạn chế cấp máy chủ, và trang trở nên rộng hơn ở đường được thêm gần nhất.

Xem xét từng vị trí, bí danh và khối thay thế như một phần của cùng chính sách. Nếu các kiểm tra IP được kết hợp với xác thực NGINX, hãy hiểu satisfy: cài đặt any có thể cho một khách hàng vào qua một cơ chế trong khi cơ chế kia chưa đạt. Đưa danh sách truy cập vào danh sách kiểm tra vị trí.

Việc từ chối HTTP xảy ra sau khi kết nối TCP đến NGINX. Nó bổ sung cho hạn chế mạng, và việc ủy quyền của chính ứng dụng vẫn áp dụng cho từng người dùng.

Xác minh đường đang hoạt động và trường hợp thất bại

Chạy trình phân tích cấu hình, kiểm tra các socket đang lắng nghe, sau đó thực hiện một yêu cầu có tên mới từ máy khách dự định. Xác nhận chứng chỉ hợp lệ, tên DNS phân giải thành địa chỉ đã gắn và phản hồi đến từ gốc mong đợi.

Tiếp theo hãy kiểm tra một nguồn bị loại trừ và một lối vào thay thế. Một yêu cầu được phép đang hoạt động không nói gì về những đường bạn muốn đóng, và chính trong kiểm tra bị loại trừ, một trình lắng nghe còn sót hoặc một chấp nhận tường lửa rộng mới lộ ra.

Lặp lại trường hợp khởi động hoặc phục hồi VPN. Nếu NGINX khởi động trước khi địa chỉ đường hầm tồn tại, việc gắn có thể thất bại ngay cả với tệp hoàn hảo. Phối hợp mức sẵn sàng của địa chỉ và giữ một đường phục hồi cục bộ trước khi thay đổi máy chủ web dùng chung.

Ghi lại socket, cổng, dải nguồn và danh sách HTTP đã vượt qua. Thay đổi VPN hoặc DNS tiếp theo có thể dịch chuyển bất kỳ mục nào trong số đó, và bốn giá trị được đặt tên dễ so sánh hơn một tab trình duyệt đang hoạt động.

Bài viết liên quan