david777
Goto Top

Routing beim Internetprovider

Hallo Leute,

Wir haben als Unternehmen insgesammt drei statische IP-Adressen unseres Providers (COX)
zur Verfuegung.
Vor zwei dieser IP-Adressen laufen Firewalls. (Firebox und IPCop)
Die dritte IP ist ebenfalls eine oeffentliche Internetadresse, allerdings haengt sie in einem anderen Subnetz des Providers.
Ich habe nun noch einen Webserver, welcher hinter der einen Firewall haengt, und auf dem sich eine Testhomepage
befindet.
Hinter der zweiten Firewall haengt einlokales Netz, mit einem einfachen PC.

de01d15b16e4a70b2cd1e1ac5857c262-ipadressen

Ich moechte nun, dass der Webserver vom ganzen Internet aus zu erreichen ist.
Somit habe ich ein Portforwarding von der ersten externen IP-Adresse, auf den Webserver gemacht.
Von der zweiten externen IP-Adresse kann ich nun ohne Probleme auf den Webserver zugreifen.
Doch es gibt Probleme sobald ich versuche den Webserver von der externen IP zu erreichen, welche
nicht mehr im selben Subnetz haengt.
Das bedeutet also, dass dort eine Route beim Provider fehlt, oder woher genau kann das kommen?
Ich moechte den Webserver vom ganzen Internet aus erreichen, aber aus irgendeinem Grund klappt es nicht.

Ich waere euch sehr dankbar, wenn ihr eure Ideen hier postet face-wink

Bis dann und schoenes WE

David

Content-ID: 109617

Url: https://administrator.de/contentid/109617

Ausgedruckt am: 16.11.2024 um 07:11 Uhr

Arch-Stanton
Arch-Stanton 20.02.2009 um 21:50:11 Uhr
Goto Top
Hmmhh, Du brauchst nur den IPCop und richtest eine DMZ ein, in der sich dann der Webserver befindet.

Gruß, Arch Stanton
David777
David777 20.02.2009 um 21:53:55 Uhr
Goto Top
Es muesste doch auch ohne DMZ gehen. Natuerlich ist das unsicher, aber ich wollte es erstmal auf diese Art und Weise hinkriegen, bevor ich weiter mache. Warum routete Cox nicht zwischen den zwei Netzen?
aqui
aqui 20.02.2009 um 21:55:47 Uhr
Goto Top
Es ist unverständlich warum hier immer umständlich externe Links für Bilder genutzt werden und einem so der Überblick erschwert wird.
Bilder kann man auch hier direkt einfügen !!!

a9b70ae00d4175333a6c53b81e84dcaf-ipadressen

Ursache ist vermutlich ein falsches Default Gateway am Webserver oder am IPcop ???
Deine Zeichnung ist auch unvollständig denn es wäre noch wichtig zu wissen WO sich der Providerrouter befindet der beide Subnetze ins Internet routet und/oder ob das z.B. 2 Router sind oder einer mit 2 lokalen Interfaces.

Das Gateway des IPcop MUSS auf alle Fälle auf den Providerrouter zeigen was vermutlich nicht der Fall ist ?!

So sieht vermutlich dein Design mit Providerrouter aus, oder:

7edea12ab1732174f3cef9e83a4c32d1-2malprov

Wichtig sind folgende Punkte:
  • Default Route des IP Cop muss auf den Provider Router LAN Adresse im Subnetz 1 zeigen
  • Port Forwarding muss im IP Cop von dessen Outbound Interface (rot, Subnetz 1) auf die Inbound IP Adresse (grün) des Webservers zeigen und die Ports TCP 80 HTTP und TCP 443 HTTPS beinhalten.

Da der IP Cop am roten Interface eine öffentliche IP hat muss er zwangsweise aus dem gesamten Internet erreichbar sein.
Damit sollte das Szenario problemlos funktionieren.
David777
David777 20.02.2009 um 22:00:38 Uhr
Goto Top
Ich habe im IpCop natuerlich den Default gateway angegeben. Das ist es ja gerade, was mich stuzig macht. Wo sich der Providerrouter befindet weiss ich nicht.
Ich habe einfach drei externe IPs vom ihm bekommen, aber wo die genau hinfuehren, und was geschieht: Keine Ahnung ...
aqui
aqui 20.02.2009 um 22:19:09 Uhr
Goto Top
Was sagt denn ein Traceroute oder Pathping auf die PFW Adresse des Webservers von extern ???
Damit weisst du doch dann sofort was geschieht und wie die Wege sind !!!

Sind die IP Adressen vom Subnet 1 öffentliche IP Adressen oder RFC 1918 IP Adressen ??
http://de.wikipedia.org/wiki/Private_IP-Adresse
David777
David777 20.02.2009 um 22:34:19 Uhr
Goto Top
Die IP-Adressen sind natuerlich alle oeffentlich.
Meine Traceroute versagt in beide Richtungen.
Aber ich kann euch auch mal noch ein paar Zahlen nennen:

IP 1:70.184.239.124 (IpCOP)
IP 2:70.184.239.42 (Watchguard)
IP 3:24.249.130.94 (Client von dem aus ich auf den Webserver hinter dem IpCop will)

SNM: 255.255.255.128
Gateway IP1 & IP2: 70.184.239.1
Gateway IP3: 24.249.130.1

