Można to rozwiązać za pomocą NAT; po prostu nie jest zbyt elegancki.
Zatem przy założeniu, że nie można rozwiązać tego problemu, mając sieci wewnętrzne, które mają tak rzadkie numery sieci, że nigdy nie wchodzą w konflikt, oto zasada:
Ponieważ zarówno lokalna, jak i zdalna podsieć mają identyczne numery sieciowe, ruch z twojego klienta nigdy nie zda sobie sprawy, że musi przejść przez bramę tunelu, aby dotrzeć do miejsca docelowego. I nawet jeśli sobie to wyobrażamy, sytuacja byłaby taka sama dla zdalnego hosta, ponieważ ma zamiar wysłać odpowiedź.
Więc zostań ze mną i udawaj, że jak dotąd nie ma żadnych problemów ubocznych, piszę, że aby uzyskać pełną łączność, trzeba będzie NAT obu końców w tunelu, aby zróżnicować hosty i umożliwić routing.
Tworzenie niektórych sieci tutaj:
- Twoja sieć biurowa używa 192.0.2.0/24
- Twoje zdalne biuro używa 192.0.2.0/24
- Brama VPN Twojej sieci biurowej ukrywa 192.0.2.0/24 hostów za numerem sieci NATed 198.51.100.0/24
- Brama VPN Twojej sieci zdalnej biura ukrywa 192.0.2.0/24 hostów za numerem sieci NATed 203.0.113.0/24
Wewnątrz tunelu VPN hostami biurowymi jest teraz 198.51.100.x, a hostami zdalnymi biurowymi 203.0.113.x. Udawajmy, że wszystkie hosty są mapowane 1: 1 w NAT ich odpowiednich bram VPN. Przykład:
- Host sieci biurowej 192.0.2.5/24 jest odwzorowany statycznie na 198.51.100.5/24 w translacji NAT Office Office VPN
- Host sieci zdalnej biura 192.0.2.5/24 jest statycznie mapowany jako 203.0.113.5/24 w NAT VPN bramy VPN biura zdalnego
Więc jeśli host 192.0.2.5/24 w biurze zdalnym chce połączyć się z hostem z tym samym adresem IP w sieci biurowej, musi to zrobić, używając adresu 198.51.100.5/24 jako miejsca docelowego. Zdarza się:
- W zdalnym biurze host 198.51.100.5 to zdalne miejsce docelowe osiągane przez VPN i tam kierowane.
- W zdalnym biurze host 192.0.2.5 jest maskowany jako 203.0.113.5, gdy pakiet przechodzi przez funkcję NAT.
- W biurze host 198.51.100.5 jest tłumaczony na 192.0.2.5, gdy pakiet przechodzi przez funkcję NAT.
- W biurze ruch powrotny do hosta 203.0.113.5 przechodzi ten sam proces w odwrotnym kierunku.
Chociaż istnieje rozwiązanie, istnieje wiele kwestii, które należy rozwiązać, aby działało w praktyce:
- Maskaradowane IP musi być użyte do zdalnej łączności; DNS się komplikuje. Wynika to z faktu, że punkty końcowe muszą mieć unikalny adres IP widziany z hosta łączącego.
- Funkcja NAT musi być zaimplementowana na obu końcach jako część rozwiązania VPN.
- Statyczne mapowanie hostów jest koniecznością dla osiągnięcia osiągalności z drugiego końca.
- Jeśli ruch jest jednokierunkowy, tylko odbiorca końcowy potrzebuje statycznego mapowania wszystkich zaangażowanych hostów; w razie potrzeby klient może uniknąć dynamicznej NAT.
- Jeśli ruch jest dwukierunkowy, oba końce wymagają statycznego mapowania wszystkich zaangażowanych hostów.
- Łączność z Internetem nie może być zakłócona bez względu na podzielony lub nierozdzielony VPN.
- Jeśli nie możesz zmapować 1 na 1, robi się bałagan; staranne prowadzenie ksiąg rachunkowych jest koniecznością.
- Oczywiście istnieje ryzyko użycia adresów NAT, które również okazują się duplikatami :-)
Rozwiązanie tego problemu wymaga starannego zaprojektowania. Jeśli twoje zdalne biuro naprawdę składa się z wojowników drogowych, dodajesz warstwę problemów w tym:
- nigdy nie wiedzą z góry, kiedy kończą się nakładającymi się identyfikatorami sieci.
- brama NAT zdalnego biura powinna być zaimplementowana na ich laptopach.
- brama biurowa potrzebowałaby dwóch sieci VPN, jednej wolnej od NAT i jednej NATed, aby obsłużyć oba scenariusze. W przeciwnym razie, gdyby ktoś wybrał jedną z podsieci, które wybrałeś dla metody NAT, rzeczy nie działałyby .
W zależności od klienta VPN może być możliwe automatyczne wybranie jednej sieci VPN lub drugiej w zależności od adresu sieciowego segmentu lokalnego.
Zauważ, że wszystkie wzmianki o NAT w tym kontekście oznaczają funkcję NAT, która, że tak powiem, ma miejsce w perspektywie tunelu. Procesowo, statyczne mapowanie NAT musi zostać wykonane, zanim pakiet „wejdzie” do tunelu, tj. Zanim zostanie zamknięty w pakiecie transportowym, który ma go przenieść przez Internet do innej bramy VPN.
Oznacza to, że nie należy mylić publicznych adresów IP bram VPN (które w praktyce mogą być również NAT: ed, ale wtedy całkowicie poza perspektywą transportu do zdalnej strony przez VPN) z unikalnymi prywatnymi adresami używanymi jako maskarady dla duplikatów adresów prywatnych. Jeśli ta abstrakcja jest trudna do wyobrażenia, ilustruje to, w jaki sposób NAT może być fizycznie oddzielony od bramki VPN w tym celu:
Wykorzystanie NAT w nakładających się sieciach .
Skondensowanie tego samego obrazu do logicznej separacji wewnątrz jednego komputera, zdolnego do wykonywania zarówno funkcji NAT, jak i bramy VPN, po prostu posuwa ten sam przykład o krok dalej, ale kładzie większy nacisk na możliwości dostępnego oprogramowania. Złamanie go razem z, na przykład OpenVPN i iptables, i opublikowanie rozwiązania tutaj byłoby godnym wyzwaniem.
Pod względem oprogramowania z pewnością jest to możliwe: PIX / ASA 7.x i później: VPN IPsec LAN-to-LAN z nakładającymi się przykładami konfiguracji sieci
i:
Konfigurowanie tunelu IPSec między routerami ze zduplikowanymi podsieciami LAN
Rzeczywista implementacja zależy zatem od wielu czynników, zaangażowanych systemów operacyjnych, powiązanego oprogramowania i jego możliwości. Ale z pewnością jest to wykonalne. Musisz trochę pomyśleć i poeksperymentować.
Nauczyłem się tego od Cisco, co widać po linkach.