Vì sao máy khách OpenVPN không khớp các bộ chọn IPsec của cổng

Ping từ cổng tới một máy chủ phía sau đường hầm IPsec từ xa và nó trả lời sạch sẽ, nên đường hầm trông khỏe mạnh và phiếu việc vẫn tiếp tục. Sau đó một máy khách đã kết nối thử cùng máy chủ đó và không nhận được gì. Ping đó chưa bao giờ là bằng chứng cho luồng của máy khách, vì nó đi ra với chính địa chỉ nguồn của cổng và khớp với một bộ chọn IPsec khác. Hiểu vì sao hai trường hợp này khác nhau là phần lớn của việc sửa.

Ping từ cổng kiểm tra một luồng mà máy khách của bạn không bao giờ dùng

Địa chỉ nguồn quyết định chính sách nào được áp dụng. Một gói tin tạo trên cổng đi ra với địa chỉ từ LAN cục bộ hoặc từ điểm cuối đường hầm, và chính sách khớp với nó được viết đúng cho trường hợp đó. Gói tin của máy khách đến giao diện OpenVPN với một địa chỉ từ nhóm máy khách, đây là một bộ chọn hoàn toàn khác.

Vì thế sự cố trông như vấn đề định tuyến trong khi thực chất là vấn đề phạm vi chính sách. Khả năng tiếp cận từ cổng chứng minh đầu kia còn sống và các đề xuất đã được thương lượng, và nó không chứng minh gì về việc nhóm có được bảo vệ hay không.

Đẩy tiền tố từ xa mà ứng dụng thực sự cần

Lấy cặp ví dụ 10.8.0.0/24 cho các máy khách đã kết nối và 172.30.239.0/25 cho mạng từ xa được bảo vệ. Điều máy khách cần là tuyến đường tới tiền tố thứ hai, không phải tới LAN của cổng và không phải tới một địa chỉ đường hầm khác. Tuyến đường được đẩy vào nhóm là thứ khiến máy khách giao lưu lượng đó cho cổng. Không có nó, gói tin không bao giờ tới được quyết định chính sách mà bạn đang gỡ lỗi.

Trên một máy chủ Community chấp nhận tuyến đường được đẩy, chỉ thị nhận mặt nạ thật: push "route 172.30.239.0 255.255.255.128". Access Server cấu hình cùng đích đó qua phần cài đặt mạng riêng hoặc quy tắc truy cập của phiên bản đã cài, với chế độ định tuyến hoặc dịch được chọn có chủ đích. Sửa các chuỗi tường lửa được sinh ra thay vì cấu hình sở hữu là cách một bản cài đang chạy trở nên không thể tái tạo.

Sau khi kết nối, hãy đọc bảng định tuyến của máy khách chứ không phải ý định của máy chủ. Một tuyến chỉ bao phủ nhóm nghĩa là lần đẩy chưa bao giờ tới, và tuyến mặc định qua đường hầm rộng hơn yêu cầu này và sẽ khiến bạn bất ngờ về sau. Kiểm tra mặt nạ và cả tiền tố, vì một /25 được đẩy như /24 sẽ gửi lưu lượng của các địa chỉ lân cận vào một đường không thể chở nó. Sau đó xác nhận máy khách đã chọn giao diện đường hầm cho đích đó.

Làm cho các bộ chọn bao gồm nhóm máy khách

Với truy cập định tuyến giữ nguyên địa chỉ máy khách, chính sách IPsec phải bảo vệ lưu lượng giữa nhóm và tiền tố từ xa. Các bộ chọn viết cho LAN của chính cổng cho ping đi qua và bỏ yêu cầu của máy khách, và đó chính là sự bất đối xứng đã khởi đầu cuộc điều tra này.

Xem xét chính sách đã thương lượng và cả các đề xuất đã cấu hình, ví dụ bằng ipsec statusall trên strongSwan hoặc lệnh trạng thái tương đương cho cách triển khai của bạn. Với IPsec dựa trên chính sách, tuyến thông thường có thể trỏ tới một giao diện vật lý trong khi lưu lượng khớp vẫn được mã hóa, nên việc thiếu thiết bị đường hầm không chứng minh gì. So sánh các cặp bộ chọn với nhóm và tiền tố bạn đã ghi lại.

NAT nguồn chung trên cổng cũng có thể phá vỡ sự khớp. Nếu một quy tắc masquerade viết lại nguồn của máy khách trước khi kiểm tra chính sách, gói tin không còn giống bộ chọn bạn đã viết. Đó là một lý do khiến một quy tắc masquerade rộng là cách sửa tồi cho VPN thứ hai: nó thay đổi chính sách nào được áp dụng và địa chỉ nào phía xa ghi nhận. Miễn trừ lưu lượng bạn định định tuyến, hoặc dịch nó một cách có chủ đích và cập nhật các bộ chọn.

Chọn định tuyến hay dịch một cách có chủ đích

Định tuyến giữ địa chỉ máy khách hiển thị với phía xa, nên nhật ký phía xa và quy tắc theo nguồn vẫn có ý nghĩa, và nó đòi hỏi cổng phía xa biết đường quay lại nhóm. Dịch giấu nhóm sau một địa chỉ duy nhất, điều này loại bỏ vấn đề tuyến quay lại và phá hủy danh tính theo từng máy khách.

Chọn một thiết kế và ghi lại, vì cả hai cần các bộ chọn khác nhau và thứ tự tường lửa khác nhau. Một masquerade áp dụng nửa vời nằm giữa hai cách và không thỏa mãn cách nào. Lựa chọn được ghi lại cũng là thứ giúp kỹ sư tiếp theo phân biệt lỗi với quyết định có chủ đích.

Khép vòng ở chuyển tiếp và phản hồi

Cổng phải chuyển tiếp giao thức và đích mà bạn dự định, nghĩa là chuyển tiếp IP được bật và có chuỗi chuyển tiếp cho phép cặp đó. Sau đó phía xa phải gửi phản hồi ngược lại theo đường IPsec, và đó là quyết định định tuyến trên cổng của họ chứ không phải của bạn. Cả hai nửa đều là cấu hình thông thường, và cả hai đều dễ bị bỏ dở. Hãy thử chúng riêng rẽ để một quy tắc chuyển tiếp thiếu không bị nhầm là đường hầm hỏng.

Xác minh bằng một yêu cầu thật từ máy khách tới ứng dụng, quan sát nó đi qua giao diện OpenVPN, quyết định IPsec và máy chủ phía xa. Xem phản hồi như một quan sát riêng, vì một yêu cầu đến nơi và một phản hồi không bao giờ quay lại trông giống nhau từ chỗ ngồi của máy khách. Một yêu cầu được theo vết đáng giá hơn bất kỳ số ping nào từ cổng.

Giữ quyền cho đích ở mức hẹp trong khi thử nghiệm, và xác nhận rằng một máy khách không có quy tắc không thể tới dịch vụ. Một tuyến đã cài đặt cộng với một liên kết đã thiết lập không phải là điều giống như quyền truy cập được cấp.