Người dùng từ xa không đến được site thứ hai qua hub VPN

Một người dùng từ xa kết nối vào hub, đến được máy chủ tệp trên LAN của chính hub và mọi thứ trông bình thường. Sau đó họ mở một thư mục chia sẻ tại 10.20.0.50 ở trụ sở chính, nơi hub đến được qua một đường hầm site-to-site riêng, và yêu cầu hết thời gian chờ. Cả hai đường hầm đều hoạt động và cả hai bộ đếm đều tăng, nên không đường hầm nào bị hỏng. Đi qua hub là ba quyết định định tuyến trên ba thiết bị, và một đường hầm chỉ mang những tiền tố mà nó được tạo ra cho. Đây là thứ tự tôi kiểm tra, và lệnh cho thấy mỗi bước có đúng hay không.

Việc đi qua cần ba lần tra cứu, không phải một đường hầm

Mỗi thiết bị tự thực hiện phép khớp tiền tố dài nhất của mình rồi quên đi. Máy tính xách tay phải gửi 10.20.0.50 vào đường hầm chứ không phải tới router cục bộ của nó. Hub phải nhận một gói đến trên giao diện truy cập từ xa và giao nó cho giao diện site-to-site. Trụ sở chính phải gửi phản hồi cho địa chỉ của người dùng quay lại qua đường hầm. Bất kỳ một trong ba lỗi đều trông giống nhau trong trình duyệt: im lặng.

Đó là lý do việc kiểm tra từng đường hầm riêng lẻ chứng minh được rất ít. Ping địa chỉ LAN của hub rèn luyện quyết định thứ nhất, và ping hub từ trụ sở chính rèn luyện quyết định thứ ba. Gói thất bại có nguồn là nhóm người dùng và đích là site thứ hai, nên hãy ghi các tiền tố đó trước. Ở đây nhóm là 10.80.0.0/24, LAN của hub là 10.10.0.0/24 và trụ sở chính là 10.20.0.0/24.

Đẩy tiền tố xa tới máy khách từ xa

Trên một máy chủ truy cập từ xa OpenVPN máy khách học tuyến vào lúc kết nối. Không có push, máy khách dùng đường hầm chia đôi sẽ gửi 10.20.0.50 tới cổng của chính nó và gói không bao giờ vào đường hầm.

push "route 10.20.0.0 255.255.255.0"

Tuyến được đẩy có hiệu lực khi máy khách kết nối, nên người dùng giữ kết nối sẽ không thấy gì cho đến khi kết nối lại. Kiểm tra trên máy khách: ip route get 10.20.0.50 trên Linux, route print trên Windows. Kết quả phải nêu tên giao diện đường hầm.

push không giúp gì cho hub. Đây là thông điệp tới máy khách, không phải tuyến trên máy chủ và không phải quyền được chuyển tiếp, nên một hub có dòng push hoàn hảo vẫn làm rơi luồng một bước nhảy sau đó. Đây là lý do thông thường khiến người ta kết luận push đã thất bại.

Cho hub một tuyến ra thực sự

Hub cần bước nhảy kế tiếp của riêng nó cho tiền tố của trụ sở chính. Trên một đường hầm được định tuyến, đó là một tuyến thông thường đi qua giao diện site-to-site, và một lệnh hiển thị cả tuyến được chọn lẫn nguồn được chọn:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Khi nhánh site-to-site tự nó là OpenVPN, tuyến có thể sống trong cấu hình đó với địa chỉ đường hầm của đối tác làm cổng: route 10.20.0.0 255.255.255.0 172.30.0.2. Cổng không phải là tùy chọn. Nếu bỏ qua, bước nhảy kế tiếp rơi vào giá trị mặc định của cách triển khai, vốn khác nhau giữa máy khách một điểm xa và hub nhiều đối tác.

IPsec dựa trên chính sách thì khác: nhân của hub gửi gói tới cổng LAN thông thường và chính sách bắt lấy nó khi ra ngoài, nên tuyến đường hầm hoặc không làm gì hoặc đưa lưu lượng đi vòng qua chính sách. Hãy để ý nguồn trong lệnh trên, vì 10.10.0.1 thay cho địa chỉ nhóm nghĩa là nhân đã chọn một địa chỉ mà phía xa sẽ từ chối. iroute cũng không phải câu trả lời; nó nói cho máy chủ biết máy khách nào sở hữu một mạng con sau đường hầm của chính nó, không phải nơi gửi lưu lượng cho site thứ ba.

