Firebox từ chối theo vị trí địa lý: hãy tìm giai đoạn vào VPN trước

Một người ở quốc gia khác không thể kết nối, và phản xạ đầu tiên là xem quy tắc cấp quyền truy cập vào tài nguyên nội bộ. Quy tắc đó chạy sau bước kết nạp, nên nó không thể là thứ từ chối đường hầm. Giai đoạn chặn nằm đâu đó trên đường vào, và Firebox có nhiều hơn một đường vào tùy theo dịch vụ VPN. Hãy làm các bước kiểm tra theo thứ tự và dừng ngay khi một bước giải thích được việc từ chối.

Bước kiểm tra 1: gọi tên dịch vụ đi vào

Với Mobile VPN dùng SSL, Access Portal và BOVPN trên TLS, đầu vào là chính sách WatchGuard SSLVPN. Hãy áp đặt giới hạn dự định tại đó, trên dịch vụ thực sự được cấu hình, thay vì suy ra từ một quy tắc truy cập người dùng chạy sau đó.

IPsec đi theo một đường khác. Chính sách IPSec tích hợp cho phép lưu lượng IPsec bên ngoài vào Firebox đối với các dịch vụ branch và VPN di động liên quan, và nó có ưu tiên cao hơn chính sách IPSec tạo thủ công. Nếu máy khách của bạn là IKEv2, bạn đang ở đường thứ hai đó, và chính sách SSLVPN không liên quan.

Làm sai điều này là buổi chiều lãng phí phổ biến nhất trong lĩnh vực này: sửa một chính sách không bao giờ nhìn thấy gói tin, rồi kết luận rằng giới hạn không hoạt động.

Bước kiểm tra 2: đọc việc từ chối, không đọc lý thuyết

Hãy thực hiện một lần thử được cho phép có kiểm soát và đối chiếu bốn thứ: địa chỉ nguồn công khai của máy khách, dịch vụ đầu vào mà nó chạm tới, chính sách đã khớp, và mọi lý do Deny trong nhật ký. Hướng dẫn khắc phục sự cố IKEv2 của WatchGuard lưu ý rằng vị trí địa lý và xử lý gói mặc định có thể từ chối lưu lượng trước khi chính sách tích hợp kết nạp, nghĩa là việc từ chối bạn thấy có thể nêu tên một giai đoạn bạn chưa xét tới.

Việc phân loại quốc gia đi theo nguồn mạng quan sát được. Một người dùng chuyển vùng, một NAT thượng nguồn hay một đường đã được phê duyệt khác có thể thay đổi những gì Firebox thấy, nên hãy xác nhận địa chỉ thay vì lời mô tả của người dùng về nơi họ ở. Hãy hỏi địa chỉ công khai mà máy khách thấy và so với nguồn trong nhật ký Firebox. Khi hai thứ khác nhau, việc phân loại đang đi theo một đường mà không ai nhắc đến.

Bước kiểm tra 3: chính sách tích hợp còn là chủ sở hữu không?

Nếu một chính sách IPSec thủ công có vẻ bị bỏ qua, hãy kiểm tra xem chính sách tích hợp còn được bật không. Một quy tắc thủ công bị quy tắc tích hợp có ưu tiên cao hơn che khuất và một quy tắc thủ công là kết nạp duy nhất là hai cấu hình khác nhau với giao diện trông giống nhau.

Hãy quyết định cái nào bạn muốn làm chủ đường đi. Nếu là chính sách thủ công, chính sách tích hợp phải bị tắt cho lưu lượng đó, và đó là nơi bước kiểm tra tiếp theo bắt đầu.

Bước kiểm tra 4: lập kế hoạch thay thế trước khi tắt

Tắt chính sách IPSec tích hợp sẽ gỡ bỏ việc kết nạp của nó cho các dịch vụ VPN bị ảnh hưởng. Điều đó bao gồm các đường hầm branch mà bạn có thể không nghĩ tới khi đang sửa kết nối của một người dùng di động.

Trước tiên hãy lập kế hoạch thay thế đầy đủ: dịch vụ nào cần kết nạp, chúng nhận những dải nguồn nào, và bạn sẽ quản lý thiết bị ra sao nếu thay đổi đi sai. Hãy giữ một đường quản trị và phục hồi độc lập luôn mở, vì một sai sót ở đây có thể gỡ mất đường hầm mà bạn sẽ dùng để sửa nó. Ghi các bước phục hồi vào biên bản thay đổi, kể cả cách tiếp cận thiết bị nếu đường VPN không còn. Sau đó hãy kiểm tra việc gia hạn, không chỉ kết nối đầu tiên.

Kết nối đang hoạt động và việc thương lượng lại sau đó đều có thể phụ thuộc vào kết nạp. Một thay đổi chạy tốt cho phiên bạn đã thử nhưng hỏng ở lần đổi khóa tiếp theo là kết cục kinh điển của việc thay kết nạp mà không kiểm tra gia hạn.

Bước kiểm tra 5: giữ danh tính tách khỏi vị trí

Vị trí địa lý thêm ngữ cảnh cho quyết định đầu vào. Nó không xác lập người dùng là ai, và không nên thay thế các bước kiểm tra danh tính cổng, phân quyền tài khoản hay MFA.

Nếu yêu cầu nghiệp vụ chỉ là người dùng đã được phê duyệt từ những nơi đã được phê duyệt, bạn cần cả hai biện pháp kiểm soát. Một quy tắc vị trí chấp nhận cả một quốc gia không thay thế cho xác thực, và một người dùng đã xác thực ở quốc gia bị chặn là câu hỏi chính sách chứ không phải lỗi.

Bước kiểm tra 6: ghi lại và kiểm chứng cả hai đường

Hãy viết ra dịch vụ, chính sách đầu vào, phạm vi vị trí dự định, các ngoại lệ và người chịu trách nhiệm phục hồi. Sau đó kiểm tra đường di động và ít nhất một đường tới site sau thay đổi, để giới hạn vẫn gắn với dịch vụ mà nó được thiết kế để kiểm soát.

Cuối cùng, hãy đọc lại việc từ chối mà bạn bắt đầu. Nếu nó đã chuyển từ từ chối vị trí sang thất bại xác thực hoặc phân quyền, vấn đề đầu vào đã được giải quyết và một vấn đề khác đang hiện ra. hướng dẫn của WatchGuard về việc từ chối IKEv2 là tài liệu tham chiếu cho thứ tự giai đoạn mô tả ở trên.