[Gelöst] Standortübergreifende DNS-Auflösung der lokalen Hosts mit FritzBox-VPN?

renne

Neuer User
Mitglied seit
23 Apr 2006
Beiträge
70
Punkte für Reaktionen
0
Punkte
6
Hi,

ich habe zwei Standorte per FritzBox-VPN miteinander verbunden (Fritzbox 7330SL <-> Fritzbox 7390). Die Fritzboxen lösen zwar die lokalen Hostnamen per DNS auf, nicht aber die entfernten Hosts. Das heißt auf die Hosts im entfernten Netzwerk kann nicht per Hostname, sondern nur per IP zugegriffen werden. :(

Kennt jemand eine Lösung, sodass die Fritzboxen auch die entfernten Hostnamen auflösen können?

Danke für jeden Hinweis!
 
Zuletzt bearbeitet:
Kennt jemand eine Lösung, sodass die Fritzboxen auch die entfernten Hostnamen auflösen können?
Versuch mal mit Linux/BSD oder mit einer Linux-Live-CD/DVD:
Code:
dig @<IP-Adresse ferne Box> <ferner Host> +short
Wenn das mit AVM-VPN geht, dann hilft dir z. B. dnsmasq aus Freetz, auf den Boxen.
 
Ich habe einen Workaround gefunden (maximal 2 Fritzboxen):

Bei beiden Fritzboxen unter
1. "Heimnetz->Netzwerk->Netzwerkeinstellungen->DNS-Rebind-Schutz" "fritz.box" als ersten Wert eintragen.
2. "Internet->Zugangsdaten->DNS-Server->DNSv4-Server->Bevorzugter" DNSv4-Server einen öffentlichen DNS-Server eintragen (z.B. Google-DNS-Server 8.8.8.8 ).
3. "Internet->Zugangsdaten->DNS-Server->DNSv4-Server->Alternativer" DNSv4-Server die IP der entfernten Fritzbox eintragen.
 
Zuletzt bearbeitet:
Ich habe einen Workaround gefunden (maximal 2 Fritzboxen):

Bei beiden Fritzboxen unter
1. "Heimnetz->Netzwerk->Netzwerkeinstellungen->DNS-Rebind-Schutz" "fritz.box" als ersten Wert eintragen.
2. "Internet->Zugangsdaten->DNS-Server->DNSv4-Server->Bevorzugter" DNSv4-Server einen öffentlichen DNS-Server eintragen (z.B. Google-DNS-Server 8.8.8.8 ).
3. "Internet->Zugangsdaten->DNS-Server->DNSv4-Server->Alternativer" DNSv4-Server die IP der entfernten Fritzbox eintragen.

Hallo, hoffe nach so langer Zeit liest noch jemand mit.
Ich hab das so gemacht. Leider hilft das bei mir nicht (Win8.1). Trotz "ipconfig -renew" und sogar Neustart komme ich nur dann auf das entfernte Netz, wenn ich die IP-Adresse angebe oder hosts. entsprechend anpasse.

Gibt es neue Erkenntnisse hierzu? Was muss ich noch beachten?
 
Gibt es neue Erkenntnisse hierzu? Was muss ich noch beachten?
Nach allem, was man so mit einem Packet-Dump beobachten kann, wird der zweite DNS-Server bei einer entsprechenden Antwort des ersten (NXDOMAIN) gar nicht erst gefragt. Nur wenn der erste Server nicht antwortet, wird auf den zweiten zurückgegriffen - ist zwar nur eine Interpretation aufgrund des Verhaltens, aber imho Konsens.

Einfacher Test: Packet-Dump auf "Internet - Routingschnittstelle" (wichtig, nur da ist der IPSec-Traffic noch zu unterscheiden) starten und einfach eine nachweislich falsche DNS-Adresse abfragen. Wenn der entfernte DNS-Server nicht nur als Backup, sondern als alternative Quelle auch bei NXDOMAIN, genutzt wird, müßte jetzt eine Abfrage dieses DNS-Servers mit genau demselben Namen von der FRITZ!Box gemacht werden. Das konnte ich bisher (ist aber schon wieder eine Weile her) noch nicht beobachten.

Die Box sucht sich wohl einen DNS-Server als "bevorzugt" selbst aus ... daher hilft es auch nicht, wenn die entfernte Box als erstes eingetragen wird. Dann reagiert diese beim Start nicht auf die Abfragen der Box (wenn die Verbindung noch nicht steht) und wird dann solange ignoriert, bis mal der als zweites eingetragene Server auch nicht antwortet.

Einzige Lösung (mit originaler Firmware + eigenem Skript) wäre imho das Ändern der DNS-Server beim Auf-/Abbau der VPN-Verbindung, vorausgesetzt der entfernte DNS-Server löst als Forwarder dann alle Anfragen aus dem lokalen Netz auch auf.
 
hmmm ...
Noch ne Beobachtung hierzu: Wenn ich die Einstellungen aus #3 vornehme, komme ich mit meinen Androiden problemlos auf die UI der entfernten FB mit deren Namen. Aber mein Win8.1 PC will das partout nicht. Dem muss ich ne manipulierte hosts. Datei unterschieben. Da die Androiden den Zugriff schaffen, scheint die FB also doch was richtig zu machen. Aber warum klappt das mit Windows nicht?
 
Da die Androiden den Zugriff schaffen, scheint die FB also doch was richtig zu machen. Aber warum klappt das mit Windows nicht?
Nur um ganz sicher zu gehen, daß wir hier über denselben Zugriff reden ... die Androiden benutzen auch die LAN-LAN-Verbindung zwischen den Boxen und nicht ihre eigene Client-LAN-VPN-Verbindung ? Haben die event. von einem vorhergehenden Versuch noch eine "gespeicherte Ahnung", wo die FRITZ!Box mit dem fremden Namen zu suchen ist ?

Ich würde das - ehrlich gesagt - nur dann glauben, wenn da wirklich im Packet-Dump um den Zeitpunkt des Zugriffs ein DNS-Query für die Adresse der entfernten FRITZ!Box erfolgt und das auch von der lokalen FRITZ!Box mit der entsprechenden Adresse beantwortet wird. Aber auch dann ist es imho noch nicht 100%ig klar ... was ein wirklich valider Test wäre, ist ein Zugriff von einem Androiden über die LAN-LAN-Verbindung auf ein Gerät im entfernten Netz, zu dem vorher definitiv noch kein Kontakt bestanden hatte (also wo die Adresse unbekannt sein muß).
 
Berechtigte Frage natürlich: Ja, ich spreche/schreibe von der LAN-LAN-Verbindung. Und es ist tatsächlich abhängig von den Einstellungen in #3. Denn wenn ich diese raus nehme funzt der Zugriff auf die entfernte FB nicht mehr. Habe ich nun dreimal hin-und her ausprobiert.

Es ist aber tatsächlich auch so, dass bei direkter VPN-Verbindung von außen dem Androiden den Zugriff auf z.B. das NAS einfach möglich ist und wenn ich das mit dem Win-Notebook versuche brauche ich wieder ne manipulierte hosts.. Nun sind die beiden Szenarien aber nicht wirklich vergleichbar, denn der VPN-Zugriff des Win-Notebooks erfolgt per Port-Forward auf den VPN-Service auf dem QNAP-NAS, da ich den direkten Zugriff mit Win-Bordmitteln noch nicht geschafft habe und die AVM Software nicht verwenden will. Das aber nur am Rande. Hier soll es erstmal um das LAN-LAN-Szenario gehen.
 
Vielleicht hat AVM ja inzwischen da geändert, ich schrieb ja mit Bedacht, daß es eine Weile her ist, daß ich getestet habe.

Um auch das zu klären, könntest Du noch einmal kurz etwas zur Firmware-Version schreiben, bis dahin gehe ich von 06.20 (und damit von einer Box, für die es diese Version gibt) aus.

Ich kann zwar im Wirkbetrieb mit einer Konfiguration wie in #3 nichts anfangen, da nur ein entfernter DNS-Server damit möglich ist (damit auch nur eine VPN-Verbindung), baue mir aber mal ein passendes Test-Szenario auf und schneide mit, wie das dabei läuft. Wenn ich dabei mangels Masse keinen Androiden einsetzen kann und auf ein anderes Linux-System zurückgreifen muß, sollte das keine Rolle spielen, da ja nach meinem Verständnis auch Dein Android-Gerät keine Kenntnis über die Tatsache hat, daß der abgefragte Name nicht lokal ist und somit ganz normal den DNS-Proxy auf der lokalen FRITZ!Box befragt, der mit der entfernten Adresse antwortet.

Um die Rahmenbedingungen vergleichbar zu bekommen, bräuchte ich noch einige Angaben.

- Welcher DNS-Server ist im GUI (Internet/Online-Monitor/Genutzte DNS-Server) als "aktuell genutzt für Standardanfragen" gekennzeichnet ?
- War bei dem erwähnten dreimaligen Test die VPN-Verbindung bereits aktiv oder nicht ? (Wenn nicht, ist der DNS-Server beim Eintragen ja erst einmal nicht erreichbar, wie es bei einem Neustart der Box auch der Fall wäre, s. #6 Abs. 4.)
- Um auch das noch einmal zu präzisieren: Das Android-Gerät kann auch aus dem lokalen Netz (also ohne eigene VPN-Verbindung) und ohne spezielle Einstellungen zum DNS-Server auf Geräte hinter der FRITZ!Box im entfernten Netz mit dem Namen zugreifen, das habe ich richtig verstanden ? Wenn die Angaben vom entfernten DNS-Server stammen, müßte das ja möglich sein.

Ein denkbarer Unterschied zwischen dem Windows-Rechner und dem Androiden ist die Behandlung von verkürzten DNS-Namen und die Reihenfolge/Quelle der Domain-Namen, die für die Bildung eines FQDN herangezogen werden, wenn eine Abfrage keinen Erfolg bringt. Als Beispiel (selbst wenn Du das sicherlich selbst weißt, spätere Leser sollen es auch nachvollziehen können):

Auf einem Windows-Host wird nach "nas123" als DNS-Name gefragt. Kommt jetzt vom DNS-Server die Antwort "unbekannte Adresse (NXDOMAIN)" zurück, wird die Adresse bei weiteren Abfragen um jeweils einen Eintrag aus der Liste der zugewiesenen Domain-Namen für den verwendeten Netzwerk-Adapter ergänzt. Diese Liste der zu verwendenden Namen wird entweder vom DHCP-Server zusammen mit der IP-Adresse bezogen (option domain-search) oder manuell für den Adapter eingestellt:
Anhang anzeigen 78896
Bei Linux-Systemen wird das in aller Regel in der Datei /etc/resolv.conf festgehalten, diese wird dann meistens auch vom DHCP-Client auf diesen Systemen entsprechend geändert. Wie es bei Android ist, weiß ich (mangels Gerät, wie erwähnt) nicht wirklich, aber wegen des Linux-Unterbaus sollte es ähnlich laufen.

Theoretisch könnte dieses Ergänzen auf einen FQDN auf beiden Seiten einer DNS-Abfrage erfolgen ... wenn also der DNS-Server der FRITZ!Box als Proxy den kurzen Namen nicht findet, kann er theoretisch auch selbst seine Liste von Domain-Namen für die Ergänzung durchgehen. Früher war das mal nur "fritz.box", heute vermutlich eine längere Liste, wenn das nicht auf einzelne Host-Einträge gemappt wird ([www.]fritz.nas, [www.]myfritz.box, u.U. auch kabel.box). Die DNS-Server der Box kriegt man afaik heutzutage mit der Abfrage "dns.fritz.box" raus.

Wie das genau in den DNS-Daten der Box aussieht, kann man mit den Support-Daten erkunden oder auch zu Fuß mit folgenden Ausschnitt daraus:
Code:
msgsend multid dnsdump
cat /var/tmp/dnsddebug.txt
/bin/showshringbuf dnsd
showdsldstat (für die verwendeten DNS-Server im Upstream, wenn die FB nur Forwarder ist, sollten dieselben sein, die als dns.fritz.box zurückgegeben werden)
Diese Kommandos einmal mit und einmal ohne VPN-Verbindung ausgeführt, sollten dann eigentlich einen signifikanten Unterschied zeigen.

Normalerweise wird das Verhalten vieler DNS-Clients (eigentlich der Libs, die die Funktionen für gethostbyname o.ä. beinhalten) bei der Verwendung von Suchdomains vom Aufbau der Abfrage abhängig gemacht, ein "absoluter" Name wird dabei durch einen zusätzlichen Punkt am Ende gekennzeichnet. Bei einer Frage nach "nas123" könnte der DNS-Client also nach "nas123" und "nas123.fritz.box" suchen, wenn er selbst die Suchdomain "fritz.box" kennt. Will das anfragende Programm das vermeiden, fragt es anstelle von "nas123" nach "nas123." und nun darf bei der Auflösung nicht mehr um "fritz.box" ergänzt werden.
Wie sich der DNS-Server der FRITZ!Box verhält, weiß ich allerdings gar nicht ... das Problem, das zu durchschauen liegt u.a. daran, daß dort eben ein DNS-Proxy läuft, der Informationen aus verschiedenen Quellen verwurstet, um eine Anfrage zu beantworten und sich nicht auf die reinen DNS-Daten beschränkt. Da wäre es imho sogar denkbar, daß er die oben erwähnten Ergänzungen selbst versucht. Die "Standard-Domain" fritz.box konnte man früher in der ar7.cfg auch noch ändern bzw. ändern kann man sie auch heute noch. Ob dann diese Einstellung aber auch heute noch berücksichtigt wird, müßte man testen.

Die FRITZ!Box "lernt" Geräte auf verschiedene Arten kennen, da könnte ein weiterer Unterschied zwischen den Android-Gerät und einem Windows-PC liegen. Einen per Multicast-DNS (Bonjour/avahi je nach Gusto, ist ziemlich dasselbe) erlernten Namen kann man in der oben erzeugten Liste an der Angabe "(mdns)" erkennen. Im Ringbuffer-Dump kann man sehen, wann die FRITZ!Box zuletzt welche Namen gelernt und auch wieder vergessen hat (wenn das Timeout für den Eintrag abgelaufen ist).

Der Windows-PC wird i.d.R. (ohne installiertes iTunes / Bonjour) nur per "normalem" DNS eine Namensauflösung machen, das Android-Gerät könnte das auch über mDNS versuchen und dabei von der FRITZ!Box andere Antworten für kurze Namen erhalten, denn häufig wird für mDNS-Verkehr eine Pseudo-Domain ".local" verwendet.

Daß bei der Abfrage des entfernten FRITZ!Box-DNS auch Antworten der Form "entfernter_host.fritz.box" zurückgegeben werden, ist ja mit einiger Wahrscheinlichkeit auch der Grund, warum die Domain "fritz.box" unter "Rebind-Ausnahmen" eingetragen werden muß. Ansonsten verwirft die FRITZ!Box alle Namen, die zu einer von ihr selbst verwalteten Domain (in diesem Falle eben fritz.box) gehören, da sie selbst dafür der "authoritative dns" ist (irgendwo in der dnsddebug.txt sollte der SOA-Record dafür stehen) und alle von ihren "Kenntnissen" abweichenden Antworten potentiell ein Angriff über "DNS-Spoofing" sein müssen.
Das ist dann auch eine Schwachstelle des o.a. Eintrags, der - nach meiner Kenntnis - eigentlich dafür gedacht ist, in einem VPN-Szenario mit einer Firma (wo die FRITZ!Box dann ihrerseits als Client auftritt -> "Diese FRITZ!Box mit einem Firmen-VPN verbinden") den möglichen (in diesem Fall dann aber berechtigten) Unterschied zwischen DNS-Abfragen über das Internet (wie sie die Box normalerweise macht) und über das Intranet (wenn sie per VPN Teil des Firmennetzwerks ist) zu kompensieren. Wenn mit einem solchen Eintrag ein Cache-Poisoning für abc.fritz.box erfolgen würde (keine Ahnung, ob der DNS-Cache der Box dafür anfällig ist), würde das vermutlich nicht mehr zurückgewiesen.
EDIT: Glatt vergessen klarzustellen ... der Rebind-Schutz verhindert natürlich (sogar in erster Linie) auch, daß Adressen an die Box von einem externen Server ausgeliefert werden, die lokal für die Box sind (und da gehört eine VPN-Adresse samt Netz dazu). Das mit dem VPN-Szenario bezog sich auf die Ausnahmen beim Rebind, die dort ggf. erforderlich sind.

Unter dem Aspekt, daß die FRITZ!Box bei den in #3 beschriebenen Einstellungen ja weiß, wann sie mit einem VPN verbunden ist, wäre sogar eine abweichende Behandlung der DNS-Abfragen durch die FRITZ!Box nicht unlogisch. Aber das müßte sich ja dann wieder aus einer geänderten Anzeige bei "Genutzte DNS-Server" mit oder ohne VPN-Verbindung und notfalls auch aus einem Paketmitschnitt des DNS-Verkehrs ermitteln lassen. Wenn man die "Routing-Schnittstelle" nimmt, sieht man ja auch die IPSec-Pakete noch im Klartext.

BTW: Mit Windows-Bordmitteln wird Dir die IPSec-Verbindung zur FRITZ!Box eher nicht gelingen, Windows verwendet m.W. immer noch L2TP-IPSec und das ist etwas anderes, als das AVM-VPN. Wenn der Windows-PC auch ein "Client-LAN-VPN" beherrschen soll, bleibt meines Wissens im Moment entweder "FRITZ!Fernzugang" (der VPN-Client, nicht das Einrichtungsprogramm) oder "Shrewsoft".
 
Zuletzt bearbeitet:
Wow! Sehr ausführlich. Aber um ehrlich zu sein für mich 90% Spanisch. Verzeihung! Aber in jedem Fall vielen Dank für Deine Arbeit.

Ein paar Antworten:
1. Die lokale Box (7490) läuft mit FRITZ!OS 06.21-29403 BETA, die entfernte 7490 läuft mit 06.20.
2. Als DNS Server habe ich in beiden Boxen exakt die Einträge wie in #3 gemacht.
3. Die Androiden können auf das NAS im lokalen Netz und die UIs beider Fritzboxen jeweils per Namen zugreifen. Win Clients können das nur im lokalen Netz, im entfernten nur per IP-Adresse.
4. ipconfig auf dem Win Client spukt mir für die relevante Schnittstelle folgendes aus:
Standardgateway . . . . . . . . . : 192.168.0.1
DHCP-Server . . . . . . . . . . . : 192.168.0.1
DHCPv6-IAID . . . . . . . . . . . : ...
DHCPv6-Client-DUID. . . . . . . . : ...
DNS-Server . . . . . . . . . . . : fd00::3631:c4ff:fe07:4ee7
192.168.0.1
NetBIOS über TCP/IP . . . . . . . : Aktiviert
5. Ja und das "BTW" ist klar. Deswegen benutze ich ja momentan Win-Bordmittel und den VPN-Service auf dem NAS mit Port Forwarding.

Hilft das? Und nochmal vielen Dank!
 
Aber um ehrlich zu sein für mich 90% Spanisch.
Schade, ich hatte im stillen die Hoffnung, es auch ohne ausführliche eigene Tests zusammen klären zu können, wo das der Unterschied zwischen VPN und "nicht VPN" bei der Namensauflösung liegen könnte.

Das würde aber natürlich die Beantwortung der ersten zwei Fragen (dann kam ja wieder mehr das Dozieren über denkbare Ursachen für Deine Beobachtungen, sorry) noch erfordern.

Die ipconfig-Ausgabe wirft auch noch die Frage auf, ob nicht der Unterschied zwischen dem Android-Gerät und dem Windows-PC auch darin bestehen könnte, daß der Windows-PC den DNS-Server der FRITZ!Box vermutlich zuerst über die IPv6-Adresse befragen wird. Wie das beim Android ist, weiß ich nicht.

Wenn Du schreibst, Du machst die IPSec-Verbindung zur Gegenseite über Port Forwarding auf dem NAS, wie muß man sich das denn vorstellen ? Macht das NAS eine Verbindung zur FRITZ!Box auf der anderen Seite auf ? Oder die beiden NAS untereinander ? Irgendwie kommt mir das etwas komisch vor ... kannst Du das mal erklären ? Bei NAS<->NAS wirst Du ja sicherlich nicht ernsthaft erwarten, daß der DNS-Server der FRITZ!Box (die 192.168.0.1 wird sicherlich eine FB sein, bei der IPv6-Adresse (theoretisch die MAC-Adresse 36:31:c4:07:4e:e7) bin ich mir da nicht so sicher) da richtig auflöst, oder ?

Oder laufen dann am Ende zwei VPN-Verbindungen (FB<->FB, die vom Android genutzt wird und NAS<->NAS, was vom WinPC benutzt wird) parallel ? :gruebel:

Ein eklatanter Unterschied zwischen IPv4 und IPv6 ist es jedenfalls noch, daß bei IPv4 die DNS-Server feststehen (per DHCP oder fest eingestellt), während bei IPv6 auch weitere DNS-Server per Multicast erlernt werden können. Wenn dann die fd00-Adresse oben gar nicht die FRITZ!Box ist, sondern z.B. das NAS, dann würde eine IPv6-Abfrage des NAS als DNS-Proxy für Adressen aus dem entfernten Netz ja nicht von den Fähigkeiten und Einstellungen der FRITZ!Box, sondern vom NAS abhängen.

Also ... da mußt Du imho noch ein paar eigene Untersuchungen anstellen und noch einige Informationen dazu packen ... bisher sind es eigentlich nur noch weitere Fragen, die da entstanden sind. ;)
 
Das würde aber natürlich die Beantwortung der ersten zwei Fragen (dann kam ja wieder mehr das Dozieren über denkbare Ursachen für Deine Beobachtungen, sorry) noch erfordern.
Sorry, dass ich das oben noch nicht gemacht habe. Hier nun:
Welcher DNS-Server ist im GUI (Internet/Online-Monitor/Genutzte DNS-Server) als "aktuell genutzt für Standardanfragen" gekennzeichnet ?
8.8.8.8

War bei dem erwähnten dreimaligen Test die VPN-Verbindung bereits aktiv oder nicht ? (Wenn nicht, ist der DNS-Server beim Eintragen ja erst einmal nicht erreichbar, wie es bei einem Neustart der Box auch der Fall wäre, s. #6 Abs. 4.)
War aktiv. Ich habe verstanden, dass die Fritzboxen die direkte Verbindung bei Bedarf immer sofort aufbauen. Und so lese ich es auch aus dem Log der FB. Ja, die Verbindung ist/war aktiv.
Um auch das noch einmal zu präzisieren: Das Android-Gerät kann auch aus dem lokalen Netz (also ohne eigene VPN-Verbindung) und ohne spezielle Einstellungen zum DNS-Server auf Geräte hinter der FRITZ!Box im entfernten Netz mit dem Namen zugreifen, das habe ich richtig verstanden ? Wenn die Angaben vom entfernten DNS-Server stammen, müßte das ja möglich sein.
Die Androiden brauchen die Einstellungen aus #3, um auf das UI der entfernten FB per deren Namen zugreifen zu können. Wenn die Einstellungen #3 nicht da sind geht der Zugriff nur über die IP der entfernten FB.

Die ipconfig-Ausgabe wirft auch noch die Frage auf, ob nicht der Unterschied zwischen dem Android-Gerät und dem Windows-PC auch darin bestehen könnte, daß der Windows-PC den DNS-Server der FRITZ!Box vermutlich zuerst über die IPv6-Adresse befragen wird. Wie das beim Android ist, weiß ich nicht.
Das hatte ich auch mal befürchtet und daraufhin den IPv6 Service der beiden FBs ausgeschaltet. Gab leider keine Verbesserung. Also habe ich einen IPv6 Einfluss hier mal ausgeschlossen. Macht das Sinn?

Wenn Du schreibst, Du machst die IPSec-Verbindung zur Gegenseite über Port Forwarding auf dem NAS, wie muß man sich das denn vorstellen ? Macht das NAS eine Verbindung zur FRITZ!Box auf der anderen Seite auf ? Oder die beiden NAS untereinander ? Irgendwie kommt mir das etwas komisch vor ... kannst Du das mal erklären ? Bei NAS<->NAS wirst Du ja sicherlich nicht ernsthaft erwarten, daß der DNS-Server der FRITZ!Box (die 192.168.0.1 wird sicherlich eine FB sein, bei der IPv6-Adresse (theoretisch die MAC-Adresse 36:31:c4:07:4e:e7) bin ich mir da nicht so sicher) da richtig auflöst, oder ?

Oder laufen dann am Ende zwei VPN-Verbindungen (FB<->FB, die vom Android genutzt wird und NAS<->NAS, was vom WinPC benutzt wird) parallel ? :gruebel:
Sorry für die Verwirrung. VPN via Port Forwarding zum NAS Service mache ich nur, wenn ich mich dem Win Client auf mein Netz einwählen will. Das hat also garnichts mit der LAN-LAN-Verbindung zu tun, die ich direkt zwischen den beiden Fritzboxen veranstalte und gemäß Anleitung von AVM erfolgreich aufgebaut und nach Anweisung in #3 ergänzt habe. Also lass uns das direkte VPN eines Win-Clients zu LAN aktuell mal vergessen. Das ist nicht aktiv.

Die "funktionierenden" Androiden befinden sich genauso wie die "nicht funktionierenden" Win Clients einem der beiden LANs per Kabel bzw WLAN und wollen auf Ressourcen im anderen per LAN-LAN-VPN verbundene Netz zugreifen. ok?
 
Zuletzt bearbeitet:
Ich habe verstanden, dass die Fritzboxen die direkte Verbindung bei Bedarf immer sofort aufbauen. Und so lese ich es auch aus dem Log der FB. Ja, die Verbindung ist/war aktiv.
Das sind zwei Punkte, die einer Klärung bedürfen. Das "bei Bedarf" sieht so aus, daß eine IPSec-Verbindung "on demand" aufgebaut wird, wenn Daten bei der FRITZ!Box ankommen, die für das entfernte Netzwerk bestimmt sind (das kennt die Box ja aus der Konfiguration bei einer LAN-LAN-Verbindung, auch wenn es in der Liste der VPN-Verbindungen (entferntes Netz) erst angezeigt wird, wenn auch die Verbindung steht). Die Daten für das entfernte Netz werden also zurückgehalten, die Verbindung wird aufgebaut und dann werden die gehaltenen Daten verzögert gesendet. Jetzt weiß der sendende Client ja nicht automatisch, daß da vor einer Antwort erst noch eine Verbindung per VPN aufgebaut werden muß und wartet seinerseits nur eine begrenzte Zeit. Klappt jetzt also aus irgendeinem Grund eine VPN-Verbindung nicht auf Anhieb (Störung im Internet oder meinetwegen ist auch die andere FRITZ!Box mal neu gestartet), kriegt der Client nicht auf Anhieb eine Verbindung und meldet dann an den Benutzer (oder woher auch immer der Verbindungswunsch kam) einen entsprechenden Fehler.

Beim "Aussuchen" der DNS-Server ist dann die FRITZ!Box ihr eigener Client - der Aufbau der VPN-Verbindung ist losgelöst vom DNS-Server. Wenn man jetzt mal den bisher (nicht nur von mir) vermuteten Ansatz betrachtet, wie die FRITZ!Box den Standard-Server auswählt, dann spielt es eben eine wichtige Rolle, ob und wann die VPN-Verbindung aktiviert ist/wird. Wenn die Annahme stimmt, daß der Server zum Standard wird, der als erster antwortet, dann ist eben der Weg bis zum Google-Server weiter als bis zur VPN-Gegenstelle und damit könnte es sein, daß der DNS-Proxy der Gegenstelle schneller antwortet und zum Standard-Server wird, wenn man ihn bei aufgebauter VPN-Verbindung neu speichert.

Deshalb auch die Frage, ob die Android-Zugriffe auch wirklich selbst dann erfolgreich mit dem Namen arbeiten (dabei muß man natürlich auch wieder aufpassen, daß da nicht noch eine Information im DNS-Cache ist, d.h. für einen "sauberen" Test müßte man entweder wissen, wie man den DNS-Cache löscht oder das Gerät neu starten), wenn zum Zeitpunkt der DNS-Anfrage (und eben genau dann) der DNS-Server für "Standardanfragen" der Google-Server ist.

Denn auch bei der Anfrage nach einem Namen im LAN der Gegenseite kann der DNS-Proxy der FRITZ!Box ja nicht schon vorher wissen, ob die Adresse nun im Internet oder im entfernten Netz liegt und sollte dann erst einmal den Standardserver abfragen. Wenn der mit NXDOMAIN antwortet, hat die FRITZ!Box zwei Möglichkeiten: Entweder sie gibt diese Nachricht direkt an den Client weiter oder sie stellt fest, daß sie ein VPN aktiviert hat und dann ? Jetzt gibt es ja immer noch mehrere Möglichkeiten, denn ohne den eingestellten zweiten Server beim VPN müßte sie den Fehler ja auch wieder weiterreichen.

Meines Wissens ist es bisher wirklich noch nie beobachtet worden, daß eine FRITZ!Box parallele DNS-Abfragen an die beiden eingetragenen Server sendet und dann die schnellere gewinnt.

Das macht im Normalfall (zwei DNS-Server vom Provider) ja auch wenig Sinn, außer daß dann eine Abfrage praktisch immer umsonst gestellt und beantwortet wird (mit dem ganzen Traffic der da dran hängt), weil der Client ohnehin nur eine braucht.

Wenn meine Vermutung (es ist - wie gesagt - nicht nur meine eigene, ich finde bloß den Thread dazu grade nicht) stimmt, dann würden bei aktivierter VPN-Verbindung und der entfernten FRITZ!Box als Standard-Server praktisch alle DNS-Abfragen an die andere FRITZ!Box gehen und dann von der beantwortet.

Das ist zwar bei den in #3 skizzierten Einstellungen auf beiden Seiten auch egal, aber spätestens beim Einsatz von SIP-Telefonie beim Anbieter kann das ganz gewaltig in die Hose gehen, wenn da der DNS-Name des SIP-Registrars nur über den eigenen DNS-Server des Providers aufgelöst werden kann, wie es z.B. bei KDG häufig der Fall ist. Solange man immer Google fragt, kriegt man ja auch im lokalen Netz keine Adressen aufgelöst, die nur im Providernetz (und damit von dessen DNS-Server) aufgelöst werden können, da macht es auch nichts, wenn der entfernte DNS-Proxy es auch nicht kann.

Die Androiden brauchen die Einstellungen aus #3, um auf das UI der entfernten FB per deren Namen zugreifen zu können. Wenn die Einstellungen #3 nicht da sind geht der Zugriff nur über die IP der entfernten FB.
Ok, die Einstellungen werden aber nur in der FRITZ!Box gemacht und nicht in den Android-Geräten selbst und ich verstehe das "brauchen" so, daß sie auf die Einstellungen in der FRITZ!Box angewiesen sind.

Das hatte ich auch mal befürchtet und daraufhin den IPv6 Service der beiden FBs ausgeschaltet. Gab leider keine Verbesserung. Also habe ich einen IPv6 Einfluss hier mal ausgeschlossen. Macht das Sinn?
Stell doch einfach mal im Windows den IPv6-Support für den Adapter ab (Checkbox bei IPv6 den Haken raus).
EDIT: Wenn der IPv6-Support der FRITZ!Box gar nicht aktiv ist, dann muß die angezeigte fd00-Adresse als DNS ja einem anderen Gerät gehören.
 
Zuletzt bearbeitet:
IPv6 hab ich jetzt mal am Laptop abgeschaltet. ipconfig zeigt jetzt nur noch 192.168.0.1 als DNS Server. Zugriff auf die entfernte BOX per Namen funzt immer noch nicht. Also liegt's nicht am IPv6.

Die beiden Boxen haben eine dauerhafte Verbindung. Ich kann das in der UI und im Log erkennen. Und bei entsprechend #3 gemachten Einstellungen haben die Androiden zu jeder Zeit Zugriff auf die entfernte Box per Namen. Egal ob ich das spontan versuche, nach längerer Arbeitspause oder das Gerät gerade neu gestartet habe.

Aber mal grundsätzlich:
Warum zeigen Win Clients als DNS Server nur die lokale Box an? Die Einstellungen dort lauten doch 1. 8.8.8.8, 2. <IP der entfernten Box>.
 
Warum zeigen Win Clients als DNS Server nur die lokale Box an? Die Einstellungen dort lauten doch 1. 8.8.8.8, 2. <IP der entfernten Box>.
Bis hierher dachte ich noch, wir reden über dasselbe ...

Die FRITZ!Box gibt per DHCP ja immer ihre eigene Adresse als DNS-Server an die Clients heraus, deshalb schreibe ich ja auch da, wo es sich um einen solchen handelt, immer von einem DNS-Proxy. Die Box nimmt selbst die DNS-Abfragen der Clients entgegen und leitet sie an die - nur ihr selbst bekannten - DNS-Server weiter. Sie wird aber niemals die DNS-Server-Adressen per DHCP direkt an die Clients herausgeben.

Wenn Du da also einen Unterschied siehst, frage ich mich, wie die Android-Clients an die Adressen der "realen" DNS-Server kommen sollten, die kennen doch genauso nur die 192.168.0.1 als DNS-Server und keinesfalls die 8.8.8.8 oder die Adresse der entfernten FRITZ!Box. Wenn das anders ist, reden wir komplett aneinander vorbei, dann ist die Situation eine vollkommen andere.
 
Nun hab ich verstanden, was DNS-Proxy bedeutet und das die FB den Clients nicht die ganze Wahrheit verrät.

Es gilt aber immer noch: Ich habe auf den den Androiden wie auf den Win Clients jeweils nicht mehr als DHCP eingestellt. Es bleibt also die ursprüngliche Frage, warum bei Anfragen der Androiden diese richtig durch den DNS-Proxy und wieder zurück kommen und bei Win eben nicht (wenn ich das mal so laienhaft ausdrücken darf).
 
Es bleibt also die ursprüngliche Frage, warum bei Anfragen der Androiden diese richtig durch den DNS-Proxy und wieder zurück kommen und bei Win eben nicht
Noch etwas zum Cache eines DNS-Proxy/Forwarders ... erklärt das aber auch noch nicht, da wirst Du um einem Paketmitschnitt nicht herum kommen.

Jede Antwort im DNS hat eine bestimmte Gültigkeitsdauer (TTL), sowohl erfolgreiche als auch nicht erfolgreiche Abfragen. Diese Gültigkeitsdauer gibt (normalerweise) der Betreiber der Domain vor. Wenn also ein Forwarder den DNS-Server von avm.de nach der Adresse des nicht existierenden Servers quasimodo.avm.de fragt und der eine Antwort "gibt es nicht" zurückschickt, dann steht in dieser Antwort gleichzeitig drin, wie lange diese Antwort gültig sein soll. Das soll einfach verhindern, daß ein DNS-Server ununterbrochen nach einem nicht vorhandenen Namen gefragt wird. Sollte dieser Name irgendwann mal dazukommen, kriegt das der letzte abfragende Server eben erst dann mit, wenn die TTL der NXDOMAIN-Antwort abgelaufen ist.

Das ist auch der Grund, warum DNS-Änderungen immer ein wenig brauchen, bis sie sich im Internet "herumgesprochen haben". Beim DynDNS werden solche Wartezeiten dadurch vermieden, daß da sehr kurze TTL (meist 60 Sekunden) zum Einsatz kommen, entsprechend häufig müssen dann andere Server eben beim zuständigen DNS-Server nachfragen, denn nach diesen 60 Sekunden ist dann auch eine positive Antwort nicht mehr gültig.

Wenn nun also die FRITZ!Box im Auftrag eines Clients eine Anfrage an den avm.de-Server nach der vorhandenen Adresse "www.avm.de" stellt, dann merkt sich die FRITZ!Box - zusätzlich dazu, daß sie die Antwort an den Client weiterleitet - die Antwort des DNS-Servers von avm.de für die mit der Antwort übermittelte Zeit. Das sind beim AVM-Server 3600 Sekunden, also eine Stunde. Wenn jetzt innerhalb dieser Stunde ein anderer Client (oder derselbe, weil er den Eintrag inzwischen vergessen hat) erneut nach der Adresse von www.avm.de fragt, dann beantwortet die FRITZ!Box diese Anfrage direkt mit der ja immer noch gültigen Adresse, dabei wird aber an den Client nicht mehr die TTL von 3600 Sekunden weitergeleitet, sondern nur noch die verbleibende "Lebensdauer" (TTL = time to live) dieser Antwort.

Dem Client steht es nun frei, sich diese Antwort für die angegebene "Restlaufzeit" zu merken oder nicht. Merkt er sie sich, fragt er innerhalb dieser Zeitspanne den DNS-Proxy der FRITZ!Box nicht erneut, sondern verwendet gleich die bekannte Adresse. Das sieht dann unter Umständen so aus, als wäre die Namensauflösung zu diesem Zeitpunkt ebenfalls möglich gewesen, dabei ist es nur das Ergebnis einer früheren Abfrage.

Bei einem Windows-PC kann man das Löschen der lokalen DNS-Caches z.B. mit einem "ipconfig /flushdns" erzwingen, dann wird bei der nächsten Suche nach dem Namen wieder der Server (also die FRITZ!Box, nicht der von AVM) gefragt. Erst wenn auch die FRITZ!Box die Adresse nicht mehr im Cache hat (wegen abgelaufener Zeit, zwangsweise geleertem Cache oder einem Neustart), erst dann wird ein vorgelagerter Server (ein sogenannter Forwarder) oder auch gleich der zuständige Server nach dieser Adresse gefragt.

Die TTL sollte allerdings nicht der Grund für den Unterschied sein, eine FRITZ!Box liefert m.W. die lokalen Adressen immer nur mit einer TTL von 9 Sekunden aus, da dürfte der Cache keine Rolle spielen, solange alle Beteiligten diese TTL beachten.

Unter Linux läßt sich die TTL relativ leicht mit "dig" ermitteln, unter Windows muß man dazu beim nslookup noch ein "set debug"-Kommando davor ausführen.

Ich habe das gerade mal mit nslookup für meine nicht sehr kurze Liste von Domain-Präfixen getestet. Windows beginnt - bei mir jedenfalls - nicht mit einem "kurzen" Namen die Abfragen, es geht gleich mit dem ersten Eintrag aus der Liste los. Aus einer Abfrage "abc" wird also gleich eine Abfrage "abc.home.meinedomain.de" bei mir. Das kann aber auch an der expliziten Einstellung der Suchdomains liegen, kannst Du ja leicht selbst prüfen, wie das bei Dir aussieht.

Das Verhalten von nslookup ist auch nicht 1:1 auf das Verhalten eines Browsers zu übertragen. Je nach Browser erfolgen ja schon beim Eintippen des Rechnernamens in die Adresszeile permanent irgendwelche Abfragen an den DNS-Server (da hat FF eine Unsitte vom Chrome übernommen, die man leider auch nicht abschalten kann) und da kann dann natürlich eine negative Antwort mit 9 Sekunden TTL auch schon zu Unterschieden führen - ob die Browser dabei die Systemfunktionen nutzen (und damit den Cache) oder direkt mit dem DNS-Server kommunizieren (und das Ergebnis dann selbst cachen), weiß ich nicht, dürfte auch durchaus vom Browser abhängig sein.

Daher testet man so etwas dann mit "ping", das ist schön simpel und bringt wenig durcheinander.

Bei Linux gibt es normalerweise noch eine Einstellung in der /etc/resolv.conf, wieviele Punkte eine angefragte Adresse maximal enthalten darf (options ndots:X), damit die Ergänzung auf FQDN durchgeführt werden darf. Da könnte auch ein Unterschied liegen bei den Androiden, aber das Mitschneiden des Netzwerkverkehrs kann Dir niemand abnehmen.

Du kannst nur vorher eben mal mit nslookup auf dem Windows-PC schauen, was der alles bei der FRITZ!Box anfragt und wie deren Antworten lauten. Wenn Du dann auf einem Androiden etwas ähnliches machen und den Unterschied zum Windows feststellen kannst, kommst Du um den Mitschnitt vielleicht herum, aber der einfachste Weg bleibt ein solcher Packet-Dump natürlich trotzdem.
 
Zuletzt bearbeitet:
ok, und was genau soll ich nun eintippen?

ipconfig /flushdns hab ich gemacht.

nslookup liefert:
nslookup <Name der entfernten Fritzbox>
Server: fritz.box
Address: fd00::3631:c4ff:fe07:4ee7

*** <Name der entfernten Fritzbox> wurde von fritz.box nicht gefunden: Non-existent domain.

Was soll ich mit "set debug" vorher machen?

Ja, und ich verwende als einfachsten Test immer
ping <Name der entfernten Fritzbox>
 
ok, und was genau soll ich nun eintippen?
Kommt sicherlich drauf an, was Du wissen willst ... die Frage läßt sich so platt ja nun nicht beantworten.

ipconfig /flushdns hab ich gemacht.
Mußtest Du gar nicht, war nur ein Beispiel, wie es bei Windows gemacht werden kann, wenn man einen sauberen DNS-Cache will und nicht den PC neu starten will. Da ich Deine Androiden nicht kenne, kann ich auch nicht sagen, ob es etwas ähnliches für die auch gibt.

nslookup liefert:
nslookup hat zwei verschiedene Modi, einen interaktiven und den, den Du benutzt hast. Im interaktiven kann man vorher das "set debug" absetzen, dann sieht man (wie bei so vielen Debug-Sachen), was da im Hintergrund abläuft.

Ist aber in Deinem Fall offenbar nicht notwendig ... der Rest gibt ja auch schon Auskunft.

Entweder Du hast Dir gedacht, IPv6 ändert nichts und es wieder angeschaltet oder es ist Dir schon nicht gelungen, es mal abzuschalten.

Die Abfrage des DNS-Proxy (Server: fritz.box) mit der IPv6-Adresse (fd00:...) bringt ja das eindeutige Ergebnis, daß dieser Name der FRITZ!Box unbekannt ist.

Wenn Du das jetzt auch noch mit "<Name der entfernten Fritzbox>.fritz.box" machst bzw. wenn das in Wirklichkeit schon diese Abfrage war (das sieht man eben mit "set debug") und auf die Abfrage des Namens der entfernten FRITZ!Box mit dem abschließenden Punkt auch diese Antwort kommt, dann können die Androiden einfach hellsehen oder die Weltherrschaft der Maschinen (in menschenähnlicher Gestalt, damit Android gerechtfertigt ist) steht unmittelbar bevor, denn sie kommunizieren im Hintergrund schon miteinander und niemand bemerkt es.

Jedenfalls geht ja wohl aus der nslookup-Abfrage eindeutig hervor, daß da nicht der Windows-PC die Fehlerquelle ist. Wenn der den DNS-Server fragt, wie die Adresse lautet und der antwortet dann: "kenne ich nicht", was soll denn der Windows-PC dann machen bzw. wieso ist er in Deinen Augen an der Misere schuld ?

Für mich stellt sich da eher die Frage, wieso es bei den Androiden überhaupt geht ... das Verhalten des Windows-PC und die Antwort der FRITZ!Box entsprechen genau dem, was zu erwarten ist, wenn die FRITZ!Box ihrerseits den Google-DNS (8.8.8.8) als Standard-Server befragt und von diesem die Antwort kriegt: "kenne ich nicht" (s.o.).

Wenn dann nicht die FRITZ!Box (wo Du den zweiten DNS ja eingestellt hast) ihrerseits die entfernte Box befragt, wieso sollte das der Windows-PC machen ? Ich kann mir auch nicht vorstellen, daß die Androids es selbst machen, die fragen garantiert nach etwas anderem und solange Du nicht weißt wonach, wirst Du dieses Mysterium nicht enträtseln können. Auf den Packet-Dump weise ich nicht noch einmal hin ... wissen ist immer besser als raten.
 
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.