Vì sao VPN khách của bạn thất bại sau NAT của VirtualBox?

Trình duyệt bên trong máy ảo hoạt động, còn ứng dụng khách VPN trên cùng khách đó không mang được dữ liệu. Khách rõ ràng có kết nối, nên lỗi nằm ở thứ giao thức bên ngoài của VPN cần và thứ NAT ảo sẽ cho qua. Ba điều kiện quyết định kết quả: tiến trình nào sở hữu VPN, trao đổi bên ngoài trông thế nào trên đường dây, và chế độ bộ điều hợp có đúng là thứ bạn nghĩ không. Gọi tên điều kiện bạn có thể thay đổi chính là toàn bộ quyết định.

Tìm tiến trình VPN trước khi đổ lỗi cho mạng

Trước hết hãy quyết định VPN chạy trong khách hay trên máy chủ, vì hai cách bố trí thất bại khác nhau. Một ứng dụng khách bên trong khách tự dựng kết nối bên ngoài qua bộ điều hợp của khách và mọi bản dịch nằm sau nó. VPN trên máy chủ bắt lưu lượng của khách theo chính sách của máy chủ và hypervisor, đây là một điểm bắt riêng với các quy tắc riêng. Chúng có thể chạy cùng lúc và làm nhiễu bằng chứng, nên hãy xác định cái nào phải mang lưu lượng này trước khi chạm vào bất kỳ cái nào.

Ghi lại chế độ bộ điều hợp của khách ngay bây giờ, trước khi thay đổi bất cứ điều gì. Giá trị duy nhất đó giải thích phần lớn những gì tiếp theo, và đó là điều đầu tiên bất kỳ ai sẽ hỏi bạn sau này.

Trao đổi bên ngoài quyết định tính tương thích

Hướng dẫn mạng của VirtualBox liệt kê các hạn chế của NAT có ý nghĩa ở đây: nó không cho qua giao thức nào khác ngoài TCP và UDP, GRE được nêu là không được hỗ trợ, và PPTP được đưa làm ví dụ bị ảnh hưởng. PPTP dùng trao đổi điều khiển TCP và GRE cho dữ liệu, nên kết nối điều khiển có thể thành công trong khi đường dữ liệu không thể vượt cùng ranh giới đó. Đó là hai bằng chứng khác nhau, và chỉ một trong hai nói về việc mang lưu lượng. Cho phép cổng TCP 47 trong một quy tắc tường lửa không giống với cho phép giao thức IP 47, và hai thứ đó liên tục bị nhầm lẫn.

Hãy giữ hạn chế gắn với cách bố trí NAT này chứ không phải với mọi thiết bị dùng từ NAT. Một bộ định tuyến vật lý có thể cho GRE qua mà không phàn nàn trong khi NAT ảo bỏ nó, và một hypervisor khác tự chọn thứ nó chuyển tiếp. Ở nơi tổ chức cung cấp một phương thức vận chuyển đã được phê duyệt trong TCP hoặc UDP, hãy dùng ứng dụng khách và hồ sơ được hỗ trợ cho đường đó. Tính tương thích là một yêu cầu trong nhiều yêu cầu, và nó không thiết lập niềm tin vào máy chủ, quyền của tài khoản hay các tuyến riêng hoạt động.

Cầu nối thực sự thay đổi điều gì

Một cầu nối giao địa chỉ MAC của khách cho phân đoạn vật lý thay vì giấu nó sau bản dịch. Sau đó khách lấy địa chỉ từ bất kỳ máy chủ DHCP nào phục vụ phân đoạn đó, trả lời ARP cho địa chỉ đó, và xuất hiện trước bộ chuyển mạch thượng nguồn như thêm một cổng nữa. Điều đó loại bỏ đường dịch ảo, đây chính là lý do một công thức cũ khuyên dùng nó, và nó thay đổi ba thứ khác cùng lúc. Việc định địa chỉ giờ đến từ phân đoạn cục bộ chứ không từ hypervisor, việc lộ diện nghĩa là khách hiện ra với phân đoạn đó, và việc chấp nhận phụ thuộc vào cổng chuyển mạch và chính sách của nó. Mỗi điều đó đều có thể là lý do từ chối thay đổi, và không điều nào nói về giao thức VPN.

Việc bắc cầu không cài một plugin thiếu, không cung cấp một tác nhân bí mật không sẵn có và không sửa một lần từ chối xác thực. Nó cũng không biến một giao thức lỗi thời thành lựa chọn tốt, và ở nơi nhà vận hành có bản thay thế được duy trì, đó là quyết định chứ không phải đổi hypervisor. Chuyển tiếp cổng là một vai trò thứ ba hoàn toàn: nó công bố một dịch vụ vào và không làm gì cho giao thức bên ngoài của một ứng dụng khách ra.

Hai đường hầm, hai dấu vết bằng chứng

VPN khách cần một đường dùng được từ giao diện của khách đến đối tác của nó trước khi bất kỳ địa chỉ bên trong hay tuyến riêng nào có ý nghĩa. Ở nơi có VPN trên máy chủ, nó có thể chuyển tiếp hoặc chặn trao đổi bên ngoài đó theo chính sách riêng, và đường hầm bên trong của khách chỉ bắt đầu sau khi đường bên ngoài thành công. Không tầng nào có thể đọc phạm vi phủ từ một biểu tượng đã kết nối hay từ địa chỉ công khai của trình duyệt trên máy chủ.

Giữ thông báo lỗi đầu tiên chứ không phải thông báo cuối, vì lần thất bại sớm nhất gọi tên tầng. Thay đổi một cách bố trí mạng được hỗ trợ mỗi lần, với cùng hồ sơ khách và cùng thông tin đăng nhập, để so sánh có ý nghĩa. Từ lỗi hãy quyết định giai đoạn nào đã gãy: tích hợp cục bộ, vận chuyển, xác thực hay truy cập tài nguyên sau khi đường hầm lên. Mỗi giai đoạn có chủ khác nhau, và chỉ một là câu hỏi về hypervisor.

Điều kiện nào thực sự chặn bạn

Giờ quyết định thu hẹp còn ba câu hỏi với câu trả lời khác nhau. Nếu giao thức bên ngoài nằm ngoài TCP và UDP, chế độ NAT là ràng buộc, và đường tiến là cầu nối hoặc một phương thức vận chuyển TCP/UDP đã được phê duyệt. Nếu trao đổi bên ngoài hoàn tất mà đường dữ liệu thì không, ràng buộc là điều đã thấy ở bằng chứng thứ hai. Nếu đường hầm lên mà tài nguyên không trả lời, vấn đề đã vượt qua hypervisor sang định tuyến hoặc chính sách.

Viết câu trả lời kèm chế độ bộ điều hợp bên cạnh, nếu không người tiếp theo sẽ lặp lại đúng buổi chiều đó. Sau mỗi lần sửa hãy kiểm tra ứng dụng thật và việc phân giải tên bên trong khách, rồi kết nối lại và thử chính sách thất bại. Một trang web chạy qua đường hầm chỉ chứng minh đường web hoạt động, đó là một tuyên bố nhỏ hơn cảm giác vào lúc đó.