WORKout

Nein, dieses Mal geht es nicht um körperliche Ertüchtigung. Heute habe ich meine Remise ausgeräumt und gefühlte zwei Tonnen Altpapier entsorgt. Die damals erwartete Wertsteigerung von diversen Jahrgängen (das älteste Magazin war von 1984) BTX-Magazin, ST-Computer, MacUp, Chip, ct, iX, diversen PC-Purzel, OS/2-Magazin, Das Beste, Tour, Bike, etc. hat sich halt doch nicht eingestellt. Beim Befüllen des Altpapier-Containers musste ich einmal aber doch innehalten. Alle Ausgaben der WORKout, die ich damals ab der ersten Ausgabe gelesen habe. Drei Hefte konnte ich dann doch nicht wegwerfen:
workout
Damals habe ich mit einem Atari TT gearbeitet und die NeXTStation war das Gerät mit dem ich ernsthaft geliebäugelt habe (einen PC hatte ich damals nur zum Betrieb einer MAUS-Mailbox, und der lief unter OS/2). Vor allem, da es an der FH eine Aktion gab, bei der dieses faszinierende Gerät inklusive Mathematica für DM 7.999,- verkauft wurde. So verrückt war ich dann aber doch nicht, soviel Geld für einen Computer auszugeben.
So, und wenn mein sentimentaler Anfall gleich vorbei ist, dann werfe ich diese drei Hefte auch noch weg.

WORKout

VPNs zwischen Standorten mit überlappenden Adressen

Gerade habe ich eine Anfrage bekommen, wie man denn Netze verbinden kann, wenn auf beiden Seiten der gleiche Adress-Bereich verwendet wird. Als Lösung gibt es verschiedene Ansätze:

  1. Readressierung
  2. Je nachdem wie gut das Netz gepflegt ist, muss das nicht ein zu großer Aufwand sein. Spätestens jetzt könnte das ein Grund sein, um DHCP und DNS konsequent umzusetzen. Wenn die überlappenden Adress-Bereiche durch einen Firmen-Zusammenschluss zustande gekommen sind, dann wird es wohl hierauf hinauslaufen.

  3. Erweiterung des Netzes um IPv6
  4. Wenn man sich noch nicht mit IPv6 beschäftigt hat, wird dies sicher am längsten dauern um implementiert zu werden. Aber dann sollte die Wahrscheinlichkeit für überlappende Netze relativ klein sein. 😉

  5. Double-NAT zwischen den Netzen
  6. 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ösung etwas “eklig” werden. Aber gerade wenn unterschiedliche Firmen verbunden werden sollen, ist dies oft die verwendete Lösung.

    Dieser Artikel beschreibt die Konfiguration dieses Ansatzes in Verbindung mit VPN-Tunneln.

Das Ausgangs-Szenario:
2router
An beiden Standorten wird das selbe IP-Netz verwendet. Die Lösung beinhaltet, dass beide Standorte ihre IP-Netze per NAT hinter einem anderen Netz “verbergen”. Dieses neue Netz wird dann verwendet, um auf die Geräte der anderen Seite zuzugreifen.
Um 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
nat-order-of-operation
Wie man sieht, werden die Daten genatted, bevor sie verschlüsselt werden und auf der anderen Seite entschlüsselt, bevor NAT angewendet wird.

Für jede Seite wird jetzt ein freies Netz gewählt (hier 10.111.111.0/24 und 10.222.222.0/24):
2routernat
Die Source-Adressen des linken Netzes werden in 10.111.111.x übersetzt, die Source-Adressen des rechten Netzes in 10.222.222.x.

Die (relevante) Konfiguration der zwei Router sieht folgendermaßen aus:


hostname R1
crypto isakmp policy 1
 encr aes 256
 authentication pre-share
 group 5
crypto isakmp key Yes,ThisKeyIsNotReallySecret,LongAndRandom address 192.168.2.2
!
crypto ipsec transform-set ESP-AES256-SHA esp-aes 256 esp-sha-hmac 
!
crypto map VPN 1 ipsec-isakmp 
 set peer 192.168.2.2
 set transform-set ESP-AES256-SHA 
 match address CRYPTO-TO-SITE-2
