OpenVPN "MULTI: bad source address from client"

Cataclysm_177

Neuer User
Mitglied seit
4 Okt 2013
Beiträge
104
Punkte für Reaktionen
3
Punkte
18
Hallo erst mal.

Ich möchte openvpn mit freetz trunk 12533 nutzten.
Ich hab mich soweit durch gewühlt das die verbindung steht, meine openvpn.conf sieht wie folgt aus:
Code:
#  OpenVPN 2.1 Config, Wed Oct  8 19:19:26 CEST 2014
proto udp
dev tun
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
dh /tmp/flash/openvpn/dh.pem
tls-server
port 1194
ifconfig 192.168.6.1 255.255.255.0
push "route-gateway 192.168.6.1"
topology subnet
push "topology subnet"
push "route 192.168.6.0 255.255.255.0"
max-clients 2
mode server
ifconfig-pool 192.168.6.2 192.168.6.200
push "route 192.168.6.1"
client-config-dir clients_openvpn
route 192.168.1.0 255.255.255.0 192.168.6.1
route 192.168.1.0 255.255.255.0 192.168.6.2
push "dhcp-option DNS 192.168.1.222"
push "redirect-gateway"
tun-mtu 1500
mssfix
log /var/tmp/debug_openvpn.out
verb 5
cipher AES-128-CBC
comp-lzo
keepalive 10 120
status /var/log/openvpn.log
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key
Die Geräte im Netzwerk ereiche ich alle, aber ich kann keine Webseiten öffnen.
In der debug_openvpn.out
bekomme ich sehr viele zeilen mit dem inhalt:
Code:
MULTI: bad source address from client
Wie kann ich den Fehler beheben?
 
Zuletzt bearbeitet:
Du hast vermutlich in der "Erweiterten Client Config" die Netze bei den Clients nicht (oder nicht richtig) angegeben oder der Eintrag stimmt, aber der Client-Name im Zertifikat stimmt nicht. Dadurch wird der "iroute"-Befehl nicht richtig gesetzt oder der richtige Eintrag wird nicht "gezogen", wenn sich der Client verbindet.
Der "Name" muss genau der Common Name (CN) im Zertifikat sein. Im Log solltest du sehen, welcher Client(-Name) sich verbindet und den vergleichen. Das Netz beim Client, aus dem die Zugriffe kommen, müssen dann beim "Netz beim Client" in der Tabelle eingetragen sein.
 
Zuletzt bearbeitet:
was muss da drin stehen das es richtig ist?
das zertifikate heisen "client1" und "client2".
 

Anhänge

  • 1.JPG
    1.JPG
    82.4 KB · Aufrufe: 15
  • 2.jpg
    2.jpg
    80.1 KB · Aufrufe: 14
Schau mal im Log, ob der Name im Zertifikat wirklich genauso ist (Groß-Klein, 1 oder 01 ...).

Das Netz 192.168.1.0 kann nicht bei beiden Clients sein...
 
WWRRWed Oct 8 21:54:22 2014 us=722185 xxx.xxx.xxx.xxx:58904 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Wed Oct 8 21:54:22 2014 us=722512 xxx.xxx.xxx.xxx:58904 [client2] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xxx:58904
Wed Oct 8 21:54:22 2014 us=722962 client2/xxx.xxx.xxx.xxx:58904 OPTIONS IMPORT: reading client specific options from: clients_openvpn/client2
Wed Oct 8 21:54:22 2014 us=723922 client2/xxx.xxx.xxx.xxx:58904 MULTI: Learn: 192.168.6.2 -> client2/xxx.xxx.xxx.xxx:58904
steht im log.

Mit verlaub, das in der zeile nicht das selbe stehen darf steht aber dort http://freetz.org/wiki/packages/openvpn
 
