HTTPS, SSL, Port 443, via IPv4 und das alles an einem Vodafone IPv6 Anschluss

[rohrbrecher]

Hi, sorry wenn bereits meine Überschrift verwirrend ist aber ich bewege mich in Gefilden in denen ich mich nicht mehr auskenne und brauche Hilfe.

Zum Hintergrund:
Seit einigen Monaten läuft hier bei mir ein Proxmox VM Host, auf dem diverse Dienste gehostet sind, unter anderem auch ein nginx welcher diese Dienste nach außen verfügbar macht. Selbst das zu erreichen war für mich teilweise echt Voodoo weil ich mich bisher nur sehr oberflächlich im Bereich IPv4 Portforwarding bewegt habe und keinerlei Ahnung von IPv6 hatte. Im Detail sieht es so aus:

Da ich von Vodafone nur noch eine IPv6 bekomme nutze ich als DynDNS https://dynv6.com/, da dieser der Einzige war welcher mir erlaubt hat meinen IPv6 Prefix dynamisch zu ändern während die festen Geräteadressen statisch blieben.
Die Fritzbox aktualisiert also meinen Prefix bei dynv6 regelmäßig und dynv6 leitet dann diverse Subdomains auf den nginx um, welcher dann wieder das tut, was ein Reverse Proxy tun soll und auf die IPs der VMs umleitet.

beispiel1.meinname.dynv6.net --> IPv6 meines nginx --> lokale IPv4 inkl. Port des Dienstes "beispiel1"
beispiel2.meinname.dynv6.net --> IPv6 meines nginx --> lokale IPv4 inkl. Port des Dienstes "beispiel2"

Bei einem DNS Lookup der dynv6 Adressen bekomme ich hier nur jeweils einen AAAA record angezeigt, welcher der IPv6 Adresse meines nginx entspricht.

Nachdem das funktioniert hat, habe ich mir eine Domain bei Strato geklickt, dort wieder Subdomains angelegt und per Subdomainumleitung auf die dynv6 verwiesen.

beispiel1.meinestratodomain.de --> beispiel1.meinname.dynv6.net --> IPv6 meines nginx --> lokale IPv4 inkl. Port des Dienstes "beispiel1"
beispiel2.meinestratodomain.de --> beispiel2.meinname.dynv6.net --> IPv6 meines nginx --> lokale IPv4 inkl. Port des Dienstes "beispiel2"

Bei einem DNS Lookup der Strato Adressen sehe ich hier je einen A und AAAA record, welche den Adressen von Strato entsprechen.

Dieser "Umweg" ist eigentlich nicht unbedingt notwendig gewesen, die kürzeren URLs sind aber für den FAF (Frauen Akzeptanz Faktor) ganz hilfreich gewesen.

Auch das hat soweit funktioniert und ich konnte seitdem meine Dienste sowohl über die Strato als auch über die direkten dynv6 Adressen ansprechen.

---

Nun zum eigentlichen Problem:
Ich möchte nun per Amazon Webservices auf einen der Dienste (Home Assistant) zugreifen. Das ist eine lange Geschichte und eigentlich fast schon ein Thema für sich. Die relevanten Fakten sind aber, dass ich dafür folgendes brauche, Zitat: "The Alexa Smart Home API requires your Home Assistant instance to be accessible from the internet via HTTPS on port 443 using an SSL/TLS certificate." Außerdem scheint es laut diverser Foren und Github Einträge so zu sein, dass die Amazon API nur auf IPv4 auflöst.

So, nun habe ich im nginx natürlich Lets Encrypt Zertifikate hinterlegt und aktiviert. Diese funktionieren nach meinem Verständnis auch, da ich per https problemlos auf die Dienste komme. Beim Versuch per Amazon darauf zuzugreifen bekomme ich allerdings den Fehler "No address associated with hostname" bzw. "Name or service not known". Das hat möglicherweise damit zu tun, dass ich direkt auf die dynv6 Adressen weiterleite und diese kein IPv4 anbieten (Bei einem DNS Lookup existiert nur ein AAAA record).

Dann bin ich auf einen Post auf github gestoßen:


