ASA VPN hairpin: định tuyến hai đường hầm qua một giao diện

Một người dùng từ xa kết nối tới ASA, yêu cầu một máy chủ phía sau chi nhánh, và ASA gửi yêu cầu đó ra ngoài qua đúng giao diện mà người dùng đã đi vào. Không điều nào trong đó cần cổng vật lý thứ hai. Điều nó cần là bốn quyết định độc lập mà người ta thường gộp thành một: quyền thực hiện hairpin, một đường hầm bảo vệ đúng địa chỉ, một chính sách NAT giữ nguyên nguồn bạn đã hứa, và một chính sách truy cập cho phép dịch vụ.

Một gói tin, hai đường hầm

Theo dõi luồng và thứ tự các thao tác không còn bí ẩn. Gói tin đến bên trong đường hầm truy cập từ xa, được giải mã và trở thành một gói IP thông thường có nguồn từ nhóm máy khách. Sau đó ASA định tuyến nó, đối chiếu với crypto ACL site-to-site, mã hóa lại và gửi ra qua giao diện bên ngoài về phía chi nhánh.

Các địa chỉ dưới đây chỉ là ví dụ, nhưng hình dạng mới quan trọng: nguồn là nhóm địa chỉ, không phải LAN nội bộ của ASA.

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

Hai điều rút ra từ đó. Máy khách cần một tuyến cho tiền tố chi nhánh qua kết nối truy cập từ xa của nó, nghĩa là split-tunnel hoặc danh sách tuyến được đẩy xuống phải bao gồm tuyến đó. Và chi nhánh phải biết cách trả lưu lượng về 10.77.0.20 hoặc về địa chỉ mà thiết kế NAT của bạn đã thay thế.

Quyền hairpin là toàn cục

Lệnh mà người ta thường dùng là same-security-traffic permit intra-interface. Nó cho phép lưu lượng đi vào và đi ra trên cùng một giao diện, đúng là điều đường đi này cần. Nó cũng là một thiết lập toàn cục: bật nó lên sẽ thay đổi hành vi của những luồng khác tình cờ đi qua cùng giao diện hai lần.

Vì vậy nó thuộc về biên bản thay đổi chứ không phải một phiên gỡ lỗi. Hãy hỏi còn gì trên thiết bị nay có thể đi theo đường của cùng giao diện đó, và liệu có thứ nào nên làm vậy. Trên một biên giới bận rộn với mạng khách hoặc các đường hầm đối tác chồng lấn, câu trả lời không tự động là không. Hãy ghi lý do bên cạnh thiết lập, vì kỹ sư tiếp theo sẽ tìm thấy lệnh chứ không tìm thấy cuộc trò chuyện.

Phạm vi bảo vệ và NAT là riêng biệt

Đường hầm site-to-site bảo vệ bất cứ thứ gì crypto ACL của nó chọn. Nếu ACL đó nêu subnet nội bộ của ASA làm nguồn, nhóm truy cập từ xa không được bảo vệ và gói tin sẽ bị bỏ hoặc được gửi đi ở dạng rõ, tùy theo hành vi của nền tảng với lưu lượng không khớp. Hãy thêm nhóm vào luồng được bảo vệ khi thiết kế giữ nguyên địa chỉ của nhóm.

Sau đó NAT quyết định địa chỉ của nhóm có sống sót hay không. Identity NAT giữ nguyên nó, và chi nhánh thấy 10.77.0.20 là nguồn. Việc dịch địa chỉ thay đổi hợp đồng: chi nhánh nay trả lưu lượng về địa chỉ đã dịch, và chính sách của nó phải chấp nhận điều đó. Thứ tự quy tắc quyết định crypto ACL khớp trước hay sau khi dịch, vì vậy hãy đọc luồng thực tế thay vì giả định cái nào thắng.

Đừng xóa các quy tắc PAT chung cho internet chỉ để một trường hợp quá cảnh hoạt động. Một ngoại lệ có mục tiêu hoặc một quy tắc identity có chủ đích dễ giải thích và dễ hoàn tác hơn một lỗ hổng trong chính sách ra ngoài.

Mã hóa không phải là cấp quyền

Một đường hầm hoạt động chỉ chứng minh rằng hai bên đồng ý về khóa và bộ chọn. Nó không nói gì về việc người dùng này có được tới dịch vụ đó hay không. Bộ lọc VPN hoặc chính sách nhóm gắn với kết nối truy cập từ xa vẫn phải cho phép đích và cổng của chi nhánh, và ACL giao diện trên đường ra ngoài vẫn áp dụng.

Hãy kiểm tra câu trả lời theo cả hai hướng. Một kết nối thành công trong khi dịch vụ bên cạnh đáng lẽ phải thất bại cho nhiều thông tin hơn một lần ping thành công, vì nó cho thấy chính sách có tính chọn lọc chứ không mở toang. Nếu bài kiểm tra đáng lẽ bị từ chối lại thành công, thủ phạm không phải đường hầm mà là chính sách. Hãy giữ cả hai kết quả trong biên bản thay đổi để người tiếp theo biết hành vi nào là chủ ý.

Hairpin hay giao diện thứ hai

Quá cảnh hairpin giữ thiết kế nhỏ gọn và chỉ tốn một thiết lập toàn cục. Một giao diện riêng, hoặc một đường hầm dựa trên định tuyến với giao diện ảo riêng, cô lập đường quá cảnh và cho bạn chính sách theo từng giao diện, đổi lại là việc đánh địa chỉ và thêm một crypto map hoặc hồ sơ nữa. Không cái nào đúng hơn; chúng hỏng theo cách khác nhau.

Các thiết kế dựa trên định tuyến là một cách bố trí khác, không phải một ô chọn trong cùng cấu hình. Nếu bạn chuyển sang kiểu đó, phần thảo luận về crypto ACL dựa trên chính sách ở trên không còn áp dụng và bảng định tuyến bắt đầu làm công việc chọn lựa.

Hãy xác minh từ máy khách thật

Một phép dò khởi phát từ ASA có địa chỉ nguồn khác và sẽ không đi qua đường từ nhóm tới chi nhánh. Dùng packet-tracer để kiểm tra bộ năm thành phần, sau đó mở một kết nối thật từ máy khách từ xa thực tế, vì công cụ theo dõi chỉ mô phỏng và không thay thế việc định tuyến cùng chính sách của chính máy khách.

Sau một thay đổi đã lên kế hoạch, hãy kết nối tới một dịch vụ đáng lẽ phải hoạt động, rồi tới một dịch vụ đáng lẽ bị từ chối, sau đó xác nhận tuyến trả về của chi nhánh. Các các ví dụ NAT hairpin cho VPN của Cisco giữ quyền intra-interface, NAT và ACL tách bạch một cách nhìn thấy được, và đó là mô hình tư duy đáng để sao chép.