Máy khách WireGuard không tới được máy khách OpenVPN?

Cả hai đường hầm đều kết nối, mỗi máy khách đều tới được cổng, và ngay khoảnh khắc một bên thử địa chỉ của bên kia thì các gói tin biến mất. Không có gì sai trong cả hai lần bắt tay, và việc cấp lại khóa không thay đổi điều đó. Cổng đang chuyển các gói IP thường không mã hóa giữa hai giao diện của chính nó, nên các giao thức không bao giờ cần hiểu nhau; điều chúng cần là ba thứ mà không lần bắt tay nào cung cấp. Độ phủ đích trên máy khách nguồn, quyền sở hữu nguồn tại cổng và một đường quay về ở phía xa. Triệu chứng giống nhau cho cả ba, vì vậy chúng được chẩn đoán cùng nhau.

Triệu chứng thiếu một mảnh mỗi lần

Thiết kế này dùng một pool WireGuard 10.71.0.0/24 trên wg1 và một pool OpenVPN 10.72.0.0/24 trên tun1, cả hai kết thúc tại một cổng duy nhất. Yêu cầu đang được kiểm thử đi từ 10.71.0.5 tới HTTPS trên 10.72.0.30. Mỗi bước dưới đây nói về đúng luồng duy nhất đó. Mỗi kiểm tra có chữ ký lỗi khác nhau dù người dùng trải nghiệm chúng như nhau, và thường chỉ thiếu một trong ba mỗi lần.

Bắt đầu bằng việc xác nhận cả hai pool thực sự nằm trên cổng này và chuyển tiếp đang bật trong không gian tên nơi các đường hầm sống. Một cổng kết thúc cả hai giao thức trong các không gian tên khác nhau thì không chuyển gì giữa chúng, và đáng để loại trừ điều đó trước khi đọc bất kỳ cấu hình peer nào.

Mở rộng độ phủ đích của nhánh

Trên máy khách WireGuard, mục peer hiện có phải chọn cổng cho đích OpenVPN, nghĩa là tiền tố đích phải xuất hiện trong danh sách được phép của peer đó. Thêm nó vào không tạo đường hầm thứ hai; nó thay đổi peer mà máy khách chọn khi tra địa chỉ đó, và với wg-quick tuyến thường tự động theo danh sách.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Để nguyên các dòng khóa và điểm cuối thật, và nhớ rằng trình quản lý dùng Table = off hoàn toàn không lấy tuyến nào từ danh sách này. Trong trường hợp đó cùng tiền tố phải được chủ sở hữu cài vào bảng tuyến của hệ thống, và một tuyến thiếu ở đó trông y hệt một tiền tố được phép bị thiếu.

Giữ quyền sở hữu nguồn tại cổng

Mục peer của máy khách này trên cổng phải tiếp tục sở hữu đúng địa chỉ nguồn của máy khách đó. Các địa chỉ được phép được kiểm tra theo cả hai chiều: chúng chọn peer cho lưu lượng đi ra và xác nhận rằng nguồn của gói đi vào thuộc về peer đã gửi nó. Đặt pool OpenVPN vào mục của nhánh vì nhánh muốn tới được nó chính là lỗi khiến lưu lượng đi về phía người tham gia sai.

AllowedIPs = 10.71.0.5/32

Hãy đọc mục đó như một tuyên bố sở hữu chứ không phải sự tiện lợi định tuyến. Mọi thứ khác mà máy khách phải tới thuộc danh sách đích của máy khách, không thuộc hình dung của cổng về việc peer này được phép gửi gì.

Cho phía OpenVPN một tuyến quay về

Đích giờ cần một tuyến quay lại nguồn WireGuard, và với máy khách trong pool thì nó thường đến dưới dạng tuyến được đẩy từ máy chủ OpenVPN. Chỉ đẩy nó cho những máy khách nên có, và xác nhận trên máy khách rằng nó đã được chấp nhận thay vì giả định rằng chỉ thị đã được áp dụng.

push "route 10.71.0.0 255.255.255.0"

Phân phối tuyến không phải là ủy quyền. Khi đích nằm sau một máy khách OpenVPN khác thay vì trong pool, quyền sở hữu LAN riêng của máy khách đó và các yêu cầu chuyển tiếp của nó tham gia vào thiết kế, và tuyến được đẩy chỉ là nửa đầu. Viết lại yêu cầu dưới dạng đồ thị trước khi thêm chỉ thị: nút nào sở hữu tiền tố nào, và nút nào chuyển tiếp về phía nó.

Chỉ cho phép đúng dịch vụ mà bạn định cho phép

Khi chuyển tiếp đã bật và cả hai pool đều định tuyến được, câu hỏi còn lại là chính sách. Viết quy tắc cho luồng cụ thể chứ không phải cho cặp giao diện nói chung, xem trước trước khi áp dụng, và giữ đường quay về có trạng thái để các phản hồi không bị chặn như kết nối mới. Một lần chạy khô không tốn gì và cho thấy chính xác điều gì sẽ được thêm.

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

Đây là các quy tắc cho lưu lượng được chuyển tiếp, tách biệt với quy tắc lắng nghe của cổng cho hai dịch vụ VPN. Mở các cổng UDP bên ngoài không ủy quyền cho yêu cầu bên trong, và ủy quyền cho yêu cầu bên trong không đòi hỏi SSH không giới hạn tới cổng hay một sự cho phép mặc định trên chuyển tiếp. Tường lửa của chính đích và địa chỉ lắng nghe cũng phải khớp, vì một dịch vụ gắn với loopback từ chối cả gói được định tuyến cẩn thận nhất. Một chính sách chỉ phủ một chiều của cuộc trò chuyện thường thất bại với yêu cầu thành công và phản hồi im lặng, đó là kết quả khó hiểu nhất trong ba.

Tuyến đối xứng thường có nghĩa là không cần dịch nguồn, điều này giữ địa chỉ WireGuard tại đích và làm nhật ký dễ đọc. Đừng thêm masquerading toàn bộ chỉ vì có hai giao thức tham gia, và đừng gỡ một quy tắc dịch hiện có mà không biết điều gì phụ thuộc vào nó. Sau đó xác minh luồng duy nhất từ đầu đến cuối, và thử cả một nguồn hoặc cổng bị cấm: một lần bắt tay chạy được ở mỗi bên không chứng minh tuyến chéo cũng không chứng minh cách ly.