Giao diện nào nhận vai trò NAT bên trong và bên ngoài trên một đầu ra VPN IOS
Theo dõi gói tin của máy khách đã được giải mã từ giao diện ảo đến đường lên. Việc dịch thuộc về luồng bên trong này, không phải phần vận chuyển bên ngoài của đường hầm.
Các bộ định tuyến cung cấp lối ra internet bằng đường hầm đầy đủ làm hai việc trông như một. Nó kết thúc đường hầm và chuyển gói tin của máy khách đã được giải mã ra internet. Chỉ việc thứ hai cần dịch, và bản dịch phải khớp với luồng bên trong. Sự khác biệt đó quyết định giao diện nào mang vai trò NAT và dải địa chỉ nào xuất hiện trong quy tắc.
Theo dõi một gói tin qua bộ định tuyến
Hãy lấy một máy khách tại 10.90.0.25 đang mở một dịch vụ HTTPS công khai. Việc đích đó có vào đường hầm hay không là quyết định chính sách của chính máy khách. Khi vào, bộ định tuyến giải mã gói tin và chuyển nó đến một giao diện ảo, từ đó nó được định tuyến đến đường lên công cộng.
Giao diện ảo đó là phía trong của việc dịch. Đường lên công cộng là phía ngoài. Nếu các vai trò bị đảo hoặc thiếu, gói tin hoặc đi ra với nguồn riêng tư, hoặc bị loại bỏ trước khi được dịch.
| Stage | Question to answer |
|---|---|
| VPN client | Does the client's policy put this destination inside the tunnel? |
| Decrypted ingress | Which virtual interface receives the inner packet? |
| Internet egress | Which route, access policy and source translation apply? |
| Reply | Is the client's flow translated back before it is delivered over the tunnel? |
Khớp chính sách dịch với nhóm máy khách
Quy tắc NAT phải nêu dải mà máy khách thực sự nhận được, không phải LAN văn phòng tình cờ dùng chung đường lên. Một quy tắc chỉ bao phủ mạng con cục bộ sẽ bỏ sót máy khách từ xa ngay cả khi cả hai đi ra qua cùng một giao diện.
ip access-list extended NAT-TUNNEL
permit ip 10.90.0.0 0.0.0.255 any
ip nat inside source list NAT-TUNNEL interface GigabitEthernet0/0/0 overloadGiữ riêng các ngoại lệ cho trang nội bộ. Lưu lượng đến các đích bên trong phải giữ nguyên nguồn gốc của nó, nếu không đích sẽ trả lời đến một địa chỉ mà nó không thể tới và chặng quay về sẽ thất bại theo cách trông giống vòng lặp định tuyến.
Áp dụng các vai trò cho các giao diện thực tế trong thiết kế đã triển khai. Một đoạn Virtual-Template sao chép từ câu trả lời Easy VPN cũ không phải là cấu hình hiện tại đầy đủ, và loại đường hầm đang dùng quyết định giao diện nào nhận gói tin đã giải mã.
Tách phần vận chuyển bên ngoài khỏi việc dịch bên trong
Dịch nguồn ứng dụng đã giải mã không phải là thao tác giống như đẩy gói IKE hoặc gói được bảo vệ qua một thiết bị NAT ở phía trên. Việc đầu tiên thay đổi thứ mà internet thấy là nguồn yêu cầu của máy khách; việc thứ hai giữ đường hầm sống qua một thiết bị trung gian.
Nhầm lẫn hai việc tạo ra hai lỗi kinh điển. Bộ định tuyến dịch phần vận chuyển đường hầm của chính nó sẽ phá vỡ quan hệ ngang hàng, trong khi bộ định tuyến không bao giờ dịch luồng bên trong lại chuyển địa chỉ riêng tư ra internet. Hãy đọc xem bạn đang nhìn luồng nào trước khi sửa quy tắc, và kiểm tra xem đường hầm có còn đứng sau thay đổi không. Một quy tắc sửa được việc duyệt web nhưng làm sập đường hầm đã di chuyển vấn đề thay vì giải quyết nó.
Không lỗi nào được sửa bằng cách thay đổi lỗi kia. Hãy đọc xem bạn đang nhìn luồng nào trước khi sửa quy tắc.
Xác minh ở cả hai ranh giới
Đọc nguồn ứng dụng ở ranh giới internet, và đích được khôi phục ở chặng quay về. Việc đầu cho biết việc dịch có xảy ra không; việc thứ hai cho biết ánh xạ ngược có quay về đúng máy khách không.
Sau đó thử một máy khách dùng đường hầm chia tách đã được phê duyệt. Máy khách đó không bao giờ dùng việc dịch internet của bộ định tuyến này, nên nó phải hành xử khác đi, và sự khác biệt xác nhận lưu lượng đã đi theo đường nào.
Nếu cả hai máy khách hành xử giống nhau, chính sách đường hầm chia tách không làm đúng như thiết kế nói. Hãy sửa điều đó trước khi thêm quy tắc dịch mới, vì một quy tắc viết cho đường không dùng sẽ che giấu vấn đề thật.