Hi,
reading client specific options from: clients_openvpn/client2
o.k., die Namen scheinen zu passen, die richtige Config wird gezogen.
Mit verlaub, das in der zeile nicht das selbe stehen darf steht aber dort http://freetz.org/wiki/packages/openvpn
Verstehe ich jetzt nicht ganz...

Beim Routing gilt eigentlich das Highlander-Prinzip "es kann nur eine [Route] geben". Ich muss gestehen, ich habe es nie getestet, aber spätestens, wenn beide Clients verbunden sind kann der Open-VPN Prozess nicht mehr entscheiden, wo denn das Netz ist.

Die Fehlermeldung "MULTI: bad source address from client" heißt, dass ein Paket mit einer Absende-Adresse von einem "unzulässigen Client" kommt (bei dem OpenVPN dieses Netz nicht kennt/sieht).
 
Die Fehlermeldung "MULTI: bad source address from client" heißt, dass ein Paket mit einer Absende-Adresse von einem "unzulässigen Client" kommt (bei dem OpenVPN dieses Netz nicht kennt/sieht).

Hmm das könnte sein, das zeigt der log auf meinem tab an.

Die öffentliche IP des tab ist 79.xxx aber unten schliest er plötzlich ne 100.xxx.xxx.xxx /29 aus, weis nciht wo die her kommt.
 

Anhänge

  • 2014-10-09 19.23.59.jpg
    2014-10-09 19.23.59.jpg
    142.5 KB · Aufrufe: 7
Wenn das Tab einer der Client ist, ist dann wirklich ein Netz "hinter" dem Tab? Also PCs, die sich durch das Tab verbinden?
Das "Netz beim Client" ist nur dann erforderlich, wenn der Client selbst ein Router ist. Dann muss das Netz, was "hiner" dem Router ist und am VPN teilnehmen will in der "Netz beim Client" Spalte eingetragen werden ("...Netze zu bestimmten Clients routen..."). Ist der Client "nur Client", bleibt diese Spalte leer.
Und auch nur auf solche Pakete, die nicht vom Client selbst (mit der "bekannten" OpenVPN-IP) kommen, sondern über den Tunnel mit anderer IP kommen, erzeugen die genannte Fehlermeldung.
 
Aha! das muss man erst mal wiessen.
Aber wen ich die Zeile leer lassen ändert sich nichts, der Fehler bleibt weiterhin.
 
Von welcher Verbindung (von welchem Client) kommen die "angemeckerten" Pakete denn?
Ist der andere Client ein "Router" (könnte ja auch eine "mitgenutzte" Verbindung sein...)?
Welche IP-Adresse wird denn so bezeichnet? Sagt dir die Adresse was? Sonst schau auf diesem Client mal nach, woher die IP kommen könnte.

Solange das keine von dir genutzte IP ist, ist es lästig, aber die Funktion sollte gegeben sein.

Was ich jetzt gerade erst sehe:
Du hast "client1" die VPN-IP der Box gegeben. Das ist nicht richtig. Wenn die Box 192.168.6.1 hat, darf natürlich kein Client die gleiche IP zugeordnet bekommen.
Es müsste eigentlich auch zu einer Fehlermeldung kommen, wenn sich client1 verbindet...
 
vom tab selber, ein samsung app was im hintergrunde die 100.xxx.xxx.xxx ip gemacht hat. Das programm heist "com.sec.msc.nts.android.proxy" seltsam seltsam.
Dafür ist jetzt die IP die verworfen wird "10.102.9.XXX" mal schauen welches app jetzt dazwischen funkt.
 
Die 10-er IP könnte eine UMTS-IP sein. Mobilfunkprovider nutzen diesen privaten IP-Bereich gerne...
 
Kann sein, ich glaub es aber eher nicht.
Nach einem neustart hat das tab die öffentliche IP "109.42.XXX.XXX" im log steht:
RFri Oct 10 21:52:11 2014 us=768xxx client2/109.42.XXX.XXX:35800 MULTI: bad source address from client [100.111.XXX.XXX], packet dropped
 
