[Gelöst] Portweiterleitung für mehrere Webserver

[JohnDoe42]

Hallo Gemeinde,

da ich mich mit der Einstellung der AVM-FW im WI von Freetz immer noch ein bischen schwer tu', würd' ich hier gern eine Frage stellen:

Auf meiner FBF 7170 läuft die neueste Variante von Freetz (1.1.3) mit OpenVPN und eben der AVM-FW.
Ich kann mich mit einem Windows-Client auf die Box connecten und bekomme auch die "korrekte" (in dem Fall erste) IP aus dem DHCP-Range. Ich betreibe den Server als Brücke (TAP) über TCP 443. Mein Problem ist, daß ich gerne auf mehrere Webserver (Port 80) im Server-Netz zugreifen würde, dies aber nicht klappt. Sehr wohl liefern "tracert bzw. ping 192.168.178.*" an die FB und die Server was Sinnvolles zurück:

Routenverfolgung zu 192.168.178.21 über maximal 30 Abschnitte
  1    45 ms    45 ms    45 ms  192.168.178.1 
  2   329 ms    45 ms    45 ms  192.168.178.21 
Ablaufverfolgung beendet.

Einzig ich kann mich mit 'nem Browser nicht auf die Server connecten.
Jetzt meine Frage (n):

1. Da ich TAP betreibe und alle Server NetBIOS-Namen besitzen, müßte ich doch eigentlich mit sowas wie "http://netbios-name" auf den Server kommen, in jedem Fall aber doch mit "http://192.168.178.*" ?

2. Muß ich ggfs. Port 80 in der AVM-FW forwarden ? Falls ja, wohin ? Auf die Box selber oder alle Webserber ? ALso von 0.0.0.0:80 auf 0.0.0.0:80 oder von 0.0.0.0:80 auf z.B. 192.168.178.31:80 ? Letzteres kann doch eigentlich garnicht sein, denn die FW muß sich doch bei einem Aufruf a la "http://192.168.178.31" auch auf eben (nur) die ".31" weiterleiten und nicht auf alle ... ?

In der Hoffung, daß Ihr mich in dieser Grundsatzfrage ein wenig unterstützen könnt,

Grüße,

J.

 

[hermann72pb]

@JohnDoe42:
1. Muss es denn gleich TAP sein?
2. IP-Adressen gehen immer. An der Namensauflösung muss man händisch arbeiten. Angeblich sollte es per push oder ähnliche Konfigurationseinstellungen von OpenVPN gehen auch den Namenserver zu definieren. Allerdings speziell für TAP-Modus ist es nicht besonders trivial.
3. Du musst nichts forwarden, wenn du schon OpenVPN benutzt.
4. Wenn du nur auf die WebIFs der Box zugreifen willst, musst du nicht zwangsläufig dafür OpenVPN quellen. SSH-Tunnel mit PUTTY geht genau so gut. Oder eben AVM-Fernwartung.

MfG

 

[JohnDoe42]

Hallo Hermann,

@JohnDoe42:]
2. IP-Adressen gehen immer.

In meinem vorliegenden Fall leider nicht. Wenn ich z.B. auf die in meinem Beispiel erwähnte .21 per "http://192.168.178.21" (vom VPN-Client aus) zugreifen möchte, klappt das nicht. Aus dem Server-Netz natürlich schon.

4. Wenn du nur auf die WebIFs der Box zugreifen willst, musst du nicht zwangsläufig dafür OpenVPN quellen. SSH-Tunnel mit PUTTY geht genau so gut. Oder eben AVM-Fernwartung.
MfG

