Xuất bản một dịch vụ nằm sau VPN site-to-site là một công việc với năm điểm hỏng, và chúng hỏng theo một thứ tự cố định. Đường hầm đi lên, bản dịch khớp, nhánh trả lời và phản hồi quay về theo cùng đường. Khi bất kỳ điểm nào sai, trình duyệt hiển thị cùng một thứ: một kết nối bị treo hoặc bị đặt lại. Hãy làm danh sách từ trên xuống dưới và dừng ở bước kiểm tra đầu tiên thất bại.

Kiểm tra 1: đường hầm bảo vệ địa chỉ nguồn

Bắt đầu từ một đường hầm đã truyền lưu lượng, sau đó xác nhận rằng địa chỉ bạn định xuất bản nằm trong dải được bảo vệ. Trên ASA dải đó đến từ ACL mã hóa hoặc từ các tuyến của VTI, và nó phải bao phủ địa chỉ thật của nguồn, không phải mạng con mà nhánh dùng để quản trị. Một bộ chọn bỏ sót nguồn sẽ cho bạn đường hầm đang lên và một luồng không bao giờ đi vào đó.

Xác nhận bằng bộ đếm của đường hầm và bảng tuyến trước khi chạm vào phần chuyển đổi. Nếu không thể tới nguồn từ trung tâm qua đường hầm, không gì sau đó trong danh sách này sửa được.

Dừng ở đây nếu dải được bảo vệ và địa chỉ nguồn không khớp.

Kiểm tra 2: quyết định nhánh sẽ thấy nguồn nào

Nhánh thấy địa chỉ gốc của máy khách hoặc một địa chỉ đã chuyển đổi, và lựa chọn đó quyết định đường quay về. Giữ nguyên địa chỉ máy khách đọc sạch hơn trong nhật ký của nguồn, nhưng khi đó nhánh phải gửi phản hồi cho máy khách công cộng ngược qua đường hầm; một tuyến mặc định internet thông thường gửi chúng sang hướng khác và kết nối chết theo một chiều. Chuyển đổi nguồn sang một địa chỉ mà nhánh đã định tuyến qua đường hầm sẽ bỏ yêu cầu đó.

Chuyển đổi cũng thay đổi thứ nguồn có thể ghi nhật ký và thứ các quy tắc dựa trên nguồn có thể khớp. Nếu ứng dụng cần biết người đứng sau một yêu cầu, chỗ đó là proxy ngược có xác thực, không phải quyết định NAT.

Kiểm tra 3: viết bản chuyển đổi theo các giao diện thực

ASA đánh giá các quy tắc chuyển đổi theo thứ tự và báo quy tắc nào khớp, nên cặp giao diện trong quy tắc không phải để trang trí. Một quy tắc viết cho đường từ ngoài vào trong sẽ không khớp với luồng có lối vào và lối ra khác với giả định của bạn.

Con đường bạn đang xây có bốn đoạn, và cả bốn phải khớp nhau:

LegSourceDestination
Request from the internet198.51.100.25203.0.113.20:443
After destination translation198.51.100.2510.60.20.10:443
After source translation toward the tunnel10.10.250.1010.60.20.10:443
Branch reply10.60.20.1010.10.250.10
Restored reply to the client203.0.113.20198.51.100.25

Hãy coi các dải trong bảng đó là giá trị giữ chỗ. Điều quan trọng là bộ giá trị sau chuyển đổi là một địa chỉ mà nhánh chấp nhận qua đường hầm, và ánh xạ ngược tồn tại trong trạng thái NAT để phản hồi được khôi phục khi đi ra.

Kiểm tra 4: giới hạn quy tắc truy cập vào cổng đã xuất bản

Xuất bản cổng, không phải máy chủ. Một quy tắc cho phép nguồn trên mọi dịch vụ biến một ứng dụng đã xuất bản thành đường tới mọi thứ nguồn chạy, kể cả giao diện quản trị mà bạn cố ý giữ ngoài internet. Cho phép cổng đã xuất bản từ nguồn đã chuyển đổi tới nguồn, và để các dịch vụ quản trị trên đường chỉ-VPN của chúng.

Đồng thời kiểm tra thứ tự quy tắc. Một quyền rộng nằm trên quy tắc cụ thể của bạn làm quy tắc cụ thể trở nên vô hình.

Kiểm tra 5: theo dõi một yêu cầu và phản hồi của nó

Đừng bắt đầu bằng trình duyệt, vì trình duyệt giấu đoạn nào đã hỏng. Theo dõi luồng trên trung tâm và đọc kết quả trước khi thay đổi bất cứ điều gì.

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

Bản theo dõi nêu bản chuyển đổi đã khớp, quy tắc truy cập đã cho phép hoặc từ chối luồng, và gói tin có được định tuyến vào đường hầm hay không. Nếu nó cho thấy luồng đi ra qua một giao diện bạn không ngờ, cặp giao diện trong quy tắc NAT là sai. Nếu nó cho thấy bị từ chối, thứ tự quy tắc là sai. Nếu gói tới đường hầm nhưng nguồn không bao giờ trả lời, vấn đề là đường quay về của nhánh.

Sau đó gửi một yêu cầu thật từ bên ngoài và xác nhận phản hồi quay về qua cùng đường hầm. Ghi lại mục đã xuất bản, bản chuyển đổi, cặp địa chỉ được bảo vệ và tuyến quay về làm hồ sơ xuất bản.

Bài viết liên quan