Một URL cho cả văn phòng và VPN? Vì sao huyền thoại danh sách cho phép thất bại

Kết nối đường hầm, mở cùng một dấu trang, và trang được cho phép trả lời đúng như khi trả lời từ văn phòng. Đây là giả định mà phần lớn kế hoạch truy cập từ xa âm thầm dựa vào, và nó chỉ đúng chừng nào ba điều tách biệt cùng đúng một lúc. Không điều nào là tính năng của ứng dụng VPN, và không bản ghi DNS nào có thể cung cấp bất kỳ điều nào. Khi dấu trang hỏng ở nhà, trình duyệt cho bạn một lỗi chung duy nhất, dù nguyên nhân là tuyến đường thiếu, địa chỉ ra không được chấp thuận hay một proxy đã thay thế nguồn mà nó báo cáo. Coi ba điều đó là một vấn đề chính là cách một sửa đổi chính sách nhỏ biến thành một tuần mở rộng danh sách cho phép.

Thiết kế sống sót khi tiếp xúc với mạng văn phòng thật thì hẹp hơn giả định: một bảng quyết định ba dòng rõ ràng, một điểm thực thi không thể vòng qua, và một bài kiểm tra từ chối chứng minh được điều gì đó. Việc tháo dỡ giả định đến trước, vì mọi thứ sau đó phụ thuộc vào việc biết lớp nào đang trình bày sai nguồn.

Huyền thoại: kết nối không phải định tuyến

Một đường hầm được thiết lập, và ứng dụng cài đặt các tuyến cho một tập tiền tố nào đó. Kết nối chỉ làm đúng thế. Liệu một yêu cầu HTTPS không liên quan có đi qua đường hầm hay không, và nó trông như đến từ địa chỉ công cộng nào khi tới, là những quyết định mà các thành phần khác đưa ra sau đó: bảng định tuyến chọn đường, và lối ra chọn nguồn.

Đó là lý do văn phòng và bàn bếp khác nhau với cùng một laptop, cùng một hồ sơ trình duyệt và cùng một dấu trang. Ở văn phòng yêu cầu đi ra qua một địa chỉ công cộng được duy trì mà người vận hành trang đã đồng ý. Qua đường hầm đầy đủ nó có thể đi ra qua lối ra VPN, tức một địa chỉ khác và, cho đến khi ai đó thêm nó, chưa được chấp thuận. Qua đường hầm chia tách nó có thể không bao giờ vào đường hầm. Chỉ hai trong ba đường đó từng là một phần của thỏa thuận với chủ trang, và đường thứ ba không phải khuyết điểm cần vá bằng một dòng allow thêm.

Ba trạng thái yêu cầu, hai lối ra được chấp thuận

Hãy viết ma trận ra trước khi chạm vào tường lửa, vì bảng là thiết kế và quy tắc chỉ là một cách hiện thực nó. Các địa chỉ dưới đây là dải tài liệu; hãy thay bằng giá trị được duy trì của bạn và giữ ở nơi chủ trang có thể kiểm toán.

Chính dòng giữa là nơi phần lớn các kế hoạch này gãy. Điều có ý nghĩa là địa chỉ mà thiết bị thực thi nhìn thấy, không phải địa chỉ riêng mà laptop giữ bên trong đường hầm và cũng không phải địa chỉ LAN của nó. Một giá trị như 10.8.0.6 không có nghĩa gì với trang công cộng, và 192.168.1.44 cũng vậy. Địa chỉ đường hầm là chi tiết định địa chỉ của đường hầm, không phải chứng thư mà trang có thể kiểm tra.

Nếu VPN của bạn không thể cung cấp một lối ra ổn định và có tài liệu, ma trận không có dòng giữa hợp lệ và không lượng danh sách cho phép nào tạo ra được. Lựa chọn trung thực lúc đó là một trang riêng đến được qua các tuyến riêng rõ ràng, hoặc một cổng truy cập nhận biết danh tính trước ứng dụng. Cả hai có hợp đồng khác với danh sách cho phép công cộng, và cả hai dễ giải thích cho kiểm toán viên hơn một danh sách đã lớn lên cho đến khi tình cờ hoạt động.

Đọc nguồn tại nơi quyết định được đưa ra

