Có thể giải quyết điều này bằng cách sử dụng NAT; nó không phải là rất thanh lịch.
Vì vậy, theo giả định, bạn không thể giải quyết điều này bằng cách có các mạng nội bộ có số mạng không phổ biến đến mức không bao giờ thực sự xảy ra xung đột, đây là nguyên tắc:
Vì cả mạng con cục bộ và mạng con từ xa đều có số mạng giống hệt nhau, lưu lượng truy cập từ máy khách của bạn sẽ không bao giờ nhận ra nó phải đi qua cổng đường hầm để đến đích. Và ngay cả khi chúng ta tưởng tượng nó có thể, tình huống sẽ giống như vậy đối với máy chủ từ xa vì nó sắp gửi câu trả lời.
Vì vậy, hãy ở lại với tôi và giả vờ rằng, cho đến nay, không có vấn đề phụ nào khi tôi viết rằng để kết nối đầy đủ, bạn sẽ cần NAT cả hai đầu bên trong đường hầm để phân biệt máy chủ và cho phép định tuyến.
Làm một số lưới ở đây:
- Mạng văn phòng của bạn sử dụng 192.0.2.0/24
- Văn phòng từ xa của bạn sử dụng 192.0.2.0/24
- Cổng mạng VPN văn phòng của bạn ẩn các máy chủ 192.0.2.0/24 đằng sau số mạng NATed 198.51.100.0/24
- Mạng VPN văn phòng từ xa của bạn ẩn các máy chủ 192.0.2.0/24 đằng sau số mạng NATed 203.0.113.0/24
Vì vậy, bên trong đường hầm VPN, các máy chủ văn phòng hiện có 198.51.100.x và máy chủ văn phòng từ xa là 203.0.113.x. Ngoài ra, hãy giả vờ tất cả các máy chủ được ánh xạ 1: 1 trong NAT của các cổng VPN tương ứng của chúng. Một ví dụ:
- Máy chủ mạng văn phòng của bạn 192.0.2.5/24 được ánh xạ tĩnh là 198.51.100.5/24 trong cổng vpn văn phòng NAT
- Máy chủ mạng văn phòng từ xa 192.0.2.5/24 của bạn được ánh xạ tĩnh thành 203.0.113.5/24 trong cổng vpn văn phòng từ xa NAT
Vì vậy, khi máy chủ 192.0.2.5/24 trong văn phòng từ xa muốn kết nối với máy chủ có cùng ip trong mạng văn phòng, nó cần phải sử dụng địa chỉ 198.51.100.5/24 làm đích. Sau đây xảy ra:
- Tại văn phòng từ xa, máy chủ 198.51.100.5 là một điểm đến từ xa thông qua VPN và được chuyển đến đó.
- Tại văn phòng từ xa, máy chủ 192.0.2.5 được giả mạo là 203.0.113.5 khi gói vượt qua chức năng NAT.
- Tại văn phòng, máy chủ 198.51.100.5 được dịch thành 192.0.2.5 khi gói vượt qua chức năng NAT.
- Tại văn phòng, trả lại lưu lượng truy cập cho máy chủ lưu trữ 203.0.113.5 trải qua quá trình tương tự theo hướng ngược lại.
Vì vậy, trong khi có một giải pháp, có một số vấn đề phải được giải quyết để làm việc này trong thực tế:
- IP giả mạo phải được sử dụng để kết nối từ xa; DNS trở nên phức tạp. Điều này là do các điểm cuối phải có một địa chỉ IP duy nhất, khi được xem từ máy chủ kết nối.
- Một chức năng NAT phải được thực hiện cả hai đầu như một phần của giải pháp VPN.
- Máy chủ ánh xạ tĩnh là phải cho khả năng tiếp cận từ đầu kia.
- Nếu lưu lượng là một chiều, chỉ có đầu nhận mới cần ánh xạ tĩnh của tất cả các máy chủ liên quan; khách hàng có thể thoát khỏi trạng thái NAT động nếu muốn.
- Nếu lưu lượng truy cập hai chiều, cả hai đầu cần ánh xạ tĩnh của tất cả các máy chủ liên quan.
- Kết nối Internet không được suy yếu bất kể VPN phân tách hay không phân chia.
- Nếu bạn không thể ánh xạ 1-1 thì nó sẽ bị lộn xộn; kế toán cẩn thận là một điều cần thiết.
- Đương nhiên, người ta có nguy cơ sử dụng các địa chỉ NAT cũng bị trùng lặp :-)
Vì vậy, giải quyết điều này cần thiết kế cẩn thận. Nếu văn phòng từ xa của bạn thực sự bao gồm các chiến binh đường phố, bạn sẽ thêm một lớp vấn đề trong đó:
- họ không bao giờ biết trước khi họ kết thúc trên các id mạng chồng chéo.
- cổng văn phòng từ xa NAT sẽ cần được triển khai trên máy tính xách tay của họ.
- cổng văn phòng sẽ cần hai VPN, một NAT-free và NATed, để bao quát cả hai kịch bản. Mặt khác, trong trường hợp ai đó chọn một trong các mạng con bạn chọn cho phương thức NAT, mọi thứ sẽ không hoạt động .
Tùy thuộc vào máy khách VPN của bạn, bạn có thể tự động chọn một VPN hoặc cái kia tùy thuộc vào địa chỉ mạng của phân khúc cục bộ.
Quan sát rằng tất cả các đề cập đến NAT trong bối cảnh này biểu thị một chức năng NAT có thể diễn ra trong viễn cảnh đường hầm. Theo quy trình, ánh xạ NAT tĩnh phải được thực hiện trước khi gói "đi vào" đường hầm, tức là trước khi nó được gói gọn trong gói vận chuyển để đưa nó qua internet đến cổng VPN khác.
Điều này có nghĩa là người ta không được nhầm lẫn các địa chỉ IP công cộng của các cổng VPN (và trong thực tế cũng có thể là NAT: ed, nhưng sau đó hoàn toàn nằm ngoài quan điểm vận chuyển đến trang web từ xa thông qua VPN) với các địa chỉ riêng tư được sử dụng làm giả mạo cho các địa chỉ riêng trùng lặp. Nếu sự trừu tượng này khó hình dung, một minh họa về cách NAT có thể được tách biệt về mặt vật lý khỏi cổng VPN cho mục đích này được thực hiện ở đây:
Sử dụng NAT trong Mạng chồng chéo .
Thu gọn hình ảnh tương tự vào một phân tách hợp lý bên trong một máy, có khả năng thực hiện cả chức năng cổng NAT và VPN, chỉ đơn giản là lấy ví dụ tương tự một bước nữa, nhưng lại chú trọng nhiều hơn vào khả năng của phần mềm. Việc hack nó cùng với ví dụ OpenVPN và iptables và đăng giải pháp ở đây sẽ là một thách thức xứng đáng.
Softwarewise chắc chắn là có thể:
PIX / ASA 7.x trở lên: VPN IPsec LAN với mạng chồng chéo Ví dụ về cấu hình mạng chồng chéo
và: Định
cấu hình đường hầm IPSec giữa các bộ định tuyến với mạng con trùng lặp LAN
Do đó, việc triển khai thực tế phụ thuộc vào rất nhiều yếu tố, các hệ điều hành liên quan, phần mềm liên quan và khả năng của nó không phải là ít nhất. Nhưng nó chắc chắn là có thể làm được. Bạn sẽ cần phải suy nghĩ và thử nghiệm một chút.
Tôi đã học được điều này từ Cisco khi nhìn thấy bởi các liên kết.