Der Hinweis mit dem CNAME record war für mich ganz interessant, da wohl eigentlich bei Strato nie die Subdomainweiterleitung sondern CNAME hätte nutzen sollen, um die Strato Adresse auf die dynv6 Adresse umzubiegen. So richtig schlau wurde ich allerdings nicht daraus.

Ich hab dann weiter herumprobiert und herausgefunden, dass ich bereits bei Strato SSL aktivieren kann. Das hab ich also getan und siehe da, der Fehler ändert sich. Bei AWS bekomme ich nun plötzlich die Fehlermeldung "SSLError(SSLError(1, '[SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure" und im Browser (sowohl Firefox als auch Chrome) bekomme ich: "SSL_ERROR_NO_CYPHER_OVERLAP".
Soll heißen: Seitdem ich bei Strato SSL für meine Domain aktiviert habe, komme ich per https auf keinen meiner Dienste mehr. Per http funktioniert es immer noch wie gehabt.

Zum Test hab ich mal eine weitere Strato Subdomain angelegt und dort nur einen CNAME Eintrag nach folgendem Schema gemacht:

beispiel3.meinestratodomain.de --CNAME--> beispiel3.meinname.dynv6.net.

Bei einem DNS Lookup dieser neuen Strato Adresse sehe ich zwei Unterschiede: Im Gegensatz zu den anderen Strato Subdomains habe ich hier keinen A record, der AAAA record zeigt auf die IPv6 Adresse meines nginx anstatt auf Strato und zudem gibt es eben noch den CNAME record.

Ich bin jetzt ehrlich gesagt langsam ziemlich verwirrt. Ich vermute, dass ich bei Amazon eine Adresse hinterlegen muss die zu einer IPv4 auflöst, SSL unterstützt und Port 443 korrekt weiterleitet. Das Ziel der Weiterleitung muss dann vermutlich wieder der nginx sein. Ich hab allerdings ohne Strato keine Möglichkeit an eine IPv4 zu kommen, SSL produziert aber den oben genannten Fehler und nun drehe ich mich gefühlt im Kreis.

PS: Eben habe ich noch gesehen, dass das Strato "SSL Starter" Paket wohl gar keine Subdomains unterstützt. Keine Ahnung warum dann das oben genannte Verhalten und der Fehler auftritt. Das ist alles wirklich sehr verwirrend.

Ich hoffe der lange, ahnungslose Post schreckt nicht ab und jemand kann mir weiterhelfen.

Gruß
Thomas

 

[blurrrr]

da wohl eigentlich bei Strato nie die Subdomainweiterleitung sondern CNAME hätte nutzen sollen, um die Strato Adresse auf die dynv6 Adresse umzubiegen. So richtig schlau wurde ich allerdings nicht daraus.

Hi

Vergiss grundsätzlich mal den Kram mit der "Weiterleitung", was Du willst ist ein "unangetasteter" HTTP-Header. Du musst grundsätzlich unterscheiden zwischen dem Ziel-FQDN im HTTP-Header und dem IP-Routing

"Umleitung": www.example.com -> www.example.org
www.example.com = 1.2.3.4
www.example.org = 2.3.4.5

vs.

"Routing": www.example.com
www.example.com -> CNAME = www.example.org = 2.3.4.5

Der HTTP-Header bleibt unverändert bestehen (www.example.com) und genau das ist es, was Du auch willst. Du willst ja nicht irgendwohin "umleiten", Du willst, dass das Ziel entsprechend zum aufgerufenen FQDN passt (unter der Haube und dort ist es nunmal "IP"). Es wird also nur der "Zeiger" (DNS) verändert, vergleich es mit einem Umzug... Du ziehst um und bei Deiner vorherigen Adresse (Hausnummer 2) hinterlässt Du ja nun auch kein Schild, welches den Leuten sagt, dass Du nun in Hausnummer 3 zu finden bist ("Umleitung"), sondern Du gehst hin und änderst Deine Anschrift, kurzum: Du wohnst nun unter Hausnummer 2 (DNS/CNAME)

Die SSL-Terminierung nimmst Du dann auch nicht bei Strato vor, sondern z.B. auf Deinem Reverse-Proxy, damit hat Strato nichts mehr zu tun (da nutzt Du nur DNS/CNAME)

 

[rohrbrecher]

