gulli:board Logo

Anzeige


  Antwort
Hejooo
#@$%!
 
Benutzerbild von Hejooo
 
Registrierungsdatum: Jul 2000
Beiträge: 690
Problem nach Serverumzug in die DMZ

Hallo zusammen,

ich habe zwei Server, welche bisher öffentliche IPs hatten, neu hinter einer Firewall (Watchguard Firebox II) in einer DMZ. Auf der Firewall hab ich Alias IPs ihrer alten öffentlichen IPs eingerichtet und auf ihre IPs in der DMZ geroutet.

Siehe Netzwerkansicht im Anhang.

Aus dem Internet (extern) sind die beiden Server (web1 & web2) per http erreichbar, nicht aber aus dem internen Netz. Kennt jemand das Problem und was muss ich tun, damit die "Internen" nur über die öffentlichen IPs auf die beiden Server per http kommen?

Hejooo
Angehängte Grafiken
Dateityp: jpg firewall.jpg (36,0 KB, 36x aufgerufen)
Alt 26. 09. 2005, 21:39 Hejooo is offline Mit Zitat antworten #1
Toady
Mitglied
 
Benutzerbild von Toady
 
Registrierungsdatum: Jul 2003
Beiträge: 5.221
Re: Problem nach Serverumzug in die DMZ

Zitat:
Original geschrieben von Hejooo
ich habe zwei Server, welche bisher öffentliche IPs hatten, neu hinter einer Firewall (Watchguard Firebox II) in einer DMZ. Auf der Firewall hab ich Alias IPs ihrer alten öffentlichen IPs eingerichtet und auf ihre IPs in der DMZ geroutet.
Warum Aliase? Ich kenne die rote Pest nur vom wegschauen, aber AFAIK kann die doch auch Netze routen und nicht bloß natten. Da besteht keine Veranlassung für S- oder DNAT in die DMZ hinein, oder hast du ein zu kleines Netz auf dem WAN-If (kann ich mir kaum vorstellen bei nur zwei Kisten, die erreichbar sein müssen).
Zitat:
Aus dem Internet (extern) sind die beiden Server (web1 & web2) per http erreichbar, nicht aber aus dem internen Netz. Kennt jemand das Problem und was muss ich tun, damit die "Internen" nur über die öffentlichen IPs auf die beiden Server per http kommen?
Warum kannst du sie nicht erreichen? Du musst mal ein paar Infos rausrücken.

Nattest du in die DMZ hinein (welche IPs haben die beiden Kisten, wird dahin genattet)? Worauf löst der gefragte FQDN denn intern auf? Was sagen die Logs der roten Pest (blockt diese gar vom LAN in die DMZ)?
Alt 27. 09. 2005, 16:16 Toady is offline Mit Zitat antworten #2
sirnnx Spender
Wonderboy
 
Benutzerbild von sirnnx
 
Registrierungsdatum: Jul 2005
Beiträge: 1.728
Routingproblem

Du musst den Traffic aus dem internen Netz auf die beiden öffentlichen IPs erlauben (Destination Port 80)

Du musst im internen Netz die Firewall als Standardgateway haben.

Wenn du einen öffentlichen DNS-Server nutzt musst du dem internen Netz
auch den Zugriff auf diesen DNS Server erlauben.

Du musst für bestehende Verbindungen den Traffic von deinen Servern nach intern
erlauben (Source Port 80)

Schlauer wäre aber von intern die DMZ-IPs anzusprechen. Das gelingt dir über einen entsprechenden Hosteintrag oder über einen eigenen internen DNS-Server.

NNX
Alt 27. 09. 2005, 16:31 sirnnx is offline Mit Zitat antworten #3
Toady
Mitglied
 
Benutzerbild von Toady
 
Registrierungsdatum: Jul 2003
Beiträge: 5.221
Re: Routingproblem

