1. Zmienić adresację w jednej z lokalizacji.
2. Zastosować NAT

Czasami rozwiązanie pierwsze nie wchodzi w grę i musimy posiłkować się NATem. W tym wpisie pokażę jak wykorzystać NAT źródłowy w dwóch zdalnych lokalizacjach w których wykorzystywane są te same adresy IP.

SCENARIUSZ

Mamy dwie lokalizacje (nazwijmy je A i B) w lokalizacji A mamy router R1, w lokalizacji B mamy router R2. W każdej z lokalizacji wykorzystywana jest podsieć 10.10.10.0/24. Oddziały łączymy ze sobą VPNem. Następnie korzystając z NAT’a robimy następujące translacje:

Lokalizacja A –    10.10.10.0/24   ->   10.100.100.0/24

Lokalizacja B –    10.10.10.0/24   ->   10.200.200.0/24

Schemat połączenia oraz adresacja:

Translacje:

ROZWIĄZANIE:

Poniżej znajduje się konfiguracja routerów R1 i R2. Podstawowa konfiguracja obejmuje konfigurację interfejsów oraz tunelu VPN. Jako sieci lokalne w lokalizacjach A i B posłużą interfejsy loopback0.

Podstawowa konfiguracja R1:

crypto isakmp policy 10
 encr aes
 authentication pre-share
 group 5
!
crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set TSET esp-aes esp-sha-hmac
!
crypto ipsec profile PROFILE
 set transform-set TSET
!
!
interface Loopback0
 ip address 10.10.10.1 255.255.255.0
!
interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 tunnel source FastEthernet0/0
 tunnel destination 13.13.13.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile PROFILE
!
interface FastEthernet0/0
 ip address 11.11.11.1 255.255.255.0

Podstawowa konfiguracja R2:

crypto isakmp policy 10
 encr aes
 authentication pre-share
 group 5
!
crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set TSET esp-aes esp-sha-hmac
!
crypto ipsec profile PROFILE
 set transform-set TSET
!
!
interface Loopback0
 ip address 10.10.10.1 255.255.255.0
!
interface Tunnel0
 ip address 10.0.0.2 255.255.255.0
 tunnel source FastEthernet0/0
 tunnel destination 11.11.11.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile PROFILE
!
interface FastEthernet0/0
 ip address 13.13.13.1 255.255.255.0

Konfiguracja NAT na R1:

interface Tunnel0
 ip nat outside
!
interface Loopback0
 ip nat inside
!
ip nat inside source static network 10.10.10.0 10.100.100.0 /24

Konfiguracja NAT na R2:

interface Tunnel0
 ip nat outside
!
interface Loopback0
 ip nat inside
!
ip nat inside source static network 10.10.10.0 10.200.200.0 /24

Musimy jeszcze ustawić routing na sieci translatowane czyli 10.200.200.0/24 oraz 10.100.100.0/24. Najprościej to zrobić dodając odpowiednie trasy statyczne na obu routerach:

R1

R1(config)#ip route 10.200.200.0 255.255.255.0 10.0.0.2

R2

R2(config)#ip route 10.100.100.0 255.255.255.0 10.0.0.1

TESTY

Przetestujmy teraz naszą konfigurację.

Lokalizacja A -> Lokalizacja B

Jako, że nasze lokalizacje nie posiadają żadnych hostów do testów posłużymy się adresami loopback0 na routerach.

R1#ping ip 10.200.200.1 source loopback 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.200.200.1, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/41/48 ms

Lokalizacja B -> Lokalizacja A

R2#ping ip 10.100.100.0 source loopback 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.100.100.0, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/32/44 ms

Sprawdźmy jeszcze co pokazuje debug ip icmp na obu routerach oraz polecenie sh ip nat translations

R1#debug ip icmp
ICMP packet debugging is on
R1#ping ip 10.200.200.1 source loopback 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.200.200.1, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/18/20 ms
R1#
*Oct 25 09:08:20.711: ICMP: echo reply rcvd, src 10.200.200.1, dst 10.10.10.1
*Oct 25 09:08:20.727: ICMP: echo reply rcvd, src 10.200.200.1, dst 10.10.10.1
*Oct 25 09:08:20.747: ICMP: echo reply rcvd, src 10.200.200.1, dst 10.10.10.1
*Oct 25 09:08:20.767: ICMP: echo reply rcvd, src 10.200.200.1, dst 10.10.10.1
*Oct 25 09:08:20.791: ICMP: echo reply rcvd, src 10.200.200.1, dst 10.10.10.1

