Quy tắc ASA nào nhìn thấy lưu lượng sau khi VPN giải mã nó

Giả định đầu tiên cần bỏ là ACL mã hóa là một chính sách truy cập. Không phải vậy. Trên Cisco ASA, danh sách đó trả lời một câu hỏi hẹp: những gói nào xứng đáng được bảo vệ, và câu trả lời đó không nói gì về việc gói đã giải mã có được đến máy chủ phía sau tường lửa hay không. Quyền truy cập được quyết định sau đó, bởi chính sách giao diện, bởi bộ lọc chính sách nhóm, hoặc cả hai, tùy vào cách đường hầm được xây dựng.

ACL mã hóa trả lời một câu hỏi khác

ACL mã hóa là một danh sách khớp. Nó nói cho đường hầm biết cần mã hóa cái gì giữa hai bên; gói không khớp với nó thì đơn giản là không được bảo vệ. Mở rộng nó chỉ thay đổi phạm vi bảo vệ và không gì khác.

Vì thế thêm một mạng con ở đó có thể dựng đường hầm lên trong khi ứng dụng thực tế vẫn thất bại. Đường hầm lên vì giờ đã có khớp. Ứng dụng vẫn thất bại vì không có gì trong danh sách đó cho phép bất cứ điều gì. Hai câu hỏi khác nhau, hai danh sách khác nhau.

Cài đặt bỏ qua thực sự bỏ qua điều gì

sysopt connection permit-vpn cho phép lưu lượng được bảo vệ bỏ qua việc kiểm tra ACL giao diện vốn sẽ áp dụng ở phía vào. Đó là một tiện ích cho việc triển khai VPN, và nó là toàn cục. Nó không chạm vào chính sách nhóm và không chạm vào bộ lọc ủy quyền theo người dùng.

Hãy đọc giá trị thực thay vì giả định: show running-config all sysopt in ra cài đặt ngay cả khi nó chưa bao giờ được cấu hình rõ ràng, và nhiều nhầm lẫn bắt đầu từ đó.

Vì cài đặt là toàn cục, thử nó như một thí nghiệm nhanh trên một mạng con đang lỗi là một sự đánh đổi tồi. Mọi đường hầm khác trên tường lửa đó đều chia sẻ kết quả. Hãy để dành nó cho một thay đổi có chủ đích với kế hoạch hoàn nguyên.

Hãy đọc bộ lọc theo hướng giải mã

Một vpn-filter LAN-to-LAN được viết từ góc nhìn của đường hầm, không phải của giao diện. Mạng từ xa nằm ở vị trí nguồn và mạng cục bộ ở vị trí đích, vì đó là hình dạng của gói sau khi giải mã. Sau đó cùng bộ lọc được đánh giá lại theo hướng ngược lại trước khi mã hóa, với vai trò địa chỉ đảo ngược.

Các điều kiện cổng đáng được chăm chút hơn một ACL giao diện sao chép, chính vì lý do đó. Một quy tắc cho phép một cổng đích có thể gây tác dụng không mong muốn ở hướng ngược lại, nơi một kết nối mới dùng cổng đó làm nguồn. Trước khi dựng danh sách, hãy ghi lại bên nào được khởi tạo, dịch vụ thực tế và bên đối diện phải giữ đóng.

Xác nhận bộ lọc nào thực sự được gắn: show running-config group-policy và show vpn-sessiondb detail l2l cùng nhau cho biết phiên đã thừa hưởng gì. Sửa một ACL mà không chính sách nào tham chiếu sẽ không thay đổi gì.

Đừng dùng lại một đối tượng ACL cho hai việc

access-group của giao diện và vpn-filter trông như cùng một loại đối tượng và được đánh giá ở những điểm khác nhau với hướng địa chỉ khác nhau. Gán một danh sách cho cả hai mời gọi một thay đổi sửa đường hầm và âm thầm nới lỏng giao diện vật lý.

Hãy giữ chúng tách biệt, đặt tên theo công việc của chúng, và để sự khác biệt về hướng hiện rõ trong tên.

Kiểm chứng bằng kết nối mới, ở cả hai hướng

Sau một thay đổi có kế hoạch, hãy mở một kết nối mới đáng được cho phép và một kết nối mới đáng bị từ chối, rồi ghi lại địa chỉ, hướng và sự khớp chính sách cùng với kết quả. Một phiên đã thiết lập không chứng minh được gì về việc lọc kết nối mới, vì nó đã được chấp nhận theo các quy tắc cũ.

Cũng tính đến việc kiểm tra sâu. Tài liệu của nhà cung cấp lưu ý rằng bộ lọc VPN kiểm tra kết nối đầu tiên chứ không phải mọi kết nối thứ cấp mà một cơ chế kiểm tra mở ra, nên một kênh điều khiển và luồng phương tiện đi kèm có thể nhận cách xử lý khác nhau. Nếu ứng dụng hiểu giao thức, hãy kiểm tra luồng thực tế thay vì một phép thử cổng đơn lẻ.

Một đường hầm trở nên dùng được sau khi bỏ qua rộng rãi cho bạn biết hạn chế đã bị gỡ bỏ, chứ không phải đã được thỏa mãn. Kết quả đáng giữ lại là một điểm thực thi có tên mà bạn có thể chỉ ra trong lần xem xét tiếp theo.