CISCO S2S VPN z VTI – te same adresy LAN

W idealnym świecie nie mamy do czynienia z zachodzącymi na siebie adresami IP. W praktyce jednak okazuje się, że często łącząc dwie lokalizacje zdalne po VPN okazuje się, że lokalne adresy nachodzą na siebie. Jeśli taka sytuacja wystąpi to mamy dwa rozwiązania:

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.