Je nachdem wie gut das Netz gepflegt ist, muss das nicht ein zu gro\u00dfer Aufwand sein. Sp\u00e4testens jetzt k\u00f6nnte das ein Grund sein, um DHCP und DNS konsequent umzusetzen. Wenn die \u00fcberlappenden Adress-Bereiche durch einen Firmen-Zusammenschluss zustande gekommen sind, dann wird es wohl hierauf hinauslaufen.<\/p>\n
Wenn man sich noch nicht mit IPv6 besch\u00e4ftigt hat, wird dies sicher am l\u00e4ngsten dauern um implementiert zu werden. Aber dann sollte die Wahrscheinlichkeit f\u00fcr \u00fcberlappende Netze relativ<\/em> klein sein. \ud83d\ude09<\/p>\n Hierbei werden die mehrfach verwendeten Netze per NAT verborgen. Je nachdem wie viele Standorte den gleichen Adress-Bereich verwenden, kann die Konfiguration und auch das Management dieser L\u00f6sung etwas “eklig” werden. Aber gerade wenn unterschiedliche Firmen verbunden werden sollen, ist dies oft die verwendete L\u00f6sung.<\/p>\n Dieser Artikel beschreibt die Konfiguration dieses Ansatzes in Verbindung mit VPN-Tunneln.<\/ol>\n Das Ausgangs-Szenario: F\u00fcr jede Seite wird jetzt ein freies Netz gew\u00e4hlt (hier 10.111.111.0\/24 und 10.222.222.0\/24): Die (relevante) Konfiguration der zwei Router sieht folgenderma\u00dfen aus:<\/p>\n Wenn aus dem linken Netz das rechte erreicht werden soll, muss nat\u00fcrlich die NAT-Adresse genommen werden. Bei einem Ping vom linken LAN-Interface zum rechten LAN-Interface sieht das dann folgenderma\u00dfen aus:<\/p>\n Ein entscheidender Nachteil dieser Methode ist, dass diese Adress-\u00dcbersetzung immer<\/strong> durchgef\u00fchrt wird und ein Router mit dieser Konfiguration nicht mehr sinnvoll f\u00fcr andere Verbindungen verwendet werden kann. Diese Translation d\u00fcrfte eigentlich nur verwendet werden, wenn das gegen\u00fcberliegende NAT-Netz angesprochen wird. Gerade habe ich eine Anfrage bekommen, wie man denn Netze verbinden kann, wenn auf beiden Seiten der gleiche Adress-Bereich verwendet wird. Als L\u00f6sung gibt es verschiedene Ans\u00e4tze: Readressierung Je nachdem wie gut das Netz gepflegt ist, muss das nicht ein zu gro\u00dfer Aufwand sein. Sp\u00e4testens jetzt k\u00f6nnte das ein Grund sein, um DHCP und DNS <\/p>\n
\n![\"2router\"](\"https:\/\/blog.iwen.de\/wp-content\/uploads\/2009\/05\/2router.png\" "\\"2router\\"")
\nAn beiden Standorten wird das selbe IP-Netz verwendet. Die L\u00f6sung beinhaltet, dass beide Standorte ihre IP-Netze per NAT hinter einem anderen Netz “verbergen”. Dieses neue Netz wird dann verwendet, um auf die Ger\u00e4te der anderen Seite zuzugreifen.
\nUm die Kombination von NAT und IPSec zu verstehen, muss man sich einfach bewusst sein, in welcher Reihenfolge im IOS die verschiedenen Funktionen abgearbeitet werden: NAT Order of Operation<\/a>
\n![\"nat-order-of-operation\"](\"https:\/\/blog.iwen.de\/wp-content\/uploads\/2009\/05\/nat-order-of-operation.png\" "\\"nat-order-of-operation\\"")
\nWie man sieht, werden die Daten genatted, bevor sie verschl\u00fcsselt werden und auf der anderen Seite entschl\u00fcsselt, bevor NAT angewendet wird.<\/p>\n
\n![\"2routernat\"](\"https:\/\/blog.iwen.de\/wp-content\/uploads\/2009\/05\/2routernat.png\" "\\"2routernat\\"")
\nDie Source-Adressen des linken Netzes werden in 10.111.111.x \u00fcbersetzt, die Source-Adressen des rechten Netzes in 10.222.222.x.<\/p>\n\nhostname R1\ncrypto isakmp policy 1\n encr aes 256\n authentication pre-share\n group 5\ncrypto isakmp key Yes,ThisKeyIsNotReallySecret,LongAndRandom address 192.168.2.2\n!\ncrypto ipsec transform-set ESP-AES256-SHA esp-aes 256 esp-sha-hmac \n!\ncrypto map VPN 1 ipsec-isakmp \n set peer 192.168.2.2\n set transform-set ESP-AES256-SHA \n match address CRYPTO-TO-SITE-2\n!\ninterface FastEthernet0\/0\n description LAN\n ip address 10.10.10.1 255.255.255.0\n ip nat inside\n!\ninterface Serial1\/0\n description Connection to Internet\n ip address 192.168.1.2 255.255.255.0\n ip nat outside\n crypto map VPN\n!\nip route 0.0.0.0 0.0.0.0 192.168.1.1\n!\nip nat inside source static network 10.10.10.0 10.111.111.0 \/24\n!\nip access-list extended CRYPTO-TO-SITE-2\n permit ip 10.111.111.0 0.0.0.255 10.222.222.0 0.0.0.255\n<\/code><\/pre>\n\nhostname R2\n!\ncrypto isakmp policy 1\n encr aes 256\n authentication pre-share\n group 5\ncrypto isakmp key Yes,ThisKeyIsNotReallySecret,LongAndRandom address 192.168.1.2\n!\ncrypto ipsec transform-set ESP-AES256-SHA esp-aes 256 esp-sha-hmac \n!\ncrypto map VPN 1 ipsec-isakmp \n set peer 192.168.1.2\n set transform-set ESP-AES256-SHA \n match address CRYPTO-TO-SITE-1\n!\ninterface FastEthernet0\/0\n description LAN\n ip address 10.10.10.1 255.255.255.0\n ip nat inside\n!\ninterface Serial1\/0\n description Connection to Internet\n ip address 192.168.2.2 255.255.255.0\n ip nat outside\n crypto map VPN\n!\nip route 0.0.0.0 0.0.0.0 192.168.2.1\n!\nip nat inside source static network 10.10.10.0 10.222.222.0 \/24\n!\nip access-list extended CRYPTO-TO-SITE-1\n permit ip 10.222.222.0 0.0.0.255 10.111.111.0 0.0.0.255\n<\/code><\/pre>\n\nR1#ping 10.222.222.1 source fastEthernet 0\/0 rep 1 \n\nType escape sequence to abort.\nSending 1, 100-byte ICMP Echos to 10.222.222.1, timeout is 2 seconds:\nPacket sent with a source address of 10.10.10.1 \n!\nSuccess rate is 100 percent (1\/1), round-trip min\/avg\/max = 32\/32\/32 ms\nR1#\n*Mar 1 00:49:23.527: ICMP: echo reply rcvd, src 10.222.222.1, dst 10.10.10.1\n<\/code><\/pre>\n\nR2#\n*Mar 1 00:49:23.319: ICMP: echo reply sent, src 10.10.10.1, dst 10.111.111.1\n<\/code><\/pre>\n
\nDiese Bedingung — die auf der PIX\/ASA per Policy-NAT einfach umzusetzen ist — w\u00fcrde auf einem IOS-Router mit einer Route-Map beschrieben werden. Diese Route-Maps k\u00f6nnen aber leider in einer statischen Translation nicht verwendet werden, wenn ganze Netze \u00fcbersetzt werden.<\/p>\n","protected":false},"excerpt":{"rendered":"