VPN site-to-site hay truy cập từ xa: mỗi loại kết nối điều gì
Một loại kết nối các cổng, loại kia kết nối thiết bị. So sánh bộ chọn lưu lượng với tuyến đường, quy hoạch địa chỉ, rồi kiểm tra chuyển tiếp và chính sách từ một máy chủ thật.
Cả hai thiết kế đều được gọi là VPN và giải quyết những vấn đề khác nhau. Đường hầm site-to-site nối hai cổng, nhờ đó mọi máy chủ phía sau đều có thể chạm tới các địa chỉ được phép ở phía bên kia mà không cần cài đặt gì. Đường hầm truy cập từ xa nối từng thiết bị vào một mạng, mỗi lần một máy khách. Việc so sánh có ý nghĩa vì phần lớn lỗi triển khai đến từ việc cấu hình một thiết kế trong khi chờ hành vi của thiết kế kia, và triệu chứng thường là hết thời gian chờ ở một dịch vụ mà đường hầm thực sự đã tới được.
Hai thiết kế, hai ranh giới
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
Không thiết kế nào mở rộng miền quảng bá LAN. Các thiết bị ở phía xa không xuất hiện trong danh sách khám phá cục bộ, và chờ đợi điều đó là giả định đầu tiên cần bỏ. Các tên DNS riêng mà bạn chủ động công bố dễ đoán hơn bất kỳ giao thức khám phá nào, và vẫn tồn tại khi đổi nhà cung cấp.
Hãy dùng 10.10.0.0/24 ở một site và 10.20.0.0/24 ở site kia. Cổng A cần một tuyến đường hoặc bộ chọn lưu lượng gửi tiền tố 10.20.0.0/24 vào đường hầm, và cổng B cần hình ảnh gương của nó. Sau đó máy chủ hai bên dùng kết nối IP thông thường và không bao giờ biết có đường hầm. Sự vô hình đó chính là tính năng, và cũng là lý do các sự cố trông như lỗi mạng thông thường chứ không phải lỗi đường hầm.
Dựa trên chính sách và dựa trên tuyến đường không phải cùng một đường hầm
Trong triển khai IPsec dựa trên chính sách, các bộ chọn lưu lượng đã thương lượng xác định chính xác cặp nguồn và đích nào được bảo vệ. Nếu một mạng con mới xuất hiện sau một cổng và không bộ chọn nào bao phủ nó, đường hầm vẫn hoạt động và mạng con mới đơn giản là không được chuyển. Trong thiết kế dựa trên tuyến đường, giao diện nhận lưu lượng và bảng định tuyến quyết định, khiến việc thêm tiền tố trở thành thay đổi tuyến đường chứ không phải thương lượng lại đường hầm.
StrongSwan hiển thị trực tiếp cả hai góc nhìn, và đọc chúng cùng nhau là cách để biết bạn thực sự đã triển khai mô hình nào.
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'Danh sách bộ chọn thiếu tiền tố bạn cần giải thích sự cố mà không cần bắt gói tin nào, và một tuyến đường trỏ sai giao diện giải thích sự cố gương trên đường về. Hãy đọc cả hai trước khi thương lượng lại bất cứ điều gì, vì việc làm mới khóa sẽ không thêm bộ chọn mà bạn chưa từng cấu hình.
Quy hoạch địa chỉ trước khi có đường hầm
Các dải chồng lấn là lỗi thiết kế không thể sửa bằng cấu hình. Nếu cả hai site dùng 192.168.1.0/24, một máy chủ cần 192.168.1.50 có hai ứng viên và không có cách nào chọn. Đường hầm sẽ xác thực, các liên kết bảo mật sẽ được thiết lập, và quyết định định tuyến vẫn sai hoặc mơ hồ.
Chọn một trong ba phương án trung thực: đánh số lại một site, chuyển dịch dải chồng lấn tại cổng để mỗi bên thấy một tiền tố riêng, hoặc bỏ định tuyến trực tiếp cho các máy chủ đó và công bố dịch vụ theo cách khác. Mỗi phương án đều có chi phí, và phương án đầu thường rẻ nhất trong tầm hai năm. Hãy quyết định trước khi đường hầm tồn tại, vì về sau thay đổi sẽ chạm tới mọi thiết bị còn địa chỉ cũ.
Cũng giải quyết sớm vấn đề MTU. Đường hầm làm giảm tải trọng hữu ích, và thiết kế dựa vào phân mảnh hành xử khác với thiết kế cố định MSS tại các cổng.
Chuyển tiếp và chính sách nằm ngoài đường hầm
Cổng phải sẵn sàng chuyển tiếp gói giữa giao diện đường hầm và giao diện LAN, và cả hai chiều đều cần chính sách cho phép dịch vụ. Trên Linux đây là hai thiết lập riêng biệt, cùng với các quy tắc tường lửa quyết định luồng được chuyển tiếp có được phép hay không.
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPTMáy chủ nhận thêm một tầng thứ ba: tường lửa của chính nó vẫn phải chấp nhận một máy khách từ mạng con xa. Một máy chủ tệp chỉ cho phép /24 cục bộ của mình sẽ từ chối lưu lượng được chuyển tiếp từ 10.20.0.7, dù đường hầm trông khỏe đến đâu, và sự từ chối đó dễ bị đọc nhầm thành lỗi định tuyến.
Hãy kiểm tra từ máy chủ, không phải từ cổng
Một ping do chính cổng gửi đi có thể đi theo địa chỉ nguồn và chính sách khác với lưu lượng người dùng được chuyển tiếp. Điều đó khiến nó thành phép thử yếu và đôi khi gây nhầm lẫn: nó thành công khi ứng dụng lỗi, hoặc lỗi khi ứng dụng hoạt động.
ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/nullDùng một máy chủ thật, địa chỉ nguồn thật và giao thức thật mà ứng dụng sử dụng. Sau đó đọc riêng đường quay về, vì chiều đi hoạt động mà không có tuyến về sẽ tạo ra hết thời gian chờ giống hệt một dịch vụ bị chặn.
Chọn thiết kế theo câu hỏi bạn đang trả lời: bạn đang nối các mạng hay đang tiếp nhận thiết bị? Mọi thứ còn lại, kể cả việc bạn cấu hình nhà cung cấp nào, đều suy ra từ câu trả lời đó.