R2#debug ip icmp
ICMP packet debugging is on
R2#
*Oct 25 09:08:20.163: ICMP: echo reply sent, src 10.10.10.1, dst 10.100.100.1
*Oct 25 09:08:20.195: ICMP: echo reply sent, src 10.10.10.1, dst 10.100.100.1
*Oct 25 09:08:20.215: ICMP: echo reply sent, src 10.10.10.1, dst 10.100.100.1
*Oct 25 09:08:20.239: ICMP: echo reply sent, src 10.10.10.1, dst 10.100.100.1
*Oct 25 09:08:20.259: ICMP: echo reply sent, src 10.10.10.1, dst 10.100.100.1

R1#show ip nat translations
Pro Inside global Inside local Outside local Outside global
--- 10.100.100.0 10.10.10.0 --- ---
--- 10.100.100.1 10.10.10.1 --- ---

R2#show ip nat translations
Pro Inside global Inside local Outside local Outside global
--- 10.200.200.1 10.10.10.1 --- ---
--- 10.200.200.0 10.10.10.0 --- ---

Widzimy, że przy pingowaniu adresu 10.200.200.1 z Loopack0 na R1,  R2 myśli, że otrzymuje pakiety od adresu 10.100.100.1 dzięki zastosowanej translacji.

WNIOSKI

Stosując NAT źródłowy na obu routerach za którymi mamy tą adresację możemy takie sieci połączyć ze sobą bez konieczności zmiany adresów jednej z nich. Stosując NAT może pojawić się problem jeśli na interfejsie tunelowym mamy konfigurację: ip nat inside. Np. w przypadku gdy udostępniamy połączenie internetowe do oddziału zdalnego, w takim przypadku nie będziemy mogli skorzystać z tego rozwiązania, ponieważ interfejs nie może mieć jednocześnie konfiguracji ip nat inside oraz ip nat outside.

N2N

N2N jest programem, który umożliwia tworzenie tuneli VPN wykorzystując metodę Peer-to-Peer. N2N pozwala na połączenie komputerów znajdujących się za NAT-em oraz komputerów korzystających z sieci z zablokowanymi portami wejściowymi (np. sieć komórkowa 3G). Architektura N2N opiera się na dwóch elementach: węzłach brzegowych i węźle głównym.

Węzły brzegowe to nic innego jak urządzenia które będziemy łączyć ze sobą przy pomocy węzła głównego w sieć VPN. Węzeł główny to komputer, do którego będą się łączyły węzły brzegowe. Może być to nasz komputer (jednak musi posiadać publiczny adres IP), albo można skorzystać z dostępnych serwerów (tzw. public supernode).

N2N jest dostępny na wiele platform. Ja korzystam z niego na komputerach z Debianem, na routerze z OpenWrt (Gargoyle), na RaspberryPI z Raspbmc, oraz na telefonie z Androidem. Probowalem uruchomić N2N na komputerze z Windows 7 jednak nie udało mi się tego zrobić. Dlatego wymyśliłem proste rozwiązanie, jako że bardzo często korzystam z VirtualBoxa, to postawiłem maszynę wirtualną z Debianem, do której łączę się przez ssh (MobaXterm) i na niej zainstalowałem N2N. Na chwilę obecną mam 5 urządzeń z zainstalowanym N2N i do każdego mogę się podłączyć przez ssh. Najbardziej podoba mi się N2N na telefon z Androidem, dzieki temu mam dostęp do moich urządzeń gdziekolwiek jestem. Do poprawnego działania oprogramowania na Androida trzeba mieć zroot’owany telefon.

KONFIGURACJA

Poniżej przedstawię przykład połączenie dwóch komputerów znajdujących się za NAT’em (PC1 i PC2) w sieć VPN wykorzystując oprogramowanie N2N. Na komputerach zainstalowany jest Debian „Wheezy” 7.0. Oba komputery znajdują się za NAT’em i nie jest możliwe bezpośrednie ich połączenie ze sobą, w tym celu skorzystam z węzła głównego dostarczanego przez remoteqth.com o adresie publicznym: 78.111.124.210:82, gdzie 82 oznacza numer portu, na którym serwer nasłuchuje połączeń od węzłów brzegowych.

Schemat połączenia.

Instalacja krok po kroku:

1. Najpierw na obu komputerach należy zainstalować pakiet n2n wydając polecenie:

root@debian:~# apt-get install n2n