Ok, damit kann ich was anfangen. Vielen Dank für die ausführliche Erklärung.

Das würde bedeuten, dass ich bei Strato alle meine Subdomains so umstelle, dass sie nicht mehr auf meine dynv6 Adressen umleiten sondern via CNAME auf die dynv6 routen.

Das mit dem SSL fände ich ebenfalls hilfreich, weil ich das bei Strato ehrlichgesagt alles irgendwie intransparent finde. Bei nginx war das mit Lets Encrypt alles easy und durchsichtig. Mir ist allerdings nicht klar, wie ich nun an die IPv4 Adresse und die Sache mit dem Port 443 komme. Der nginx läuft doch bei mir lokal und da ich nur eine öffentliche IPv6 Adresse habe, kriege ich die Anforderungen von AWS nicht erfüllt.

 

[blurrrr]

Mir ist allerdings nicht klar, wie ich nun an die IPv4 Adresse und die Sache mit dem Port 443 komme.

So gesehen... garnicht. Das wäre nur ein sauberes Konstrukt. Du hast aber diverse Möglichkeiten:

1) Zusehen, dass Du eine IPv4-Adresse bekommst (ISP)
2) Zusehen, dass Du eine IPv4-Adresse bekommst (externe Dienste, wie feste-ip, welche das über einen Tunnel realisieren)
3) Thematik auslagern (günstige VM anmieten mit Dualstack (IPv4+IPv6), Reverse-Proxy drauf und weiter wie gehabt)
4) Thematik auslagern (günstige VM anmieten mit Dualstack (IPv4+IPv6), 6tunnel einrichten)
etc.

Denke, so wie Du das Szenario beschreibst, wäre es wohl am sinnvollsten den Reverse-Proxy auszulagern (sofern Du da bei Dir noch eine vernünftige Firewall laufen hast, womit Du den Zugriff von extern auf Deine Dienste auf den Reverse-Proxy beschränken kannst), oder Du besorgst Dir halt für ein paar Mark im Monat so ein IPv4-Tunnelding von einem Anbieter.

Außerdem scheint es laut diverser Foren und Github Einträge so zu sein, dass die Amazon API nur auf IPv4 auflöst.

HA-Alexa-Anleitung:

Create an AWS Lambda Function

-> https://docs.aws.amazon.com/vpc/latest/userguide/aws-ipv6-support.html? Sieht für mich jetzt erstmal nach Dualstack (4+6) aus. Weiss jetzt aber auch nicht, ob das jetzt genau "das" ist, was auch angesprochen wird, dafür bin ich da zu wenig im Thema

 

[rohrbrecher]

Hmm, da kenn ich mich leider echt nicht gut genug aus. Die Aussage mit IPv4 kam aus dem github in dem der Code für die Lambda Funktion liegt. Allerdings steht da auch:

• Exposed 443 HA port(MUST).
• Any SSL cert.
• Get the external HA Address.
• Alexa config in HA confiuration.xml
• Lambda at right region for locale
• Set the address into everywhere correctly like BASE_URL, Alexa console, etc.
• Non-blocked network path to HA reside in your room.
• Wait discovery and use.

Mir ist nur nicht klar, wie das dann mit dem Port 443 funktioniert. Ich hab mein Home Assistant auf Port 443 umgestellt und nginx zeigt auch darauf. Wenn ich bei AWS nun meine Strato -> CNAME -> dynv6 Geschichte hinterlege, was passiert dann mit dem Port?

 

[blurrrr]

Das würde bedeuten, dass ich bei Strato alle meine Subdomains so umstelle, dass sie nicht mehr auf meine dynv6 Adressen umleiten sondern via CNAME auf die dynv6 routen.

Btw... je nachdem, wie das Verhältnis ist... Theoretisch kannst Du auch einfach hingehen z.B. folgendes machen:

sub1 -> strato-ip
sub2 -> strato-ip
* -> CNAME -> dyn-fqdn

Damit wir dann einfach "alles" (was nicht anderweitig angegeben ist) an Deine Dyn-Adresse weitergeleitet. Somit musst Du Dich bzgl. der vHosts nur noch auf dem Reverse-Proxy darum kümmern. Also wenn "neu anlegen", dann brauchst Du das nur noch auf dem Reverse-Proxy zu machen.

