Erreichbartkeit des Forums via IPv6

    Zitat von Phino

    So ein Forum basiert auf einen engagierten Betreiber, da er kein Gewinn damit erzielt (ein hoch auf die Webefreiheit dieser Seite), wird er sich kaum einen Management-Server bei Wehost.One zulegen. Und unter dem gibt es kein IPv6 für den Server.

    Ok, angesichts dessen braucht man nun wahrlich kein IPv6 zu fordern und sollte sich freuen, dass es dieses wertvolle Forum überhaupt gibt! Danke für die Recherche!


    Aus ökonomischer Sicht wundert mich die Angebotsgestaltung von WebhostOne allerdings schon: Das knappe Gut "IPv4_Adresse" ist der Standard in den günstigsten Angeboten, das überreichlich vorhandene Gut "IPv6_Adresse" gibt es hingegen nur gegen Aufpreis? Hetzner macht das m.W. genau anders herum und aus meiner Sicht irgendwie richtiger - aber gut, ich bin kein Ökonom und muss das nicht verstehen.


    Zur Orientierung: Wenn man IPv4-Adressen kaufen möchte, zahlt man aktuell etwa 50-55 USD pro Adresse, siehe z.B. hier. Auch interessant, wie viel Bewegung da im Markt ist - die Broker verdienen daran sicherlich prächtig.

    Aus eigenen Erfahrung weiß ich, dass das Hosten von mehreren Webseiten mit verschieden IPv6 Adressen deutlich aufwendiger ist als eine IPv4 Adresse für 50 und mehr Webseiten zu hosten. Das liegt daran, dass Bind es für IPv4 out-of-the-Box macht. Dasselbe mit IPv6 Adressen ist schon verwaltungsmäßig deutlich aufwendiger. Daher bieten die meisten Webhoster bei den preiswerten Versionen es kaum an. HostEurope ist einer der es kostenfrei macht, man muss es aber auch erst freischalten. Erst bei Hostservern ist es dabei. Hier ist aber für den Webseiten-Betreiber administrativ aufwendiger (Sicherheits-Update etc.).

    Zitat von Phino

    Aus eigenen Erfahrung weiß ich, dass das Hosten von mehreren Webseiten mit verschieden IPv6 Adressen deutlich aufwendiger ist als eine IPv4 Adresse für 50 und mehr Webseiten zu hosten. Das liegt daran, dass Bind es für IPv4 out-of-the-Box macht. Dasselbe mit IPv6 Adressen ist schon verwaltungsmäßig deutlich aufwendiger.

    Nur interessehalber- ist nicht mein Fachgebiet:


    Welche Zauberfunktion besitzt denn Bind (ich verstehe darunter die bekannte DNS-Server-Implementierung), um über die Auflösung von N (N>50) FQDNs verschiedener Webpräsenzen auf die immerselbe IPv4-Adresse hinaus zur richtigen Webpräsenz zu "routen"? Für mich liegt das etwas außerhalb des Scopes eines DNS-Servers bzw. des DNS-Funktionskonzepts.


    Ich verstehe ja, dass es irgendeine Instanz geben muss, die anhand der den jeweiligen FQDN beinhaltenden Aufruf-URL entscheidet, welche Web-Präsenz zu präsentieren ist, hätte diese Instanz jetzt aber nicht im DNS-Server verortet.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

  • ::1

    Hat den Titel des Themas von „Erreichbartkeit der Forums via IPv6“ zu „Erreichbartkeit des Forums via IPv6“ geändert.
    Zitat von ::1

    Nur interessehalber- ist nicht mein Fachgebiet:


    Welche Zauberfunktion besitzt denn Bind (ich verstehe darunter die bekannte DNS-Server-Implementierung), um über die Auflösung von N (N>50) FQDNs verschiedener Webpräsenzen auf die immerselbe IPv4-Adresse hinaus zur richtigen Webpräsenz zu "routen"? Für mich liegt das etwas außerhalb des Scopes eines DNS-Servers bzw. des DNS-Funktionskonzepts.


    Ich verstehe ja, dass es irgendeine Instanz geben muss, die anhand der den jeweiligen FQDN beinhaltenden Aufruf-URL entscheidet, welche Web-Präsenz zu präsentieren ist, hätte diese Instanz jetzt aber nicht im DNS-Server verortet.

    Ich habe es nicht vollständig beschrieben. Bind nimmt im LAN die Anfragen vom WAN entgegen und verteilt sie an die Server, können mehrere zu einer FQDN sein. Die eigentliche Zuordnung zu den verschiedenen Web-Präsenz erfolgt dann durch den httpd z.B. Apache. Hier heißt die Eintragung APACHE_VHOST und zeigt dann auf ein Verzeichnis. Es kann eine Subdomain, aber auch eine FQDN sein.APACHE2_VHOST_x_SERVER_NAME=xyz.ltd

    APACHE2_VHOST_x_DOCUMENT_ROOT='/var/www/meinedomain.de/htdocs/'

    Die Aussage ist jetzt aber verwirrend. Bind nimmt gar nix entgegen, Bind ist ein DNS-Server. Das einzige, was Bind macht, ist zu sagen "Okay, die Domain www.glasfaserforum.de hat die IP-Adresse 89.107.187.146". Bind ist dabei egal, ob es 100 Seiten mit der gleichen IP gibt, egal ob IPv4 oder IPv6.


    Die Anfrage geht direkt an den Webserver (hier im Forum ist der externe Webserver ein Nginx, könnte aber auch genauso gut ein Apache sein). Der entscheidet dann anhand von IP-Adresse und vHost, weclhe Webseite / welcher DocumentRoot jetzt tatsächlich greift.


    Du hast recht, dass es ein bisschen komplexer ist, jedem vHost (= aka jeder Webseite) seine eigene IPv6-Adresse zu geben und weiterhin alle Seiten über die gleiche IPv4 erreichbar zu machen.

    Das kann man aber ganz einfach dadurch umgehen, dass man es genauso macht wie bei IPv4: Man gibt dem gesamten Server eine IPv6-Adresse, und macht unter dieser dann *alle* Webseiten erreichbar.


    Damit ist dann, was die Konfiguration von Bind und Apache angeht, alles identisch wie bei IPv4: die Anfrage kommt, egal ob per IPv4 oder IPv6, an den Webserver, dieser schaut in den HTTP Host Header (oder, bei HTTPS, ins SNI) und entscheidet dann, wo die Anfrage "hingeht".


    ::1: IPv4 ist bei WebHostOne auch nicht inklusive - es teilen sich einfach ~1000 Kunden mit ~1000 Webseiten eine einzige IPv4, und man war zu faul, das halt auch für IPv6 einzurichten. Es ist nicht so, dass bei WebHostOne jeder Kunde für seine Webseite ne eigene IPv4 bekommt.


    Ich wundere mich allerdings darüber, dass noch nicht mal die Webseite einer Digital-Agentur, die "meinen Next-Level-Digitalauftritt [entwickelt]" (Zitat qlixx-digital.de, die Webseite des Betreibers dieses Forums), eine IPv6-kompatible Webseite hat. Da würde ich es noch viel mehr erwarten als bei einem Glasfaserforum. Läuft wohl auch über WebHostOne ...

    Eigentlich sprecht ihr von den gleichen Vorgängen, wenn im Apache namensbasierte virtuelle Hosts konfiguriert werden.

    Die Funktionsweise ist relativ simpel: Auf einem öffentlichen (!) DNS-Server z.B. bind (Berkeley Internet Name Daemon) werden für eine IP-Adresse mehrere Hostnamen konfiguriert. In der vhost.conf des Apaches werden nun die Eigenschaften jedes einzelnen virtuellen Hosts konfiguriert. Restart und fertig ist die Laube. Das war jetzt eine ganz stark verkürzte und gar nicht vollständige Beschreibung des Vorganges!


    Wie wählt nun der Apache den richtigen vhost aus? In dem http Request des Clients ist der Name des vhosts enthalten und somit eine Zuordnung möglich. Probleme kann das TLS-Zertifikathandling bedeuten, wenn aus irgendwelchen Gründen Browser unterstützt werden müssen, die keine Server Name Indication (SNI) unterstützen. Dafür bieten sich dann IP basierte virtuelle Hosts an und im Gegenzug muss der Webserver natürlich viele Netzwerkinterfaces oder virtuelle IP-Adressen unterstützten (das können mittlerweile alle OSe).


    Das war ein kleiner off-topic Ausflug, sorry.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von Leseratte10

    Die Aussage ist jetzt aber verwirrend. Bind nimmt gar nix entgegen, Bind ist ein DNS-Server. Das einzige, was Bind macht, ist zu sagen "Okay, die Domain http://www.glasfaserforum.de hat die IP-Adresse 89.107.187.146". Bind ist dabei egal, ob es 100 Seiten mit der gleichen IP gibt, egal ob IPv4 oder IPv6.

    Das stimmt, entgegen nimmt Bind nichts, er verwaltet nur und forwarded.

    Ein Provider "muss" ein/mehrere DNS-Server betreiben, damit das "Netz" überhaupt die FQDN der Kunden kennt. Gleichzeitig sorgt dieser dann dafür, dass die Anfragen intern an die verschiedenen lokalen Server weitergeleitet werden. Grundsätzlich hat ein Provider ja auch dieselben Inhalte auf verschiedenen Server, um die Ausfallsicherheit zu gewährleisten und Loadbalance umzusetzen. Erst danach greift der httpd mit den vhost, um die Anfragen auf das richtige Verzeichnis zu lenken.

    Es gibt auch Provider, wie DomainFactory, bei dem man den vollen Zugriff hat auf DNS.

    Als Ziel geht auch eine Adresse von einem DynDNS-Anbieter, um die Webseite zu Hause zu hosten.

    Falls jemand die Möglichkeiten zu Hause mal probieren möchte, kann ich eisfairempfehlen. Ist sehr schlank aufgebaut, hat aber alles für einen "echten" Internetserver mit Webhosting und Mail-Server.

    Man kann bei DomainFactory sogar fremde DNS einbinden.

    Dann kann man z.B. die vielen Sicherheitsfunktionen(DDos-Abwehr) von Cloudflare nutzen.

    Also wenn wir hier schon über den Stand der Webhosting-Technik diskutieren, dann sollte man doch nicht gerade DomainFactory nennen, wo es noch nicht einmal Letsencrypt Zertifikate gibt, sondern die Bezahl-Zertifikate der GoDaddy Gruppe, zu der DomainFactory gehört. Da kannst du dann vielleicht per IPv6 auf die Webseite zugreifen, aber die Verschlüsselung kostet mehr als bei anderen Providern das ganze Hosting.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von alfalfa

    Also wenn wir hier schon über den Stand der Webhosting-Technik diskutieren, dann sollte man doch nicht gerade DomainFactory nennen, wo es noch nicht einmal Letsencrypt Zertifikate gibt, sondern die Bezahl-Zertifikate der GoDaddy Gruppe, zu der DomainFactory gehört. Da kannst du dann vielleicht per IPv6 auf die Webseite zugreifen, aber die Verschlüsselung kostet mehr als bei anderen Providern das ganze Hosting.

    Na ja, das ist halt Firmenpolitik. War vor der Übernahme nicht so.
    Aber mit dem "Umleitung" zu Cloudflare kann man dort die SSL-Auth nutzen.
    Oder auf den Homeserver, aber dies ist nichts für die kommerzielle Anwendung. ;)

    Mit der "Umleitung" zu Cloudflare geht der Traffic zwischen Cloudflare und dem Origin-Server ohne Zertifikat unverschlüsselt durch's Netz. Selbst wenn der Origin-Server TLS anbietet, sieht Cloudflare die Verbindung unverschlüsselt. Ist das Thema noch, wie man es richtig macht?

    Hallo Zusammen,


    ich habe jetzt nicht alles gelesen. Nur kurz zum aktuellen Stand der Dinge. Ich wurde vor einigen Monaten bereits auf IPv6 Erreichbarkeit angesprochen und habe dieses beim Webhoster geprüft. Ich habe mir zugegebenermaßen vorher nie darüber Gedanken gemacht.


    Aktuell bietet der Webhoster dies nicht an. Ich bleibe dort aber dran und werde einmal genauer mit der Technik sprechen. Die Prio ist bei mir allerdings nicht gerade hoch zu diesem Thema. Das kann sich aber je nach Nachfrage ändern. Aktuell gehe ich aber nicht davon aus, dass so eine ganze Gruppe gänzlich ausgeschlossen wird, wenn wir keine IPv6 Erreichbarkeit haben.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von alfalfa

    Eine IP-Adress-Sperre erscheint mir deshalb wenig sinnvoll und das eigentliche Problem zu sein, und nicht etwa, dass du eine Verbindung mit CGNAT nutzt.

    Nun ja, CGNAT-Adressen der DG liegen im Block 94.31.64.0/18. RIPEstat sagt dazu (siehe hier) :

    94.31.64.0/18 has been found in RECENT blocklists



    Sehr viele IP-Adressblöcke von Access Providern stehen auf DNSBLs. Das trifft auch auf Adressbereiche zu, die nicht für CGNAT verwendet werden. Wer versucht, von einer Access-Provider IP Adresse unauthentifiziert Mail zu verschicken, ist ungefähr drei Jahrzehnte zu spät dran. Viele Mailprovider nehmen schon dann keine Mail an, wenn es sich um eine solche Adresse handelt, egal ob sich irgendein Nutzer des Adressbereichs sonst irgendwie daneben benommen hat oder nicht.


    Das "deshalb" bezog sich darauf, dass Web.de und GMX den Kunden anhand der Login-Daten einwandfrei identifizieren können und nicht darauf angewiesen sind, ihn per DNSBL in Sippenhaft zu nehmen. Eine IP-Adress-Sperre ist dann so, als würde man sagen: "Wir wissen zwar, wer du bist, aber wir blocken dich trotzdem, weil der da drüben dich nicht kennt." Das erscheint mir nicht vernünftig.

    Dennoch werden solche Listen von E-Mail Security Appliances, Stichwort Ironport, verwendet. Es kommt mehr oder weniger regelmäßig vor, das gerade @web.de Adressen blockiert werden, weil es sich die Appliances Hersteller sehr einfach machen und vorschnell ganze Domains blocken, seltsamerweise geschieht das sehr selten im Falle der Ironport mit @gmail.* Accounts.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Auch wenn der Name das vielleicht fälschlicherweise nahelegt: DNSBLs listen keine DNS-Namen sondern IP-Adressen. Es ging darum, dass die Server von Web.de und GMX den authentifizierten Zugriff auf ein Mailkonto verweigerten, weil ihnen die IP-Adresse des Kunden nicht gefiel. Das Problem ist dann nicht, dass man sich die Reputation mit anderen Nutzern teilt. Das passiert auch ohne CGNAT. Das Problem ist diese unsinnige Sperre, die den individuell bekannten Benutzer auf der Basis eines kollektiven Reputation-Scores zurückweist. Auch die IPv6-Adressen von Access Providern sind übrigens als Access-Provider Adressräume gelistet und entsprechend unvertrauenswürdig für bestimmte Zwecke, ganz ohne NAT.

    Es ist schon klar, das DNSBLs IP-Adressen enthalten. Ich habe es einmal von der Sicht einer Empfängerinfrastruktur betrachtet, dort wird sich auf einen Reputation Service des Appliances Anbieters verlassen, Ironport war nur ein Beispiel. Im IP-Adressumfekd ist das dann Palo Alto, das ist keine portbasierte Firewall sondern eine protokollbasierte. Beispiel: der Service HTTPS ist freizugeben, dabei spielt es keine Rolle ob es 443, 8443, 9443 oder irgend etwas anderes ist. So weit so gut. Die Erkennungsregeln werden online durch Palo Alto aktualisiert! Hin und wieder kommt es dann zu einer Umkategorisierung mit neuen Elementen im Erkennungsregelwerk. Steht dann in einer Regel "Postscript erlaubt", Palo Alto meint aber das es HP JetDirect sei, macht die FW was sie soll, nämlich dicht. Bevor jetzt die Kritiker kommen und sagen: wer macht denn sowas über das Internet, dem sei gesagt, das die gleiche Technik in der firmeninternen Mikrosegmentierung verwendet wird. Ich glaube ich muss nicht erwähnen, welchen Aufwand dies im Troubleshooting bedeutet und welchen Ruf die firmeninterne IT dadurch erhält.


    Alles das schlägt in die gleiche Kerbe: Nicht vom Menschen gesteuerte Automatismen z.B. Abfrage von DNSBLs und ungeprüftes Übernehmen von Herstellerregelwerken ist zwar für den Konsultant der schnelle Weg zur Zielerreichung (und lässt sich auch gut als Kostenersparnis an den Entscheider bringen), läuft aber diametral zu der Betriebsstabilität. Gespart wird da unter dem Strich nix, es erfolgt lediglich eine Verlagerung auf eine andere Kostenstelle.

    Zitat von alfalfa

    Das "deshalb" bezog sich darauf, dass Web.de und GMX den Kunden anhand der Login-Daten einwandfrei identifizieren können und nicht darauf angewiesen sind, ihn per DNSBL in Sippenhaft zu nehmen. Eine IP-Adress-Sperre ist dann so, als würde man sagen: "Wir wissen zwar, wer du bist, aber wir blocken dich trotzdem, weil der da drüben dich nicht kennt." Das erscheint mir nicht vernünftig.

    Dir mag das nicht vernünftig erscheinen, aber woher weißt du, dass GMX/web.de genauso vernünftig sind wie du?

    Zitat von alfalfa

    Sehr viele IP-Adressblöcke von Access Providern stehen auf DNSBLs. Das trifft auch auf Adressbereiche zu, die nicht für CGNAT verwendet werden.

    Ok, auch an einem "vollwertigen" IPv4-Consumer-Anschluss (z.B. der Telekom) kann ich eine IPv4-Adresse zugewiesen bekommen, die durch Missbrauch des Vorbesitzers (der ggf. als Opfer bzw. Teil eines Bot-Netzes gar nichts davon wusste) auf eine BL gekommen ist. Aber die Wahrscheinlichkeit, dass mich solch eine Blockade trifft, ist mit einer CGNAT-Adresse doch ungleich größer, weil der ja eben in der Regel deutlich kleiner ist als der Access-Pool eines großen Providers wie Telekom, der jedem Kunden immer noch den Luxus einer eigenen öffentlichen IPv4-Adresse aus einem Riesen-Pool bieten kann. Ein /18 der DG enspricht 2^14=16384 CGNAT-Adressen - der Access-Pool der Telekom ist da sicherlich um einige Größenordnungen größer.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Ich musste nicht lange suchen, um einen Telekom-IPv4-Adressbereich zu finden, der die gleiche negative Klassifikation hatte: Der erste Versuch war schon ein Treffer. Access-Provider-Adressbereiche sind einfach "dirty". Niemand macht sich die Mühe, nach einzelnen Adressen zu schauen. Die Adressen werden dynamisch vergeben, also kann eine noch nicht aufgefallene Adresse jetzt eine Virenschleuder sein. Die Reputation trifft auch ohne CGNAT den ganzen Adressbereich. Das wird sich mit IPv6 nicht grundsätzlich ändern.

    Zitat von alfalfa

    Das wird sich mit IPv6 nicht grundsätzlich ändern.

    Hm, naja, angesichts der üblicherweise verwendeten Privacy-Extensions an Endgeräten hinter Consumer-Zugängen macht ein Blockieren einzelner IPv6-Adressen (hierzu gefunden: "UCEPROTECT Blacklist Policy LEVEL 1", siehe hier) nun wirklich keinen Sinn, da hoffe ich dann auch auf "vernünftige" Sichtweisen. Wenn schon, müsste man da gleich den zugehörigen /56 des PD-Blocks (Level 2) als Pendant zur geblockten IPv4-Adresse am WAN-Port des Internet-Zugangsrouters (sofern noch öffentlich) bzw. zur CGNAT-Adresse in die BL aufnehmen. Das hielte ich gelinde gesagt für sehr gewagt.