Die Fernwartung klappt ja leider aufgrund der libcrypto-Ersetzung nicht mehr direkt (über http://meinefritzbox.dyndns.com).
Aber dafür kann ich in der Tat Port 80 via SSH tunneln.

Allerdings möchte ich primär auf mehrere Webserver (mit verschiedenen) im Server-Netz vom OpenVPN-Client aus in der Art zugreifen, wie ich 's oben beschrieben hab'. Geht aber alles nicht. Also vielleicht doch in der FW Port 80 auf 0.0.0.0:80 forwarden ... ?

Grüße,

J.

 

[Silent-Tears]

die sache mit der libcrypto ist im trunk längst aus der Welt geschaft. Da hattne Oliver und ich seinerzeit reichlich Zeit investiert, um das PRoblem zu umgehen.

Was die Sache mit VPN und so angeht: Mal ehrlich: Das Thema ist hundertfach erschlagen worden. Das kann der Totschläger Boardsuche sicher beantworten, wie du da was und welche Routen organisieren musst.

 

[hermann72pb]

@JohnDoe42: Nein, du brauchst keine Weiterleitung. Dir scheinen Grundlagen zur Netzwerkverwaltung und vor allem zu OpenVPN zu fehlen. Und das ist eindeutig nicht FREETZ-Thema, sondern dein eigenes Problem. Und auch wenn du noch einen dritten Thread zum gleichen Thema aufmachst, wird es dir nicht helfen dein Problem zu lösen.

Ich sage hier schon zum 125 Mal: Warum fängt ihr gleich alle mit irgendwelchen abgedrehten Konfigurationen an (TCP anstatt UDP, TAP anstatt TUN) usw., wenn ihr von der Materie wenig Ahnung habt? OpenVPN ist ein mächtiges Tunnel-Werkzeug. Man muss aber damit umgehen können. Fang doch bitte von klein an und erstelle bitte zunächst eine Verbindung über TUN und über einen UDP-Port in default-Einstellungen, so wie im WebIF zu OpenVPN vorgegeben ist und besser noch mit static key. Wenn es auf die Art und Weise funktioniert, kannst du dich weiter steigern. Gleichzeitig lernst du OpenVPN kennen, was dir offensichtlich fehlt.

MfG

 

[JohnDoe42]

die sache mit der libcrypto ist im trunk längst aus der Welt geschaft.

Ich hab' mir den aktuellen Trunk ausgecheckt und von den geänderten Sourcen ein Update/Upgrade gemacht. Leider paßt jetzt das OpenVPN-Package nicht mehr in mein IMage (FBF 7170).

@JohnDoe42: Nein, du brauchst keine Weiterleitung.
MfG

Nehmen wir folgendes an: Mein (Server-)Heimnetz wie gehabt 192.168.178.0/24, TAP auf TCP-Port 443 (meinetwegen auch UDP 53).

Wenn der Server sein Heimnetz auf den Client pusht (und ich die Clients wie oben erwähnt anpingen und tracen kann), dann antworten die Rechner im Server-LAN (bei http-Zugriff) nicht an meinen Client, weil sie keine Route zu meinem Client haben. Aber die wird doch gepusht ....???

Erklär' mir doch bitte kurz und schmerzlos, ob und wenn ja wie ich den Rechnern im Server-LAN noch eine Route ins Client-LAN mitgeben muß (insbesondere wenn selbiges eben nicht im 192.168.178.* 255.255.255.0 ist sondern 134.*.*.* 255.255.0.0).

Wie schon erwähnt: Ich kann mich mit dem Client verbinden, bloß bekomm' ich keine Rückmeldung von den Rechnern im Server-LAN. Die meisten Anleitungen und/oder Threads behandeln den umgekehrten Fall, also den, daß aus dem Server-LAN kein Rechner im Client-LAN zu erreichen ist.
Grüße,

J.

 

[hermann72pb]

@JohnDoe42: Ich habe kein Interesse dir hier irgendwelche Basics zu erklären. Schließlich ist es DEIN Problem nicht meins.
Hier kannst du deine Kenntnisse bzgl. Bridging und Routing verbessern. Und dort liest du genau das, worüber ich mich hier ständig ärgere: Man sollte klein anfangen und sich langsam hocharbeiten, anstatt Dinge zu tun, von denen man herzlich wenig Ahnung hat. In diesem Zusammenhang heißt es UDP+TUN(Routing)+1194! Bevor du es nicht getan hast, macht es wenig Sinn hier über alle möglichen wenn und aber zu diskutieren.

MfG

 

[JohnDoe42]

So,

ich kann sowohl von der Box meinen Client anpingen als auch vom Client sämtliche IP's im Netz hinter der Box anpingen.
Einzig der http-Zugriff auf die Webserver gelingt nicht. In der Firewall-GUI ist Port 80 ausgehend für TCP freigegeben, eingehend jede IP-Adresse (IP permit any).
Daß die Pings auch wirklich durch den Tunnel laufen, hab' ich mit Wireshark geprüft.
Hier mal die server-config auf der Box, die die OpenVPN-GUI erstellt:

proto tcp-server
dev tap0
ca /tmp/flash/cacrt
cert m/tmp/flash/box.crt
key /tmp/flash/box.key
dh /tmp/flash/dh.pem
tls-server
tls-auth /tmp/flash/static.key 0
port 443
ifconfig-pool 192.168.178.100 192.168.178.150
push "route 192.168.178.0 255.255.255.0"
client-to-client
ifconfig 192.168.178.1 255.255.255.0"
push "rote-gateway 192.168.178.1"
push "route 192.168.178.0 255.255.255.0"
max-clients 5
client-to-client
tun-mtu 1500
mssfix
verb 3
daemon
cipher AES-256-CBC
comp-lzo
keepalive 10 120

Wieso tauchen client-to-client und push route zweimal auf ?
Hat noch jemand eine Idee, warum ich keinen der Webserver im Box-Netz vom Client aus erreichen kann ?
Grüße,

JD

 

[MaxMuster]

Du hast da scheinbar irgendwie Bridging und Routing vermengt. Wenn der Client-PC wirklich eine IP aus dem gebrückten LAN bekommt, dann ist der Trace aus dem ersten Beitrag "falsch" (ein angeschlossenens Netz wird nicht über das DG geroutet, sondern erreicht dieses Gerät direkt).
Routing-Einträge für angeschlossene Netze sind übrigens überflüssig, dafür gibt es IP und Netzmaske ;-).
Ob dein Bridging funktioniert, siehst du, wenn du nach einem Ping mit "arp -a" schaust, ob der HTTP-Server im ARP-Cache auftaucht.