Mir ist nur nicht klar, wie das dann mit dem Port 443 funktioniert. Ich hab mein Home Assistant auf Port 443 umgestellt und nginx zeigt auch darauf. Wenn ich bei AWS nun meine Strato -> CNAME -> dynv6 Geschichte hinterlege, was passiert dann mit dem Port?

Sorry, verstehe ich nicht... Weder Strato, noch CNAME, noch dynv6 haben etwas mit "Ports" zu tun. Der "Port" ist "nur" bei Deiner Firewall/Deinem Router geöffnet für den Reverse-Proxy, welcher unter Port 443/TCP zwecks HTTPS erreichbar ist. Wenn ich Dich besuchen fahre ("Deine Adresse"+"Tür-Nummer 5") interessiert mich die Tür-Nummer solange nicht, bis ich bei Dir vor der Tür stehe. Heisst, der Port ist erst dann interessant, wenn man quasi grade zu der hinterlegten IP Deiner Dyn-Adresse geht - alles davor hat mit Ports noch garnichts zu tun.

Die relevanten Fakten sind aber, dass ich dafür folgendes brauche

Hast Du es denn überhaupt mal "ausprobiert"?

Also grundsätzlich: Bei Strato "nur" DNS (CNAME -> Dyn-Adresse), damit ergibt sich: ha.example.com = <Deine Dyn-"IP" vom Reverse-Proxy>. Den Zugriff testest Du dann einfach mal über das Handy (ohne WLAN!). Funktioniert das, würde ich das einfach mal mit Amazon versuchen.

 

[rohrbrecher]

Hi, sorry für die späte Antwort. Ich hatte gestern Abend eigentlich schon alles fertig geschrieben, denn ich war mir sicher dass das erst mal klappen wird und dann ging plötzlich garnichts mehr. Der Versuch den du vorgeschlagen hattest, also wirklich erst mal zu schauen ob ich per Strato -> CNAME -> dynv6 -> nginx -> lokale VM komme, hat nicht funktioniert. Allerdings funktionieren seither keine meiner Adressen mehr, also auch nicht die, die ich bei Strato noch mit klassischer Weiterleitung laufen habe. Strato scheint aber nicht das Problem zu sein, denn auch bei Eingabe der dynv6 Adresse direkt, komme ich nicht mehr auf meine Seiten. Lokal geht noch alles aber sobald ich es von Außen probiere, kriege ich im Chrome DNS_PROBE_FINISHED_NXDOMAIN angezeigt.

Das hat monatelang funktioniert denn ich konnte ohne Weiteres von Außen auf meinen HA zugreifen. Ich habe auch schon die AAAA records bei dynv6 gelöscht und neu angelegt aber das hat nicht geholfen. Ebenfalls komisch finde ich, dass ein DNS Lookup weiterhin plausible Ergebnisse liefert. Ich bin wirklich absolut ratlos warum das grade nicht mehr klappt und ich ärgere mich, dass ich nun was funktionierendes zerschossen habe...

 

[blurrrr]

Hi,

öhm... was genau treibst Du da? Keine Sorge, kriegt man schon alles hin... aber lass uns erst nochmal über 2 Dinge reden, sonst führt das ggf. noch zu Verwirrungen...

1) HTTP-Header: "Host"-Feld, teilt dem Webserver - wo die Anfrage landet - mit, was Du von ihm willst (gewünschter vHost)
2) DNS (löst einen Namen in eine IP auf, damit das Paket an die korrekte IP geschickt wird)

Ersteres sollte halt "unverändert" den Webserver erreichen. Zweiteres sorgt nur dafür, dass das Paket generell beim Webserver ankommt.

Was Du NICHT willst, sieht so aus....

domain1.tld ==> domain2.tld -> CNAME -> DynDNS -> Webserver

Übersetzt: Die Anfrage nach "domain1" wird komplett auf "domain2" umgeschrieben, Anfrage nach "domain2" erreicht Webserver

...denn: Ist domain2 jetzt überhaupt noch sinnvoll? Eigentlich... so garnicht...

Was Du eigentlich möchtest, wäre ein "sauberes" Konstrukt in Form von :

domain1.tld -> domain2.tld -> CNAME -> DynDNS -> Webserver