whois für 100.64.0.0/10:
Code:
NetRange:       100.64.0.0 - 100.127.255.255
CIDR:           100.64.0.0/10
OriginAS:
NetName:        SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
NetHandle:      NET-100-64-0-0-1
Parent:         NET-100-0-0-0-0
NetType:        IANA Special Use
Comment:        This block is used as Shared Address Space. Traffic from these addresses does not come from IANA. IANA has simply reserved these numbers in its database and does not use or operate them. We are not the source of activity you may see on logs or in e-mail records. Please refer to http://www.iana.org/abuse/
Comment:
Comment:        Shared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router interfaces when addresses are identical on two different interfaces.
Comment:
Comment:        This block was assigned by the IETF in the Best Current Practice document,
Comment:        RFC 6598 which can be found at:
Comment:        http://tools.ietf.org/html/rfc6598
RegDate:        2012-03-13
Updated:        2012-04-23
Ref:            http://whois.arin.net/rest/net/NET-100-64-0-0-1
Das riecht mehr nach einem provider-internen NAT und spricht eigentlich für den von MaxMuster vermuteten Mobilfunk-Provider. Das Tablet hat eine eigene Mobilfunk-Verbindung oder nutzt die eines Smartphones mit ?

Das sieht für mich nämlich eher danach aus, daß dort auf dem Tablet eine falsche Route "gepullt" wurde oder von vorne herein eine falsche Route eingerichtet ist. Wenn das Absicht ist, daß der gesamte Traffic des Tablets über den OpenVPN-Tunnel geht, dann sollte dieser Traffic eigentlich auch mit der für dieses Interface "zuständigen" Adresse (192.168.6.x) gesendet werden und nicht mit der Adresse eines anderen Interfaces. Wenn gar nicht der gesamte Traffic durch den Tunnel soll (sondern nur der für "zuhause"), dann ist das Senden dieser Pakete mit Source-Adresse 100.111.x.x über das tun-Interface auch falsch (die gehen ja verloren, da die Box sie verwirft) und mit hoher Wahrscheinlichkeit auch ein falscher Eintrag in der Routing-Tabelle daran schuld.

Wenn diese Pakete wirklich von einem "nachgelagerten" Client kommen sollten (wer hängt da hinter dem Tablet noch ?) oder irgendeine App noch weitere "virtuelle" Interfaces betreibt, müßte eigentlich auf dem Tablet SNAT/Masquerading stattfinden, damit die Pakete dann "vom Tablet" auf der FRITZ!Box ankommen.

Bei "com.sec.msc.nts.android.proxy" handelt es sich offenbar um Bloatware von Samsung (nicht meine Einschätzung, die Meinung habe ich aus dem Netz "adoptiert", ich habe gar kein Samsung-Tablet), die irgendetwas mit einer Datenverbindung zu schaffen hat ... vermutlich mit der Umschaltung zwischen 3G und 4G. Gut möglich, daß die sich über das "normale" Routing hinwegsetzen will und dabei auf Granit beißt, weil die Pakete trotzdem im Tunnel landen, aber eben mit der Adresse des falschen Interfaces oder auch, daß dieser Dienst bei einer Umschaltung zwischen den Mobilfunk-Generationen wegen schwankendem Empfang irgendwo tief in den Netzwerkstack eingreift und dabei die Adressierung von Paketen durcheinander bringt. Es gibt einige Anleitungen zum Entfernen dieses Dienstes im Netz, welche "Nebenwirkungen" das hat, müßtest Du selbst lesen.

Ist es denn gesichert, daß das Tablet die "öffentliche Adresse 109.irgendwas" hat oder ist das nur die Schlußfolgerung aus der Protokollierung der OpenVPN-Servers der FRITZ!Box ? Dann kann das ja genauso gut die Adresse des CGN-Gateways beim Provider sein und der benutzt dann intern für die Verbindungen den o.a. Adressblock.

