Mô-đun ASA FirePOWER không có tuyến quản trị đến FMC

FMC hiển thị mô-đun là không thể kết nối, đăng ký vẫn ở trạng thái chờ, trong khi ping từ bên trong ASA hoạt động hoàn hảo. Trong một triển khai ASA FirePOWER hiện có, sự kết hợp đó là bình thường. Mô-đun có địa chỉ quản trị riêng, cổng mặc định riêng và các quyết định định tuyến riêng, và việc chia sẻ một kết nối quản trị vật lý với ASA trên một số nền tảng không hợp nhất chúng thành một ngăn xếp mạng duy nhất. Hai thiết bị trả lời từ hai góc nhìn khác nhau trên cùng một sợi dây.

Những điều sau áp dụng cho các mô-đun đã đưa vào vận hành. Xác định kiểu khung máy, loại mô-đun và phiên bản phần mềm được hỗ trợ trước khi áp dụng bất kỳ sơ đồ cổng nào từ hướng dẫn.

Vẽ mô-đun như một máy chủ riêng

Bắt đầu sơ đồ bằng IP quản trị của mô-đun, mặt nạ và cổng mặc định, VLAN thực sự mang kết nối đó, và địa chỉ FMC cần đến. Sau đó, trong một ô riêng, ghi địa chỉ giao diện của ASA và toàn bộ bảng định tuyến của nó. Nếu hai ô cuối cùng chia sẻ một mạng con với các địa chỉ thuộc các chủ khác nhau, bạn đã tìm ra phần thú vị của vấn đề.

Hướng dẫn mô-đun ASA FirePOWER cho thấy cách bố trí cổng khác nhau giữa các nền tảng, bao gồm cả cách đi dây quản trị chia sẻ khi ASA và mô-đun có địa chỉ riêng trên cùng một phân đoạn. Sơ đồ phần cứng đó là đầu vào cho thiết kế, không phải chú thích.

Tìm nơi tuyến quay về bị đứt

Hãy lấy một bố cục định tuyến qua lõi. Mô-đun gửi lưu lượng hướng tới FMC vào một lõi Layer 3, lõi chuyển tiếp đích quản trị từ xa về phía giao diện bên trong của ASA, và VPN của site mang nó sang phía bên kia. Sau đó site từ xa cần một tuyến quay về mạng con quản trị của mô-đun. Mọi bước trong chuỗi đó đều có thể đúng trong khi tuyến cuối cùng đó bị thiếu, và đó là lý do sự cố thường trông giống một đường hầm bị đứt.

Hãy đọc góc nhìn của chính ASA trước khi thay đổi bất cứ điều gì:

show interface ip brief
show route
show running-config interface

Lệnh thứ ba quan trọng vì một địa chỉ giao diện bạn quên chính là thứ khiến tuyến quay về hạ cánh trên thiết bị sai.

Kiểm tra ASA coi gì là đã kết nối

Nếu ASA có địa chỉ trên mạng con quản trị của mô-đun, tuyến kết nối của nó sở hữu tiền tố đó. Tuyến tĩnh về phía lõi không thay thế quyền sở hữu tuyến kết nối, nên gói tin quay lại ASA và dừng ở đó. Đăng ký sau đó thất bại tại một điểm không liên quan gì đến thông tin xác thực.

Đừng kết luận rằng một kiểm tra chống giả mạo cụ thể đã bỏ gói tin trừ khi bạn có quan sát của chính thiết bị trước mắt. Thay vào đó hãy so sánh giao diện vào, tuyến đích đã chọn và ranh giới chuyển tiếp giữa quản trị và dữ liệu được hỗ trợ cho nền tảng đó. Ba sự thật đó thường phơi bày xung đột cấu trúc liên kết trước khi ai đó bắt đầu đặt lại khóa đăng ký.

Chọn cách sửa giữ mô-đun vẫn kết nối

Xóa địa chỉ của ASA khỏi phân đoạn đó và vô hiệu hóa vật lý một cổng chia sẻ không phải là những hành động tương đương. Trên các nền tảng mà mô-đun đi qua cùng kết nối quản trị vật lý, vô hiệu hóa cổng sẽ loại bỏ liên kết duy nhất của mô-đun — bạn sẽ biến một vấn đề định tuyến thành một thiết bị chết. Hãy ưu tiên thay đổi phân bổ lại quyền sở hữu định tuyến quản trị, và chuẩn bị nó với sự có mặt của chủ mạng.

Một lựa chọn được hỗ trợ thứ hai là cấp cho đường quản trị của ASA một phân đoạn riêng để mạng con quản trị của mô-đun chỉ có một chủ. Việc đó tốn một địa chỉ và một chút tài liệu, và loại bỏ sự mơ hồ vĩnh viễn. Dù chọn con đường nào, sau đó hãy xác nhận rằng mô-đun vẫn đến được cả FMC và các nguồn DNS hoặc NTP của nó.

Chỉ đăng ký khi tuyến đã nhất quán

Khi tuyến quay về đã sạch, hãy lập kế hoạch kết nối quản trị và các tham số đăng ký theo hướng dẫn phiên bản tương ứng của FMC và mô-đun. Giữ bí mật đăng ký ngoài các ghi chú và phiếu chia sẻ, và chống lại cám dỗ đăng ký lại như một bước chẩn đoán: một khóa mới trên tuyến bị đứt chỉ tạo ra cùng lỗi với dấu thời gian mới hơn.

Hãy chấp nhận tuyến từ ngăn xếp quản trị của chính mô-đun thay vì từ ping do ASA khởi tạo, vì nguồn của phép thử chính là thứ đang bị nghi ngờ. Ghi lại bước nhảy tiếp theo của mô-đun, lựa chọn VPN của ASA và tuyến trả lời của FMC, và duy trì một phương pháp khôi phục độc lập cho cả hai vai trò quản trị. Chính bản ghi đó phân biệt một đường truyền đã sửa với một đăng ký thành công.

Khi mô-đun cuối cùng xuất hiện trong FMC, hãy chạy lại ba lệnh đó và lưu kết quả bên cạnh sơ đồ. Người tiếp theo chạm vào phân đoạn quản trị đó sẽ cần chính xác phép so sánh ấy.