Übersetzt: Die Anfrage nach "domain1" wird unverändert an den Webserver weitergegeben, Anfrage nach "domain1" erreicht Webserver

Das wäre der "saubere" Weg und so würde ich es auch umsetzen. Heisst nun aber auch - jetzt kommen wir mal zu dem, was ich ein kleines bisschen vermute...

Wenn Du domain1 nun als CNAME an die DynDNS-Adresse und somit zum Webserver dahinter schickst.... WEISS der denn überhaupt schon von seinem Glück?! Bisher kannte er nur domain2 und alles war auf domain2 abgestimmt, das muss nun alles auf domain1 abgestimmt werden (inkl. der Zertifikate) und ja, ist vermutlich ein bisschen Arbeit. Hättest Du direkt alles FAF-tauglich gemacht, hättest Du das Problem ja nun auch nicht

Was die Strato-Nummer und die Weiterleitung angeht... Es ist total nett, dass Du auf Domain1 kommst, da irgendwelche Zertifikate hast (oder auch nicht), da lauscht aber kein HomeAssistant... Die "Umleitung" sorgt dann erstmal wieder dafür, dass "nichts" passt (domain1 ist halt nicht domain2) und ebenso sorgt die Umleitung ebenfalls dafür, dass nicht mehr der IPv4/6-Strato-Host angesprochen wird, sondern wieder nur Deine DynDNS-IP (welche ja nur via v6) läuft.

Lass Strato einfach den DNS-Teil machen (konkret: Deine DNS-Records -> CNAME -> DynDNS-Adresse... "Fertig"), den Rest machst Du bei Dir. Wenn Du dann noch etwas anderes willst, was z.B. nur IPv4 spricht, musst Du halt irgendwie dafür sorgen, dass Dein HomeAssistant auch via IPv4 erreichar ist und auch da gibt es generell erstmal nur "2" Optionen:

1) Sorg dafür, dass Du bei Dir eine öffentliche IPv4 bekommst
2) Sorg dafür, dass HomeAssistant irgendwo eine öffentliche IPv4 bekommt

Wenn ich davon ausgehe, dass Du das schon gerne bei Dir laufen haben möchtest, bleiben Dir da eigentlich auch nur 2 (3) Optionen:

1) Beim Provider nachfragen, ob sowas für Dich möglich ist (am besten Dualstack (v4+6))
2) Einen entsprechenden Dienst dafür nutzen (kostenpflichtig, z.B. feste-ip.de)
(3) Selbst etwas basteln (vllt nicht die beste Lösung, wenn vieles für Dich schon "Voodoo" ist, wie Du sagst))

 

[rohrbrecher]

Erst mal vielen vielen Dank für die Geduld und die ausführlichen Erläuterungen. Wenn ich das richtig verstehe, dann brauche ich auf jeden Fall CNAME, da der nginx ja nur funktioniert wenn ich ihm die korrekte Ursprungsadresse gebe. Und nun verstehe ich auch, warum das bisher funktioniert hat: Der nginx kennt nur die dynv6 Adressen und sollte daher ja nicht funktionieren, wenn ich von Strato komme. Da Strato bisher aber nicht per CNAME sondern per Umleitung lief, kam beim nginx am Ende wieder nur ein Request von dynv6 an und alles war gut.


Ich hab nun erst Mal, um dynv6 aus der Gleichung zu nehmen, dafür gesorgt dass meine DynDNS direkt von der Fritzbox bereitgestellt wird. Wie ich gestern Abend herausgefunden habe, kann man in der Fritzbox nämlich über MyFritz auch die IPv6 einzelner Geräte im Netzwerk mit einer DynDNS versehen und das habe ich nun für den nginx getan.

Soll heißen: Ich hab hier nun eine nginxproxymanager.xyz.myfritz.net Adresse, die direkt auf meinen nginx zeigt.

Als zweites hab ich dann auf Strato eine neue Subdomain angelegt und deren CNAME zeigt nun auf nginxproxymanager.xyz.myfritz.net.



Der wiederum leitet das dann auf die IP des Home Assistant:



Es sollte also so aussehen:

Strato Subdomain -> CNAME -> MyFritz DynDNS des nginx -> lokale IP

