Máy khách bridge của VMware mất mạng sau OpenVPN

Một máy khách từng được làm cầu nối và truy cập được một giờ trước giờ bị quá thời gian với mọi thứ, và không ai sửa cài đặt của nó. Trên máy chủ, internet vẫn hoạt động qua đường hầm. Hai sự thật đó cùng nhau chỉ ra khỏi VPN và hướng về hypervisor, vì máy chủ và máy khách không còn dùng cùng một đường đi. Chỉ một bộ điều hợp ảo mới là đủ để gây ra chuyện này.

Máy khách không đổi, cầu nối đã đổi

Cài đặt ứng dụng OpenVPN trên Windows sẽ thêm một bộ điều hợp mạng ảo mà dịch vụ gắn vào khi đường hầm được thiết lập. Với hệ điều hành, nó trông như một giao diện thông thường với trạng thái liên kết và thường có địa chỉ riêng. Thế là đủ để VMware coi nó là ứng viên cầu nối.

VMnet0 mặc định được đặt thành Tự động, nghĩa là hypervisor chọn một bộ điều hợp máy chủ mỗi khi nó làm cầu nối. Một bộ điều hợp ảo vừa cài sẽ gia nhập nhóm đó, và nếu nó được chọn, mọi khung mà máy khách phát ra đều đi tới một thiết bị đường hầm thay vì cổng vật lý của switch.

Ghim cầu nối hoặc định tuyến máy khách

Nhánh thứ nhất là đúng khi máy khách phải là một thành viên ngang hàng trên LAN vật lý: đừng để cầu nối tự chọn nữa, và nêu tên bộ điều hợp một cách rõ ràng. Nhánh thứ hai áp dụng khi máy khách phải dùng đường hầm của doanh nghiệp, và trong trường hợp đó cầu nối chưa bao giờ là thiết kế đúng, vì máy khách đã làm cầu nối không thừa hưởng tuyến VPN của máy chủ.

Hãy quyết định điều đó trước, vì hai câu trả lời dẫn tới công việc khác nhau. Đảo ngược thứ tự sẽ tạo ra một cầu nối được ghim đúng nhưng gắn vào máy khách lẽ ra không bao giờ nên làm cầu nối.

Với nhánh thứ nhất, mở Virtual Network Editor trên máy chủ, chọn VMnet0 và thay Tự động bằng bộ điều hợp vật lý. Nếu có nhiều bộ điều hợp, dùng danh sách cài đặt tự động và bỏ chọn mọi thứ không bao giờ được mang lưu lượng của máy khách: thiết bị OpenVPN TAP hoặc Wintun, cùng các bộ điều hợp Hyper-V, WSL, Docker và loopback. Giữ chọn cả bộ điều hợp vật lý có dây và không dây trên máy tính xách tay, nếu không máy khách sẽ mất cầu nối vào lần tới khi người dùng đặt nó vào đế.

Ba điều kiện quyết định lựa chọn

Việc một cầu nối có phù hợp hay không phụ thuộc vào mục đích của máy khách. Nếu máy khách phải xuất hiện như một máy chủ riêng trên LAN, với địa chỉ riêng và khả năng truy cập vào riêng, thì cầu nối là mô hình đúng và việc ghim là toàn bộ cách sửa. Nếu máy khách chỉ cần truy cập ra ngoài, mạng chỉ dành cho máy chủ hoặc NAT đơn giản hơn và không bị ảnh hưởng khi bộ điều hợp thay đổi.

Nếu máy khách phải dùng cùng đường hầm với máy chủ, cả chế độ cầu nối lẫn bộ điều hợp được ghim đều không giúp gì, vì lưu lượng của máy khách không bao giờ đi vào quyết định định tuyến của máy chủ. Trường hợp đó cần một đường được định tuyến hoặc chuyển đổi trên máy chủ, và việc chọn bộ điều hợp trở nên không còn quan trọng.

VMware Player không có trình chỉnh sửa mạng trong giao diện, nên máy chủ chỉ chạy Player cần trình chỉnh sửa độc lập hoặc bản cài Workstation để tới được các cài đặt này. Ràng buộc đó đôi khi tự nó quyết định cách tiếp cận.

Đọc kết quả từ bên trong máy khách

Khởi động lại NIC ảo, hoặc khởi động lại máy khách, để nó yêu cầu lại một bản thuê. Sau đó đọc những gì nó thực sự nhận được, chứ không phải những gì máy chủ tưởng là đã cấu hình.

ipconfig /all
ip addr
ip route

Đọc hai trường trong đầu ra đó và bỏ qua phần còn lại lúc này. Cổng mặc định phải là bộ định tuyến của LAN, và phần mô tả bộ điều hợp phải nêu thiết bị Ethernet của VMware chứ không phải một đường hầm. Một địa chỉ tự gán trong 169.254.0.0/16 nghĩa là không có máy chủ DHCP nào trả lời, và đó chính là hình dạng của một cầu nối trên bộ điều hợp đường hầm nhìn từ phía máy khách.

Còn một điểm phân biệt nữa đáng làm trước khi thay đổi bất cứ điều gì khác. Một máy khách tới được bộ định tuyến nhưng không tới internet là có cầu nối hoạt động và một vấn đề ở phía trên. Một máy khách nhận được địa chỉ trong dải đường hầm thì vẫn gắn vào thiết bị sai. Tắt bộ điều hợp TAP không phải là cách sửa cho cả hai trường hợp, vì dịch vụ OpenVPN cần nó.