Tuyến mặc định tunneled trên Cisco ASA: khi nào nó thực sự được áp dụng

Một người dùng truy cập từ xa không đến được gì phía sau ASA trong khi cùng máy chủ đó vẫn trả lời ping từ LAN bên trong. Đường hầm được dựng lên, máy khách nhận địa chỉ từ pool, và gói tin vẫn đi ra theo tuyến mặc định internet hoặc biến mất. Kiểu này thường có nghĩa là lưu lượng đã giải mã không tìm thấy tuyến riêng và rơi xuống tuyến mặc định thông thường. Cách khắc phục không phải là một quy tắc NAT khác; đó là tuyến mặc định tunneled.

Bắt đầu từ triệu chứng, không phải từ cấu hình

Hãy xem gói tin đi đâu, chứ không phải nơi bạn kỳ vọng nó đi. Một bản bắt gói trên cổng ngoài trong phiên thất bại cho thấy gói đã giải mã đang đi về phía cổng của ISP với địa chỉ pool vẫn còn nguyên, hoặc không cho thấy gì cả vì việc tra cứu thất bại. Dù thế nào thì đường hầm không phải là vấn đề.

Đường hầm trông khỏe mạnh trong show vpn-sessiondb, và đó chính là lý do người ta cứ tiếp tục gỡ lỗi IKE.

Điều phân biệt trường hợp này với việc bị ACL chặn là hướng. Việc bị ACL chặn được ghi log và đếm, còn tuyến bị thiếu tạo ra lỗi tra cứu mà không có mục nào khớp. Chạy show route cho đích của máy khách và đọc xem ASA thực sự đã chọn gì, kể cả việc có chọn tuyến mặc định hay không và chọn tuyến nào.

Tra cứu tunneled khác ở điểm nào

Hướng dẫn của Cisco về định tuyến tĩnh trên ASA 9.23 ghi nhận một tuyến mặc định riêng cho lưu lượng VPN đã giải mã mà không có tuyến tĩnh hoặc tuyến đã học. Từ khóa tunneled đánh dấu tuyến đó, nên gói đã giải mã có thể rơi xuống một chặng kế tiếp khác với chặng mà ASA dùng cho vận chuyển của chính nó. Các tuyến cụ thể hơn vẫn thắng, đó là lý do máy khách có thể đến được 10.0.0.0/8 qua cổng nội bộ và mất mọi thứ còn lại.

Một bố trí tối thiểu giữ hai tuyến mặc định với chặng kế tiếp khác nhau. Một tuyến chở lưu lượng của chính ASA, tuyến còn lại chở lưu lượng đã giải mã không có tuyến tốt hơn. Cả hai chặng kế tiếp vẫn phải đến được từ cổng mà bạn gắn chúng vào.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

Nếu cả hai tuyến mặc định trỏ đến cùng một chặng kế tiếp thì từ khóa không thay đổi gì và triệu chứng sẽ không nhúc nhích.

Những hạn chế quyết định việc nó có hoạt động hay không

Cùng hướng dẫn đó chỉ cho phép một tuyến mặc định tunneled và nêu rõ ECMP không được hỗ trợ cho tuyến này, nên bạn không thể chia tải trên đường đó. Tài liệu cũng liệt kê các hạn chế liên quan đến theo dõi tuyến, kiểm tra đường về và một số luồng kiểm tra cùng quản trị. Hãy đọc chúng đối chiếu với bản phát hành bạn đã cài trước khi thiết kế quanh tính năng này. Một thiết kế bỏ qua chúng thường hỏng ở một điểm cụ thể chứ không phải ở mọi nơi, và đó là lý do triệu chứng có vẻ chập chờn.

Kiểm tra đường về là thứ cắn trong các thiết kế bất đối xứng. Nếu phản hồi đi vào qua một cổng khác với cổng ASA mong đợi, gói tin bị bỏ trước khi việc định tuyến kịp có ý nghĩa. Hãy sửa cấu trúc liên kết hoặc đường về thay vì tắt kiểm tra để ép một chặng kế tiếp.

Theo dõi tuyến là một cái bẫy riêng: đối tượng được theo dõi thường canh tuyến mặc định thông thường, không phải tuyến tunneled.

Từ khóa không làm gì

Nó không chọn địa chỉ nguồn mà ASA dùng để dựng IKE. Điểm cuối đường hầm bên ngoài tuân theo việc chọn cổng và nguồn của chính nền tảng, và tuyến mặc định tunneled không có phần trong quyết định đó. Thay đổi nó sẽ không sửa được phase 1 khởi nguồn từ địa chỉ sai.

Nó cũng không biến chặng kế tiếp thành proxy. Nếu đích mong đợi một cuộc trao đổi HTTP CONNECT, việc gửi gói IP thô đến một máy chủ proxy chỉ cho bạn một máy chủ không định tuyến những gói đó. Thay vào đó hãy cấu hình cơ chế proxy mà máy khách hỗ trợ.

Và nó không tạo ra chuyển tiếp xuôi dòng. Cổng mà bạn trỏ tới vẫn cần một tuyến quay lại pool VPN, cùng với dịch địa chỉ nguồn ở nơi thiết kế yêu cầu.

Kiểm tra đường đi từ đầu đến cuối

Sau khi tuyến đã vào bảng, hãy kiểm tra bốn thứ theo thứ tự: show route cho một đích mà pool cần, bắt gói trên cổng hướng về chặng kế tiếp mới, bắt gói trên chính cổng đó, và đường về từ cổng đó đến địa chỉ pool. Hai bước đầu chứng minh ASA đã chọn đường, hai bước cuối chứng minh có ai đó trả lời trên đó.

Nếu cổng trả lời nhưng máy khách không bao giờ thấy phản hồi, hãy xem dịch địa chỉ nguồn và tuyến phản hồi trước khi chạm lại vào bảng định tuyến.

Ghi lại bản phát hành bạn đã kiểm chứng, vì danh sách hạn chế phụ thuộc vào phiên bản và một thiết kế chạy được trên nhánh này có thể cần đường khác trên nhánh khác. Ghi chú đó sống lâu hơn đoạn cấu hình.