Zitat:
Original geschrieben von sirnnx
Du musst den Traffic aus dem internen Netz auf die beiden öffentlichen IPs erlauben (Destination Port 80)
Warum sollte man vom LAN aus irgendetwas grundsätzlich verbieten? Außerdem kann er ja andere Ziele erreichen.
Zitat:
Du musst im internen Netz die Firewall als Standardgateway haben.
Bist du Hellseher? Das kommt auf das SetUp an, und wenn, dann muss es das LAN-If des Routers sein. Da er aber andere Hosts erreicht wird es nicht daran liegen
Zitat:
Wenn du einen öffentlichen DNS-Server nutzt musst du dem internen Netz
auch den Zugriff auf diesen DNS Server erlauben.
S.o. - er kann doch andere Hosts erreichen.
Zitat:
Du musst für bestehende Verbindungen den Traffic von deinen Servern nach intern
erlauben (Source Port 80)
Nochmals - er kann andere Ziele erreichen, davon ab wird die rote Pest Statefull arbeiten, also aufgebaute Verbindungen erlauben.
Zitat:
Schlauer wäre aber von intern die DMZ-IPs anzusprechen. Das gelingt dir über einen entsprechenden Hosteintrag oder über einen eigenen internen DNS-Server.
Einzig sinnvoll wäre es, den Kisten direkt ihre IPs zu geben und nicht zu natten.
Alt 27. 09. 2005, 16:54 Toady is offline Mit Zitat antworten #4
sirnnx Spender
Wonderboy
 
Benutzerbild von sirnnx
 
Registrierungsdatum: Jul 2005
Beiträge: 1.728
Re: Re: Problem nach Serverumzug in die DMZ

Zitat:
Original geschrieben von Toady
Warum Aliase? Ich kenne die rote Pest nur vom wegschauen,
Nach deiner Meinung über die FW war eigentlich nicht gefragt. Er wird sie jetzt wohl nicht mehr tauschen
Zitat:
aber AFAIK kann die doch auch Netze routen und nicht bloß natten. Da besteht keine Veranlassung für S- oder DNAT in die DMZ hinein, oder hast du ein zu kleines Netz auf dem WAN-If (kann ich mir kaum vorstellen bei nur zwei Kisten, die erreichbar sein müssen).Warum kannst du sie nicht erreichen? Du musst mal ein paar Infos rausrücken.

Er hat private IPs in seiner DMZ (siehe Grafik) die kann keiner aus dem Internet ansprechen. Also muss er ein DNAT machen wen er keine öffentlichen IPs einsetzen will. Ich finde seine Lösung vernünftig.[/b][/quote]
Zitat:
Nattest du in die DMZ hinein (welche IPs haben die beiden Kisten, wird dahin genattet)?

Was sollte das den bitte bringen? Schau dir die Grafik an - dort stehen alle IPs.
Zitat:
Worauf löst der gefragte FQDN denn intern auf?

Mal eine gute Frage - die hilft das Problem einzukreisen.
Wäre gute zu wissen, ob es bloss an der Namensauflösung liegt.
Zitat:
Original geschrieben von Toady
...Bist du Hellseher? Das kommt auf das SetUp an, und wenn, dann muss es das LAN-If des Routers sein. Da er aber andere Hosts erreicht wird es nicht daran liegenS.o. - er kann doch andere Hosts erreichen
Nein - ich bin kein Hellseher! Aber ich habe mir die Mühe gemacht, sein Posting zu lesen und mir die Grafik anzusehen.
Die Firewall ist sein Standardgateway und Router (sonst muss er halt eine Route einrichten) und davon das er von intern was anderes erreicht steht nichts da.

NNX
Alt 27. 09. 2005, 17:18 sirnnx is offline Mit Zitat antworten #5
Toady
Mitglied
 
Benutzerbild von Toady
 
Registrierungsdatum: Jul 2003
Beiträge: 5.221
Re: Re: Re: Problem nach Serverumzug in die DMZ

