Một cổng OpenVPN, ba dịch vụ: vì sao cổng bên trong quan trọng

Một phiên SSH, một ứng dụng web và một lần tra tên có thể dùng chung một kết nối VPN mà không tranh nhau cổng. Máy khách tạo một luồng mã hóa tới cổng vào, và mọi cuộc trò chuyện của ứng dụng đều đi bên trong nó. Bên ngoài chỉ thấy giao vận và cổng của chính đường hầm. Bên trong, mỗi dịch vụ giữ cổng riêng và vẫn cần quyền riêng.

Luồng bên ngoài mang gì, và che giấu gì

Máy khách bọc mọi gói tin trong giao vận của đường hầm trước khi nó rời máy. Luồng bên ngoài đó có một cổng đích, được cố định khi VPN được cấu hình. Bên trong lớp bọc, mỗi gói tin gốc giữ địa chỉ và cổng của dịch vụ mà nó nhắm tới. Cổng vào gỡ lớp bọc và định tuyến theo tiêu đề bên trong, nên đích thấy một máy khách bình thường đến từ mạng.

Vì thế bắt gói trên giao diện WAN chỉ cho thấy một cuộc trò chuyện, không phải ba. Các cổng bên trong chỉ xuất hiện sau khi gỡ gói. Đó là lý do một lỗ mở tường lửa có thể mang SSH, HTTPS và DNS cùng lúc.

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

Tài liệu TUN/TAP trình bày việc bàn giao trong đó một thiết bị TUN được định tuyến chuyển gói IP giữa nhân hệ điều hành và một tiến trình trong không gian người dùng. Chính việc bàn giao đó khiến tiêu đề bên trong hiện ra với mã định tuyến và tường lửa của cổng vào. Nó cũng giải thích vì sao cổng bên ngoài không nói gì về việc dịch vụ nào được phép.

Chuyển tiếp NAT thuộc về trình lắng nghe, không thuộc về ứng dụng

Một cổng vào tự lưu trữ sau NAT IPv4 cần một phép dịch vào: địa chỉ và cổng công khai được ánh xạ tới trình lắng nghe VPN. Không cần quy tắc nào cho SSH, HTTPS hay DNS chỉ vì người dùng đường hầm chạm tới chúng. Công bố những cổng đó sẽ phơi bày các dịch vụ mà đường hầm đã bảo vệ. Quy tắc chuyển tiếp mô tả khả năng tiếp cận của trình lắng nghe, không phải quyền cho bất cứ thứ gì bên trong.

Điều ngược lại cũng đúng. Mở cổng đường hầm không phơi bày gì khác, nên một dịch vụ chỉ tiếp cận được qua đường hầm vẫn giữ bề mặt công khai đóng. Sự tách biệt đó thường là lý do giữ dịch vụ ở chế độ riêng tư.

Chính sách bên trong là nơi quyền truy cập thực sự được quyết định

Mã hóa bảo vệ đường đi; nó không cấp quyền cho một đích. Các tuyến của máy khách chọn tiền tố nào đi vào đường hầm, chính sách chuyển tiếp của cổng vào quyết định gói tin có được rời đi hay không, còn tường lửa và đăng nhập của đích quyết định dịch vụ có trả lời hay không. DNS là trường hợp rõ nhất: mang theo truy vấn không làm cho trình phân giải chấp nhận chúng từ nhóm máy khách của bạn. Mỗi lớp đều có thể nói không một cách độc lập.

Kiểm tra từng dịch vụ riêng rẽ qua đường hầm. Một lần tra thành công không nói gì về cổng web, và một yêu cầu web thành công không nói gì về SSH.

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

Khi đường hầm đang hoạt động mà mọi thứ đều thất bại, hãy đọc bảng tuyến của máy khách trước. Khi một dịch vụ thất bại trong lúc các dịch vụ khác vẫn chạy, lỗi nằm ở đích đó. Hai quan sát đó chỉ tới những người phụ trách khác nhau, và trộn lẫn chúng sẽ lãng phí thời gian.

WireGuard vạch cùng một ranh giới

WireGuard đặt tên trình lắng nghe bên ngoài của nó là ListenPort, và một ứng dụng bên trong vẫn dùng cổng dịch vụ mà nó cần. AllowedIPs là một tập tiền tố được định tuyến, không phải danh sách cổng dịch vụ được phép. Đọc nó như danh sách cho phép cổng tạo ra các quy tắc không khớp với điều đường hầm làm. Cách đặt tên khác; cách phân lớp thì không.

Cho phép dịch vụ trong chính sách đầu vào cục bộ khi nó chạy trên chính điểm cuối, hoặc trong chính sách chuyển tiếp khi nó nằm sau điểm cuối đó. Sự phân biệt này quyết định tập quy tắc nào nhìn thấy gói tin.

Hình dạng tổng quát là một giao vận bên ngoài với nhiều cuộc trò chuyện bên trong. Những sản phẩm cần nhiều lần trao đổi bên ngoài, hoặc một giao thức IP khác, là lời nhắc rằng mô hình một cổng công khai mô tả thiết kế này chứ không phải mọi VPN.