Dann kommt beim nginx die Strato Adresse an und dort mache ich dann das Mapping auf die lokalen IPs.

Verrückt an der Sache ist: Ich komme nun mit zwei verschiedenen PCs außerhalb meines Heimnetz über diese Adresse auf meine HA Instanz. Vom Handy aus, im mobilen Vodafone Netz, klappt es nicht Ich hab auch schon den Google und Cloudflare DNS probiert, aber keine Änderung. Aus dem mobilen Netz komm ich irgendwie nicht drauf.

 

[blurrrr]

Soll heißen: Ich hab hier nun eine nginxproxymanager.xyz.myfritz.net Adresse, die direkt auf meinen nginx zeigt.

Als zweites hab ich dann auf Strato eine neue Subdomain angelegt und deren CNAME zeigt nun auf nginxproxymanager.xyz.myfritz.net.

Das hört sich soweit "sehr" gut an Somit bleibt auch das Host-Feld im HTTP-Header erreichbar und genau das wird vom NPM ausgewertet ("vHost"-Thematik).

Strato Subdomain -> CNAME -> MyFritz DynDNS des nginx -> lokale IP

Genau SO soll es sein

Dann kommt beim nginx die Strato Adresse an und dort mache ich dann das Mapping auf die lokalen IPs.

Völlig korrekt!

Verrückt an der Sache ist: Ich komme nun mit zwei verschiedenen PCs außerhalb meines Heimnetz über diese Adresse auf meine HA Instanz. Vom Handy aus, im mobilen Vodafone Netz, klappt es nicht Ich hab auch schon den Google und Cloudflare DNS probiert, aber keine Änderung. Aus dem mobilen Netz komm ich irgendwie nicht drauf.

Ganz wichtig: Erstmal nicht verrückt machen! Du hast Änderungen am DNS vorgenommen, sowas kann schon ein bisschen dauern, bis "die ganze Welt" davon weiss.

Du hast bestimmt gesehen, dass bei den DNS-Records (auch beim CNAME!) eine "TTL" angegeben ist/werden kann. Die TTL ist eine Gültigzeitszeitraum-Angabe. Wenn ich vorhin z.B. "hatest.domain.tld" angefragt habe und mir mitgeteilt wurde, dass der Eintrag z.B. 1 Stunde lang gültig ist, werde ich eine Stunde nicht mehr danach fragen, ob sich da irgendwas geändert hat, sondern werde einfach den zwischengespeicherten Wert nehmen. 3600 Sekunden (1Std) und 86400 Sekunden (24 Stunden) sind oftmals übliche Vorgaben. Bei DynDNS ist das allerdings anders (ändert sich die IP, will man ja "schnellstmöglich" aktuell sein), da liegt die TTL meist bei 60 Sekunden (1 Minute).

Schau Dir mal die TTL von Deinem CNAME-Record an, da solltest Du dann die maximale Wartezeit haben (sofern sich das nicht schon vorher erledigt)

 

[rohrbrecher]

Ich hab nun nochmal etwas rumprobiert und komme leider an der Stelle nicht weiter.

Ein nslookup auf meinem lokalen Rechner liefert "nichts".


Der genau gleiche nslookup, via SSH auf der nginx VM:


Warum kann ein Rechner in meinem Heimnetz die Adresse auflösen und der andere nicht?
Kann es damit was zu tun haben, dass nginx die Fritzbox via IPv4 und mein Rechner und Handy die Fritzbox via IPv6 kontaktieren?


Ich komme weiterhin mit meinem Arbeitsrechner (per VPN im Firmennetz) auf die Adressen, vom Heimrechner und Handy leider nicht.

PS: Ich kann am Heimrechner wie am Handy die myfritz Adresse des nginx aufrufen und komme dann auch korrekt raus, das Problem liegt also zwischen Strato und nginx.

 

[blurrrr]

Ein nslookup auf meinem lokalen Rechner liefert "nichts".

1) Mal den DNS-Cache leeren via ipconfig /flushdns (in der Windows-Eingabeaufforderung)
2) Mal anderweitiges fragen, z.B. via:
nslookup hatest.domain.tld 8.8.8.8 (IPv4)
bzw.
nslookup hatest.domain.tld 2001:4860:4860::8888 (IPv6)