Ich glaube jedenfalls nicht an ein Problem von OpenVPN an sich, schon gar nicht an ein Problem des OpenVPN-Servers auf der ge"freetz"ten Box ... dann noch eher an den Android-Client.

EDIT: Glatt vergessen ... wenn Du die Option "Jedes Paket des Clients umleiten" (oder so ähnlich) auswählst, dann kommt dabei die Option "redirect-gateway" heraus und die führt dann eben dazu, daß der komplette Verkehr über den VPN-Tunnel geht. Ist das wirklich Deine Absicht ?
 
Zuletzt bearbeitet:
tja ich bin woll tatsächlich auf den log rein gefallen. Im status menü von adnriod steht ich hätte die ip 100.111.XXX.XXX. so kan man ein log falsch lesen.
Aber wo kommt dan die 109.42.XXX.XXX im open vpn log her?
Ich hab auschlich probleme mit dem openvpn zugang zur fritzbox.
Mit dem Qnap openvpn server auf der arbeit kann ich mich verbinden und es wird alles über vpn reoutet, so wie ich es haben möchte.
das konfig file für das tab sieht folgendermaßen aus
client
dev tun
script-security 3
proto udp
remote QNPAxxxa.myqnapcloud.com 1194
resolv-retry infinite
nobind
ca ca.crt
auth-user-pass
reneg-sec 0
cipher AES-256-CBC
comp-lzo
und das konfig file vom server so
port 1194
proto udp
dev tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/myserver.crt
key /etc/openvpn/keys/myserver.key
auth-user-pass-verify /usr/sbin/vpn_check_account via-env
client-cert-not-required
username-as-common-name
no-name-remapping
dh /etc/openvpn/keys/dh1024.pem
server 192.168.4.0 255.255.255.0
ifconfig-pool-persist /var/log/ipp.txt
push "redirect-gateway def1"
push "dhcp-option DNS 192.168.2.1"
client-to-client
duplicate-cn
keepalive 10 60
reneg-sec 0
cipher AES-256-CBC
comp-lzo
max-clients 5
client-connect /etc/openvpn/connect.sh
client-disconnect /etc/openvpn/disconnect.sh
management localhost 7505
persist-key
persist-tun
status /var/log/openvpn-status.log
#log /tmp/openvpn.log
verb 3

hilft das evtl. weiter? der openvpn server nutzt die standart einstellungen.
 
Ich fasse mal den Kenntnisstand - so wie ich es bis hier verstanden habe - zusammen:

1. Du willst absichtlich jeden Datenverkehr des Tablet über eine OpenVPN-Verbindung zu Deiner FRITZ!Box leiten und erwartest dabei, daß dann über die VPN-Verbindung auch "normale Internetseiten" (also WAN-Zugriffe) aufgerufen werden können.
2. Dieselbe Konfiguration funktioniert mit einem anderen OpenVPN-Server (auf einem QNAP-NAS) wie erwartet.
3. Bei der FRITZ!Box ist dann aber kein Aufruf einer Internet-Seite möglich.

Nur wenn das so stimmt, machen die folgenden Fragestellungen Sinn.

A) Theoretisch müßten die Probleme mit den falschen Absenderadressen bei der Verbindung zu QNAP genauso auftreten. Kann es sein, daß diese nur wegen fehlender Protokollierung nicht aufgefallen sind und genauso stattfinden ?

B) Wenn die "internen" Geräte alle erreichbar sind, was heißt das genau ? Lassen die sich über ihre Namen ansprechen oder nur über IP-Adressen ?

C) Hast Du die Hinweise von MaxMuster zu den bisherigen Fehlern in der Konfiguration umgesetzt ? Wie sieht die aktuelle Serverkonfiguration auf der Box aus ?

