Cách mô hình hóa luồng VPN với ASA packet-tracer

Packet-tracer trên ASA trả lời một câu hỏi hẹp: gói này, đi vào đây với tuple này, có được cho phép không, và nó sẽ đi đâu. Nó không trả lời liệu đầu xa có nhận được gì không. Lỗi thường gặp là đưa vào một tuple IKE bên ngoài khi thứ bạn muốn kiểm tra là ứng dụng chạy bên trong đường hầm. Sửa tuple trước, đọc các pha, rồi thu thập bằng chứng thật cho mọi thứ mà bộ mô phỏng không thấy được.

Phần trình bày dưới đây giả định ACL, quy tắc NAT và ngữ cảnh tunnel-group đang ở trước mắt bạn. Không có chúng, kết quả chỉ mô tả một chính sách bạn không thể kiểm tra.

Bước 1: viết luồng bên trong bằng từ ngữ đơn giản

Mô tả ứng dụng trước khi gõ bất cứ thứ gì. Một máy chủ bên trong mở SSH tới máy chủ phía sau cổng từ xa là một luồng TCP bên trong với cổng nguồn cụ thể. Đó là luồng mà ACL và bộ lọc VPN đánh giá, nên đó là luồng bạn gõ.

Viết nó thành một câu, rồi dịch từng trường một:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Bước 2: chọn giao diện vào và hướng

Lối vào là giao diện mà gói đến, không phải giao diện nó rời đi. Với máy chủ LAN khởi tạo, đó là giao diện inside. Với gói phản hồi của cùng phiên, đó là giao diện outside, và tuple đảo ngược. Gõ đích làm nguồn là cách phổ biến thứ hai để có được một ALLOW thuyết phục nhưng không liên quan.

Cổng cũng có hướng. Cổng dịch vụ thuộc trường đích với một yêu cầu được khởi tạo, và cổng tạm thời của máy khách thuộc trường nguồn. Một mô hình có đích TCP 500 mô tả ứng dụng TCP đang lắng nghe trên 500; nó không trở thành bài kiểm tra IKE chỉ vì con số xuất hiện trong lệnh.

Bước 3: đọc các pha theo thứ tự

Mỗi pha trong kết quả là một quyết định có chủ: tra tuyến, ACL, NAT, rồi chọn VPN hoặc đường hầm. Đọc chúng theo thứ tự in ra và dừng ở pha đầu tiên không khớp với thiết kế.

NAT thường đánh lừa mọi người. Nếu nguồn đã dịch nằm ngoài crypto ACL chọn lưu lượng cho đường hầm, luồng có thể được cho phép và không bao giờ được đóng gói. Bản theo dõi in ra địa chỉ đã dịch, nên hãy so sánh nó với lưu lượng đáng quan tâm của đường hầm chứ không phải địa chỉ gốc.

Bước 4: kiểm tra bạn đã chọn những bỏ qua nào

Dạng detailed nhận các tùy chọn bỏ qua kiểm tra, và Cisco ghi nhận tùy chọn bypass-checks bao gồm ACL, bộ lọc VPN, uRPF và kiểm tra giả mạo IPsec. Một ALLOW có được khi bỏ qua những thứ đó nói rằng tuyến và NAT sẽ hoạt động, không phải rằng chính sách sẽ nhận một gói thật. Ghi lại các tùy chọn bên cạnh kết quả.

Nếu cần câu trả lời về chính sách, hãy chạy mà không có các bỏ qua. Nếu đang cô lập một câu hỏi định tuyến, hãy chạy cùng chúng và dán nhãn kết quả là câu trả lời định tuyến.

Bước 5: lấp khoảng trống bằng trao đổi thật

Một sự cho phép mô phỏng dừng tại ASA. Cổng từ xa có giải mã gói hay không, máy chủ có chấp nhận kết nối hay không và có phản hồi trở về hay không là những quan sát riêng biệt. Dùng bộ đếm điểm cuối hoặc một bản chụp bắt hẹp trên đường đã được phê duyệt.

Một số tùy chọn trace và replay truyền gói hoặc giữ trạng thái. Hãy theo hành vi được ghi nhận cho bản phát hành và quy trình chẩn đoán đã được phê duyệt của bạn thay vì coi mọi biến thể là tra cứu chỉ đọc.

Điều mà bản theo dõi vẫn không thể nói

Giữ bốn thứ trong một ghi chú: tuple, quy tắc NAT khớp, đường hầm hoặc chính sách nên mang luồng, và quan sát đặc thù theo hướng. Không có chúng, kỹ sư sau này không thể tách quyết định chính sách cục bộ khỏi mặt phẳng điều khiển đã thiết lập và khỏi dịch vụ đang hoạt động. Thất bại đầu tiên rồi thành công cũng không phải bằng chứng rằng đường hầm phải dựng lên ở giữa; ghi lại pha và thay đổi trạng thái.

Bắt đầu với tuple bên trong, dừng ở pha đầu tiên mâu thuẫn với thiết kế, và chỉ sau đó mới tìm bằng chứng điểm cuối. Bản theo dõi là một oracle chính sách, không phải biên nhận giao hàng.