Das "hinten dran" ist der zu fragende DNS-Server, da kannst Du auch hingehen und z.B. die IPv6-Adresse Deiner Fritzbox eintragen, um diese via IPv6 zu kontaktieren. Das sollte allerdings nichts an den Antworten ändern (die ja nunmal auch von "aussen" kommen, da die Fritzbox diese DNS-Anfragen selbst garnicht beantworten kann (ausser es liegt ggf. noch etwas im Resolver-Cache, aber über die TTL sprachen wir ja bereits)).

Ich komme weiterhin mit meinem Arbeitsrechner (per VPN im Firmennetz) auf die Adressen, vom Heimrechner und Handy leider nicht.

Da hat die Fritzbox etwas namens "Rebind-Schutz". Da wirst Du für die myfritz-Adresse vermutlich auch etwas auf der Fritzbox konfiguriert haben. Diesbezüglich schauste einfach mal hier rein: https://avm.de/service/wissensdaten...re-Anfrage-aus-Sicherheitsgrunden-abgewiesen/ und ziehst das ggf. nochmal glatt (falls nicht schon passiert)

 

[Barungar]

Warum kann ein Rechner in meinem Heimnetz die Adresse auflösen und der andere nicht?

Als erstes fällt mir auf, dass augenscheinlich unterschiedliche DNS-Server gefragt werden.
Im ersten Beispiel per IPv6 der fd00::1eed:6fff:fe07:5752 und im zweiten Beispiel per IPv4 der 192.168.178.1
Zwei verschiedene DNS-Server, zwei Antworten... so sieht es erst einmal ohne nähere Kenntnis Deiner Umgebung aus.

 

[blurrrr]

Und, bist Du bzgl. Deiner Problematik weiter gekommen?

 

[rohrbrecher]

Sooo, wieder Updates von mir.

Da hat die Fritzbox etwas namens "Rebind-Schutz". Da wirst Du für die myfritz-Adresse vermutlich auch etwas auf der Fritzbox konfiguriert haben. Diesbezüglich schauste einfach mal hier rein: https://avm.de/service/wissensdaten...re-Anfrage-aus-Sicherheitsgrunden-abgewiesen/ und ziehst das ggf. nochmal glatt (falls nicht schon passiert)

Das war tatsächlich der Punkt warum es von Außen aber nicht von Innen ging. Außerdem scheint unter Windows ein reiner DNS flush nicht immer zu genügen (Reboot tut gut) und unter Android scheinen Chrome und Firefox separate DNS caches zu haben, was mich ebenfalls einige Nerven gekostet hat.

Als erstes fällt mir auf, dass augenscheinlich unterschiedliche DNS-Server gefragt werden.
Im ersten Beispiel per IPv6 der fd00::1eed:6fff:fe07:5752 und im zweiten Beispiel per IPv4 der 192.168.178.1
Zwei verschiedene DNS-Server, zwei Antworten... so sieht es erst einmal ohne nähere Kenntnis Deiner Umgebung aus.

Das sind nur IPv4 und IPv6 der gleichen Fritzbox.



Nachdem die Auflösung nun also klappt heißt das: Ich komme wieder wie vorher von überall auf meine Rechner und kann sie nutzen und habe dazu sogar noch alles etwas vereinfacht, da dynv6 nun komplett raus ist. Zwischenzeitlich hat sich noch mein nginx verabschiedet (kam ums Verrecken nicht mehr aufs Webinterface) und hab das Ding daher kurzerhand einfach nochmal neu aufgesetzt...

Nun wieder zum eigentlichen Thema. Mein Homeassistant läuft unter Port 443, die URL zeigt definitiv auf den Homeassistant aber eben nur AAAA. Leider geht das ganze AWS Thema noch immer nicht und ich krieg noch immer die nichtssagende Fehlermeldung:

'Failed to establish a new connection: [Errno -2] Name or service not known'

Ich werd mich jetzt noch 1-2 Tage durch verschiedene Forenposts wühlen aber wenn das dann nicht klappt, dann lass ich es wohl bleiben. Das ganze AWS scheint ein echter Sumpf zu sein und die meisten Aussagen sind widersprüchlich bis verwirrend.

 

[blurrrr]

Name or service not known