D) Der Aufruf einer Webseite ist ja ein etwas komplexerer Vorgang. Dabei muß zuerst mal der Name aufgelöst werden (das setzt eine funktionierende DNS-Konfiguration voraus) und dann muß über die Box als Gateway der Kontakt dorthin aufgenommen werden. Also zerlegt man diesen Komplex am besten in seine Einzelschritte und probiert als erstes, ob die Auflösung externer DNS-Namen über die FRITZ!Box per OpenVPN überhaupt funktioniert. Der Eintrag für den DNS-Server in der Serverkonfiguration (192.168.1.222), der dann zum Client "gepusht" wird, läßt mich daran ehrlich gesagt eher zweifeln. Wenn das wider Erwarten richtig sein sollte, ruft man die Internet-Seite erst mal nicht über den Namen, sondern über die Adresse auf. Wenn auch das nicht geht, liegt es wohl am Routing, ansonsten am DNS.

PS: Deine Shift-Taste scheint nicht zu reagieren. Bei allem Verständnis für "hippes Schreiben", soviel Mühe/Höflichkeit sollte man schon erwarten dürfen.
.negitäteb uz etsaT-tfihS eid lamnie hcua na dnu ba ,rewhcs os thcin rag sad tsi iebaD .driw neseleg sknil hcan sthcer nov nehcarpS neginie ni liew run ,sträwkcür thcin hcua aj ebierhcs hcI
 
1.Ja, webseiten aus dem Internet und Webseiten aus meinem Heimnetz.
2. Die selbe ist das nicht, ich meinte damit das, wen mein tab das problem wäre, es auch bei der anderen openvpn verbindung auch das zeigen.
3.Webseiten gehen nicht, aber Geräte im Heimnetz kann ich ereichen.

A) Uffff könnte sein, ich muss mich mal durch das log wühlen und melde mich wieder. Also die NAS prdoziert keinen gescheiten log, im config file wird die Zeile mit dem #log /tmp/openvpn.log wieder auskommentiert wen ich den openvpn server starte.
B) Namen gehen grundsätzlich nicht da es tun verbindungen sind (beide verbindungen).
C) Wen du das mit dem "Netz bei Client" meinst, ja das ist schon länger rausgelöscht (in der freetz seite von open vpn wird darüber, genauer gesagt über die "Erweiterte Clientkonfiguration" nciht erwähnt)
D) und wie teste ich die einzelne Schritte?

PS: nein klemmt nicht, nennt sich Rechtschreibschwäche

# OpenVPN 2.1 Config, Fri Oct 10 23:39:53 CEST 2014
proto udp
dev tun
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
dh /tmp/flash/openvpn/dh.pem
tls-server
port 1194
ifconfig 192.168.006.001 255.255.255.000
push "route-gateway 192.168.006.001"
topology subnet
push "topology subnet"
push "route 192.168.006.000 255.255.255.000"
max-clients 2
mode server
ifconfig-pool 192.168.6.2 192.168.6.108
push "route 192.168.006.001"
client-config-dir clients_openvpn
push "dhcp-option DNS 8.8.8.8"
push "redirect-gateway"
tun-mtu 1500
mssfix
log /var/tmp/debug_openvpn.out
verb 9
cipher AES-128-CBC
comp-lzo
keepalive 10 120
status /var/log/openvpn.log
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key
 
Zuletzt bearbeitet:
3.Webseiten gehen nicht, aber Geräte im Heimnetz kann ich ereichen.
Wie muß ich das jetzt verstehen ? Wie kannst Du die Geräte im Heimnetz erreichen, also woher weißt Du, daß die erreichbar sind ?

A) Uffff könnte sein, ich muss mich mal durch das log wühlen und melde mich wieder. Also die NAS prdoziert keinen gescheiten log, im config file wird die Zeile mit dem #log /tmp/openvpn.log wieder auskommentiert wen ich den openvpn server starte.
Der konkrete Log-Inhalt ist mir eigentlich auch egal, schon die Auskunft, daß man es beim QNAP-NAS schlicht nicht weiß, reicht. Dann ist es ja auch nicht automatisch gesagt, daß der von Dir in #1 postulierte Fehler (MULTI: bad source address from client) etwas mit dem Problem der nicht erreichbaren Internet-Inhalte zu tun hat.

