VPN doanh nghiệp bên trong WireGuard: lớp nào đi trước?

Có hai lý do chính đáng để lồng đường hầm trên máy tính xách tay của lập trình viên. Hoặc ứng dụng khách doanh nghiệp phải trông như đến từ một quốc gia cụ thể, hoặc hai mạng riêng phải truy cập được cùng lúc. Cả hai trường hợp đều cần đường hầm bên ngoài mang kết nối của chính ứng dụng khách bên trong.

Khởi động hai ứng dụng khách theo bất kỳ thứ tự nào không tạo ra điều đó. Định tuyến mới tạo ra.

So sánh hai thứ tự khả dĩ

Chọn lớp ngoài là đường hầm có điểm cuối truy cập được từ internet công cộng. Lớp trong là đường hầm có máy chủ chỉ trả lời qua lối ra đó. Trên Windows, cách phân chia thực tế là WireGuard ở ngoài và ứng dụng khách doanh nghiệp ở trong. Yếu tố quyết định là khả năng kiểm soát.

Ứng dụng khách WireGuard chính thức áp dụng một tệp cấu hình đầy đủ, bao gồm tuyến và DNS. Các ứng dụng khách doanh nghiệp thương mại thường ẩn cả hai. Đặt một ứng dụng khách ẩn ở ngoài khiến bạn phải đoán về đường đi bên dưới.

Thứ tự ngược lại không phải là không thể. Chỉ khó lập luận hơn, vì ứng dụng khách bên ngoài ghi lại tuyến theo một lịch trình bạn không bao giờ thấy.

Hãy để AllowedIPs chỉ đặt tên cho dải doanh nghiệp

AllowedIPs liệt kê các đích mà WireGuard định tuyến vào đường hầm. Để lồng nhau, nó chỉ cần địa chỉ máy chủ bên trong và các tiền tố doanh nghiệp. Mọi thứ khác ở lại mạng cục bộ, kể cả máy in và hypervisor. Đây là đường hầm chia tách theo thiết kế, và nó tránh hoàn toàn vấn đề loại trừ.

Lớp ngoài dạng đường hầm đầy đủ cần 0.0.0.0/0 trừ các dải cục bộ. Định dạng không thể diễn đạt một loại trừ, nên phần bù phải được tính và dán vào.

[Interface]
PrivateKey = ...
Address = 10.99.4.2/32

[Peer]
PublicKey = ...
Endpoint = 198.51.100.44:51820
AllowedIPs = 198.51.100.44/32, 10.20.0.0/16, 10.21.0.0/16

Khi ứng dụng khách bên trong không tự cài tuyến, hãy tự liệt kê các tiền tố doanh nghiệp. Một tiền tố bị bỏ sót khỏi dòng đó là đích mà đường hầm bên ngoài không bao giờ mang. Một bản sao lỗi thời của danh sách còn tệ hơn không có, vì nó vẫn trông đúng.

Thứ tự, chỉ số và bộ điều hợp thứ hai

Kết nối đường hầm bên ngoài trước, sau đó khởi động ứng dụng khách doanh nghiệp. Khi đó kết nối điểm cuối của nó đi ra qua WireGuard thay vì cổng mặc định cục bộ. Gán cho giao diện doanh nghiệp chỉ số thấp hơn để các tiền tố của nó thắng cho những địa chỉ nó sở hữu.

# which interface currently claims the corporate prefix?
Find-NetRoute -RemoteIPAddress 10.20.10.5 | Select-Object -First 1

# prefer the corporate interface for its own prefixes
Set-NetIPInterface -InterfaceAlias 'Corp VPN' -InterfaceMetric 3
Set-NetIPInterface -InterfaceAlias 'wg-personal' -InterfaceMetric 40

wg show interfaces

Chỉ số là bước mà người ta bỏ qua. Không có thứ tự, tuyến được cài sau cùng sẽ thắng cho tiền tố chồng lấn. Điều đó thay đổi giữa các lần khởi động, nên vấn đề trông có vẻ gián đoạn.

Các ứng dụng khách xây trên OpenVPN 2.6 thêm một cái bẫy riêng. Khi bộ điều hợp dỡ tải kênh dữ liệu đã bận, phiên bản thứ hai đơn giản là từ chối khởi động. Thêm disable-dco vào hồ sơ sẽ quay lại đường TAP cũ, và khi đó cả hai chạy song song.

Nơi đường đi lồng nhau bị đứt

Ngắt đường hầm bên ngoài sẽ giết đường hầm bên trong. Kết nối lại chỉ ứng dụng khách bên trong thường đưa nó thẳng ra internet và âm thầm gỡ bỏ việc lồng nhau. Hãy thử trình tự từ đầu mỗi lần, với cả hai đường hầm đã dừng.

Hãy chờ một MTU hữu ích nhỏ hơn. Mỗi lớp thêm chi phí, nên một cặp khởi đầu khoảng 1420 và 1400 là điểm bắt đầu. Một lần truyền bị treo ở gói lớn trong khi các yêu cầu nhỏ thành công là dấu hiệu thường gặp. Chính sách doanh nghiệp là giới hạn khác, vì một ứng dụng khách đòi thiết bị được quản lý có thể coi đường đi lồng nhau là vi phạm.

Khi cả hai đầu là mạng cố định, một đường hầm site-to-site giữa các cổng sẽ loại bỏ vấn đề thứ tự thay vì quản lý nó. Trên một máy xách tay, hai đường hầm chỉ cùng tồn tại khi mỗi cái có giao diện riêng và một quy tắc chọn đích theo tiền tố.