Das liest sich jetzt aber erstmal, als würde da etwas in eine andere Richtung nicht funktionieren... DNS funktioniert? Einmal im HA-Terminal überprüfen via nslookup google.de, es werden auch die IPv4+IPv6-Einträge von google.de ausgeliefert?

 

[rohrbrecher]

Ja, das scheint erst mal zu passen:


Am Desktop PC liefert der Aufruf die selbe IPv6, jedoch keine IPv4 zurück.

 

[blurrrr]

Das ist schon mal gut (Name not found, deutet oftmals auf einen Fehler in der DNS-Auflösung hin, daher die Frage)

Ich vermute einfach mal, dass es dabei darum geht https://www.home-assistant.io/integrations/alexa.smart_home/? Nochmal kontrolliert, ob diesbezüglich alle Einstellungen korrekt sind?

Wenn es "wirklich" an der IPv6-Thematik liegen sollte, besorg Dir irgendwo einen günstigen kleinen vServer mit Dualstack (das Ding muss ja eigentlich auch nix können) und pack Dir da einen Reverse-Proxy drauf. Den kannst Du dann von extern via v4 und v6 ansprechen und nach hinten raus spricht er halt via v6 mit Deinem Standort.

 

[rohrbrecher]

Naja, wie gesagt. Die Anleitung von Home Assistant selbst ist erst mal relativ wenig auf mögliche Fehlerquellen ausgelegt. Die beschreiben nur was man zu tun hat und wenn man dann zum Test der Verbindung kommt, schlägt das Ganze bei mir fehl.
Ich hab dann noch unterhalb des eigentlichen Python Scripts (https://gist.github.com/matt2005/744b5ef548cc13d88d0569eea65f5e5b) und auf der github Seite des selbigen (https://github.com/Mitchell-kw-Lee/alexa_skill_bridge_lambda) einige Hinweise gefunden aber bisher hat mich das nicht weiter gebracht.

Im Kern steht da ja:

• Exposed 443 HA port (MUST) -> Habe HA auf 443 umgestellt
• Any SSL cert -> Hab ich über den nginx
• Get the external HA Address -> Die externe Adresse des nginx hab ich über die Fritzbox, funktioniert zB für HA oder Jellyfin von Unterwegs
• Alexa config in HA confiuration.xml -> hab ich
• Lambda at right region for locale -> hab ich (Irland)
• Set the address into everywhere correctly like BASE_URL, Alexa console, etc. -> hier hab ich die Strato Adresse eingetragen die per CNAME auf die Fritzbox DynDNS Adresse des nginx zeigt.
• Non-blocked network path to HA reside in your room -> kann ich nicht beurteilen

Ich hab dann noch ein weiteres Experiment gemacht. Ebenfalls über die Fritzbox hab ich mir die DynDNS Adresse meines HA Servers geben lassen. Ich wollte also mal den Reverse Proxy überbrücken, um diesen als Fehlerquelle ausschließen zu können. Allerdings klappt das auch nicht, vermutlich weil die Fritzbox den Traffic nicht an den HA durchlässt. Ich bekomme nur "Seite wurde nicht gefunden - ERR_CONN_TIMED_OUT". Genau dafür ist ja eigentlich der Reverse Proxy da :-/ ich hab jetzt auch nicht den Nerv mich nochmal komplett mit dem externen Zugriff auf HA ohne nginx zu beschäftigen, zumal ich sowieso glaube, dass das nur bedingt und in meinem Fall mit Vodafone evtl. überhaupt nicht klappt.

 

[blurrrr]

Lambda at right region for locale -> hab ich (Irland)

Eigentlich dürfte es keinen Unterschied machen, aber warum Irland??

Schau mal hier: https://docs.aws.amazon.com/de_de/general/latest/gr/lambda-service.html, da gibt es auch durchaus etwas in "Deutschland", z.B. Frankfurt. Dort sind 2 Adressen aufgeführt:

1) lambda.eu-central-1.amazonaws.com
2) lambda.eu-central-1.api.aws

Beim ersten werden bei einem nslookup nur IPv6-Adressen zurückgegeben, beim zweiten auch IPv6-Adressen, von daher... versuch es doch einfach mal mit dem 2. Link (api.aws)