!
interface FastEthernet0/0
 description LAN
 ip address 10.10.10.1 255.255.255.0
 ip nat inside
!
interface Serial1/0
 description Connection to Internet
 ip address 192.168.1.2 255.255.255.0
 ip nat outside
 crypto map VPN
!
ip route 0.0.0.0 0.0.0.0 192.168.1.1
!
ip nat inside source static network 10.10.10.0 10.111.111.0 /24
!
ip access-list extended CRYPTO-TO-SITE-2
 permit ip 10.111.111.0 0.0.0.255 10.222.222.0 0.0.0.255

hostname R2
!
crypto isakmp policy 1
 encr aes 256
 authentication pre-share
 group 5
crypto isakmp key Yes,ThisKeyIsNotReallySecret,LongAndRandom address 192.168.1.2
!
crypto ipsec transform-set ESP-AES256-SHA esp-aes 256 esp-sha-hmac 
!
crypto map VPN 1 ipsec-isakmp 
 set peer 192.168.1.2
 set transform-set ESP-AES256-SHA 
 match address CRYPTO-TO-SITE-1
!
interface FastEthernet0/0
 description LAN
 ip address 10.10.10.1 255.255.255.0
 ip nat inside
!
interface Serial1/0
 description Connection to Internet
 ip address 192.168.2.2 255.255.255.0
 ip nat outside
 crypto map VPN
!
ip route 0.0.0.0 0.0.0.0 192.168.2.1
!
ip nat inside source static network 10.10.10.0 10.222.222.0 /24
!
ip access-list extended CRYPTO-TO-SITE-1
 permit ip 10.222.222.0 0.0.0.255 10.111.111.0 0.0.0.255

Wenn aus dem linken Netz das rechte erreicht werden soll, muss natürlich die NAT-Adresse genommen werden. Bei einem Ping vom linken LAN-Interface zum rechten LAN-Interface sieht das dann folgendermaßen aus:


R1#ping 10.222.222.1 source fastEthernet 0/0 rep 1 

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.222.222.1, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.1 
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 32/32/32 ms
R1#
*Mar  1 00:49:23.527: ICMP: echo reply rcvd, src 10.222.222.1, dst 10.10.10.1

R2#
*Mar  1 00:49:23.319: ICMP: echo reply sent, src 10.10.10.1, dst 10.111.111.1

Ein entscheidender Nachteil dieser Methode ist, dass diese Adress-Übersetzung immer durchgeführt wird und ein Router mit dieser Konfiguration nicht mehr sinnvoll für andere Verbindungen verwendet werden kann. Diese Translation dürfte eigentlich nur verwendet werden, wenn das gegenüberliegende NAT-Netz angesprochen wird.
Diese Bedingung — die auf der PIX/ASA per Policy-NAT einfach umzusetzen ist — würde auf einem IOS-Router mit einer Route-Map beschrieben werden. Diese Route-Maps können aber leider in einer statischen Translation nicht verwendet werden, wenn ganze Netze übersetzt werden.

VPNs zwischen Standorten mit überlappenden Adressen

Spambots können rechnen …

… sind aber trotzdem dumm! 🙂

Bisher hatte ich gegen Kommentar-Spams nur ein Plugin aktiviert, das eine einfache Rechenaufgabe gestellt hat. Lange Zeit war das absolut ausreichend. Vor einigen Tagen ging es aber los, dass es jeden Tag doch ca. 30 bis 40 automatisierte Spams geschafft haben. Die wurden zwar alle als Spam markiert, mussten aber schon noch durchgeschaut werden, ob nicht doch ein “normaler” Kommentar dabei war (bisher allerdings nicht). Jetzt habe ich das Plugin NoSpamNX laufen, das ein paar versteckte Felder bei den Kommentaren einfügt. Wenn die auch ausgefüllt werden, kann das kein Mensch gewesen sein, denn der hätte das Feld nicht gesehen. Diese Kommentare gehen gleich in die Mülltonne und das automatisierte Spam-Aufkommen ist wieder bei Null.

Spambots können rechnen …