2. Teraz konieczne jest wybranie następujących parametrów:

• hasła, którego n2n będzie używać do szyfrowania transmisji;
• nazwa sieci (community), każdy węzeł brzegowy może należeć jednocześnie do kliku sieci VPN, ktore są określane przez nazwe sieci;
• adresy IP węzłów brzegowych, adresy IP węzłów w tej samej sieci VPN (community) muszą być z tej samej podsieci.

Ja do mojego przykładu wybralem następujące parametry:

• hasło – „abcd1234”
• community – „vpn”
• adresy IP – PC1 : 10.10.10.1 ; PC2 : 10.10.10.2

3. Uruchomienie programu:

Na PC1:

root@debian:~# N2N_KEY=abcd1234 /usr/sbin/edge -d n2n0 -a 10.10.10.1 -c vpn -f -l 78.111.124.210:82 -b

Na PC2:

root@debian:~# N2N_KEY=abcd1234 /usr/sbin/edge -d n2n0 -a 10.10.10.2 -c vpn -f -l 78.111.124.210:82 -b

Opcja -d n2n0 określa nazwę interfejsu TAP, który zostanie stworzony przez program N2N i do którego zostanie przypisany wybrany przez nas adres IP, natomiast opcja -f oznacza, że program będzie działał w tle.

Po wydaniu powyższych poleceń na PC1 i na PC2, na ekranie konsoli powinien pojawić się następujący komunikat:

oznacza on, że program poprawnie utworzył interfejs n2n0 i nadał mu odpowiedni adres IP. Teraz można zweryfikować utworzony interfejs wydając polecenie:

root@debian:~# ifconfig n2n0

Teraz można przetestować, czy między komputerami PC1 i PC2 jest łączność, w tym celu pingujemy z jednego komputera drugi:

Jeśli nie działa nam komunikacja to należy sprawdzić czy poprawnie wpisaliśmy hasło (N2N_KEY), nazwę sieci VPN (community) oraz czy adresy IP są z tej samej podsieci, w moim przypadku podsieć to 10.10.10.0/24. Szczegółowe informacje na temat ew problemów z działaniem N2N można znaleźć w syslogu:

root@debian:~# cat /var/log/syslog

4. Autostart

N2N możemy uruchomić przy starcie naszego systemu, w tym celu należy w pierwszej kolejności stworzyć plik n2n_autostart.sh o następującej zawartości:

Dla PC1:

#!/bin/bash

N2N_KEY=abcd1234 /usr/sbin/edge -d n2n0 -a 10.10.10.1 -c vpn -f -l 78.111.124.210:82 -b

Dla PC2:

#!/bin/bash

N2N_KEY=abcd1234 /usr/sbin/edge -d n2n0 -a 10.10.10.2 -c vpn -f -l 78.111.124.210:82 -b

Skryptowi należy nadać atrybut wykonywalności +x:

root@debian:~# chmod +x n2n_autostart.sh

Po utworzeniu skryptów konieczne jest dodanie poniższego wpisu do tablic crontab obu komputerów:

@reboot /root/n2n_autostart.sh >> /var/log/cron 2>&1 &

Do edycji tablicy crontab służy polecenie:

root@debian:~# crontab -e

W moim przykładzie plik n2n_autostart.sh znajduje się w katalogu /root/n2n_autostart.sh , jeśli jednak skrypt znajduje się w innym katalogu, to trzeba zmienić we wpisie crontab ścieżkę skryptu.

Poniższy wpis w crontab spowoduje, że przy każdym restarcie i uruchomieniu się komputera zostanie uruchomiony skrypt n2n_autostart.sh, a jego wynik zostanie zapisany w logu: /var/log/cron.

WYDAJNOŚĆ

Teraz pora na test wydajności połączenia pomiędzy komputerami w sieci N2N VPN. Do testowania połączenia użyłem oprogramowania iperf:

Jak widać na powyższym screenie prędkość połączenia TCP pomiędzy komputerami PC1 i PC2 wynosi ok 0,5Mb/s, co nie jest najgorszym wynikiem, a przy połączeniach terminalowych w zupełności wystarcza. Na ten wynik w głównej mierze ma wpływ korzystanie z serwera pośredniczącego jakim jest węzeł główny 78.111.124.210:82. Musimy wziąć pod uwagę, że serwer ten jest dostarczany za darmo i umożliwia nam dostęp do komputerów, które nie posiadają publicznych adresów IP (są za NAT’em i nie są dostępne z zewnątrz), więc nie ma co narzekać.