B) Namen gehen grundsätzlich nicht da es tun verbindungen sind (beide verbindungen).
Ok, offenbar fehlt mir da ein Stück Film. Warum kann ein OpenVPN-Tunnel keine DNS-Abfragen transportieren, wenn tun-Devices verwendet werden ?

C) Wen du das mit dem "Netz bei Client" meinst, ja das ist schon länger rausgelöscht (in der freetz seite von open vpn wird darüber, genauer gesagt über die "Erweiterte Clientkonfiguration" nciht erwähnt)
Das soll eigentlich (nach meinem Kenntnisstand) auch nicht die eigene Lektüre der möglichen Konfigurationseinstellungen von OpenVPN komplett ersetzen. Da wird schon einige Male direkt auf die OpenVPN-Seite verwiesen, oder ? Und welche Einstellung sich hinter welchem Punkt im Freetz-Interface verbirgt, läßt sich sicherlich ganz einfach durch einen Vergleich der Serverkonfigurationsdatei mit der HTML-Maske ermitteln.

D) und wie teste ich die einzelne Schritte?
Eine Möglichkeit wäre es ja z.B., sich mal die Adresse einer bekannten Webseite zu ermitteln und diese dann einfach bei aktivierter OpenVPN-Verbindung vom Tablet mit dieser Adresse anstelle des Namens aufzurufen. Wenn das funktioniert, ist es ein DNS-Problem, wenn nicht ... aber ich wiederhole mich.
Ansonsten bräuchtest Du so etwas wie ping oder noch besser traceroute auf dem Tablet, wie Du das da hinbekommst, findest Du bestimmt in den Weiten des Internets. Damit kann man dann den Weg zu einer bestimmten Adresse im Internet verfolgen, wenn der über OpenVPN und die FRITZ!Box geht und funktioniert, ist es auch wieder ein DNS-Problem (mit einiger Wahrscheinlichkeit). Das diagnostiziert man dann wieder am besten auf der Kommandozeile des Tablets ... wenn es so etwas gibt.

Warum Du in Deiner Serverkonfiguration anstelle der FRITZ!Box-Adresse einen Google-DNS zum Client "pushst", mußt Du mir ohnehin mal erklären. Wenn Du da 192.168.6.1 (oder besser sogar die LAN-Adresse der FRITZ!Box => dazu fehlen sämtliche Angaben, ich hoffe mal, daß das LAN nicht die 192.168.6.0/24 verwendet) angibst, sollte die Auflösung von Namen im LAN meiner Meinung nach kein Problem sein und in der Folge dann auch für externe Namen nicht.

Zusätzlich (ist zwar nicht das aktuelle Problem, aber irgendwann fällt Dir das doch auf die Füße) solltest Du Dir die Bedeutung der "DHCP-Range für Clients" (derzeit bei Dir offenbar auf 192.168.6.2-192.168.6.108 eingestellt - warum eigentlich ausgerechnet 108 ?) anlesen und dann überlegen, warum das bei einer festen Zuordnung der 192.168.6.2 zu mindestens einem Client keine gute Idee sein kann.
Auch die - hoffentlich auch korrigierte - Einstellung für die IP-Konfiguration von client1 (das war mal die 192.168.6.1 nach Deinem Screenshot und das ist definitiv falsch, wie Dir MaxMuster schon ins Stammbuch geschrieben hat) wäre als Ergänzung noch interessant bei Gelegenheit, also am besten beide Dateien aus dem Client-Verzeichnis noch dazu packen zu den Ergebnissen des direkten Aufrufs einer Internet-Seite per Adresse. Und wenn Du die Konfiguration erneut änderst, solltest Du die neue Variante dann auch kundtun (oder mindestens einen Diff oder eine korrekte verbale Beschreibung), damit man auf dem aktuellen Stand bleibt.