Đặt hạn chế lên thiết bị kết thúc yêu cầu, và xác nhận rằng không đường gốc thay thế nào vòng qua nó. mô-đun truy cập của Nginx đánh giá các chỉ thị allow và deny theo thứ tự, kết quả khớp đầu tiên thắng, và các quy tắc kế thừa từ khối bao quanh vẫn áp dụng bên trong location. Một allow hẹp cạnh một allow rộng ở cùng chỗ thường có nghĩa là cái rộng quyết định. Hãy đọc toàn bộ cấu hình hiệu lực cho location đó trước khi sửa dù chỉ một dòng của nó.

server {
    listen 443 ssl;
    server_name intranet.example.com;

    set_real_ip_from 10.20.0.10;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    location /app/ {
        allow 203.0.113.24;    # office public exit
        allow 198.51.100.77;   # approved VPN egress
        deny  all;
        proxy_pass http://app_backend;
    }
}

Sau bộ cân bằng tải hoặc proxy ngược, quy tắc đó thấy proxy trừ khi bạn nói khác. Chỉ khôi phục địa chỉ người gọi qua cơ chế proxy tin cậy được hỗ trợ, với danh sách địa chỉ proxy rõ ràng. Tiêu đề yêu cầu khẳng định một địa chỉ được chấp thuận không phải bằng chứng rằng người gọi sở hữu nó, và trên một cổng nghe công cộng, tiêu đề được chuyển tiếp chưa xác thực biến danh sách cho phép thành đồ trang trí.

Sau đó kiểm tra họ địa chỉ còn lại. Một bộ quy tắc chỉ bao IPv4 là quyết định chưa đầy đủ cho một tên máy chủ cũng trả lời trên AAAA, và một ứng dụng khách có IPv6 hoạt động sẽ đến cùng ứng dụng qua một đường bạn chưa bao giờ xem xét.

Đường hầm chia tách: yêu cầu không bao giờ vào

Đường hầm chia tách chỉ mang các tiền tố trong danh sách của nó. Các mạng con nội bộ của văn phòng thường nằm trong danh sách đó; một trang web công cộng thì không. Trình duyệt phân giải tên, so sánh địa chỉ được chọn với bảng định tuyến, và vẫn thấy cổng mặc định cục bộ ở phía trước.

Vì thế yêu cầu đến từ kết nối tại nhà của người dùng, bị từ chối, và báo cáo nói VPN hỏng trong khi đường hầm làm đúng điều nó được cấu hình để làm. Có hai cách sửa chính đáng: định tuyến đích đó qua đường hầm và để lối ra được chấp thuận mang nó, hoặc chấp nhận rằng trang được truy cập trực tiếp và cho người dùng từ xa một đường được chấp thuận khác như cổng truy cập. Mở rộng danh sách cho phép công cộng của trang cho đến khi một địa chỉ nhà tình cờ nằm trong đó không phải cách nào trong hai cách ấy, và nó xóa bỏ ranh giới mà thiết kế phải thực thi. Hai cách đầu giữ ma trận trung thực; cách thứ ba âm thầm xóa một dòng khỏi nó.

Chứng minh từ chối, rồi chứng minh phục hồi

Hãy thử bằng một yêu cầu thực sự dùng quyết định thật, từ một ứng dụng khách đứng trên từng dòng của bảng. Kiểm tra khả năng tiếp cận tới một trang bất kỳ hiển thị địa chỉ không chứng minh gì, vì đích đó có thể đi đường khác với ứng dụng.

curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'

So sánh bản ghi truy cập ở ranh giới với điều bảng dự đoán. Sau đó hạ đường hầm xuống và tạo một yêu cầu mới đáng lẽ phải bị từ chối; một trang đã tải sẵn, hay một kết nối đã mở, không kiểm tra được gì cả. Nếu không có từ chối nào xuất hiện, điểm thực thi không ở nơi bạn nghĩ.

Giữ xác thực ứng dụng sau khi được nhận vào mạng, vì lối ra văn phòng và lối ra VPN mỗi cái đại diện cho nhiều người và không cái nào nhận diện một cá nhân. Chỉ dẫn cho người dùng vẫn ngắn: bật đường hầm được chấp thuận, rồi thử lại. Đó là điều giữ một URL tiện lợi trong khi quy tắc nguồn vẫn là một quyết định chứ không phải phỏng đoán.