Chuyển tiếp DHCP trên ASA qua VPN site-to-site: hướng dẫn từng bước

Chuyển tiếp hoạt động theo ba chặng, và chỉ chặng giữa đi qua VPN. Máy khách phát quảng bá trên phân đoạn chi nhánh, ASA biến lần phát đó thành yêu cầu unicast tới máy chủ DHCP, và máy chủ trả lời tới địa chỉ chuyển tiếp chứ không phải máy khách. Đi qua các chặng theo đúng thứ tự đó, và phần lớn trường hợp «chuyển tiếp hỏng» quy về một chính sách thiếu hoặc một dòng setroute bị đọc sai.

Chặng một: bật chuyển tiếp trên giao diện phía máy khách

Trên ASA của chi nhánh, chuyển tiếp là thuộc tính của giao diện hướng về phía máy khách. Máy chủ có thể được khai báo toàn cục cùng giao diện tiếp cận được, hoặc nằm dưới giao diện phía máy khách đó để bảng định tuyến chọn lối ra. Hai dạng này không thay thế cho nhau, và sao chép nhầm dạng là chỗ đầu tiên một hướng dẫn đi chệch.

Kiểm tra cấu hình đang chạy trước khi đổi bất cứ thứ gì: giao diện nào bật chuyển tiếp, dạng máy chủ nào đang có, và setroute có gắn với giao diện máy khách không. Nếu ASA cũng chạy máy chủ DHCP cho phân đoạn khác, hãy dừng lại và đọc danh sách hạn chế; máy chủ và chuyển tiếp không thể cùng bật trên một thiết bị.

Chuyển tiếp đặt địa chỉ phía máy khách của chính nó vào trường địa chỉ cổng. Máy chủ sẽ trả lời đúng địa chỉ đó, nên nó phải tiếp cận được từ site xa qua đường hầm, không chỉ cục bộ.

Chặng hai: mang lưu lượng do ASA tạo ra qua đường hầm

Đây là bước người ta hay bỏ qua. VPN site-to-site dựa trên chính sách thường được dựng cho lưu lượng giữa các mạng con, còn yêu cầu chuyển tiếp do chính ASA tạo ra. Nếu danh sách truy cập của đường hầm và bản đồ mã hóa chỉ khớp với luồng từ máy chủ chi nhánh tới mạng con máy chủ, gói chuyển tiếp có thể không bao giờ vào được đường hầm. Hãy kiểm tra danh sách truy cập theo cả hai chiều, không chỉ dòng từ chi nhánh tới máy chủ.

Xác nhận lưu lượng quan tâm bao gồm nguồn chuyển tiếp của ASA và địa chỉ máy chủ, và chiều quay về cũng được cho phép. Trong thiết kế dựa trên VTI, quyết định định tuyến đơn giản hơn, nhưng hỗ trợ chuyển tiếp trên VTI đến trong một bản phát hành cụ thể; hướng dẫn DHCP của ASA nêu 9.14(1), nên hãy kiểm tra image trước khi sao chép ví dụ VTI sang thiết bị cũ hơn.

Ping từ ASA tới máy chủ tự nó chứng minh được ít điều. Nó có thể thành công qua đường khác, với địa chỉ nguồn khác, hoặc dưới một chính sách mà các gói chuyển tiếp không khớp.

Chặng ba: đọc câu trả lời và tùy chọn setroute

RFC 2131 nói rằng khi trường đó khác không, máy chủ gửi câu trả lời tới địa chỉ trong giaddr. Vì vậy đường quay về phải được định tuyến tới địa chỉ chuyển tiếp, và chính sách đường hầm phải cho phép chiều từ máy chủ tới chuyển tiếp. Nếu yêu cầu đã đi qua nhưng đề nghị không bao giờ đến, đây chính là chỗ cần xem.

Sau đó tách hai thứ nghe giống nhau. Từ khóa setroute thay đổi hoặc thêm tùy chọn bộ định tuyến mặc định mà ASA cấp cho máy khách. Nó không cài tuyến trên ASA và không tạo chính sách VPN. Máy khách nhận được địa chỉ nhưng không tới được gì thường gặp vấn đề setroute hoặc phạm vi, không phải vấn đề đường hầm. Hãy thử với máy khách không có cổng mặc định tĩnh và xem bộ định tuyến mặc định nào xuất hiện trong đề nghị.

Đọc đề nghị từ đầu đến cuối: địa chỉ được cấp, mặt nạ, bộ định tuyến mặc định, DNS và thời hạn thuê. Sau đó để thời hạn thuê gia hạn. Một chuyển tiếp chạy được một lần rồi hỏng khi gia hạn thường có vấn đề phạm vi, thuê hoặc đường quay về mà lần trao đổi đầu đã che mất.

Tôi kiểm tra gì trước khi nói đã sửa

Bắt đầu từ máy khách và bắt lấy lần phát quảng bá, sau đó xác nhận ASA đã chuyển tiếp nó với địa chỉ của chính nó là giaddr. Ở phía xa, xác nhận máy chủ đã thấy yêu cầu đó và chọn phạm vi khớp với chi nhánh. Trở lại chi nhánh, xác nhận máy khách đã chấp nhận đề nghị và tới được cổng của nó.

Nếu chặng nào im lặng, hãy kiểm tra chính sách hoặc tuyến tương ứng thay vì thêm một câu lệnh chuyển tiếp nữa. Cấu hình chuyển tiếp thường đã đúng vào lúc có người báo lên; thứ đã thay đổi là chính sách đường hầm hoặc tuyến quay về.

Viết ba chặng vào biên bản thay đổi: giao diện phía máy khách, chính sách VPN bao phủ lưu lượng chuyển tiếp và tuyến quay về của máy chủ tới giaddr. Chính biên bản đó biến lần dựng chi nhánh tiếp theo thành công việc lặp lại được thay vì một phiên gỡ lỗi. Nó cũng cho kỹ sư tiếp theo biết nên thu thập đầu ra lệnh nào trước.