Bedenke, dass du beim Bridging das TAP zur LAN-Brücke hinzufügen musst.

Falls du Routing nutzt, musst du ein vom LAN verschiedenes IP-Netz im VPN benutzen.

Jörg

 

[JohnDoe42]

Hallo Jörg,

vielen Dank für Deine Antwort.
Ich möchte die Verbindung im Bridging-Modus betreiben, damit mein Client bei stehender Verbindung eine IP aus meinem Server-Netz bekommt.
(Vergiß bitte mein tracert aus dem Eingangs-Post, das war in der Tat nicht sinnvoll; ich wollte bloß belegen, daß die Verbindung steht ... )
Ohne stehende VPN-Verbindung liefert ein arp -a auf meinem Client das folgende,

Schnittstelle: 134.*.*.50 --- 0x10004
  Internetadresse       Physikal. Adresse     Typ
  134.*.*.1          00-00-5e-00-01-3f     dynamisch 
  134.*.*.11         00-13-72-f8-73-27     dynamisch 
  134.*.*.151        00-c0-eb-0a-05-69     dynamisch 
  134.*.*.152        00-c0-eb-09-e9-01     dynamisch 
  134.*.*.154        00-c0-eb-0a-05-6f     dynamisch 
  134.*.*.155        00-c0-eb-0a-5f-d1     dynamisch 
  134.*.*.157        00-c0-eb-0a-05-63     dynamisch 
  134.*.*.158        00-c0-ee-5f-9c-05     dynamisch 
  134.*.*.159        00-c0-eb-0a-05-6c     dynamisch

mit stehender (zunächst) VPN-Verbindung dieses:

Schnittstelle: 192.168.178.100 --- 0x2
  Internetadresse       Physikal. Adresse     Typ
  192.168.178.1         00-24-fe-16-25-24     dynamisch 

Schnittstelle: 134.*.*.50 --- 0x10004
  Internetadresse       Physikal. Adresse     Typ
  134.*.*.1          00-00-5e-00-01-3f     dynamisch 
  134.*.*.11         00-13-72-f8-73-27     dynamisch 
  134.*.*.151        00-c0-eb-0a-05-69     dynamisch 
  134.*.*.152        00-c0-eb-09-e9-01     dynamisch 
  134.*.*.154        00-c0-eb-0a-05-6f     dynamisch 
  134.*.*.155        00-c0-eb-0a-5f-d1     dynamisch 
  134.*.*.157        00-c0-eb-0a-05-63     dynamisch 
  134.*.*.158        00-c0-ee-5f-9c-05     dynamisch 
  134.*.*.159        00-c0-eb-0a-05-6c     dynamisch

