VPN site-to-site chỉ hoạt động một chiều: hai lỗi khác nhau

Site A đến được B, B không đến được A, và đường hầm trông ổn ở cả hai chiều. Trước khi chạm vào đường hầm, hãy xác định bạn thực sự gặp lỗi nào. Một kết nối mới khởi tạo tại B và bị từ chối, cùng một phản hồi cho kết nối khởi tạo tại A không bao giờ đến, tạo ra những khiếu nại giống nhau và những chẩn đoán hoàn toàn khác nhau. Một là vấn đề chính sách hoặc tuyến trên đường đi; cái kia là vấn đề đường về hoặc trạng thái đối với lưu lượng vốn đã được cho phép.

Sự phân biệt này quyết định nên chạy những lệnh nào.

Hai lỗi trông giống hệt nhau

Trong trường hợp đầu, máy chủ của B gửi SYN tới A và không có gì quay lại. Trong trường hợp thứ hai, máy chủ của A mở phiên thành công và phản hồi biến mất trên đường về. Cả hai người dùng đều nói đường liên kết là một chiều, và cả hai đều mô tả một gói tin đã biến mất, nên chỉ mô tả thì không thể phân biệt được chúng.

Hãy hỏi bên nào đã khởi tạo lần thử thất bại. Chỉ một dữ kiện đó loại bỏ một nửa số nguyên nhân có thể.

Sau đó kiểm tra xem bài kiểm tra có dùng cùng máy chủ và cùng dịch vụ trong suốt quá trình không. Ping từ một bên và kết nối chia sẻ tệp từ bên kia kiểm tra hai thứ khác nhau, và chẩn đoán chạy từ cổng có thể chọn một địa chỉ đường hầm mà không lưu lượng người dùng nào dùng.

Trường hợp một: thiếu đường về

Một máy chủ từ xa trả lời qua cổng mặc định khác có thể nhận yêu cầu và định tuyến phản hồi đi nơi khác. Sau đó tường lửa theo dõi trạng thái sẽ loại bỏ phản hồi không đối xứng vì nó không khớp với luồng đã thiết lập, điều này trông đúng như một chiều chưa bao giờ hoạt động. Dịch địa chỉ thêm một biến thể khác: đích thấy nguồn đã được dịch và trả lời địa chỉ đó, nên một quy tắc viết cho địa chỉ gốc không bao giờ khớp.

Kiểm tra địa chỉ mà đích thực sự thấy sau khi dịch, và tuyến về cho địa chỉ đó thay vì cho mạng con gốc.

Trường hợp hai: chính sách chưa bao giờ cho phép

Trường hợp ngược lại đơn giản và phổ biến hơn vẻ ngoài của nó: một văn phòng chỉ được dùng dịch vụ trung tâm và không bao giờ được khởi tạo kết nối vào trung tâm. Sự bất đối xứng đó là quyết định truy cập có chủ đích, và đường hầm hoạt động đúng như thiết kế. Hãy đọc chính sách truy cập trước khi thay đổi bất kỳ cài đặt nào của đường hầm. Tài liệu, chứ không phải bản bắt gói, mới nói chiều nào là dự kiến. Bản bắt gói chỉ có thể cho thấy điều gì đã xảy ra, không phải điều gì được phép.

Nếu thực sự cần khởi tạo hai chiều, hãy thêm quyền cho dịch vụ cụ thể thông qua bộ quy tắc mà nền tảng hỗ trợ. Việc làm mọi mạng con tin cậy lẫn nhau để sửa một ứng dụng biến một yêu cầu hẹp thành quyền rộng, và sự đánh đổi đó hiếm khi được xem lại sau này.

So sánh trước và sau trên cùng các máy chủ

Hãy quan sát cả hai đầu của cùng một lần thử, không phải hai lần thử riêng biệt. Bắt gói tại cổng của máy chủ khởi tạo và tại đích, rồi so sánh điều gì đã vào, điều gì đã ra và địa chỉ nào phía xa đã thấy.

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

Nếu bản bắt gói tại đích cho thấy yêu cầu với địa chỉ nguồn bất ngờ, câu trả lời nằm ở dịch địa chỉ hoặc định tuyến, không phải ở chính sách bảo mật của đường hầm. Nếu đích không cho thấy yêu cầu nào, gói tin chưa bao giờ đi qua đường được bảo vệ.

Sau khi sửa, hãy lặp lại đúng bài kiểm tra đó từ đúng máy chủ đó và xác nhận rằng truy cập không liên quan vẫn bị từ chối. Trạng thái đường hầm “established” tự nó không chứng minh kết luận nào trong hai kết luận.