Hallo,
wie kann ich dem Windows-Client beibringen, daß er für die vom DHCP-Server via option static-routes 192.168.1.0 192.168.0.2; übermittelte Routinginformation korrekt verarbeitet.
Der Linuxclient stellt die Netmask (255.255.255.0) korrekt ein, aber Windows setzt an dieser Stelle 255.255.255.255. Damit funktioniert die Route natürlich nicht.
static-routes akzeptiert aber keine Netmask-Angabe.
Das Ganze ist notwendig, weil ein 2. Router für's VPN dasteht, der nicht das Standardgateway ist.
Ciao Rico
wie kann ich dem Windows-Client beibringen, daß er für die vom DHCP-Server via option static-routes 192.168.1.0 192.168.0.2; übermittelte Routinginformation korrekt verarbeitet.
weiß ich nicht.
Der Linuxclient stellt die Netmask (255.255.255.0) korrekt ein, aber Windows setzt an dieser Stelle 255.255.255.255. Damit funktioniert die Route natürlich nicht.
static-routes akzeptiert aber keine Netmask-Angabe.
Dann ist sowieso fragwürdig, wie es zu interpretieren ist und /32 ist der sicherere Ansatz ;-)
Das Ganze ist notwendig, weil ein 2. Router für's VPN dasteht, der nicht das Standardgateway ist.
Mach doch den VPN-Router zum Default-GW (ich meine, in der Routing-Tablette des Clients) und dann dort gibt's sicher einen ICMP-Redirect, den m.W. die W-Clients sehr gut verstehen (und wenigstens früher sogar in der Routing-Tablette darstellten).
Heiko
am Mon, dem 17.01.2005, um 18:27:15 +0100 mailte Heiko Schlittermann folgendes:
Mach doch den VPN-Router zum Default-GW (ich meine, in der Routing-Tablette des Clients) und dann dort gibt's sicher einen ICMP-Redirect, den m.W. die W-Clients sehr gut verstehen (und wenigstens
ACK, zumindest zwischen 98 und 2000 klappt das. Hab ich auf Arbeit so, andere Clients hab ich nicht mit sowas. Was (manchmal) sehr eigen ist: OS/Halbe, aber eher nicht bei Routing, sondern Windows-Netzwerkumgebung. Aber da zickt Wintendo eh selbst schon genug rum...
Andreas
Andreas Kretschmer schrieb:
ACK, zumindest zwischen 98 und 2000 klappt das. Hab ich auf Arbeit so, andere Clients hab ich nicht mit sowas. Was (manchmal) sehr eigen ist:
Ja, hab dazu gelesen, daß ein Windows-DHCP-Server andere DHCP-Anweisungen sendet. Damit klappt's dann wohl auch.
Rico
Heiko Schlittermann schrieb:
option static-routes 192.168.1.0 192.168.0.2;
Der Linuxclient stellt die Netmask (255.255.255.0) korrekt ein,
Dann ist sowieso fragwürdig, wie es zu interpretieren ist und /32 ist der sicherere Ansatz ;-)
Es scheint aber so in irgendeiner RFC zu stehen, wenn ich mich recht erinnere als 'classless routing', aber vielleicht hab ich das auch falsch verstanden. Jedenfalls scheint die DHCP-Option so wohl RFC-konform zu sein, obwohl ich das auch als etwas unsinnig angesehen habe.
Das Ganze ist notwendig, weil ein 2. Router für's VPN dasteht, der nicht das Standardgateway ist.
Mach doch den VPN-Router zum Default-GW (ich meine, in der Routing-Tablette des Clients) und dann dort gibt's sicher einen
Das geht ja vielleicht noch.
ICMP-Redirect, den m.W. die W-Clients sehr gut verstehen (und wenigstens früher sogar in der Routing-Tablette darstellten).
Auf dem VPN Router das Standardgateway auf den ursprünglichen Router setzen hilft hier leider nicht. Der Router kapiert das nicht (schon das Routing selbst), von ICMP-Redirect will ich dann noch garnicht reden.
Insofern war Andreas sein Ansatz hilfreicher. ICMP-Redirect hatte ich inzwischen auch schon als Alternative gefunden, davon wird das Netzwerkdesign aber auch nicht besser. ;-) Diese Lösung sehe ich noch eher als verkorkst an. Die DHCP-Option hat dagegen regelrecht eingeladen, leider ist die wohl unvollständig.
Hab inzwischen eine andere Lösung gefunden, was wohl auch die sauberste Lösung ist:
| | WAN | -------------- | VPN-Router | -------------- | | -------------- DMZ ---------- | Firewall |------| Server | -------------- ---------- | | LAN |
Da sich die Firewallfunktion des Routers (Netgear FVS 318) ebenfalls als unbrauchbar herausstellte, wurde ein FVS 328 eingesetzt. Dort läßt sich das NAT auch abschalten, was wegen den öffentlichen IPs im DMZ nötig war. Es mußten lediglich 2 statische Routen für DMZ und LAN auf dem Router eingetragen werden. So hab ich wenigstens die vollständige Kontrolle, auch über den VPN-Verkehr. NAT wird von der Firewall selektiv nur für die Verbindungen LAN -> WAN erledigt.
Wenn ich vorher genug Zeit zum nachdenken gehabt hätte, wäre ich auch gleich auf diese Lösung gekommen, aber $CHEF hatte ja wieder mal keine Geduld. :-(
Danke nochmal für die Tips.
Ciao Rico
am Thu, dem 27.01.2005, um 15:10:50 +0100 mailte Rico Koerner folgendes:
Heiko Schlittermann schrieb:
option static-routes 192.168.1.0 192.168.0.2;
Der Linuxclient stellt die Netmask (255.255.255.0) korrekt ein,
Dann ist sowieso fragwürdig, wie es zu interpretieren ist und /32 ist der sicherere Ansatz ;-)
Es scheint aber so in irgendeiner RFC zu stehen, wenn ich mich recht erinnere als 'classless routing', aber vielleicht hab ich das auch falsch verstanden.
Lies News:Message-ID: csqbcu$6l1$1@online.de und Antworten, insbesondere Message-ID: 110633E468.bdpe@manchmal.in-ulm.de
Jedenfalls scheint die DHCP-Option so wohl RFC-konform zu sein, obwohl ich das auch als etwas unsinnig angesehen habe.
Das Ganze ist notwendig, weil ein 2. Router für's VPN dasteht, der nicht das Standardgateway ist.
Mach doch den VPN-Router zum Default-GW (ich meine, in der Routing-Tablette des Clients) und dann dort gibt's sicher einen
Das geht ja vielleicht noch.
ICMP-Redirect, den m.W. die W-Clients sehr gut verstehen (und wenigstens früher sogar in der Routing-Tablette darstellten).
Auf dem VPN Router das Standardgateway auf den ursprünglichen Router setzen hilft hier leider nicht. Der Router kapiert das nicht (schon das Routing selbst), von ICMP-Redirect will ich dann noch garnicht reden.
Insofern war Andreas sein Ansatz hilfreicher.
Danke ;-)
Andreas
am Mon, dem 17.01.2005, um 18:17:31 +0100 mailte Rico Koerner folgendes:
Das Ganze ist notwendig, weil ein 2. Router für's VPN dasteht, der nicht das Standardgateway ist.
Kannst Du diesem, also dem Standardgateway, nicht die korrekte Router verklickern? Statische Routen auf Clients sind IMHO Ausdruck eines verkorksten Netzdesings...
Andreas
lug-dd@mailman.schlittermann.de
-
Andreas Kretschmer -
Heiko Schlittermann -
Rico Koerner