Chuyển tiếp cổng và truy cập VPN: gói tin thực sự đi đâu

Hai thiết kế, một ứng dụng HTTPS, và gói tin đi theo con đường khác nhau trong mỗi thiết kế. Chuyển tiếp cổng thay đổi nơi gói tin được giao và để phần còn lại yên. VPN mang gói tin đó bên trong một gói tin khác trước, nên trình lắng nghe của ứng dụng thấy một nguồn khác và tải trọng tối đa nhỏ hơn. Việc mã hóa mà mọi người tranh luận có mặt trong cả hai trường hợp, vì ứng dụng vẫn là HTTPS; điều khác biệt là ai có thể mở kết nối và mạng ở giữa có thể quan sát được gì. Sự phân biệt đó giải quyết hầu hết các câu hỏi thực tế.

Quy tắc DNAT ghi lại đích đến và dừng ở đó

Trên một cổng Linux, công bố dịch vụ nghĩa là một quy tắc trong chuỗi PREROUTING của bảng nat, hoặc tương đương trong nftables. Quy tắc khớp địa chỉ và cổng công khai, rồi ghi lại đích đến thành địa chỉ riêng của ứng dụng. Địa chỉ nguồn, cổng nguồn và tải trọng không bị chạm tới, và conntrack ghi lại ánh xạ để các phản hồi được ghi lại khi đi ra. Hành vi này là mô hình dịch địa chỉ truyền thống được mô tả trong RFC 3022.

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

Trình lắng nghe của ứng dụng không bao giờ biết rằng kết nối đến qua một phép dịch. Nó thấy địa chỉ nguồn thật của máy khách, hữu ích cho nhật ký truy cập và giới hạn tốc độ, và nó trả lời tới địa chỉ riêng vì conntrack đảo ngược ánh xạ. Không có gì trên đường đó giải mã hay mã hóa lại: TLS vẫn chạy giữa máy khách và chứng thư của chính ứng dụng.

Quy tắc cũng quy định các chế độ lỗi mà bạn sẽ gặp sau này. Nếu cổng chuyển tiếp nhưng máy chủ của ứng dụng không có đường trở về máy khách, các phản hồi đi ra với nguồn sai và quá trình bắt tay bị kẹt. Nếu một quy tắc thứ hai khớp trước, thứ tự quyết định kết quả, và iptables -t nat -L -n -v hiển thị các bộ đếm chứng minh quy tắc nào đã lấy gói tin.

Đường hầm bọc gói tin trước khi trình lắng nghe thấy

VPN hoàn toàn không công bố ứng dụng. Máy khách dựng một gói tin bên ngoài hướng tới địa chỉ công khai của cổng, mã hóa gói tin bên trong vào trong đó, và cổng giải mã rồi định tuyến gói tin bên trong tới đích riêng. Với WireGuard, vận chuyển bên ngoài là UDP, thường trên một cổng cao; với OpenVPN trên TCP 443, gói tin bên ngoài trông như TLS với bất cứ thứ gì theo dõi đường đi.

Bên trong đường hầm, gói tin bên trong giữ địa chỉ riêng: địa chỉ đường hầm của máy khách, giả sử 10.8.0.6, và ứng dụng tại 10.20.30.40. Vì vậy trình lắng nghe thấy một nguồn từ nhóm đường hầm, và mỗi máy khách chia sẻ cổng đó làm bước nhảy tiếp theo. Nhật ký truy cập sau VPN thường hiển thị cổng thay vì người dùng chính vì lý do này, trừ khi cổng giữ nguyên nguồn gốc.

Việc bọc tốn không gian tiêu đề, và đó là khác biệt duy nhất ở mức cơ chế có hệ quả đo được. Một tiêu đề IP bên ngoài cộng UDP cộng tiêu đề riêng của WireGuard ăn vào MTU của đường đi, nên các gói lớn phải được phân mảnh hoặc ngăn xếp TCP bên trong phải giới hạn MSS của nó. Một lần truyền hoạt động trên đường đã chuyển tiếp có thể bị kẹt trên đường hầm khi một thiết bị trung gian bỏ ICMP lẽ ra báo MTU nhỏ hơn.

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Mức phơi nhiễm được quyết định ở lối vào, không phải ở mật mã

