Cùng một subnet ở hai đầu: ánh xạ LAN từ xa vào một dải trống
Ánh xạ địa chỉ phía máy khách có thể trình bày một LAN từ xa bị chồng lấn dưới một dải trống, nhưng chỉ một số máy khách áp dụng nó và đường quay về vẫn phải tồn tại.
Nhà và văn phòng đều dùng 192.168.1.0/24, nên một yêu cầu tới 192.168.1.1 có hai câu trả lời khả dĩ và máy khách chọn một mà không hỏi. Đánh số lại một mạng văn phòng đang chạy hiếm khi được ưa chuộng, và địa chỉ router thường được ghi cứng vào máy in, camera và tài liệu. Ánh xạ địa chỉ phía máy khách có thể thay vào đó trình bày mạng từ xa dưới một dải trống, và phần host có thể giữ nguyên để 192.168.1.20 hiện ra là 10.203.41.20. Vấn đề là chỉ một số máy khách triển khai nó, và nó không làm gì cho đường quay về.
Hai góc nhìn về cùng một host
Ánh xạ giữ phần host và chỉ đổi phần mạng. Cùng máy đó sau đó trả lời ở hai địa chỉ tùy theo bạn đứng ở đâu. Ghi cả hai cột trước khi cấu hình bất cứ thứ gì ngăn việc đọc sai nhật ký và quy tắc tường lửa về sau.
| The application dials | The remote device is |
|---|---|
| 10.203.41.1 | 192.168.1.1 |
| 10.203.41.20 | 192.168.1.20 |
Các thiết bị cục bộ ở nhà giữ địa chỉ 192.168.1.x của chúng, và đó là mục đích của bài tập. Máy in ở phòng bên cạnh vẫn truy cập được trong khi văn phòng hiện ra dưới một dải không trùng.
Thứ tự đối số chính là toàn bộ mẹo
Tùy chọn nhận một hướng, một mạng và mặt nạ, và một bí danh: mạng đầu tiên là cái máy khách thấy, bí danh là cái máy chủ thấy. Với các tài nguyên nằm sau cổng từ xa, hướng là dạng đích. Đảo hai mạng vì đối số cuối được gọi là bí danh là lỗi tạo ra một đường hầm kết nối mà không ánh xạ gì.
push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"
Tuyến là cái gửi gói tin của máy khách cho dải mới vào đường hầm; bản dịch viết lại đích trên đường đi. Một câu trả lời từ 192.168.1.20 được viết ngược lại thành 10.203.41.20 để socket trên máy khách giữ nhất quán. Một host đơn hoạt động như vậy với mặt nạ đầy đủ, miễn là tuyến và ánh xạ mô tả cùng một địa chỉ.
Đây là ánh xạ địa chỉ, không phải ánh xạ cổng. Hai dịch vụ trên một host không thể tách bằng nó, và một giao thức nhúng địa chỉ IP vào tải trọng vẫn sẽ thấy những địa chỉ thật.
Ánh xạ không tạo ra đường quay về
Bản dịch xảy ra ở máy khách, nên máy chủ vẫn phải định tuyến các câu trả lời vào đường hầm và tường lửa của nó vẫn phải cho phép chúng. Nếu cổng từ xa không biết cách tới subnet của đường hầm, yêu cầu đến và câu trả lời đi ra bằng cửa sai; ánh xạ chỉ khiến sự cố trông như vấn đề của máy khách.
Các quy tắc phía máy chủ nên mô tả những địa chỉ tồn tại trên máy chủ sau bản dịch, không phải dải mà máy khách thấy. Sao chép bí danh vào một quy tắc cho phép làm mất cả một buổi chiều, vì không gói tin nào ở phía đó mang nó.
Chọn một dải bí danh không trùng với bất cứ thứ gì khác mà máy khách định tuyến: một VPN khác, một mạng container, một văn phòng thứ hai. Xung đột ở đây đưa lại sự mơ hồ ban đầu dưới một con số khác và khó thấy hơn vì các địa chỉ trông xa lạ.
Tên và tải trọng sống sót qua bản dịch
Một tên host phân giải thành 192.168.1.20 thật sẽ gửi trình duyệt tới thiết bị cục bộ thay vì thiết bị từ xa, bất kể bảng định tuyến nói gì. Câu trả lời DNS riêng phải trỏ tới dải mà máy khách thấy, trong khi chứng chỉ TLS vẫn mang tên mà ứng dụng mong đợi. Hãy thử bằng tên thay vì bằng địa chỉ, vì địa chỉ có thể hoạt động trong khi tên lặng lẽ phân giải sai hướng. Khi cổng từ xa cũng phục vụ vùng đó, các bản ghi của chính nó cũng cần dải mà máy khách thấy.
Chuyển hướng, URL nhúng và các ứng dụng tự đưa địa chỉ của mình vào tải trọng có thể hỏng theo cách không ánh xạ gói tin nào sửa được. Hãy coi đó là vấn đề của ứng dụng và ước lượng công sức cho tương xứng trước khi hứa rằng việc đánh số lại là không cần thiết.
Ba kiểm tra trước khi cam kết
Thứ nhất, xác nhận việc triển khai phía máy khách. Community OpenVPN hỗ trợ tùy chọn này; cơ sở mã OpenVPN 3 liệt kê nó trong các tính năng không được hỗ trợ, nên một hồ sơ đẩy tới máy khách kiểu Connect có thể chỉ đơn giản bỏ qua nó. Một chỉ thị được chấp nhận và không bao giờ áp dụng còn tệ hơn một lỗi, vì đường hầm trông khỏe mạnh.
Thứ hai, xác minh tuyến và bản dịch riêng rẽ với một cửa sổ chẩn đoán ngắn ở mức chi tiết cao, rồi kiểm tra dịch vụ thực thay vì ping. Thứ ba, xác nhận rằng router cục bộ và tài nguyên từ xa vẫn phân biệt được từ phía máy khách, vì đó là mục tiêu ban đầu.
Nếu máy khách không thể dịch, hãy nhờ phía cổng giúp hoặc chấp nhận đánh số lại. Thêm tuyến cho cùng một địa chỉ không phải là thiết kế.