11
Einheitliche VPN-Verbindung über ISA-Server
Hallo Leute!
Bin am Re-Organisieren eines Netzwerks, und langsam wird's ernst: Es handelt sich um ein öffentliches Gebäude mit mehreren AccessPoints, die jedoch nur bestimmte Personengruppen benützen dürfen. Diese sind im AD angelegt.
Meine Vorstellung ist folgende: Zwei DCs, die entweder beide oder einzeln für AD, DHCP, DNS, DFS zuständig sind. Nach außen hängen wir über Glasfaser am Internet. Abgesichert hätte ich dieses über einen ISA-Server. In der DMZ stehen der Web- und der Edge-Transport-Server. Jetzt gibt's bei uns ca. 100 Stand-PCs (die sind eh kein Problem) und nochmals ca. 100 Laptop-Benutzer, die laufend quer durchs Haus laufen und von überall über einen der AccessPoints ins Netzwerk/Internet müssen.
Den ISA-Server hänge ich aus Sicherheitsgründen nicht in die Domäne. Um dem Broadcast-Traffic möglichst gering zu halten, möchte ich mehre Subnetze einrichten. Um nicht zig NICs in die Server einbauen zu müssen, möchte ich die Subnetze über VLANs realisieren.
Um den Zugriff auf die einzelnen Netze genau steuern zu können (z.B. Absicherung des Verwaltungsnetzes, ...), müssen - zumindest meinem bisherigen Verständnis nach - alle Netze am ISA-Server zusammenlaufen. Sprich mein ISA-Server kontrolliert, sagen wir mal, 10 Subnetze: 192.168.0.x/24, 192.168.1.x/24, ..., 192.168.9.x/24. Da die Laptops durchwegs private Geräte sind, und erst recht mit privaten Profilen ausgestattet sind - sprich ich kann die Laptops nicht zur Domäne hinzufügen -, möchte ich erst recht nicht auf allen die Firewall-Client-Software des ISA-Servers installieren. Andererseits brauche ich eine Authentifizierung. Jetzt werde ich das über eine VPN-Verbindung realisieren.
Sodala, jetzt fangen die Probleme an: Wenn ich meine Leute über den ISA-Server (diesen als RADIUS-Client an einen DC angebunden), müsste ja jeder 10 verschiedene VPN-Verbindungen auf dier unterschiedlichen IP-Adressen der Subnetzs/NICs eingerichtet haben und je nach Standort die richtige erwischen --> nicht durchführbar. Oder aber ich schicke die VPN-Verbindung direkt an einen DC. Aber sind die Clients dann noch gemäß ISA-Server authentifzierte Benutzer (SecureNAT + VPN-Verbindung = authentifizierter Benutzer).
Weiß jemand aus (sicherer) Erfahrung, dass letztere Methode funktioniert? Oder gibt es Alternativen?
Danke, Stefan
Bin am Re-Organisieren eines Netzwerks, und langsam wird's ernst: Es handelt sich um ein öffentliches Gebäude mit mehreren AccessPoints, die jedoch nur bestimmte Personengruppen benützen dürfen. Diese sind im AD angelegt.
Meine Vorstellung ist folgende: Zwei DCs, die entweder beide oder einzeln für AD, DHCP, DNS, DFS zuständig sind. Nach außen hängen wir über Glasfaser am Internet. Abgesichert hätte ich dieses über einen ISA-Server. In der DMZ stehen der Web- und der Edge-Transport-Server. Jetzt gibt's bei uns ca. 100 Stand-PCs (die sind eh kein Problem) und nochmals ca. 100 Laptop-Benutzer, die laufend quer durchs Haus laufen und von überall über einen der AccessPoints ins Netzwerk/Internet müssen.
Den ISA-Server hänge ich aus Sicherheitsgründen nicht in die Domäne. Um dem Broadcast-Traffic möglichst gering zu halten, möchte ich mehre Subnetze einrichten. Um nicht zig NICs in die Server einbauen zu müssen, möchte ich die Subnetze über VLANs realisieren.
Um den Zugriff auf die einzelnen Netze genau steuern zu können (z.B. Absicherung des Verwaltungsnetzes, ...), müssen - zumindest meinem bisherigen Verständnis nach - alle Netze am ISA-Server zusammenlaufen. Sprich mein ISA-Server kontrolliert, sagen wir mal, 10 Subnetze: 192.168.0.x/24, 192.168.1.x/24, ..., 192.168.9.x/24. Da die Laptops durchwegs private Geräte sind, und erst recht mit privaten Profilen ausgestattet sind - sprich ich kann die Laptops nicht zur Domäne hinzufügen -, möchte ich erst recht nicht auf allen die Firewall-Client-Software des ISA-Servers installieren. Andererseits brauche ich eine Authentifizierung. Jetzt werde ich das über eine VPN-Verbindung realisieren.
Sodala, jetzt fangen die Probleme an: Wenn ich meine Leute über den ISA-Server (diesen als RADIUS-Client an einen DC angebunden), müsste ja jeder 10 verschiedene VPN-Verbindungen auf dier unterschiedlichen IP-Adressen der Subnetzs/NICs eingerichtet haben und je nach Standort die richtige erwischen --> nicht durchführbar. Oder aber ich schicke die VPN-Verbindung direkt an einen DC. Aber sind die Clients dann noch gemäß ISA-Server authentifzierte Benutzer (SecureNAT + VPN-Verbindung = authentifizierter Benutzer).
Weiß jemand aus (sicherer) Erfahrung, dass letztere Methode funktioniert? Oder gibt es Alternativen?
Danke, Stefan
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 81595
Url: https://administrator.de/forum/einheitliche-vpn-verbindung-ueber-isa-server-81595.html
Ausgedruckt am: 23.12.2024 um 06:12 Uhr
11 Kommentare
Neuester Kommentar
Du machst einen Denkfehler was das Thema Routing in deinem Netz anbetrifft. Natürlich ist es unsinnig 10 VPN Verbindungen anzunehmen, aber das hast du dir sicher schon selber gedacht...
Normalerweise würde man in so einem Szenario das WLAN abtrennen und mit einem separaten Subnetz betreiben, was du richtigerweise ja auch vorhast. Generell ist dein Weg absolut der Richtige das gesamte Netzwerk so zu segmentieren.
Wenn nun dein WLAN ein separates Netz ist, dann kommen über dieses Netz die Clients generell in den Netz. Da du schon eine Benutzerauthentifizierung mit 802.1x machst oder planst und so die Clients eindeutig authentifizierst (Vermutlich wirst du ja auch WPA(2) als Verschlüsselung) nehmen fragt man sich was denn ein VPN auf dem WLAN noch für einen tieferen Sinn haben sollte ??
Ein VPN auf dem WLAN macht nur Sinn wenn du ein offenes WLAN betreiben willst um so Sicherheit über das WLAN herzustellen. (VPN über ein WPA-2 gesichertes WLAN ist eigentlich Unsinn und erzeugt dir sinnlosen Overhead im WLAN die deine Performance drastisch und unsinnigerweise senken würde..!)
Benutzt du aber eine Radius basierende Benutzerauthentifizierung, wie du sie ja planst, ist dies zumeist überflüssig.
Alle auf diesem WLAN VLAN Subnetz eingehenden Verbindungen werden ja über den Router der alles VLANs zusammenführt (in deinem Falle willst du das ja mit einem Server realisieren) auch in die anderen Subnetze problemlos geroutet. Von einer Verbindung mit 10 Subnetzen kann also keine Rede sein, was natürlich auch unsinnig wäre.
Mit der Firewall oder Accesslisten kannst du nun genau bestimmen welche Dienste aus dem WLAN in den anderen Subnetzen (VLANs) erreichbar sein sollten und/oder welche Subnetze bei Bedarf z.B. aus Sicherheit ganz abgeschottet werden vom Zugriff aus dem WLAN.
Das ist ein gängiges und normales Szenario wie man ein solches Netz aufzieht.
Es ist ebenso unsinnig 10 NICs in die Server zu setzen. Eine einzige NIC (oder auch 2) die VLAN Tagging nach 802.1q supporten (alle modernen und guten Karten können das..) erledigen das vollkommen problemlos wie dir dieses Tutorial ganz genau erklärt:
Technisch besser ist es in jedem Falle bei der Größenordnung deines Netzes und der Anzahl der VLANs Layer 3 fähige Switches, also Routing fähige Switches im Core zu verwenden wie jeder Switchhersteller sie im Portfolio hat ! Damit kannst du mit dem VRRP Protokoll sogar ein Hochverfügbarkeits Design umsetzen.
Das gesamte Routing Geschäft und auch die Redundanz (sofern gewollt) legst du so auf die eigentliche Netzwerk Infrastruktur wo sie eigentlich auch hingehört und hälst es somit von den Servern fern, die niemals gute Router sind. Abgesehen belastet man die Server sehr startk mit Packet Forwarding Diensten was auf die Performance von anderen Diensten schlägt.
Routende Server sollten somit immer wenig andere Netzdienste anbieten sofern man überhaupt mit Servern routen muss.
Auch bei der technisch erheblich besseren Switchlösung ist ein granularer Zugang über Accesslisten nach Diensten usw. problemlos konfigurierbar !
Diese Vorgangsweise ist ein erheblich besserer und auch performanterer Weg dein Design umzusetzen. Von der späteren Managebarkeit einmal ganz abgesehen !
Normalerweise würde man in so einem Szenario das WLAN abtrennen und mit einem separaten Subnetz betreiben, was du richtigerweise ja auch vorhast. Generell ist dein Weg absolut der Richtige das gesamte Netzwerk so zu segmentieren.
Wenn nun dein WLAN ein separates Netz ist, dann kommen über dieses Netz die Clients generell in den Netz. Da du schon eine Benutzerauthentifizierung mit 802.1x machst oder planst und so die Clients eindeutig authentifizierst (Vermutlich wirst du ja auch WPA(2) als Verschlüsselung) nehmen fragt man sich was denn ein VPN auf dem WLAN noch für einen tieferen Sinn haben sollte ??
Ein VPN auf dem WLAN macht nur Sinn wenn du ein offenes WLAN betreiben willst um so Sicherheit über das WLAN herzustellen. (VPN über ein WPA-2 gesichertes WLAN ist eigentlich Unsinn und erzeugt dir sinnlosen Overhead im WLAN die deine Performance drastisch und unsinnigerweise senken würde..!)
Benutzt du aber eine Radius basierende Benutzerauthentifizierung, wie du sie ja planst, ist dies zumeist überflüssig.
Alle auf diesem WLAN VLAN Subnetz eingehenden Verbindungen werden ja über den Router der alles VLANs zusammenführt (in deinem Falle willst du das ja mit einem Server realisieren) auch in die anderen Subnetze problemlos geroutet. Von einer Verbindung mit 10 Subnetzen kann also keine Rede sein, was natürlich auch unsinnig wäre.
Mit der Firewall oder Accesslisten kannst du nun genau bestimmen welche Dienste aus dem WLAN in den anderen Subnetzen (VLANs) erreichbar sein sollten und/oder welche Subnetze bei Bedarf z.B. aus Sicherheit ganz abgeschottet werden vom Zugriff aus dem WLAN.
Das ist ein gängiges und normales Szenario wie man ein solches Netz aufzieht.
Es ist ebenso unsinnig 10 NICs in die Server zu setzen. Eine einzige NIC (oder auch 2) die VLAN Tagging nach 802.1q supporten (alle modernen und guten Karten können das..) erledigen das vollkommen problemlos wie dir dieses Tutorial ganz genau erklärt:
Technisch besser ist es in jedem Falle bei der Größenordnung deines Netzes und der Anzahl der VLANs Layer 3 fähige Switches, also Routing fähige Switches im Core zu verwenden wie jeder Switchhersteller sie im Portfolio hat ! Damit kannst du mit dem VRRP Protokoll sogar ein Hochverfügbarkeits Design umsetzen.
Das gesamte Routing Geschäft und auch die Redundanz (sofern gewollt) legst du so auf die eigentliche Netzwerk Infrastruktur wo sie eigentlich auch hingehört und hälst es somit von den Servern fern, die niemals gute Router sind. Abgesehen belastet man die Server sehr startk mit Packet Forwarding Diensten was auf die Performance von anderen Diensten schlägt.
Routende Server sollten somit immer wenig andere Netzdienste anbieten sofern man überhaupt mit Servern routen muss.
Auch bei der technisch erheblich besseren Switchlösung ist ein granularer Zugang über Accesslisten nach Diensten usw. problemlos konfigurierbar !
Diese Vorgangsweise ist ein erheblich besserer und auch performanterer Weg dein Design umzusetzen. Von der späteren Managebarkeit einmal ganz abgesehen !
Hai!
Ich glaub, wir sollten privat weiterquatschen
Aber ehrlich, ich bin echt froh, dass mir da wer kompetent weiterhilft. Manchmal hab ich echt einen Knoten im Hirn, der nicht aufgehen will...
Meine WLANs sind offen, das ist korrekt. Das hat einen ganz bestimmten Hintergrund, denn einige der AccessPoints sind nämlich transportabel - ergo ist der Reset-Switch frei zugänglich und wird auch fleißig gedrückt. Das ist Tatsache und lässt sich nicht ändern (das ist 'ne eigene Geschichte).
Da ich die Reset-Buttons auch nicht grad ausbauen will (wozu ich aber langsam ehrlich Lust hätte...), dachte ich mir, ich lasse die AccessPOints offen und sichere über VPN ab. Damit stelle ich erstens serverseitig und zweitens zu 100% sicher, dass die Benutzer nur aus der Organisation kommen.
Ich bin froh, dass ich mit meinem Konzept auf dem halbwegs richtigen Dampfer bin. Ich hatte das früher schon mal da gepostet: Beim Netzwerkdesign bin ich leider echter Newbie. Aber genau deswegen frag ich ja hier.
Was mir bloß (noch) nicht eingeht ist, wie ich die (einheitliche) VPN-Verbindung auf den Clients dann konfigurieren muss, wenn meine Gedanken bis dato passen: Durch die VLAN-Konfiguration werden mir am ISA-Server - bleiben wir bei den 10 - 10 Netzwerkkarten dargestellt mit der jeweiligen IP-Konfiguration. Also hat mein ISA-Server die IP-Adressen
Oje... - VIELEN DANK für die Geduld mit mir!
LGs Stefan
Ich glaub, wir sollten privat weiterquatschen
Aber ehrlich, ich bin echt froh, dass mir da wer kompetent weiterhilft. Manchmal hab ich echt einen Knoten im Hirn, der nicht aufgehen will...Meine WLANs sind offen, das ist korrekt. Das hat einen ganz bestimmten Hintergrund, denn einige der AccessPoints sind nämlich transportabel - ergo ist der Reset-Switch frei zugänglich und wird auch fleißig gedrückt. Das ist Tatsache und lässt sich nicht ändern (das ist 'ne eigene Geschichte).
Da ich die Reset-Buttons auch nicht grad ausbauen will (wozu ich aber langsam ehrlich Lust hätte...), dachte ich mir, ich lasse die AccessPOints offen und sichere über VPN ab. Damit stelle ich erstens serverseitig und zweitens zu 100% sicher, dass die Benutzer nur aus der Organisation kommen.
Ich bin froh, dass ich mit meinem Konzept auf dem halbwegs richtigen Dampfer bin. Ich hatte das früher schon mal da gepostet: Beim Netzwerkdesign bin ich leider echter Newbie. Aber genau deswegen frag ich ja hier.
Was mir bloß (noch) nicht eingeht ist, wie ich die (einheitliche) VPN-Verbindung auf den Clients dann konfigurieren muss, wenn meine Gedanken bis dato passen: Durch die VLAN-Konfiguration werden mir am ISA-Server - bleiben wir bei den 10 - 10 Netzwerkkarten dargestellt mit der jeweiligen IP-Konfiguration. Also hat mein ISA-Server die IP-Adressen
- 192.168.0.1: Servernetz mit DC (192.168.0.2), ...
- 192.168.1.1: WLAN 1
- 192.168.2.1: WLAN 2
- 192.168.3.1: ...
- ...
- 192.168.9.1: ...
Oje... - VIELEN DANK für die Geduld mit mir!
LGs Stefan
Hallo Stefan,
Eins ist etwas unklar: Sind alle VLANs mit Ausnahme des .0.0er Netzes deine WLAN Subnetze bzw. VLANs ? Vermutlich wohl ja, denn bei 100 mobilen Clients insgesamt macht es schon Sinn die Netze etwas zu segmentieren. Allerdings solltest du dich fragen ob es wirklich so viele Subnetze sein müssen...
Wenn jeder AP mit einer 100 Mbit/s Leitung an den Switch angeschlossen ist würden auch sicher 3 VLANs reichen, also ggf. eine Aufteilung pro Stockwerk. Du hast ja keine Any to Any Kommunikation vermutlich mit den Clients sondern wohl eher Internet oder Serverbasierend, so das eine so hohe Aufteilung in Subnetze sich nicht nötig ist und es reicht wenn man ein paar APs in einem VLAN kumuliert.
In der Tat etwas ungewöhnlich mit einem offenen VLAN aber wenn die Infrastruktur bei dir so ist musst du damit leben.
Man könnte noch daruüber nachdenken um nicht allen Tür und Tor zu öffenen ein sog. "Captive Portal" dazwischenzuschalten. Das ist eine Zwangswebseite die automatisch sich öffnet wenn man den Browser startet und in die man sich mit einem Weblogin einloggen muss um überhaupt ins WLAN zu kommen. Danach könnte man dann den VPN Client z.B. mit dem Windows PPTP Client starten. Ist die Frage ob deine Benutzer mit einem doppelten Login klarkommen aber das ist eine administrative Frage, keine technische...
So oder so musst du dich aber von einem Denkfehler befreien. Auch wenn du angenommen 10 Subnetze/VLANs hast in denen sich deine WLAN Clients verteilt befinden spielt deren IP Adressierung doch keinerlei Rolle. Auch wenn du 20 Subnetze hast wäre es egal.
Dein VPN Tunnelendpunkt zu dem alle deine Clients den Tunnel aufbauen ist doch eine feste IP Adresse in einem Netz/Subnetz und die zählt. Welche Quelladresse der Client hat spielt keine Rolle. Draf es auch gar nicht, denn du wirst ja vermutlich DHCP in den WLAN Subnetzen nutzen wollen und dann ändern sich die Quell IPs deiner Clients täglich.
Vergleiche es etwas mit dem Internet und jemanden der 10 Filialen und eine Verwaltung hat. Alle 10 Filialen haben unterschiedliche IPs, die sogar wechseln können aber die IP Adresse des VPN Tunnel Endpunktes in der Verwaltung ist fix, denn dahin wird der VPN Tunnel aufgebaut.
Analog ist es bei dir !
Der Radius Server der die 802.1x Authentifizierung der WLAN Clients vornimmt sieht nur den Benutzernamen/Passwort oder ein Zertifikat (bessere Methode), die IP Adresse aber interessiert ihn nicht, da die Radius Abfrage der Accesspoint macht.
Du solltest dich allerdings fragen ob ein MS Server die Anzahl von 100 gleichzeitigen VPN Sessions verkraftet. Ggf. ist es besser dies mit einer Firewall Appliance zu machen die erheblich performanter und skalierbarer ist.
Es hätte noch den schönen Nebeneffekt, das du deine WLAN Subnetze auch noch wasserdicht absichern kannst indem du nur die Ports deines verwendeten VPN Tunnelprotokolls durchlässt und das auch nur auf die Ziel IP des VPN Servers. Alle Daten werden ja über den Tunnel übertragen. Damit sicherst du dein WLAN dann nebenbei gleich gegen Eindringlinge ab.
Damit sollte dein Projekt problemlos realisierbar sein !
Eins ist etwas unklar: Sind alle VLANs mit Ausnahme des .0.0er Netzes deine WLAN Subnetze bzw. VLANs ? Vermutlich wohl ja, denn bei 100 mobilen Clients insgesamt macht es schon Sinn die Netze etwas zu segmentieren. Allerdings solltest du dich fragen ob es wirklich so viele Subnetze sein müssen...
Wenn jeder AP mit einer 100 Mbit/s Leitung an den Switch angeschlossen ist würden auch sicher 3 VLANs reichen, also ggf. eine Aufteilung pro Stockwerk. Du hast ja keine Any to Any Kommunikation vermutlich mit den Clients sondern wohl eher Internet oder Serverbasierend, so das eine so hohe Aufteilung in Subnetze sich nicht nötig ist und es reicht wenn man ein paar APs in einem VLAN kumuliert.
In der Tat etwas ungewöhnlich mit einem offenen VLAN aber wenn die Infrastruktur bei dir so ist musst du damit leben.
Man könnte noch daruüber nachdenken um nicht allen Tür und Tor zu öffenen ein sog. "Captive Portal" dazwischenzuschalten. Das ist eine Zwangswebseite die automatisch sich öffnet wenn man den Browser startet und in die man sich mit einem Weblogin einloggen muss um überhaupt ins WLAN zu kommen. Danach könnte man dann den VPN Client z.B. mit dem Windows PPTP Client starten. Ist die Frage ob deine Benutzer mit einem doppelten Login klarkommen aber das ist eine administrative Frage, keine technische...
So oder so musst du dich aber von einem Denkfehler befreien. Auch wenn du angenommen 10 Subnetze/VLANs hast in denen sich deine WLAN Clients verteilt befinden spielt deren IP Adressierung doch keinerlei Rolle. Auch wenn du 20 Subnetze hast wäre es egal.
Dein VPN Tunnelendpunkt zu dem alle deine Clients den Tunnel aufbauen ist doch eine feste IP Adresse in einem Netz/Subnetz und die zählt. Welche Quelladresse der Client hat spielt keine Rolle. Draf es auch gar nicht, denn du wirst ja vermutlich DHCP in den WLAN Subnetzen nutzen wollen und dann ändern sich die Quell IPs deiner Clients täglich.
Vergleiche es etwas mit dem Internet und jemanden der 10 Filialen und eine Verwaltung hat. Alle 10 Filialen haben unterschiedliche IPs, die sogar wechseln können aber die IP Adresse des VPN Tunnel Endpunktes in der Verwaltung ist fix, denn dahin wird der VPN Tunnel aufgebaut.
Analog ist es bei dir !
Der Radius Server der die 802.1x Authentifizierung der WLAN Clients vornimmt sieht nur den Benutzernamen/Passwort oder ein Zertifikat (bessere Methode), die IP Adresse aber interessiert ihn nicht, da die Radius Abfrage der Accesspoint macht.
Du solltest dich allerdings fragen ob ein MS Server die Anzahl von 100 gleichzeitigen VPN Sessions verkraftet. Ggf. ist es besser dies mit einer Firewall Appliance zu machen die erheblich performanter und skalierbarer ist.
Es hätte noch den schönen Nebeneffekt, das du deine WLAN Subnetze auch noch wasserdicht absichern kannst indem du nur die Ports deines verwendeten VPN Tunnelprotokolls durchlässt und das auch nur auf die Ziel IP des VPN Servers. Alle Daten werden ja über den Tunnel übertragen. Damit sicherst du dein WLAN dann nebenbei gleich gegen Eindringlinge ab.
Damit sollte dein Projekt problemlos realisierbar sein !
Guten Morgen!
Nein, es sind nicht alles WLAN-Netze. Ich habe ca. 5 Rechner in der Verwaltung stehen, einige "EDV-Säle" mit jeweils ca. 15 PCs, die rund 100 Laptop-Benutzer und dann kommen nochmals rund 20 PCs dazu, die im gesamten Gebäude fest verkabelt, teils in abgesperrten Räumen, teils als öffentlich (für Mitarbeiter) zugänglich herumstehen.
Ganz konkret hätte ich mir die Netzwerkstruktur so gedacht:
Die Idee mit dem Captive Portal klingt interessant. Ich hab mich schon immer gefragt, wie man sowas realisiert! Allerdings möchte ich doppelte Anmeldungen tunlichst vermeiden. Und damit muss ich wohl die Windows-integrierte Authentifizierung hernehmen. Selbst da muss ich mich ja einerseits für die VPN- und andererseits dann für die Freigaben anmelden. Ist das schon verwirrend genug für die User.
Aber der Denkfehler ist leider immer noch nicht weg. Von jedem Subnetz aus gesehen hat der Server doch eine andere IP-Adresse: 192.168.0.254 im Verwaltungsnetz, 192.168.11.254 im WLAN 1, 192.168.12.254 im WLAN 2 etc. Wenn ich die VPN-Verbindung zum ISA-Server aufbaue, muss ich doch immer die jeweilige Server-IP ansprechen, oder? Das die Client-IP dabei keine Rolle spielt, ist klar.
Verträgt ein HP ProLiant QuadCore 4x1,86 GHz, 4GB RAM, 3 SAS-Platten 100 VPN-Clients?
LGs Stefan
Nein, es sind nicht alles WLAN-Netze. Ich habe ca. 5 Rechner in der Verwaltung stehen, einige "EDV-Säle" mit jeweils ca. 15 PCs, die rund 100 Laptop-Benutzer und dann kommen nochmals rund 20 PCs dazu, die im gesamten Gebäude fest verkabelt, teils in abgesperrten Räumen, teils als öffentlich (für Mitarbeiter) zugänglich herumstehen.
Ganz konkret hätte ich mir die Netzwerkstruktur so gedacht:
- 192.168.0.x/24: Verwaltungsnetz (6 PCs, aus Sicherheitsgründen für ISA segmentiert)
- 192.168.1.x/24: EDV 1 (15 PCs)
- 192.168.2.x/24: EDV 2 (15 PCs)
- 192.168.3.x/24: EDV 3 (15 PCs)
- 192.168.11.x/24: WLAN 1 (15-50 PCs, je nachdem... (gilt für alle APs))
- 192.168.12.x/24: WLAN 2
- 192.168.13.x/24: WLAN 3
- 192.168.14.x/24: WLAN 4
- 192.168.15.x/24: WLAN 5
- 192.168.20.x/24: Bibliothek, Surfstations (öffentliche PCs), ...
- 192.168.21.x/24: andere PCs (über 150 Netzwerksteckdosen, die aber selten genutzt werden)
- 192.168.100.x/24: Servernetz mit 2 DCs (AD, DHCP, DNS, DFS, Exchange, Certi, ....)
- 192.168.101.x/24: DMZ mit Webserver, Edge-Transport, WSUS, ...
Die Idee mit dem Captive Portal klingt interessant. Ich hab mich schon immer gefragt, wie man sowas realisiert! Allerdings möchte ich doppelte Anmeldungen tunlichst vermeiden. Und damit muss ich wohl die Windows-integrierte Authentifizierung hernehmen. Selbst da muss ich mich ja einerseits für die VPN- und andererseits dann für die Freigaben anmelden. Ist das schon verwirrend genug für die User.
Aber der Denkfehler ist leider immer noch nicht weg. Von jedem Subnetz aus gesehen hat der Server doch eine andere IP-Adresse: 192.168.0.254 im Verwaltungsnetz, 192.168.11.254 im WLAN 1, 192.168.12.254 im WLAN 2 etc. Wenn ich die VPN-Verbindung zum ISA-Server aufbaue, muss ich doch immer die jeweilige Server-IP ansprechen, oder? Das die Client-IP dabei keine Rolle spielt, ist klar.
Verträgt ein HP ProLiant QuadCore 4x1,86 GHz, 4GB RAM, 3 SAS-Platten 100 VPN-Clients?
LGs Stefan
Oha, ein Fehler vorweg:
"Der Netzwerkkarte auf dem ISA-Server ist jeweils die x.y.z.254/32 - Adresse zugewiesen..."
Das darfst du nicht machen ! Der Server hat in den Bereichen keine Hostmaske mit 32 Bit sondern genau dieselbe Maske wie die Endgeräte auch mit 24 Bit sonst hast du eine Inkonsistenz im IP Netz bzw. der Adressierung !
OK, das vereinfacht die Sache wenn nicht alles WLANs sind, das Prinzip bleibt aber.
Zu deinem Denkproblem: In der Theorie hast du Recht, denn du könntest den server über all seine Gateway Adressen ansprechen. In der Praxis ist das Unsinn und das macht man nicht. Du generierst ein weiteres VPN VLAN mit einer Server IP oder besser hängst die VPN Server IP mit in dein DMZ Segment mit der .101.
Und NUR and diese IP Adresse bindest du den VPN Server, so das der nur auf eine einzige IP Adresse hört !
Das macht auch den Aufwand der Filterung (Accesslisten, Firewall) handhabbar, so das du Traffic aus den WLANs z.B. nur auf diese IP zulässt wie vorab beschrieben, alles andere ist Overkill.
Die .254er Adressen sind dann reine Routing Gateway IPs.
Ein Captive Portal kann man mit freien Bordmitteln z.B. mit Zeroshell oder auch M0n0wall realisieren:
http://www.zeroshell.net/eng/captiveportaldetails/
Das auf einem alten Rechner der statt Platten eine IDE-Compact-Flashkarte hat (Zeroshell gibts gleich als Flashcard Image zum Download) und 2 Netzwerkkarten ist ein gangbarer Weg. Zum Testen und spielen kannst du Zeroshell auch auf eine Live Boot CD brennen und einen PC damit direkt booten.
Einige WLAN Hersteller bieten sowas auch komplett mit ihrer WLAN Lösung an was aber vermutlich für dich nicht interessant ist, da du ja schon eine WLAN Infrastruktur hast.
"Der Netzwerkkarte auf dem ISA-Server ist jeweils die x.y.z.254/32 - Adresse zugewiesen..."
Das darfst du nicht machen ! Der Server hat in den Bereichen keine Hostmaske mit 32 Bit sondern genau dieselbe Maske wie die Endgeräte auch mit 24 Bit sonst hast du eine Inkonsistenz im IP Netz bzw. der Adressierung !
OK, das vereinfacht die Sache wenn nicht alles WLANs sind, das Prinzip bleibt aber.
Zu deinem Denkproblem: In der Theorie hast du Recht, denn du könntest den server über all seine Gateway Adressen ansprechen. In der Praxis ist das Unsinn und das macht man nicht. Du generierst ein weiteres VPN VLAN mit einer Server IP oder besser hängst die VPN Server IP mit in dein DMZ Segment mit der .101.
Und NUR and diese IP Adresse bindest du den VPN Server, so das der nur auf eine einzige IP Adresse hört !
Das macht auch den Aufwand der Filterung (Accesslisten, Firewall) handhabbar, so das du Traffic aus den WLANs z.B. nur auf diese IP zulässt wie vorab beschrieben, alles andere ist Overkill.
Die .254er Adressen sind dann reine Routing Gateway IPs.
Ein Captive Portal kann man mit freien Bordmitteln z.B. mit Zeroshell oder auch M0n0wall realisieren:
http://www.zeroshell.net/eng/captiveportaldetails/
Das auf einem alten Rechner der statt Platten eine IDE-Compact-Flashkarte hat (Zeroshell gibts gleich als Flashcard Image zum Download) und 2 Netzwerkkarten ist ein gangbarer Weg. Zum Testen und spielen kannst du Zeroshell auch auf eine Live Boot CD brennen und einen PC damit direkt booten.
Einige WLAN Hersteller bieten sowas auch komplett mit ihrer WLAN Lösung an was aber vermutlich für dich nicht interessant ist, da du ja schon eine WLAN Infrastruktur hast.
Hallo Aqui!
Bei der Subnetz-Maske hab ich mich halb-vertippt. Ich meinte damit, dass die IP fest ist, die Subnet-Mask bleibt aber natürlich dieselbe im Netz. Sorry für die Ungenauigkeit.
Ich hab mir jetzt lang den Kopf drüber zerbrochen, aber ich komm nicht drauf, wie sich die Idee mit dem weiteren VLAN (VPN VLAN??) realisieren lässt. Das ist jetzt leider der Punkt, an dem ich echt aussteige. Kannst du mir da irgendwelche Unterlagen/Links empfehlen, dass nicht du da deine kostbare Zeit mit meinen Hirn-Knoten verbringen musst? Ich bräuchte da echt eine ausführliche, detaillierte Erklärung/Beschreibung!
Danke auf für die Tipps mit dem Captive Portal. Muss ich mir mal genauer ansehen.
Danke, Stefan
Bei der Subnetz-Maske hab ich mich halb-vertippt. Ich meinte damit, dass die IP fest ist, die Subnet-Mask bleibt aber natürlich dieselbe im Netz. Sorry für die Ungenauigkeit.
Ich hab mir jetzt lang den Kopf drüber zerbrochen, aber ich komm nicht drauf, wie sich die Idee mit dem weiteren VLAN (VPN VLAN??) realisieren lässt. Das ist jetzt leider der Punkt, an dem ich echt aussteige. Kannst du mir da irgendwelche Unterlagen/Links empfehlen, dass nicht du da deine kostbare Zeit mit meinen Hirn-Knoten verbringen musst? Ich bräuchte da echt eine ausführliche, detaillierte Erklärung/Beschreibung!
Danke auf für die Tipps mit dem Captive Portal. Muss ich mir mal genauer ansehen.
Danke, Stefan
Du musst nicht unbedingt ein weiteres VPN VLAN nehmen. Du hast doch schon eine DMZ bzw. ein DMZ VLAN. Das bietet sich doch förmlich an das damit zu machen.
Hier hängst du auch das Serverbein (IP Interface für das VLAN) rein was der VPN Server bedient und bindest nur den VPN Server Service an diese IP.
Für alle Clients im WLAN ist dann diese IP die Ziel IP für ihren VPN Tunnel.
Ist doch eigentlich ganz einfach...oder ?!
Hier hängst du auch das Serverbein (IP Interface für das VLAN) rein was der VPN Server bedient und bindest nur den VPN Server Service an diese IP.
Für alle Clients im WLAN ist dann diese IP die Ziel IP für ihren VPN Tunnel.
Ist doch eigentlich ganz einfach...oder ?!
Eigentlich schon 
Serverbei?
"Den VPN Server Service an die IP-Adressen binden" heißt...? Einen Server in die DMZ hängen, dort RRAS für VPN (nicht LAN-Routing) aktivieren und als RADIUS-Client an einen der AD-Server hängen. Versteh ich das richtig?
Hier hängst du auch das Serverbei rein was der VPN Server bedient und bindest nur den VPN Server Service an diese IP
Serverbei?
"Den VPN Server Service an die IP-Adressen binden" heißt...? Einen Server in die DMZ hängen, dort RRAS für VPN (nicht LAN-Routing) aktivieren und als RADIUS-Client an einen der AD-Server hängen. Versteh ich das richtig?
...korrigiert !
Ja das ist richtig. Das müssen nur nicht unterschiedliche Maschinen sein, das kann auch ein einzelner machen. Allerdings sollte man Routing und VPN ggf. trennen wegen der Ausfallsicherheit.
Ja das ist richtig. Das müssen nur nicht unterschiedliche Maschinen sein, das kann auch ein einzelner machen. Allerdings sollte man Routing und VPN ggf. trennen wegen der Ausfallsicherheit.
Okay, eine letzte Zusammenfassung (in diesem Thread ) für mein Verständnis...
ISA-Server als LAN-Router mit 3 Netzwerkkarten verwaltet die ganzen VLANs (1. NIC) sowie die DMZ (2. NIC) und das Internet (3. NIC). Am ISA-Server läuft das LAN-Routing. In der DMZ stehen ein oder mehrere Server, die sich die Aufgaben Webserver, Datenbankserver, ... und v.a. VPN-Routing aufteilen. Der VPN-Router-Server wird als RADIUS-Client an einen IAS auf einem DC zwecks Authentifizierung gebunden.
Soweit so einfach so gut Jetzt muss ich bloß noch ausprobieren, ob der ISA-Server diese Kombination aus SecureNAT-Client und VPN-Client (der jedoch nicht am ISA-Server verwaltet wird), gemeinsam als "authentifizierter Benutzer" erkennt...
DANKE für all die Hilfe! Steff
) für mein Verständnis...ISA-Server als LAN-Router mit 3 Netzwerkkarten verwaltet die ganzen VLANs (1. NIC) sowie die DMZ (2. NIC) und das Internet (3. NIC). Am ISA-Server läuft das LAN-Routing. In der DMZ stehen ein oder mehrere Server, die sich die Aufgaben Webserver, Datenbankserver, ... und v.a. VPN-Routing aufteilen. Der VPN-Router-Server wird als RADIUS-Client an einen IAS auf einem DC zwecks Authentifizierung gebunden.
Soweit so einfach so gut
Jetzt muss ich bloß noch ausprobieren, ob der ISA-Server diese Kombination aus SecureNAT-Client und VPN-Client (der jedoch nicht am ISA-Server verwaltet wird), gemeinsam als "authentifizierter Benutzer" erkennt...DANKE für all die Hilfe! Steff
Ganz so glatt sind deine Ausführungen noch nicht:
ISA-Server als LAN-Router mit 3 Netzwerkkarten verwaltet die ganzen VLANs (1. NIC) sowie die DMZ (2. NIC) und das Internet (3. NIC). Am ISA-Server läuft das LAN-Routing....
Ja, das ist soweit OK wenn die 1. NIC 802.1q basiertes Trunking auf den VLAN Switch Switch macht wie beschrieben.
In der DMZ stehen ein oder mehrere Server, die sich die Aufgaben Webserver, Datenbankserver, ... und v.a. VPN-Routing aufteilen.....
Nein, der letzte Part ist nicht ganz richtig ! VPN Routing macht hier keiner der Server in der DMZ sondern ja schon der ISA über die NIC-1 !! VPN Packete sind ja ganz normale IP Packete die von einem der VLANs über die NIC-1 in deine DMZ geroutet werden über das normale IP Routing !
Der VPN-Router-Server.....
Sowas gibts gar nicht ! Hier steht dein VPN Server aber der routet nicht sondern terminiert nur die VPN Tunnel von deinen Clients die diese IP über das normale Routing erreichen ! D.H. vom Client gelangen alle Daten via VLAN und NIC-1 an diese IP werden hier VPN seitig ausgepackt in intern normal weitergeroutet (..macht ja der ISA über NIC-1) wo sie denn letztendlich hinsollen...
Wo du den Radius Server (IAS bei MS) laufen lässt ist eigentlich relativ egal. Du solltest ihn auch am besten am DC laufen lassen wo dein AD ist.
So sollte das eigentlich alles problemlos laufen !
ISA-Server als LAN-Router mit 3 Netzwerkkarten verwaltet die ganzen VLANs (1. NIC) sowie die DMZ (2. NIC) und das Internet (3. NIC). Am ISA-Server läuft das LAN-Routing....
Ja, das ist soweit OK wenn die 1. NIC 802.1q basiertes Trunking auf den VLAN Switch Switch macht wie beschrieben.
In der DMZ stehen ein oder mehrere Server, die sich die Aufgaben Webserver, Datenbankserver, ... und v.a. VPN-Routing aufteilen.....
Nein, der letzte Part ist nicht ganz richtig ! VPN Routing macht hier keiner der Server in der DMZ sondern ja schon der ISA über die NIC-1 !! VPN Packete sind ja ganz normale IP Packete die von einem der VLANs über die NIC-1 in deine DMZ geroutet werden über das normale IP Routing !
Der VPN-Router-Server.....
Sowas gibts gar nicht ! Hier steht dein VPN Server aber der routet nicht sondern terminiert nur die VPN Tunnel von deinen Clients die diese IP über das normale Routing erreichen ! D.H. vom Client gelangen alle Daten via VLAN und NIC-1 an diese IP werden hier VPN seitig ausgepackt in intern normal weitergeroutet (..macht ja der ISA über NIC-1) wo sie denn letztendlich hinsollen...
Wo du den Radius Server (IAS bei MS) laufen lässt ist eigentlich relativ egal. Du solltest ihn auch am besten am DC laufen lassen wo dein AD ist.
So sollte das eigentlich alles problemlos laufen !