Cả hai thiết kế đều kết thúc tại cùng một trình lắng nghe TLS, nên cả hai thừa hưởng cùng chứng thư, cùng phiên bản giao thức và cùng đăng nhập ứng dụng. Điều thay đổi là ai được phép bắt đầu bắt tay. Với chuyển tiếp công khai, bất kỳ máy chủ nào chạm tới 203.0.113.10:443 đều nhận được bắt tay TCP và TLS ClientHello trước khi quyền truy cập của ứng dụng được xem xét. Với truy cập chỉ qua đường hầm, trình lắng nghe chỉ tiếp cận được từ các địa chỉ mà cổng định tuyến vào đường hầm, và SYN của người lạ chết tại chính sách của cổng.

Sự khác biệt đó là về khả năng tiếp cận, không phải về bí mật. Một dịch vụ HTTPS được chuyển tiếp không phải văn bản thuần, và VPN không loại bỏ nhu cầu xác thực ứng dụng: việc nhận vào đường hầm trả lời thiết bị có được gửi gói tin vào mạng này hay không, trong khi ứng dụng tệp trả lời người dùng có được đọc tài liệu hay không. Trộn lẫn hai điều đó là cách các nhóm kết thúc với một VPN trao toàn bộ LAN và một ứng dụng có một mật khẩu dùng chung.

Hãy kiểm tra trình lắng nghe và chính sách riêng rẽ, vì mỗi thứ đều có thể rộng hơn bạn nghĩ:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

Nếu ss cho thấy trình lắng nghe gắn với 0.0.0.0, ứng dụng tiếp cận được từ bất cứ đâu mà định tuyến và chính sách tường lửa cho phép, và chuyển tiếp chỉ là một trong các lối vào. Gắn với địa chỉ riêng, hoặc giới hạn dải nguồn trong tường lửa, là quyết định tách biệt với việc chọn VPN, và đó là quyết định thực sự thu hẹp mức phơi nhiễm.

Hãy đo đường đi, không đo nhãn

Khi ai đó cho rằng chuyển tiếp nhanh hơn, so sánh trung thực phải giữ mọi thứ khác cố định: cùng máy khách, cùng mạng truy cập, cùng tệp, cùng cấu hình TLS, cùng máy chủ ứng dụng. Chạy truyền hai lần cho mỗi đường đi và ghi lại tổng thời gian, số lần thất bại và khả năng phản hồi, không phải đầu ra của một bài kiểm tra tốc độ không liên quan.

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

Những con số đó tách việc thiết lập kết nối khỏi thời gian truyền, điều này quan trọng vì hai đường đi thường khác nhau ở độ trễ khứ hồi và MTU chứ không phải ở chi phí mật mã. Công việc TLS diễn ra tại các đầu mút trong cả hai thiết kế, và đường hầm thêm đóng gói, tuyến khác và có thể là một cổng bận hơn. Nếu đường hầm dài hơn hoặc cổng của nó quá tải, sự khác biệt thuộc về đường đi chứ không phải từ mã hóa.

Hãy chọn chính sách lối vào mà dịch vụ thực sự cần, rồi quyết định xem một khác biệt đo được có biện minh cho việc thay đổi nó không. Chuyển tiếp công khai phù hợp với dịch vụ dành cho internet mở, với giới hạn nguồn, TLS được cập nhật và giám sát phía trước. Truy cập chỉ qua đường hầm phù hợp với công cụ nội bộ mà người dùng đã được đăng ký, miễn là định tuyến của cổng và quyền của ứng dụng đều hẹp hơn toàn bộ LAN.

Trước khi tuyên bố thiết kế hoàn tất, hãy xác nhận bốn điều: trình lắng nghe gắn với địa chỉ nào, quy tắc hay tuyến nào nhận gói tin vào, đường trở về có hoạt động từ địa chỉ thật của máy khách không, và các tải trọng lớn có vượt qua MTU không. Mỗi điều đều có một lệnh ở trên, và không điều nào được trả lời bằng từ an toàn hay bằng biểu đồ băng thông.