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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 81595
Url: https://administrator.de/contentid/81595
Ausgedruckt am: 05.11.2024 um 12:11 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 !
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 !
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.
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 ?!
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 !