Beide Gateways lassen sich von allen PCs anpingen.
70.184.239.94, kann nicht angepingt werden, und die Tracerouter versagt.
AENDERUNG IN DIESEM SATZ *
Das sieht folgendermassen aus, und ist nur von dem Subnetz moeglich, in dem sich die IP
befindet.
Der IPCop hat also default Gateway 70.184.239.1 eingetragen.
AENDERUNG IN DIESEM SATZ *
6d97234ad149d7d6cdfdd38c43cae61e-tracerouter
Dani
Dani 20.02.2009 um 22:37:51 Uhr
Goto Top
Hi David,
bitte in Zukunft die Bilder in den Beitrag hochladen. Ich hasse nichts mehr, wie externe Links. Stell dir mal vor, ich will meinen Kindern in 5 Jahren den Beitrag zeigen; nur tote Links und somit ist der Beitrag unvollständig! Also bitte die Funktion benutzen...


Gruß,
Dani (Admo-Editor)
David777
David777 20.02.2009 um 22:41:51 Uhr
Goto Top
Ich hab hier schon gesucht, aber irgendwie gibts bei mir keinen Button dafuer *gg*.
Die Zeichnung, welche aqui geschrieben hat trifft uebrigens genau auf meine infrastruktur zu.
Nur das es eben leider nicht funktioniert ;-(
aqui
aqui 20.02.2009 um 23:10:42 Uhr
Goto Top
Auch aus D ist bei "wsip-98-190-9-129.ks.ks.cox.net [98.190.9.129]" Schluss !!

12 155 ms 155 ms 155 ms ae-2-52.edge6.Chicago1.Level3.net [4.68.101.50]

13 211 ms 214 ms 208 ms COX-COMMUNI.edge6.Chicago1.Level3.net [4.79.74.1
0]
14 225 ms * 232 ms kscydsrj01-ge610.rd.ks.cox.net [68.1.1.177]
15 217 ms 217 ms 264 ms 70.183.66.74
16 239 ms 239 ms 239 ms 70.183.66.70
17 243 ms 240 ms 240 ms wsip-98-190-9-129.ks.ks.cox.net [98.190.9.129]
18 * * * Zeitüberschreitung der Anforderung.
19 * * * Zeitüberschreitung der Anforderung.

Ein Pingen der IP Cop und Watchguard Adresse ist gar nicht möglich, was aber vermutlich daran liegt das beides Firewalls sind und ICMP Pakete per Default blocken, was ja auch gut so ist !

Es ist zu vermuten das diesem letzten Provider Router "wsip..." von Cox die Route in eurer öffentliches Subnetz 1 mit 70.184.239.x fehlt !
Allem Anschein nach ein Providerproblem !
Du solltest dringenst den Provider kontaktieren und ihn bitten die internen Routen seines Netzes in dein Subnetz 1 zu kontrollieren.

Der Fehler liegt vermutlich nicht an dir !!!
David777
David777 20.02.2009 um 23:15:03 Uhr
Goto Top
Also ich kann ja beide Firewalls aus Subnetz 1 anpingen face-big-smile Nur um das noch richtig zu stellen.
Ich kann mir zwar nicht vorstellen, dass COX einen so gravierenden Fehler machen, aber ich werde
denen Mal schreiben, dass sie da mal nachschauen sollen...

OH Moment

Kann das ueberhaupt sein, dass die Route falsch ist? Weil ich kann den Gateway des anderen Subnetzes schliesslich anpingen...?!?!
aqui
aqui 20.02.2009 um 23:42:08 Uhr
Goto Top
Das kann sein das für dich intern oder in Teilbereichen dieses Netzes alles stimmt mit dem Routing !

Fakt ist aber das man aus anderen Netzen wie hier in D eben nicht auf dieses Subnetz 70.184.239.x kommt !!
Vermutlich stimmt dort auch was mit der Subnetzmaske nicht, oder der Provider arbeitet mit Secondary IPs auf seinem Router ?!

Was auffällig ist, ist das deine IP Adressen des Subnetzes 1 recht weit auseinanderliegen !
Normalerweise bekommt man von Providern niemals solch große Netze und das schon gar nicht in einen Class A Bereich 70.x.x.x wie dem deinigen ???

Du müsstest eine 25 Bit Subnetzmaske (255.255.255.128) mit 126 adressierbaren Hostadressen da haben um die .42 und die .124 im Subnetz 1 adressieren zu können.
Das ist mehr als ungewöhnlich aufgrund der Größe. Vermutlich hat man dir da falsche IP Adressen oder Masken gegeben...kann auch sein ??!!

Oder weisst du ob du mehrere kleinere Subnetze hast und der Provider mit sog. secondary IP Adressen/Netzen auf seinem Router arbeitet ???

So oder so riecht das aber sehr stark nach einem Providerproblem !!
David777
David777 24.02.2009 um 21:32:36 Uhr
Goto Top
Ich wollte mich noch einmal fuer die ausfuehrlichen Antworten und eure Hilfe bedanken. Mein Problem ist nun geloest: Es lag tatsaechlich am Provider.
Ich habe die angerufen, und sie haben die Route korrigiert.

Mein Webserver funktioniert jetzt.