Zitat:
Original geschrieben von sirnnx
Nach deiner Meinung über die FW war eigentlich nicht gefragt. Er wird sie jetzt wohl nicht mehr tauschen
Wo habe ich eine Meinung dazu abgegeben - die Dinger heißen landläufig nunmal so.
Aliases sind sinnfrei, er sollte das Netz routen.
Zitat:

Er hat private IPs in seiner DMZ (siehe Grafik) die kann keiner aus dem Internet ansprechen. Also muss er ein DNAT machen wen er keine öffentlichen IPs einsetzen will. Ich finde seine Lösung vernünftig.
Stimmt, hätte mir die Grafik anschauen müssen.
Vernünftig ist das allerdings keinesfalls. Warum sollte man NATten und IP kaputt machen? Welchen Sinn hat das?
NAT ist die größte Pest, die je implementiert wurde, und deren weite Verbreitung hat erst die Einführung von IPv6 ermöglicht, damit eben dieser miese Hack endlich dem Orkus der Vergangenheit überantwortet werden kann.
Zitat:
Wäre gute zu wissen, ob es bloss an der Namensauflösung liegt.
Davon gehe ich nun aus.
Zitat:
Nein - ich bin kein Hellseher! Aber ich habe mir die Mühe gemacht, sein Posting zu lesen und mir die Grafik anzusehen.
Die Firewall ist sein Standardgateway und Router (sonst muss er halt eine Route einrichten) und davon das er von intern was anderes erreicht steht nichts da.
Nein, nicht der Router selbst, sondern das LAN-If des Routers. Ein Router zeichnet sich dadurch aus, dass er mindestens zwei Interfaces besitzt und jedes für sich angesprochen werden kann.
In seinem Fall sind es drei Interface, eines zum LAN, eines zur DMZ und eines zum WAN.
BTW:
Eine Firewall in diesem Zusammenhang ist *immer* ein Router, ausnahmslos.
Alt 27. 09. 2005, 17:35 Toady is offline Mit Zitat antworten #6
sirnnx Spender
Wonderboy
 
Benutzerbild von sirnnx
 
Registrierungsdatum: Jul 2005
Beiträge: 1.728
Re: Re: Re: Re: Problem nach Serverumzug in die DMZ

Zitat:
Original geschrieben von Toady
...Warum sollte man NATten und IP kaputt machen? Welchen Sinn hat das?

In seinem Fall ist es egal. Wenn man nur eine öffentliche IP hat und zum Beispiel einen Web- und einen getrennten Mailserver - könnte man anhand des Zielportes trennen und ein unterschiedliches DNAT machen (SMTP zum Mailserver, HTTP zum Webserver).

Das du NAT nicht magst, habe ich noch in Erinnerung. Aber wo siehst du konkrete Nachteile in seiner Konfiguration?

Wenn rote Pest keine abfällige Bemerkung war, streiche meinen 1. Kommentar.

NNX
Alt 27. 09. 2005, 17:43 sirnnx is offline Mit Zitat antworten #7
Toady
Mitglied
 
Benutzerbild von Toady
 
Registrierungsdatum: Jul 2003
Beiträge: 5.221
Re: Re: Re: Re: Re: Problem nach Serverumzug in die DMZ