Und noch ein Wort zu den diversen Subnetzen bei Dir ...
Wenn ich richtig mitgekommen bin, hast Du folgende Subnetze (oder wolltest sie haben):

192.168.2.1/?? am QNAP-NAS (geschlossen aus dem Push von 192.168.2.1 als DNS-Server)
192.168.4.0/24 als OpenVPN-Netz am QNAP-NAS
192.168.6.0/24 als OpenVPN-Netz an der FRITZ!Box
192.168.2.0/24 als clientseitiges Netz bei client2
192.168.1.0/24 als clientseitiges Netz bei client1

Das erscheint mir mächtig durcheinander, ich werde irgendwie den Eindruck nicht los, daß Du da "auf gut Glück" probierst. Kannst Du das mal bitte ordentlich "aufdröseln" ? Was ist denn nun z.B. das LAN bei der FRITZ!Box ?

PS: nein klemmt nicht, nennt sich Rechtschreibschwäche
Siehste, geht doch ... manchmal taugt ja so ein Nachschlagewerk sogar für korrekte Groß-/Kleinschreibung. Das gibt es auch noch als "Duden".
Ich sehe das auch nicht immer so eng, aber wenn Du Dir Deine eigenen Ergüsse in #15 Satz 1 bis 5 noch einmal durchliest, bekommst Du vielleicht wie ich den Eindruck des "schriftlichen Lallens" und man kann von seinem Gegenüber nicht automatisch unbegrenztes Interesse an solchen Sätzen erwarten. Wenn ich einen Satz erst dreimal lesen muß, bevor ich ihn einmal begreife (und das nicht wegen eines komplizierten Sachverhalts, sondern wegen schlechter Orthographie und Grammatik), dann verliere ich einfach das Interesse ... und das geht sicherlich nicht nur mir so. Vielleicht wäre ja also ein wenig mehr Anstrengung (ggf. öfter nachschlagen) doch besser ... ansonsten ist aber Legasthenie heutzutage kein Stigma mehr.
 
ich tippe die ip addresse ein und ein Webinterface öffnet sich. (sat receiver o. Fritzbox)

Ich bezog mich nicht auf DNS "Namen" (www.google.de) sondern Netzwerknamen, also du tippst ein z.b. note2 und landetest auf dem Samba server des Handys, Bei Windows heist es "Computername".


Nein die Subnetzte sind anders verteilt.


192.168.1.xxx Mein Netzwerk zu Hause <--7272
192.168.2.xxx Netzwerk an meinem Arbeitsplatz <--6360
192.168.3.xxx Zu Hause Netzwerk meines Chefs <--7362 SL
192.168.4.xxx OpenVPN Netwerk von der Qnap NAS <--hängt mit beiden LAN Kabeln an der 6360 (Subnetz 192.168.2.xxx)
192.168.5.xxx 2.Standort Arbeit <--6360
192.168.6.xxx OpenVPN in meinem Heimnetz <--Zuerst ein Raspberry, der jetzt andere aufgaben hat, deswegen möchte ich das ganze Openvpn dienste vom Raspberry auf die 7272 übertragen.

Die 7272,6360 und die 2te 6360 sind untereinander per AVM VPN verbunden, die 7362 sl ist nur mit der 6360 mit dem Subnetz 192.168.2.xxx per AVM VPN Verbunden.
Die 6360 Fritzbox mit dem 2.xxx subnetz hat eine Route die das 192.168.4.xxx auf die ip von der NAS legt (in diesem Fall 192.168.2.32).
 
ich tippe die ip addresse ein und ein Webinterface öffnet sich. (sat receiver o. Fritzbox)
Klar ... und genau das solltest Du für eine Internet-Adresse auch mal probieren.

