VirtualBox NAT hay bridge: VPN của VM kết thúc ở đâu

Hai câu hỏi khác nhau cùng xuất hiện mỗi khi một máy ảo chạy ứng dụng VPN, và câu trả lời của chúng khác nhau. Câu thứ nhất là liệu đường hầm bên trong khách có bảo vệ máy chủ hay không, câu thứ hai là liệu đường hầm trên máy chủ có bao phủ khách hay không. Chế độ adapter quyết định cả hai, hơn cả bản thân phần mềm VPN. Adapter NAT biến máy chủ thành đầu cuối nhìn thấy được, còn adapter bridge đặt khách lên mạng với địa chỉ riêng của nó.

Ai thực sự kết thúc phiên được mã hoá

Một phiên được mã hoá thuộc về máy kết thúc nó, và đó là khách khi ứng dụng chạy bên trong VM. Chỉ lưu lượng đi vào adapter ảo của khách mới đi qua đường hầm đó, và hypervisor không bao giờ tự mình định tuyến một máy khác qua khách. Vì thế khách có thể giữ một đường hầm hoạt động trong khi máy chủ duyệt web công khai. Chiều ngược lại không đối xứng, và chính sự bất đối xứng đó là phần mà hầu hết hướng dẫn hiểu sai.

Mạng bên ngoài nhìn thấy địa chỉ của ai là câu hỏi mà chế độ adapter trả lời. Khi điều đó đã rõ, phạm vi bao phủ không còn là câu hỏi chính sách mà trở thành câu hỏi kỹ thuật. Mọi thứ bên dưới đều bắt nguồn từ hai sự thật đó.

NAT viết lại khách cho đến khi nó giống máy chủ

Với NAT, hypervisor viết lại mọi gói của khách sang địa chỉ của máy chủ trước khi gói đó tới switch đầu tiên. Lưu lượng đó sau đó được giao cho chồng giao thức mạng của chính máy chủ, tại đó nó theo bảng định tuyến của máy chủ, kể cả tuyến mặc định do một đường hầm trên máy chủ sở hữu. Vì vậy một khách NAT được bao phủ bởi đường hầm trên máy chủ mà không cần cấu hình gì, điều này ngược với những gì trường hợp từ khách sang máy chủ gợi ý.

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

Khách chạy ứng dụng riêng của mình sẽ kết thúc đường hầm đó bên trong khách, và lưu lượng được mã hoá thoát ra qua cùng phép viết lại, nên các ứng dụng trên máy chủ giữ đường đi riêng và địa chỉ ra riêng. VirtualBox cũng sở hữu việc phân giải tên trong chế độ này, chuyển truy vấn của khách qua công cụ của chính nó trừ khi --natdnshostresolver1 được bật. Bật nó sẽ giao việc tra cứu của khách cho bộ phân giải của máy chủ, điều này sửa phân giải khi góc nhìn của chính máy chủ là đúng và đồng thời cũng giao một bộ phân giải có thể chỉ tồn tại bên trong đường hầm. Phải tắt VM trước khi thay đổi thiết lập, và thiết lập thuộc về adapter chứ không phải phần mềm của khách.

Bridge cho khách quyền thuê và mức phơi bày riêng

Bridge chuyển khung của khách sang đoạn mạng vật lý, nên DHCP cấp cho nó một quyền thuê và mạng coi nó là một máy chủ riêng. Mỗi khách được bridge có thể giữ một đường hầm độc lập với tuyến mặc định riêng, và bảng của máy chủ không bao giờ thay đổi. Cái giá là mức phơi bày: khách trả lời các gói quảng bá, xuất hiện trong bảng lân cận, và chịu sự chi phối của bảo mật cổng switch và cách ly máy khách không dây. Một đường hầm trên máy chủ cũng không bao phủ cách bố trí này, vì khung của khách không bao giờ đi qua chồng giao thức của máy chủ.

Sự khác biệt đó so với trường hợp NAT đáng được nói thẳng ra thay vì để lại như một hàm ý. Một khách được bridge cần ứng dụng riêng và thông tin xác thực riêng mỗi khi lưu lượng của nó phải dùng đường hầm. Ở nơi khách phải vô hình với mạng cục bộ, NAT hoặc một mạng chỉ nội bộ với định tuyến được kiểm soát là thiết kế tốt hơn.

Vì sao khách không thể là cổng của máy chủ

Cho máy chủ vay đường hầm của khách không có công tắc nào được hỗ trợ trong cả hai hypervisor lớn. Máy chủ không có tuyến vào đường hầm của khách và không có quy tắc dịch nào trỏ tới đó, nên lưu lượng của khách và của máy chủ vẫn là hai dòng riêng với chủ sở hữu riêng. Hướng đó thất bại bất kể chế độ adapter.

Các phương án thay thế khả thi là chuyển tiếp và proxy. Chuyển tiếp cục bộ SSH cho phép máy chủ kết nối tới loopback của chính nó trong khi khách mang dòng vào đường hầm, điều này bao phủ các dịch vụ TCP mà không cần cài ứng dụng thứ hai. Bắt lưu lượng IP của chính máy chủ dùng đường hầm của khách thay vào đó đòi hỏi một bộ định tuyến bên trong khách, cùng một tuyến rõ ràng trên máy chủ và phép dịch trên máy chủ. Đó là một thiết kế mạng nhỏ chứ không phải một ô đánh dấu, và nó cần một kế hoạch cho đường về. Khi khách chỉ tồn tại để chạy ứng dụng, hãy đặt ứng dụng trên máy chủ và bỏ bước nhảy thừa.

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

Bộ phân giải và tuyến không vượt qua ranh giới

DNS đi theo adapter đã nhận tuỳ chọn, nên khách không thừa hưởng bộ phân giải của đường hầm trên máy chủ và máy chủ không bao giờ biết máy chủ tên bị đẩy xuống khách. Các giá trị dhcp-option DNS bị đẩy áp dụng cho giao diện đã chấp nhận chúng, và đó là lý do một khách được bridge không có ứng dụng không thể phân giải tên nội bộ. Khách NAT thường dùng cách xử lý DNS của hypervisor, và sự khác biệt hiện ra trong một lệnh cho mỗi môi trường.

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

Hãy đọc bộ phân giải và tuyến bên trong khách trước khi cho rằng một trong hai đi theo máy chủ. Thêm bộ phân giải của đường hầm vào adapter riêng của khách khi tên nội bộ phải được phân giải ở đó, rồi kiểm tra bằng một tên chỉ tồn tại phía sau đường hầm. Ghi lại chế độ adapter, chủ sở hữu đường hầm và nguồn của bộ phân giải cho từng VM, vì ba sự thật đó trả lời gần như mọi câu hỏi về sau. Các hypervisor khác đổi tên các chế độ và giữ nguyên nguyên lý.