Zitat:
Original geschrieben von sirnnx
In seinem Fall ist es egal. Wenn man nur eine öffentliche IP hat und zum Beispiel einen Web- und einen getrennten Mailserver - könnte man anhand des Zielportes trennen und ein unterschiedliches DNAT machen (SMTP zum Mailserver, HTTP zum Webserver).
Das ist mir schon bewusst
Es ist aber ein mieser Hack.
Zitat:
Das du NAT nicht magst, habe ich noch in Erinnerung. Aber wo siehst du konkrete Nachteile in seiner Konfiguration?
Na, im NATten. Das ist eine Notlösung - zB für obige Szenarien. Wenn du mehrere Kisten zu Hause hast bleibt dir aufgrund der Knappheit an IP-Adressraum nix anderes übrig (wobei, momentan haben wir noch genügend Adressen, nichteinmal die Hälfte ist vergeben, und meiner groben Schätzung nach sind mindestens die Hälfte unnötig vergeben (HP hat alleine drei /8er und zig /16er - das sind über 60 Millionen Adressen, die sie aus historischen Gründen immer noch haben - wobei, IIRC haben sie ein /8er wieder zurückgegeben, dann wären es nur noch weit über 40 Mio.).
Es sind nicht alle so geizig wie das RIPE, das ARIN gibt jeder Eisdiele ein /16er.
Zitat:
Wenn rote Pest keine abfällige Bemerkung war, streiche meinen 1. Kommentar.
Na, es steckt schon Wertung drinne, aber die heißen wirklich so, der Ausdruck stammt nicht von mir.
Alt 27. 09. 2005, 18:06 Toady is offline Mit Zitat antworten #8
Hejooo
#@$%!
(Threadstarter)
 
Benutzerbild von Hejooo
 
Registrierungsdatum: Jul 2000
Beiträge: 690
Hallo zusammen

Danke für die Antworten.

Ich denke nicht dass es ein DNS Problem ist. Ping -a auf die öffentliche IP aus dem internen wie auch externen Netz ergibt korrekterweise mail.firma.com. Die Firewall ist ziehmlich alt und wird auch von Watchguard selber nicht mehr supportet. Ich tippe eher darauf dass sie NAT nicht richtig kann, zumindest wenns aus dem internen Netz kommt.

Ich würde deshalb gerne wieder die öffentlichen IPs benutzen, nicht mehr als Alias in einem eigenen Subnetz. Nur weiss ich nicht wie das zu konfigurieren ist.

Hier mal ein paar Details:

Wir haben die folgenden öffentlichen IPs:

10.10.10.192 /28

10.10.10.192 reserviert
10.10.10.193 gateway
10.10.10.194
10.10.10.195
10.10.10.196
10.10.10.197
10.10.10.198
10.10.10.199 web1 (Mailgateway)
10.10.10.200 Watchguard Firewall
10.10.10.201
10.10.10.202
10.10.10.203 web2 (Mailserver)
10.10.10.204
10.10.10.205
10.10.10.206
10.10.10.207 reserviert

Im Anhang Screenshots der aktuellen Firewallkonfiguration.

Beim Register External hab ich noch die beiden Aliase 10.10.10.199 und 10.10.10.203 eingerichtet.

Anmerkung: IPs wurden verändert (10.10.10).

Wie müsste ich die Firewall konfigurieren (Register "optional") um auf NAT zu verzichten und den Servern je eine öffentliche IP geben könnte?

Gruss Hejooo
Angehängte Grafiken
Dateityp: gif fw_set.gif (33,1 KB, 11x aufgerufen)
Alt 28. 09. 2005, 12:47 Hejooo is offline Mit Zitat antworten #9
Toady
Mitglied
 
Benutzerbild von Toady
 
Registrierungsdatum: Jul 2003
Beiträge: 5.221
Zitat:
Original geschrieben von Hejooo
Hallo zusammen

Danke für die Antworten.

Ich denke nicht dass es ein DNS Problem ist. Ping -a auf die öffentliche IP aus dem internen wie auch externen Netz ergibt korrekterweise mail.firma.com.
Ja und?
Der umgekehrte Weg ist ja wichtig (und warum ping?).

Gebe einmal 'nslookup mail.firma.com' ein - was wird zurückgegeben?
Zitat:
Ich würde deshalb gerne wieder die öffentlichen IPs benutzen, nicht mehr als Alias in einem eigenen Subnetz. Nur weiss ich nicht wie das zu konfigurieren ist.
Nach Handbuch. Die Doku soll recht gut sein, habe ich mir sagen lassen.
Zitat:
Wir haben die folgenden öffentlichen IPs:

10.10.10.192 /28

10.10.10.192 reserviert
10.10.10.193 gateway
10.10.10.194
10.10.10.195
10.10.10.196
10.10.10.197
10.10.10.198
10.10.10.199 web1 (Mailgateway)
10.10.10.200 Watchguard Firewall
10.10.10.201
10.10.10.202
10.10.10.203 web2 (Mailserver)
10.10.10.204
10.10.10.205
10.10.10.206
10.10.10.207 reserviert
Das sind alles Adressen aus RFC1918, also private, keine öffentlichen. 10.0.0.0/8 ist komplett frei für den privaten Gebrauch.
Alt 28. 09. 2005, 17:17 Toady is offline Mit Zitat antworten #10
Hejooo
#@$%!
(Threadstarter)
 
Benutzerbild von Hejooo
 
Registrierungsdatum: Jul 2000
Beiträge: 690
Hi

Warum Ping? Weil ping -a den Namen rausgibt. Nslookup gab die öffentliche IP aus.

Aus dem Handbuch wurde ich mir nicht sicher wie es zu machen ist. Deshalb frag ich, wie ich es konfigurieren müsste. Ist auch schon ein älteres Handbuch und ich würde mir gern sicher sein.

10.10.10 weil ich hier nicht die firmen IPs veröffentlichen will.

Hejooo
Alt 29. 09. 2005, 00:23 Hejooo is offline Mit Zitat antworten #11
Toady
Mitglied
 
Benutzerbild von Toady
 
Registrierungsdatum: Jul 2003
Beiträge: 5.221
Zitat:
Original geschrieben von Hejooo
Warum Ping? Weil ping -a den Namen rausgibt. Nslookup gab die öffentliche IP aus.
?
nslookup $IP gibt den Hostnamen aus. Ping sendet Echo-Requests (ICMP) an einen Host, damit überprüft man, ob man einen Host erreichen kann (naja, und nebenbei zählt Ping auch die Zeit vom Aussenden des Echo-Requests bis zum Eintreffen des Echo-Replies).
Um DNS-Infos zu bekommen nimmt man nslookup (naja, eigentlich host oder dig, aber Windows liefert halt nur das schon seit drei Jahren obsolete nslookup mit - die können aber alle das gleiche für diesen Fall).
Zitat:
Aus dem Handbuch wurde ich mir nicht sicher wie es zu machen ist. Deshalb frag ich, wie ich es konfigurieren müsste. Ist auch schon ein älteres Handbuch und ich würde mir gern sicher sein.
na, ist ja auch ein altes Produkt
Da man die rote Pest kaum updaten kann wird sich auch nicht wirklich was geändert haben.
Ich kann dir zur Administration der Kiste jedenfalls nix sagen.
Zitat:
10.10.10 weil ich hier nicht die firmen IPs veröffentlichen will.
OK, aber dann nochmal um sicher zu sein:
Du bekommst intern wie extern die gleiche IP ausgegeben?
Die Kisten haben diese offizielle IP, die dir intern wie extern ausgegeben wird?
Lassen sich die Kisten anpingen, wenn nein, welche Fehlermeldung kommt (genauer - kommt "Zeitüberschreitung" oder "Destination unreachable")?
Welche Meldungen sind im Log der roten Pest zu finden?
Alt 29. 09. 2005, 00:35 Toady is offline Mit Zitat antworten #12
Themen-Optionen Antwort


Themen-Optionen

Gehe zu



Alle Zeitangaben in UTC +1. Es ist jetzt 14:44 Uhr.
Angetrieben von vBulletin
Copyright ©2000 - 2006, Jelsoft Enterprises Ltd.
epilepsy.gullisys.net

Anmelden

Benutzername
Kennwort
© Copyright 1998-2008 gulli.com home | regeln | sitemap | kontakt | impressum | partner | downloads | disclaimer |
Message Boards and Forums Directory