nicht angemeldet
Ich gegen das Routing - und wofür braucht man einen hostname?
Sup!
Folgendes: Ich habe ein Gateway. Das hat zwei Netzwerkkarten, mit einer hängt es am Internet, mit der anderen im LAN.
Masquerading etc. funktioniert super, ich habe nur folgendes Problem:
Das Gateway ist im Internet unter xyz.dnsalias.org zu erreichen. Nun will ich aber Anfragen auf Port 80 an einen anderen Rechner weiterreichen - kein Problem,
iptables -t nat -A ppp0 -p PREROUTING -p tcp -port 80 -j DNAT --to 192.168.0.6 hilft.
Wenn ich jetzt aber vom Lan aus auf xyz.dnsalias.org zugreifen will, dann kommt der Zugriff ja nicht von ppp0 sondern von eth0...
Flugs die IP von xyz.dnsalias.org in $IP reingeholt und folgendes gemacht:
/usr/sbin/iptables -t nat -A PREROUTING -i eth0 --destination $IP -p tcp --dport 80 -j DNAT --to 192.168.0.6
Nun werden tatsächlich die Anfragen von außen an den Webserver auf 192.168.0.6 geschickt (die kommen auch an), und die Anfragen von innerhalb des LANs werden auch an 192.168.0.6 weitergeleitet - dumm nur, daß die Verbindung dennoch einen timeout bekommt, obwohl sich die Rechner laut tcpdump irgendwelche Pakete zuschicken.
Und damit kommt ich zur Frage, was eigentlich der hostname eines Rechners für Auswirkungen hat - wenn der Apache "port 80" bzw. "listen 80" in der Konfiguration stehen hat, dann "lauscht" er doch unabhängig vom evtl. im http-Header angegebenen Namen und beantwortet alles, was kommt - oder?
Gruesse,
Bio
-
Sup!
Hmmm... vielleicht kommt erschwerend hinzu, daß der Gateway, der auf dem ppp0 Interface xyz.dnsalias.org heisst und irgendeine IP hat, auf dem eth0 Interface shadow heisst und die IP 192.168.0.1 hat.
Der tcpdump zeigt auf jeden Fall, daß, wenn Rechner .3 versucht xyz.dnsalias.org zu kontaktieren, erst der Rechner .3 dem Rechner .6 ein SYN Paket schickt, der schickt eins zurück, dann sendet .3 an .6 ein RST, .6 sendet SYN zurück, und dann sendet .3 noch ein RST.
Kann man daraus irgendwas schliessen?
Gruesse,
Bio
-
Moin,
Also zur Frage in deinem ursprünglichen Post: Den eingetragenen Hostnamen benutzt der Apache unter Umständen um URLs für Redirects zusammenzubauen. Wenn du also http://bla/bla eingibst, und bla keine Datei sondern ein Verzeichnis ist, wird in den meisten Fällen ein redirect auf http://bla/bla/ gemacht.
Was das Port-Forwarding angeht: Such mal mit groups.google in einer Firewallgruppe danach, da kommt sowas häufiger vor. Weiter kann ich dazu leider nichts sagen.
Der tcpdump zeigt auf jeden Fall, daß, wenn Rechner .3 versucht xyz.dnsalias.org zu kontaktieren, erst der Rechner .3 dem Rechner .6 ein SYN Paket schickt, der schickt eins zurück, dann sendet .3 an .6 ein RST, .6 sendet SYN zurück, und dann sendet .3 noch ein RST.
Kann man daraus irgendwas schliessen?
Ohne die Pakete jetzt direkt gesehen zu haben: Aus deiner Beschreibung entnehme ich, dass 3 versucht eine Verbindung zu 6 aufzunehmen. Das zurückkommende SYN-Paket ist vielleicht ein SYN/ACK? Andernfalls macht das nämlich kaum Sinn. Also 3 versucht zu 6 zu verbinden, 6 bestätigt die Verbindung mit SYN/ACK, 3 bricht die Verbindung mit RST ab. Das andere ist auch merkwürdig: 6 versucht zu 3 zu verbinden und wird abgewiesen.
Das ist nicht koscher, also schicke besser mal den tcpdump-Ausschnitt.--
Henryk Plötz
Grüße aus Berlin* Help Microsoft combat software piracy: Give Linux to a friend today! *
-
-
Hi Ritter,
Und damit kommt ich zur Frage, was eigentlich der
hostname eines Rechners für Auswirkungen hat - wenn
der Apache "port 80" bzw. "listen 80" in der
Konfiguration stehen hat, dann "lauscht" er doch
unabhängig vom evtl. im http-Header angegebenen Namen
und beantwortet alles, was kommt - oder?ich denke, ja - und würde Dein Problem auch eher in
der Netzwerkebene suchen als im Apache.Allerdings hat der "Host:"-Header durchaus eine
Bedeutung, wenn Du Virtual Hosts verwendest - dann
entscheidet er darüber, welcher dieser Virtual Hosts
den URL in einen Pfadnamen übersetzen soll.
Wenn Du dann nur mit einer IP-Adresse ankommst, fällt
der Request in den ersten definierten Virtual Host
(glaube ich mich zu erinnern). Aber daß deshalb der
Apache _nicht_ antwortet, dürfte nicht möglich sein.Viele Grüße
Michael -
Aloha!
Wenn ich jetzt aber vom Lan aus auf xyz.dnsalias.org zugreifen will, dann kommt der Zugriff ja nicht von ppp0 sondern von eth0...
Flugs die IP von xyz.dnsalias.org in $IP reingeholt und folgendes gemacht:
/usr/sbin/iptables -t nat -A PREROUTING -i eth0 --destination $IP -p tcp --dport 80 -j DNAT --to 192.168.0.6
Schätzungsweise bringt das die Probleme, denn auf eth0 ist ja gar kein NAT (wäre auch doof, wenn's so wäre).
Ich denke, du solltest dein Problem an der Namensauflösung anpacken.
Vom Internet her kriegt man die öffentliche IP und vom Port-Forwarding nichts mit.
Aus dem Intranet sollte für den dnsalias-Namen die interne private IP-Adresse bekannt gemacht werden. Entweder auf jedem Rechner mit einer HOSTS-Datei, oder beim Nameserver zentral. Dadurch bleibt das Gateway vollkommen aussen vor, was den internen Zugriff auf den Webserver angeht.
So etwas ähnliches (möglicherweise das gleiche), wie du es willst, hatte bei mir in der Firma (eine andere Firma als jetzt :) ) ebenfalls für Probleme gesorgt. Man konnte von intern nicht über die Angabe von externen IP-Adressen zurück auf interne Server zugreifen, weil irgendwas in der Firewall durchgedreht hat (bzw. wohl immer im Kreis gelaufen ist).
- Sven Rautenberg
-
Sup!
Hmmmm... auch gute Idee. Seeeehr tricky - naja, die Idee ist ja auch von Dir. Ich hab' erstmal die netfilter-Liste gespammt... mal gucken, was die sagen, morgen probiere ich mal 'rum, ich mach' erstmal was anderes, man sieht ja, wie wenig man weiterkommt, wenn man sich zu sehr reinstresst, auf die Idee mit der Namensauflösung, die ja genial einfach ist, bin ich ja nicht gekommen, wo ich doch normalerweise so ein kluges Kerlchen bin... ich muß dringend ausspannen... bla... also danke!
Gruesse,
Bio
-
Sup!
Es hat funktioniert.
Gruesse,
Bio
-
-