Nach einem Ping auf die IP-Adressen der Web-Server im (VPN-)Server-Netz liefert ein arp -a dieses:

Schnittstelle: 192.168.178.100 --- 0x2
  Internetadresse       Physikal. Adresse     Typ
  192.168.178.1         00-24-fe-16-25-24     dynamisch 
  192.168.178.21        00-03-c5-04-22-f6     dynamisch 
  192.168.178.25        00-24-fe-17-6d-09     dynamisch 

Schnittstelle: 134.*.*.50 --- 0x10004
  Internetadresse       Physikal. Adresse     Typ
  134.*.*.1          00-00-5e-00-01-3f     dynamisch 
  134.*.*.11         00-13-72-f8-73-27     dynamisch 
  134.*.*.151        00-c0-eb-0a-05-69     dynamisch 
  134.*.*.152        00-c0-eb-09-e9-01     dynamisch 
  134.*.*.154        00-c0-eb-0a-05-6f     dynamisch 
  134.*.*.155        00-c0-eb-0a-5f-d1     dynamisch 
  134.*.*.157        00-c0-eb-0a-05-63     dynamisch 
  134.*.*.158        00-c0-ee-5f-9c-05     dynamisch 
  134.*.*.159        00-c0-eb-0a-05-6c     dynamisch

Demnach müßte doch die Netz-Brücke soweit okay sein ... oder überseh' ich was ?
Könnte es doch an der AVM-Firewall scheitern ?
Grüße,

JD.

 

[MaxMuster]

Das sieht in der Tat so aus, wie es soll. Die AVM-Firewall ist an dieser Kommunikation unbeteiligt, denn die geht ja über die "VPN"-Devices TUN oder TAP während die AVM-FW ausschließlich das "Internet-Interface" (dsl) "anpackt".

Ggf. müsste man dann echt im Sniffer nachsehen, was von wo wohin geht...

Jörg

 

[JohnDoe42]

[edit olistudent: Bitte die Ändern-Funktion nutzen und nicht 3 Beiträge hintereinander schreiben!]
Hallo Jörg,

besten Dank für Dein prüfendes Auge.
Das http-Protokoll eines (versuchten) Zugriffs auf eine Web-GUI (die natürlich im Server-LAN problemlos über die gleiche IP klappt) sieht in Wireshark so aus:

NOTIFY * HTTP/1.1
HOST: 239.255.255.250:1900
LOCATION: http://192.168.178.25:49200/MediaRendererDevDesc.xml
SERVER: FRITZ!WLAN Repeater N/G UPnP/1.0 AVM FRITZ!WLAN Repeater N/G 68.04.83
CACHE-CONTROL: max-age=1800
NT: urn:schemas-upnp-org:service:AVTransport:1
NTS: ssdp:alive
USN: uuid:fa095ecc-e13e-40e7-8e6c-0024FE02DCA8::urn:schemas-upnp-org:service:AVTransport:1

In diesem Fall versuche ich auf die Web-GUI eines Fritz-WLAN-Repaters zuzugreifen, selbiger hat die 192.168.178.25.
Mich irritert ein wenig der Host respektive die Destination 239.255.255.250 ... könnte das darauf hinweisen, daß die Pakete überhaupt nicht bei mir (192.168.178.100) ankommen können, weil sie woanders hin geroutet werden ? Wenn ja: Woher kommt dieser Host ?
T'schuldigung für meine blöde Fragerei ...
Grüße,

JD.

EDIT: Okay, ich hab' den SSDP-Dienst deaktiviert ... aber das hilft mir nicht weiter ...

Noch ein kleiner Nachtrag:

Wenn ich bei stehender OVPN-Verbindung im Browser versuche, 192.168.178.21 zu öffnen, geht laut Wireshark bezüglich dieser IP nichts, aber auch gar nichts über das TAP-Device meines Clients.
Wenn ich mich mit SSH auf den Dropbear der Box "lokal" verbinde, d.h. auf die 192.168.178.1 und dann die Verbindung auf den Webserver mit der *.21 tunnele, passiert auf meinem TAP-Device ebenfalls nichts. Wenn ich aber ohne SSH-Tunnel auf die *.21 pinge, antwortet sie laut Wireshark korrekt an meinen Client (192.168.178.100) über mein TAP-Device ...
Ich bin ratlos ..

Grüße,

JD.

EDIT:
Ich betreibe noch einen weiteren OVPN-Server mit fast identischer Config. Zu diesem klappt die Verbindung des gleichen Clients einwandfrei, alle Broadcasts kommen über mein TAP-Device, ich kann auf alle Freigaben zugreifen etc.

 

[MaxMuster]

Wenn der Server beim Ping durchs TAP antwortet die Nachfrage: Wird er auch durch das TAP gefragt?
Wenn du die ARP-Einträge löscht (arp -d <ip>) und dann einen Ping machst, geht der ARP-Request/-Reply durch das TAP?

Oder ist da irgendetwie möglich, dass der Verkehr "asymmetrisch" läuft??


Jörg

 

[JohnDoe42]

Hallo Jörg,

sowohl der Ping-Request als auch der Ping-Reply gehen definitiv durch das TAP-Device (per Wireshark für genau dieses Device nachgeprüft).
Auch nachdem ich den arp-Eintrag lösche und den gleichen Ping nochmal mache, geht er wiederum durch mein TAP-Device.
Und das es definitiv der Server ist, auf den ich gern möchte, kann ich zweifelsfrei an den Ethernet-Frames seh'n.
Grüße,

JD.

 

[MaxMuster]

GAAAAANZ blöde Frage: Du hast nicht einen Proxy drin?

Wie wäre denn mal: "telnet 192.168.178.21 80" ??

Jörg

 

[JohnDoe42]

Hallo Jörg,

selbstverständlich muß mein Client auf dem Weg zum Server an einem Proxy vorbei ...
Aber:

1. Mit dem anderen von mir betriebenen Server läuft das problemlos (und ebenfalls über TCP Port 443)

2. Ein telnet 192.168.178.21 80 scheint tendenziell zu funktionieren .... wenn denn der Dropbear auf meiner Box auf Port 80 für eine telnet-Verbindung lauschen würde ...

Hast Du noch irgendeine Idee, nach was ich gucken könnte ?
Grüße und Dank für Deine Ausdauer,

JD.

 

[MaxMuster]

Hier gilt jetzt mal: "Proxy - Nixe gutt ;-)"

Also, wenn du über einen Proxy gehst, hat das gerade den Sinn, dass eben nicht dein PC (der VPN-Client), sondern der Proxy die HTTP-Requests losschickt. Und der weiß natürlich nix davon, dass dein Client eigentlich im LAN des Servers ist.
Also: "Proxy für lokale Adressen umgehen" (das geht hoffentlich auch für dynamisch hinzugekommene lokale Adressen) oder 192.168.178.0/24 ausnehmen.

Jörg

 

[JohnDoe42]

...
oder 192.168.178.0/24 ausnehmen.
Jörg

Ich werd' wahnsinnig: Der geeeehhhhhht !!!!
Die Idee war reines Gold wert, alles läuft einwandfrei. Massiven Dank !!!!!
Daran hab' ich jetzt ca. 'n paar Wochen herumüberlegt !!!
Nochmals Danke !!!!
Und ich hab' wieder was über Netzwerke gelernt.
Danke und Grüße,

JD.

 

[MaxMuster]

Freut mich.

Würdest du zur Übersichtlichkeit bitte den ersten Beitrag nochmal ändern, und dort über "erweitert" den Titel um ein [gelöst] oder so ergänzen?
Das steigert die Übersichtlichkeit und hilft aderen Usern, offene von gelösten Problemen zu unterscheiden...

Viel Spaß weiterhin!

Jörg

 

[JohnDoe42]

Schon passiert.
Vielen Dank nochmal für Deine Hilfe und Grüße,

JD.