Ich bezog mich nicht auf DNS "Namen" [...] sondern Netzwerknamen, also du tippst ein z.b. note2 und landetest auf dem Samba server des Handys, Bei Windows heist es "Computername".
Die Auflösung von Windows-Netzwerknamen (http://support.microsoft.com/kb/119493/de) erfolgt in einer Mischform (die fest konfiguriert oder von DHCP gesetzt werden kann) zwischen DNS und "WINS" und Broadcasts.
Das einzige, was bei geroutetem Netzwerk nicht funktioniert (ich nehme mal an, das meintest Du mit "tun verbindungen"), ist das Auflösen von WINS-Namen per Broadcast über die Grenzen einer Broadcast-Domain hinweg.
Die Vorgehensweise bei der "Aufteilung" der Namenssuche zwischen direkten Serverabfragen und Broadcasts wird durch den NBT-Nodetype festgelegt. Bei richtiger Konfiguration und einem WINS-Server (auch der nmbd des Samba-Pakets läßt sich als Server und nicht nur als Responder konfigurieren) kann man dann auch WINS-Namen über die Grenzen einer Broadcast-Domain hinaus auflösen. Ansonsten greift Windows normalerweise von sich aus auf DNS-Abfragen zurück, wenn kein WINS-Server konfiguriert ist und eine Auflösung per Abfrage erfolgen soll.

Netzwerkadressen:
Die diversen Kreuzverbindungen der Boxen sind schwer zu durchschauen, ich hoffe nur, daß Du das Routing da auch ordentlich hinbekommen hast.

Wenn bei Dir daheim die Box die 192.168.1.1/24 hat, solltest Du es einfach mal mit dem Eintragen dieser Adresse als DNS-Server für OpenVPN-Clients probieren ... anstelle der ziemlich sinnlosen Angabe 8.8.8.8, die bei aktivierter OpenVPN-Verbindung versuchen würde, über den Tunnel auf den Google-DNS zuzugreifen, was ja vielleicht gar nicht funktioniert. Was nun genau an Deiner "Internet-Verbindung" nicht funktioniert, wenn die Daten über den Tunnel zur Box gehen, hast Du ja offenbar immer noch nicht ermittelt; wenn davon also auch der DNS-Service betroffen ist, hast Du mit der 8.8.8.8 gar keinen DNS-Service auf den OpenVPN-Clients - weder für's LAN noch für's WAN.

So sollte ja auch die Eingabe des richtigen Hostnamens (kann man unter "Netzwerk" für die Clients der FB einfach ablesen) in einem Browser auf dem Tablet ausreichen, um den HTTP-Server eines beliebigen Gerätes auch über den Tunnel anzusprechen. Wenn Du keine anderes Gerät mit einem HTTP-Server hast (was mich angesichts eines RasPi sehr erstaunen würde), könntest Du auch einfach (richtige DNS-Serverkonfiguration am OpenVPN-Client mal vorausgesetzt) mit "fritz.box" das GUI der Box aufrufen.

Aber offenbar schreibst Du nicht nur sehr ungerne richtig (mir war gar nicht bewußt, daß bei Legasthenie sich die Schreibweise von Wörtern innerhalb eines Textes ständig ändert ... komisch) ... Du liest auch die Vorschläge zum Testen nicht oder verstehst sie nicht oder führst sie nicht aus oder verrätst das Ergebnis nicht. Was könnte man denn da nun machen ? Bleibt ja fast nur noch, Dich nochmals auf die OpenVPN-Dokumentation hinzuweisen und sich hier zu verabschieden ... ohne Deine Mithilfe und eine systematische Suche wird Dir sicherlich niemand Dein Problem per Zauberstab lösen. Was schlägst Du also vor ?
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
244,695
Beiträge
2,216,697
Mitglieder
371,315
Neuestes Mitglied
jack-mack
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.