Đường hầm chia tách không miễn trừ máy chủ công cộng khỏi quy tắc NAT của ASA
Tuyến split-include kéo máy chủ công cộng vào đường hầm, nơi ASA phải hairpin và dịch nguồn. Bỏ qua một trong hai bước là luồng dữ liệu đứt.
Đường hầm chia tách thường được mô tả là cách giữ lưu lượng doanh nghiệp bên trong đường hầm và phần còn lại của internet bên ngoài tường lửa. Cả hai nửa của mô tả đó đều sai theo cùng một cách. Đường hầm chia tách là quyết định định tuyến do máy khách đưa ra, và quyết định định tuyến không nói gì về điều gì xảy ra với gói tin sau khi nó đến headend.
Chỉ một dịch vụ đối tác trên địa chỉ công cộng, vốn khăng khăng muốn thấy địa chỉ trụ sở của bạn, là đủ để phá vỡ câu chuyện này.
Lầm tưởng: đường hầm chia tách đưa tường lửa ra khỏi đường đi
Niềm tin là mọi đích đến ngoài các dải riêng tư đều ở lại trên kết nối internet cục bộ, nên tường lửa không bao giờ thấy nó và không bao giờ cần quy tắc cho nó. Điều đó chỉ đúng khi đích đến không có trong danh sách đường hầm. Ngay khi quản trị viên thêm máy chủ công cộng vào ACL split-include, máy khách gửi lưu lượng đó vào đường hầm, và ASA phải định tuyến, lọc và dịch nó như mọi luồng đã giải mã khác. Trên máy khách không có gì thay đổi ngoài danh sách đích.
Máy khách không trở thành bộ định tuyến. Nó chỉ tuân theo chính sách bạn đưa ra.
Tuyến split-include thực sự làm gì
Trong một cấu hình truy cập từ xa Cisco ASA, chính sách nhóm mang split-tunnel-policy tunnelspecified và một split-tunnel-network-list nêu tên một ACL chuẩn. Mỗi dòng permit trong ACL đó là một đích mà máy khách phải gửi vào đường hầm, và mọi thứ khác tiếp tục dùng tuyến mặc định cục bộ.
Thêm một máy chủ là một dòng duy nhất, và đó là phần duy nhất của thay đổi mà máy khách có thể thấy: access-list RA-SPLIT standard permit host 203.0.113.20.
Sau đó kết nối lại máy khách. Chính sách được trao đổi khi kết nối, nên một phiên đã thiết lập giữ danh sách cũ và khiến thay đổi trông như không làm gì cả.
Gói tin đi vào và đi ra trên cùng một giao diện
Giờ hãy theo dõi luồng sau khi giải mã. Gói tin đi vào giao diện ngoài qua đường hầm VPN, đích của nó là địa chỉ công cộng, và bảng định tuyến gửi nó trở ra qua chính giao diện ngoài đó về phía internet. Lưu lượng đi vào và đi ra trên một giao diện sẽ bị bỏ trừ khi ASA được phép cho qua, và đó là điều same-security-traffic permit intra-interface làm. Không có nó, kết nối thất bại theo cách trông giống sự cố định tuyến nhưng không phải.
Cài đặt đó là toàn cục. Nó cho phép hairpinning với mọi luồng cần đến, không chỉ máy chủ đối tác này, nên nó thuộc về một thay đổi đã được rà soát chứ không phải một bài kiểm tra nhanh.
Vì sao PAT giới hạn theo đích không phải tùy chọn
Địa chỉ nguồn trong gói đã giải mã vẫn là địa chỉ VPN của máy khách, thường từ một pool như 10.77.0.0/24. Địa chỉ đó không có tuyến trên internet công cộng, nên đối tác hoặc không bao giờ trả lời hoặc trả lời vào hư không.
Việc dịch sửa nguồn và để đích nguyên vẹn. Vì các đối tượng đã được định nghĩa ở nơi khác, một quy tắc thủ công giới hạn theo đích này có dạng như sau:
same-security-traffic permit intra-interface
object network RA_POOL
subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
host 203.0.113.20
nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOSTPhần destination static quan trọng. Nếu bỏ nó, quy tắc trở thành một phép dịch rộng có thể khớp với nhiều lưu lượng hơn dự định, và một quy tắc identity rộng đứng trước trong thứ tự có thể đánh bại nó hoàn toàn. Hãy kiểm tra show nat detail và thứ tự các phần trước khi cho rằng quy tắc của bạn là cái khớp.
PAT giao diện cũng có nghĩa là đối tác thấy địa chỉ giao diện của ASA, địa chỉ này có thể được dịch lại ở phía trên. Nếu hợp đồng nêu một địa chỉ, hãy xác nhận từ đầu đến cuối thay vì ở một bước nhảy.
Chứng minh bằng đích kiểm tra đúng
Hãy dùng chính máy chủ đối tác, không dùng trang what-is-my-ip chung. Trang đó gần như chắc chắn nằm ngoài danh sách split, nên nó báo địa chỉ internet cục bộ của bạn và không nói gì về đường đi này. Mở kết nối mới tới dịch vụ đối tác và hỏi họ đã quan sát nguồn nào, hoặc chạy packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed và đọc các bước NAT và định tuyến từng dòng. Traceroute từ máy khách là kiểm tra yếu hơn, vì nó cho thấy đường đi đã xảy ra chứ không phải chính sách đã chọn nó.
Sau đó kiểm tra những gì không được thay đổi. Một trang web thông thường vẫn phải đi ra qua kết nối cục bộ, và một tài nguyên riêng trong danh sách đường hầm vẫn phải truy cập được. Một thay đổi sửa được đối tác mà làm hỏng một trong hai điều đó là một lỗi khác.
Phiên bản hoạt động của thiết kế này rất ngắn: một máy chủ trong ACL split, quyền hairpin, một quy tắc PAT giới hạn theo đích. Phần còn lại của câu chuyện là lầm tưởng.