Chính sách VPN hai WAN phải khớp với gói tin nào?

Các yêu cầu định tuyến VPN qua đường lên thứ hai mô tả ít nhất hai công việc khác nhau, và chính sách sửa được cái này sẽ không đụng đến cái kia. Ở công việc thứ nhất, lưu lượng đã mã hóa giữa hai đầu chuyển sang một địa chỉ WAN khác. Ở công việc thứ hai, luồng ứng dụng đã giải mã của người dùng đang kết nối đi ra tới một bước nhảy tiếp theo khác. Cả hai đều hợp lệ, cả hai đều dùng định tuyến, và mỗi cái cần một sự khớp trên gói tin tồn tại tại điểm ra quyết định. Hãy đi qua các kiểm tra dưới đây theo thứ tự, vì cái đầu tiên quyết định gói tin nào mà các quy tắc sau phải nêu tên.

Gọi tên hai cuộc trò chuyện

Hãy hình dung một nhân viên từ xa kết nối với cổng văn phòng, mở HTTPS tới một máy chủ ứng dụng nội bộ. Có hai cuộc trò chuyện độc lập trên đường truyền, và chúng có địa chỉ khác nhau ở mỗi đầu. Cuộc trò chuyện bên ngoài chạy giữa hai đầu VPN: từ địa chỉ cổng đến địa chỉ đối tác, với giao thức và cổng mà việc triển khai đã thương lượng. Cuộc trò chuyện bên trong chạy từ địa chỉ được cấp cho máy khách đến địa chỉ máy chủ ứng dụng trên cổng 443.

Cổng đích của ứng dụng không phải cổng vận chuyển của VPN, và không lượng chính sách nào trên TCP 443 di chuyển được đường hầm. Tương tự, một quy tắc chuyển hướng địa chỉ vận chuyển của đối tác không nói gì về việc yêu cầu HTTP của người dùng đó đi đâu sau khi giải mã. Hãy ghi lại cả hai cuộc trò chuyện với địa chỉ thật trước khi chạm vào một quy tắc, vì phần lớn sự nhầm lẫn trong lĩnh vực này đến từ việc gọi tên cái này và cấu hình cái kia.

Tìm nơi chính sách của bạn thực sự nhìn thấy gói tin

Sự khớp phải được đánh giá trong chuỗi và không gian tên nơi gói tin vẫn còn ở dạng bạn mô tả. Một quy tắc gắn vào lối vào LAN nhìn thấy gói tin bên trong, chưa mã hóa, trước khi nó được định tuyến tới đường hầm. Một quy tắc áp dụng cho lưu lượng sinh ra tại chỗ nhìn thấy các gói tin do chính cổng tạo ra, và nó không tự động bao gồm lưu lượng mà cổng chỉ chuyển tiếp. Đầu ra đã đóng gói lại là trường hợp thứ ba, thường được xử lý trên giao diện mang đường hầm chứ không phải ở phía LAN.

Đó là lý do cùng một đoạn cấu hình hành xử khác nhau trên hai nền tảng: điểm gắn khác nhau, và móc chính sách của nhà cung cấp có thể nằm trước hoặc sau bước mã hóa. Hãy đọc đường đi của gói tin cho sản phẩm cụ thể thay vì giả định thứ tự từ sơ đồ của nhà cung cấp khác.

Xác nhận lưu lượng vận chuyển đã thương lượng

Với IPsec đóng gói trong UDP, RFC 3948 đặt ESP bên trong UDP và dùng dấu hiệu không phải ESP để IKE vẫn phân biệt được trên cổng dùng chung. ESP thường là một giao thức IP, không phải cổng TCP hay UDP, nên một quy tắc tường lửa viết theo số cổng sẽ không khớp với nó chút nào. Sự phân biệt này quyết định chính sách WAN của bạn cần quy tắc UDP, quy tắc giao thức hay cả hai.

Giá trị đã thương lượng thắng giá trị đã ghi nhớ. Hãy đọc cổng và địa chỉ hiện tại của hiệp hội từ thiết bị thay vì thêm TCP 4500 hay một cổng cũ của nhà cung cấp để phòng hờ, việc này bắt lưu lượng không liên quan và che mất vấn đề phân loại thật.

Kiểm tra đường về trước khi cam kết

Thành công ở chiều ra chỉ chứng minh một nửa thiết kế. Gói tin quay về phía nhóm máy khách từ xa không còn hiển thị dưới địa chỉ của máy khách khi việc đóng gói thay thế nó: đích bên ngoài là địa chỉ vận chuyển của đối tác. Nếu đường lên thứ hai tới đối tác đó qua một nhà mạng khác, việc dịch và lọc của nó có thể không khớp với cái đầu, và hiệp hội có thể cần được dựng lại thay vì chuyển đi.

Trạng thái dịch địa chỉ mạng là nạn nhân thường thấy của việc đổi WAN. Hãy ghi lại đường lên đã chọn, địa chỉ nguồn bên ngoài dự kiến, bản dịch đang dùng và khả năng tiếp cận của đối tác trở lại nó, rồi giữ lưu lượng vận chuyển có thể tiếp cận mà không đẩy nó vào đường hầm mà nó mang.

Kiểm chứng cả hai tầng bằng hai lần bắt gói

Một lần bắt gói trên giao diện WAN và một lần bên trong đường hầm giải quyết câu hỏi nhanh hơn mọi so sánh cấu hình. Hãy chạy chúng từ cổng trong khi một máy khách đã được phê duyệt thực hiện một yêu cầu duy nhất, và giữ cả hai tệp.

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

Lần bắt gói đầu tiên phải cho thấy cuộc trò chuyện bên ngoài rời giao diện mà bạn định dùng, với địa chỉ nguồn dự kiến. Lần thứ hai phải cho thấy cuộc trò chuyện bên trong một lần, không trùng lặp, với địa chỉ máy khách là nguồn và máy chủ ứng dụng là đích. Việc tra cứu tuyến xác nhận bảng nào bộ định tuyến sẽ dùng cho cặp nguồn và đích đó, và đó là nơi lỗi chính sách thường xuất hiện. Nếu một trong hai lần bắt gói không xuất hiện, điểm quyết định nằm ở nơi khác chứ không phải nơi quy tắc được gắn, và cách sửa thuộc về nơi đó chứ không phải một sự khớp rộng hơn.