Chia sẻ phiên VPN của máy chủ với khách VMware

Máy ảo của bạn không tiếp cận được một hệ thống nội bộ vốn chạy hoàn hảo trên máy chủ, và máy chủ được kết nối qua một ứng dụng khách nắm giữ bảng định tuyến. Bắc cầu bộ điều hợp ảo vào đường hầm trông hiển nhiên và thất bại vì hai lý do riêng biệt. Thứ hoạt động là dịch địa chỉ trên một phân đoạn mà cả hai máy cùng sở hữu. Cái giá là thật: mỗi khách mất danh tính riêng của mình trên mạng doanh nghiệp.

Hai lý do cầu nối không thể hoạt động

Bộ điều hợp của ứng dụng khách thường mang một địa chỉ duy nhất, thường là /32, và ứng dụng khách viết lại các tuyến của máy chủ để lưu lượng ra thông thường ưu tiên đường hầm. Các ứng dụng trên máy chủ tuân theo bảng đó và tiếp cận hệ thống riêng. Một khách đã bắc cầu không bao giờ đọc bảng, vì các khung của nó đi ra qua một bộ chuyển mạch bên dưới lớp IP.

Đặt bộ điều hợp đường hầm vào một cầu nối về lý thuyết sẽ giải quyết đường đi, và trình điều khiển sẽ không chấp nhận. Windows 10 cũng chỉ cho phép một thiết bị cầu nối và không cấp vai trò định tuyến để một trạm làm việc chuyển tiếp giữa hai mạng con. Cái còn lại là dịch địa chỉ nguồn. Làm cho lưu lượng của khách trông như đến từ máy chủ, và các quyết định của chính máy chủ sẽ đưa nó vào đường hầm mà khách không cần một tuyến nó không thể có.

Tạo một phân đoạn do máy chủ sở hữu

Trong trình biên tập mạng ảo, hãy thêm một mạng chỉ máy chủ như VMnet3 trên một tiền tố bạn không định tuyến ở nơi nào khác, ví dụ 172.28.90.0/24. Máy chủ nhận 172.28.90.1 trên bộ điều hợp đó và khách gắn vào cùng bộ chuyển mạch. Tắt DHCP của trình ảo hóa trên phân đoạn đó để một dịch vụ địa chỉ duy nhất sở hữu nó.

Xác nhận Windows nhìn thấy giao diện trước khi bạn xây dựng bất cứ thứ gì lên trên, vì toàn bộ thiết kế phụ thuộc vào việc bộ điều hợp đó là bình thường:

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-NetIPAddress -AddressFamily IPv4 | Where-Object PrefixLength -eq 24

Bộ điều hợp chỉ máy chủ xuất hiện ở đó như bất kỳ bộ điều hợp vật lý nào. Đó chính xác là điểm khác biệt với bộ điều hợp đường hầm, thứ không thể gắn vào bất cứ điều gì.

Dịch tiền tố của khách

Mở một phiên có quyền cao và dịch tiền tố. Trước tiên hãy kiểm tra những gì đã tồn tại, vì môi trường chạy container và trình ảo hóa cài đặt bản dịch của riêng chúng và xóa nhầm sẽ làm hỏng một sản phẩm khác.

Get-NetNat | Format-Table Name, InternalIPInterfaceAddressPrefix, Active
New-NetNat -Name "LabGuestEgress" -InternalIPInterfaceAddressPrefix 172.28.90.0/24

Sau đó cấu hình khách với một địa chỉ tĩnh trong tiền tố đó, 172.28.90.1 làm cổng vào và các địa chỉ phân giải mà đường hầm cấp cho máy chủ. Dịch địa chỉ chuyển tiếp gói tin và không dạy khách điều gì về DNS, nên một khách để trên bộ định tuyến cục bộ sẽ phân giải tên công cộng và thất bại với mọi tên nội bộ.

Kiểm tra chặng đầu, rồi đến cái giá

Thử ranh giới gần nhất trước khi thử một ứng dụng. Một dấu vết dừng ở cổng vào của máy chủ nghĩa là việc dịch không xảy ra, trong khi một dấu vết dừng xa hơn máy chủ nghĩa là đường hầm đã chết hoặc phía bên kia đã từ chối địa chỉ đã dịch.

tracert -d 172.20.31.10
nslookup intranet.corp.example
Get-NetNatSession -NatName "LabGuestEgress"

So sánh với việc chính máy chủ truy cập cùng đích trong khi đường hầm đang hoạt động. Nếu máy chủ thành công mà khách thì không, lỗi nằm ở việc dịch hoặc ở thiết lập cổng vào của khách, không phải ở kết nối.

Sau đó hãy chấp nhận sự đánh đổi. Các hệ thống doanh nghiệp giờ chỉ thấy một địa chỉ cho mọi khách, nên chứng chỉ thiết bị và kiểm tra trạng thái theo từng thiết bị không thể phân biệt chúng, và một số chính sách cấm hẳn điều này. Hãy quyết định cả hành vi khi rơi, vì lưu lượng đã dịch có thể rơi xuống đường internet thông thường khi đường hầm hỏng, trừ khi bạn chặn tiền tố đó trên tường lửa của máy chủ.