Mở rộng phía xa tới nhóm người dùng

Trụ sở chính đã bao phủ LAN của hub, 10.10.0.0/24. Nhóm người dùng là tiền tố thứ hai và cũng phải có trong các bộ chọn, nếu không sẽ không có chính sách nào bao phủ phản hồi gửi tới 10.80.0.25. Mỗi đối tác nêu cùng một cặp bộ tiền tố từ phía mình:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

local_ts của thiết bị này là remote_ts của thiết bị kia. Sao chép khối của hub sang trụ sở chính thì cặp bị đảo, nên SA con không bao giờ lên.

Cú pháp cũ hơn ipsec.conf dùng leftsubnet phân tách bằng dấu phẩy. Hiệp hội bảo mật đang chạy giữ các bộ chọn mà nó đã thương lượng, nên hãy thiết lập lại đường hầm sau khi sửa. Một bộ chọn đổi lúc 10:00 và được thử với SA lên lúc 09:40 vẫn thất bại, trong khi tệp cấu hình trông đúng suốt thời gian.

Sau đó kiểm tra bước nhảy cuối. ip route get 10.80.0.25 ở đầu xa phải trỏ vào đường hầm. Nếu dịch vụ dùng router LAN làm cổng mặc định, router đó cũng cần tuyến quay về, nếu không phản hồi chết ở đó. Chạy tcpdump -ni eth1 host 10.80.0.25 trên đoạn đó cho thấy phản hồi có rời đầu xa hay không.

Cho phép luồng tại hub

Chuyển tiếp phải được bật và đường đi phải được cho phép. Giới hạn quy tắc trong hai tiền tố thay vì chấp nhận mọi thứ giữa các giao diện.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Lọc đường quay về là lỗi im lặng bên cạnh: khi hai nhánh ở các giao diện khác nhau, rp_filter=1 có thể bỏ phản hồi trong khi bộ đếm của quy tắc chấp nhận không hề nhúc nhích. So sánh iptables -vnL FORWARD trước và sau một lần thử. Một quy tắc không bao giờ tăng thì không được chạm tới, nên hãy nhìn xuống một lớp thay vì viết lại nó.

Nếu chỉ một nhóm cần đi qua, hãy đặt tuyến trong tệp riêng cho từng máy khách dưới client-config-dir thay vì mở rộng push toàn cục. Source NAT trên hub cũng loại bỏ nhu cầu tuyến quay về ở phía xa, nhưng nó che địa chỉ người dùng, nên nhật ký của site xa và các quy tắc dựa trên địa chỉ không còn phân biệt người dùng.

Kiểm tra từ máy khách, rồi quay lui theo thứ tự ngược lại

Hãy thử một cổng TCP, không chỉ ICMP, vì ping có thể đi qua trong khi dịch vụ vẫn bị chặn. nc -vz 10.20.0.50 445 và traceroute -n 10.20.0.50 từ máy khách cho thấy bước nhảy thứ hai có phải là địa chỉ đường hầm của hub không. Trên hub, tcpdump -ni tun0 host 10.20.0.50 và cùng bộ lọc trên giao diện site-to-site: yêu cầu trên cả hai mà không có phản hồi trên cả hai thì chuyển vấn đề sang phía xa.

Sau đó thử một thứ phải tiếp tục bị chặn. Nếu một máy chủ mà nhóm không bao giờ được tới cũng trả lời, bạn đã mở nhiều hơn mức đi qua và nên thu hẹp quy tắc. Một hub chuyển tiếp mọi thứ tới mọi nhánh sẽ vượt qua phép thử đầu và thất bại ở phép thử thứ hai.

Giữ một danh sách quay lui, vì bốn đối tượng đã thay đổi và ba thứ dễ quên: tuyến được đẩy, tuyến của hub, các bộ chọn và quy tắc tường lửa. Hãy hoàn tác theo thứ tự ngược lại, thiết lập lại SA và cho một người dùng kết nối lại. Một lần quay lui một phần để lại tuyến trỏ vào đường hầm không còn khớp, và điều đó khó đọc hơn sự im lặng ban đầu. Hướng dẫn OpenVPN 2.6 ghi lại push, route và iroute cho phiên bản của bạn.