Mạng VM kiểu NAT hay bridged: kiểu nào chở lưu lượng VPN?
Khách NAT chỉ mượn đường hầm của máy chủ khi ứng dụng khách tạo đường hầm theo tuyến; khách bridged tự định tuyến. Hãy kiểm tra khách rồi chọn chế độ phù hợp.
Bridged và NAT không phải hai cách gắn cùng một khách vào VPN của bạn; chúng quyết định ai sở hữu các gói của khách trước khi bất kỳ đường hầm nào xuất hiện. Ở chế độ NAT, hypervisor viết lại lưu lượng của khách và phát ra từ mã phía máy chủ, nên khách đi theo bất kỳ tuyến nào máy chủ trao cho mã đó. Ở chế độ bridged, khách có danh tính tầng liên kết riêng trên phân đoạn vật lý và tự chọn cổng mặc định, khiến đường hầm của máy chủ trở nên không liên quan với nó, trừ khi chính router LAN là bên tạo đường hầm. Tôi ngừng coi VM là thứ nằm trên VPN và bắt đầu coi đó là câu hỏi tuyến mặc định của khách trỏ về đâu. Bài kiểm tra dưới đây mất vài phút mỗi chế độ và giải quyết chuyện này mà không cần đoán.
NAT giữ khách sau mã của hypervisor, nơi các tuyến của máy chủ có hiệu lực
Trong VirtualBox, khách NAT nằm ở 10.0.2.0/24 với cổng ảo tại 10.0.2.2, proxy DNS tại 10.0.2.3 và không có tuyến riêng tới mạng vật lý. Các gói đi ra được công cụ NAT bắt lấy, viết lại để nguồn là máy chủ rồi chuyển cho ngăn xếp IP của máy chủ. Từ đó lưu lượng của khách là một luồng của máy chủ, và việc tra tuyến dựa theo đích: một ứng dụng khách tạo đường hầm toàn phần đặt 0.0.0.0/1 và 128.0.0.0/1 trên máy chủ sẽ bắt được nó mà không hề biết có một VM. Chương về mạng của VirtualBox do Oracle viết liệt kê các giá trị mặc định này nếu bạn muốn xác nhận địa chỉ trên bản dựng của mình.
Mạng mặc định của libvirt cũng tới cùng chỗ từ 192.168.122.0/24, nơi dnsmasq cấp hợp đồng thuê và máy chủ ánh xạ địa chỉ cho mạng con, nên gói của khách lại tới quyết định định tuyến của máy chủ. Ngoại lệ là ứng dụng khách chọn lưu lượng theo tiến trình thay vì theo tuyến. Nếu danh sách đường hầm tách chỉ có trình duyệt của bạn, công cụ NAT không nằm trong danh sách đó, và khách rời máy mà không có đường hầm trong khi trình duyệt trên máy chủ vẫn trông như được che. Cùng một mạng con, kết quả ngược lại.
Bridged trao cho khách chỗ đứng riêng trên LAN vật lý
Khách bridged được cấp một NIC ảo gắn vào bộ điều hợp thật, có địa chỉ MAC riêng và nhận hợp đồng thuê DHCP từ mạng vật lý. Cổng mặc định của nó là router LAN chứ không phải hypervisor, và các khung của nó đi ra dây qua bộ điều hợp đó. Các tuyến đường hầm của máy chủ nằm trong bảng của máy chủ và không bao giờ được tra tới, vì khung của khách không bao giờ vào ngăn xếp IP của máy chủ.
Điều đó cắt cả hai chiều. Duyệt mDNS và SMB bắt đầu hoạt động vì khách thấy lưu lượng quảng bá của LAN, và khách trở nên truy cập được từ máy khác trong cùng phân đoạn mà không có tường lửa của máy chủ ở giữa. Bridging cũng không phải cách đẩy khách qua một đường hầm sẵn có: gắn VM vào giao diện WireGuard hay OpenVPN của máy chủ không phải việc VirtualBox hay libvirt làm thay bạn. Nếu khách bridged buộc phải được tạo đường hầm, đường hầm phải kết thúc ở đâu đó trên LAN ấy.
Bài kiểm tra kết thúc cuộc tranh luận
Chạy cùng các kiểm tra ở cả hai chế độ và ghi lại câu trả lời:
- Trên máy chủ,
curl -s https://ifconfig.mecho địa chỉ công khai v4. - Trong khách, cùng lệnh đó, cộng thêm
ip routetrên Linux hoặcGet-NetRoute -DestinationPrefix 0.0.0.0/0trên Windows cho cổng mặc định. - Danh tính trình phân giải:
resolvectl statushoặccat /etc/resolv.conftrong khách, để xem nó trỏ tới 10.0.2.3 hay một máy chủ trong LAN. - Họ địa chỉ:
ip -6 addr show scope globalvà một yêu cầu v6, vì đường hầm v4 không nói gì về địa chỉ v6 toàn cầu mà khách có thể có.
Địa chỉ công khai trùng nhau nghĩa là khách đi trên đường của máy chủ. Địa chỉ của khách trùng với lối ra thông thường của LAN nghĩa là không. Bước mà người ta hay bỏ qua là phép đối chứng: hạ đường hầm của máy chủ xuống rồi lặp lại yêu cầu từ khách. Nếu khách vẫn duyệt được, nó chưa bao giờ phụ thuộc vào đường hầm của máy chủ, bất kể tên chế độ nói gì. Ở chế độ NAT, khách phải mất internet khi đường hầm của máy chủ bị hạ, trừ khi ứng dụng khách được cấu hình cho phép lưu lượng ngoài đường hầm, điều này tự nó đáng để biết.
Hai dấu hiệu đánh lừa. Một ping thành công chứng minh khả năng tới được, không phải đường ra. Và DNS có thể được proxy 10.0.2.3 trả lời qua trình phân giải của máy chủ trong khi TCP đi tuyến khác, đó là cách bạn có một trang tải được và một lần đăng nhập không bao giờ hoàn tất.
Chế độ nào hợp với công việc
Chế độ là một quyết định định tuyến, nên chọn theo yêu cầu chứ không theo thói quen:
| Requirement | Mode that fits |
|---|---|
| Every guest flow must exit through the host tunnel | NAT, with a host client that tunnels by route, verified from inside the guest |
| The guest needs its own VPN account or profile | Bridged, or NAT with a client running inside the guest, not both |
| The guest must serve SSH, SMB, or a dev server to the LAN | Bridged; NAT needs a port forward, which does not change the outbound path |
| The guest must stay invisible to the LAN | NAT; a bridged guest is another host on the segment |
| The guest needs a real public IPv6 address | Bridged; VirtualBox NAT mode has no IPv6 forwarding |
| Isolation from the LAN with access to the host | Host-only adapter, not NAT |
Hàng đầu là chỗ người ta sập bẫy: NAT cộng với ứng dụng khách tạo đường hầm toàn phần trên máy chủ thật sự che được khách, nhưng chỉ khi ứng dụng khách tạo đường hầm theo tuyến và đường lên của máy chủ chính là đường hầm đó. Chuyển ứng dụng khách sang danh sách chỉ cho phép trình duyệt là lớp che biến mất mà chẳng có lỗi nào ở đâu cả. Hàng thứ tư là lỗi ngược lại, một khách được bridged cho tiện rồi lặng lẽ bắt đầu trả lời SMB hay SSH trên LAN của văn phòng.
Những hỏng hóc bị đổ cho VPN
Trên Windows, việc dịch NAT chạy trong tiến trình VM của VirtualBox, nên ứng dụng khách theo từng ứng dụng cần đúng ảnh đó trong danh sách chứ không phải một quy tắc chung cho máy ảo. Khi bản cập nhật ứng dụng khách dựng lại danh sách tiến trình được phép, khách NAT mất lớp che trước tiên, và báo cáo đọc như một VM tới được LAN nhưng không tới internet trong khi máy chủ vẫn ổn.
Bridging sang Wi-Fi là ca kinh điển khác. Điểm truy cập hiếm khi chuyển tiếp các khung mang MAC nguồn lạ, nên một cầu nối lên wlan0 hoặc thất bại ngay, hoặc chạy được cho tới khi tính năng cách ly máy khách trên AP bắt đầu bỏ nó. VirtualBox vẫn sẽ đưa bộ điều hợp không dây vào danh sách. Nếu máy chủ ở trên Wi-Fi và khách buộc phải bridged, hãy lên kế hoạch kiểm tra thay vì giả định.
MTU là cái thứ ba. Khách bridged giữ MTU 1500 byte của LAN, và nếu nó chạy ứng dụng khách WireGuard riêng ở 1420 thì các bắt tay TLS lớn bị kẹt trong khi yêu cầu nhỏ vẫn qua. Dưới NAT, MTU của đường hầm máy chủ là chuyện của máy chủ, nhưng khách vẫn tin vào 1500, và UDP có bật bit don't-fragment cũng rơi vào hố đen y như vậy.
Ghi lại chế độ rồi kiểm tra lại sau mỗi lần đổi bộ điều hợp
Ghi lại chế độ, giao diện máy chủ mà cầu nối dùng, cổng mặc định của khách, trình phân giải của nó và địa chỉ ra v4 lẫn v6. Chính bản ghi đó làm cho sự cố sau rẻ đi: khi laptop chuyển từ dock sang Wi-Fi, khách bridged đi theo cầu nối sang bộ điều hợp vật lý khác và có thể thuê lại địa chỉ ở mạng con khác, trong khi khách NAT giữ địa chỉ 10.0.2.x và lặng lẽ thừa hưởng một đường lên khác.
Trước khi đóng phiếu, hãy xác nhận từng mục sau:
- Địa chỉ ra của khách khác địa chỉ ra của máy chủ, nên nó không nằm trên đường hầm của máy chủ.
- Trình phân giải là proxy 10.0.2.3 hoặc một máy chủ trong LAN, và bạn biết cái nào đã trả lời.
- Không có địa chỉ v6 toàn cầu trong khách nếu thiết kế đường hầm chỉ dành cho v4.
- Khi đường hầm của máy chủ bị hạ, khách ngừng duyệt, hoặc bạn đã biết nó chưa bao giờ phụ thuộc vào đó.
- Khách không thấy lưu lượng quảng bá của LAN mà nó không có việc gì phải thấy.