Dirkg (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Dirkg (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
Zeile 65: | Zeile 65: | ||
<table> | <table> | ||
<tr> | <tr> | ||
<td><b>Name:</b></td><td>Ist frei wählbar</td> | <td><b>Name:</b></td><td>Ist frei wählbar. In diesem Beispiel <i>Netmap-Netz</i></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
Zeile 97: | Zeile 97: | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td><b>Ziel:</b></td><td>Netzwerk des Roadwarrior | <td><b>Ziel:</b></td><td>Netzwerk des Roadwarrior</td> | ||
</tr> | |||
<tr> | |||
<td><b>Dienst:</b><td>any</td> | |||
</tr> | |||
<tr> | |||
<td><b>NAT-Typ</b></td><td>NETMAP</td> | |||
</tr> | |||
<tr> | |||
<td><b>NAT-Netzwerkobjekt <b></td><td>Netmap-Netz</td> | |||
</tr> | |||
<tr> | |||
<td><b>NAT-Dienst</b></td><td>any</td> | |||
</tr> | |||
</table> | |||
===Zu beachten=== | |||
Der VPN Client muss die Verbindung neu aufbauen, damit dieser auch das korrekte Subnetz übermittelt bekommt. | |||
Der Zugriff vom Client auf einen Host im internen Netzwerk erfolgt dann über die IP-Adresse 192.168.2.x, da hier die Subnetzmaske /24 definiert wurde. Das letzte Oktet ist also die Original Host-IP. <br> | |||
Wenn wir in diesem Beispiel also den Host mit der Original IP-Adresse 192.168.0.1 ansprechen möchten, muss der Client die IP-Adresse 192.168.2.1 verwenden um diesen zu erreichen. | |||
Der Client kann hier nur mit IP-Adressen auf die Hosts im internen Netzwerk zugreifen. Eine DNS abfrage würde zur Folge haben, dass die Original IP des Host übertragen werden würde und darüber ist dieser vom Client nicht mehr erreichbar. |
Version vom 24. März 2016, 17:22 Uhr
NATten von gleichen Ziel-Subnetzen bei gleichzeitigem VPN-Verbindungsaufbau eines VPN-Client zu verschiedenen Standorten
In diesem Wiki wollen wir den Fall behandeln, wenn ein Roadwarrior gleichzeitig eine VPN Verbindung zu verschiedenen Zielen aufbaut, die aber jeweils das gleiche Subnetz verwenden. Weiterhin bekommt der VPN-Client auch noch eine Adresse aus dem gleichen Roadwarrior Pool von den VPN-Servern. In diesem Fall hätte der Client natürlich das Problem, dass er nicht zwischen den Zielen unterscheiden kann.
Hierbei kann der NAT-Typ NETMAP Abhilfe schaffen.
In unserem Beispiel nehmen wir die folgenden Vorgaben an:
Roadwarrior Pool: | 192.168.250.0/24 |
Internes Netz der Standorte: | 192.168.0.0/24 |
Netmap-Netz des ersten Standort: | 192.168.2.0/24 |
Weiterhin gehen wir davon aus, dass die SSL-VPN Roadwarrior Verbindung schon eingerichtet ist und auch funktioniert wenn nur eine einzige Verbindung aufgebaut wird.
Vorbereitungen
Zur Nutzung der NETMAP Funktion sind folgende Bedingungen zu beachten:
- Die Subnetze der am NETMAP beteiligten Objekte müssen alle die gleiche Größe haben, zum Beispiel alle /24.
- Alle beteiligten Objekte müssen eine definierte Netzwerk IP-Adresse eingetragen haben. Es dürfen also keine Schnittstellen ausgewählt werden.
Das Netzwerkobjekt des Internen Netzwerkes darf nicht auf die Schnittstelle eingerichtet sein. Dieses kann gegebenenfalls auf Adresse umgestellt werden indem der Radio-Button vor Adresse aktiviert und die Netzwerk-Adresse mit der entsprechenden Subnetzmaske in das Feld eintragen wird. In diesem Beispiel haben wir auf beiden Seiten das Netzwerk 192.168.0.0/24
Einstellung im SSL-VPN Server
Unter dem Menüpunkt befinden sich die Einstellungen für SSL-VPN. Hier wird die zu ändernde Rodwarrior-Server Instanz ausgewählt und bearbeitet.
Unter Subnetze übermitteln wird nur das Netmap-Netz eingetragen und nicht das Original Subnetz des internen Netzwerk.
Sollten weitere Subnetze an den Client übermittelt werden, muss vorher überprüft werden, dass diese nicht auch auf anderen Zielen vorhanden sind.
Netzwerkobjekte erstellen
Neben dem vorhandenen Netzwerkobjekt für den Roadwarrior, wird ein weiteres für das Netmap-Netz mit den folgenden Eigenschaften benötigt um eine entsprechende Portfilterregel zu erstellen:
Name: | Ist frei wählbar. In diesem Beispiel Netmap-Netz |
Typ: | Netzwerk (Adresse) |
Adresse: | Das Subnetz das für Netmap verwendet werden soll. In diesem Beispiel 192.168.2.0/24 |
Zone: | Die Netzwerkzone in der sich auch das Netzwerk befindet, mit deren Hosts der Client eine Verbindung per VPN hergestellt werden soll. |
Portfilterregeln
Zuletzt werden zwei Portfilterregeln benötigt.
Die erste wird schon vorhanden sein, denn die SSL-VPN Verbindung wurde ja schon angelegt und funktioniert, wenn vom Client nicht gleichzeitig eine weitere Verbindung zu einem anderen Ziel mit dem selben Subnetz aufgebaut wird.
Bei dieser Portfilterregel geht es um die grundsätzliche Steuerung der Datenübertragung vom Roadwarrior zum Internen Netzwerk mit bestimmten Diensten. Hierbei ändert sich auch nichts.
Die zweite Portfilterregel ist neu und bezieht sich auf das Netmap. Diese hat die folgenden Eigenschaften:
Quelle: | Netzwerk auf das der Roadwarrior Zugriff haben soll. In diesem Beispiel internal-network |
Ziel: | Netzwerk des Roadwarrior |
Dienst: | any |
NAT-Typ | NETMAP |
NAT-Netzwerkobjekt | Netmap-Netz |
NAT-Dienst | any |
Zu beachten
Der VPN Client muss die Verbindung neu aufbauen, damit dieser auch das korrekte Subnetz übermittelt bekommt.
Der Zugriff vom Client auf einen Host im internen Netzwerk erfolgt dann über die IP-Adresse 192.168.2.x, da hier die Subnetzmaske /24 definiert wurde. Das letzte Oktet ist also die Original Host-IP.
Wenn wir in diesem Beispiel also den Host mit der Original IP-Adresse 192.168.0.1 ansprechen möchten, muss der Client die IP-Adresse 192.168.2.1 verwenden um diesen zu erreichen.
Der Client kann hier nur mit IP-Adressen auf die Hosts im internen Netzwerk zugreifen. Eine DNS abfrage würde zur Folge haben, dass die Original IP des Host übertragen werden würde und darüber ist dieser vom Client nicht mehr erreichbar.