Beiträge von eripek

    https://www.techrepublic.com/article/androi…loyment-issues/

    Hmmm...

    Erfordert Root...

    https://play.google.com/store/apps/det…client&hl=en_US

    Hmmm... nur bis Lollipop...

    https://en.wikipedia.org/wiki/Compariso…erating_systems

    Hmmm...

    https://seclists.org/nanog/2015/Oct/448

    Also, wenn Dein Device nicht allzu alt ist, und, wenn Dein Device via SLAAC/Radvd einen LLA-Router angekündigt bekommt, aber via dhcpv6 die externe Adresse erhält (Radvd assisted mode), könnte es ja klappen, oder?

    Ja, Android kann kein statefull DHCPv6. Ist so gewollt, ist ein Politikum. Das Argument ist, dass dadurch User Tracking ermöglicht wird (z. B

    in Campus-WiFis). Das will der Chef-Netzwerker bei Android nicht ermöglichen, also sagt er "nutz gefälligst SLAAC".

    Wie rührend, dass Google sich um den Schutz unserer Daten so sehr bemüht. :P

    ich weiss was diese komische fe80:: Adresse ist, und wenn des Teil sich keine ordentliche 2001::... aufzwingen läßt,

    braucht er auch nicht mit der komischen fe80:: Adressen meinen da sich wohin zu verbinden

    Das finde ich aber gar nicht zum Lachen: Kann es sein, dass Dein Androide eine Firewall-App drauf hat, die es etwas zu gut mit ihm meint und auf dem linklokalen Netz UDP 546/547 blockt? (https://en.wikipedia.org/wiki/DHCPv6)

    die komische fe80:: irgendwas Adresse bleibt damit ja erhalten,

    und weil ich dem Teil einen Proxy mit DNS-Namen eingetragen habe, kommt niemand auf eine derarte abstruse Idee

    wenn der Proxy einen 403 liefert dann mit der fe80:: Adresse eine Verbindung zum Proxy aufzubauen ...

    mainziman Alles gut?! „die komische fe80::” ist eine LLA. Die brauchst Du in jedem Fall.

    warum werden neue Server immer noch mit Debian 8 ausgeliefert?

    Ich glaube die Antwort zu kennen: Froxlor. Wobei man sich wahrscheinlich gedacht haben wird, dass man Debian 9 auslassen kann. Nur gibt es schon getestete Konfigurationssnippet für Froxlor mit Debian Buster?

    Wenn Du nur die Domain umgezogen hast, aber ansonsten alles dort bleiben soll, wo es war, verwendest Du die Netcup-Nameserver und trägst nur folgende Zeilen via CCP ein:

    1. pss-interservice.ch. 3600 IN A 81.18.31.151
    2. pss-interservice.ch. 3600 IN MX 10 mail.pss-interservice.ch.
    3. pss-interservice.ch. 3600 IN TXT "v=spf1 mx a ip4:193.246.110.114/28 a:mail.netradox.com a:webmail.netradox.com ~all"

    Wenn Du netcup als Provider für alles verwenden möchtest, musst Du die Daten migrieren. Die Standardeinstellungen für das Hosting sind dann der richtige Weg.

    Wenn Du die Domain aus Kostengründen zu netcup gebracht hast, aber (der Vertrag und) die Nameserver bei netradox weiterhin existieren, dann möchtest Du NUR diese Zeilen im CCP eingetragen wissen - und zwar über „DNS Zone editieren“ in https://www.customercontrolpanel.de/domains.php unter „DNS“:

    ns01.netradox.com.

    ns02.netradox.com.

    Diese Einträge werden in der Root zone von .ch hinterlegt und verweisen dann auf diese beiden Server, wo die Zonendaten sodann weiter verwaltet werden.

    Ich empfehle, wenn man das das erste Mal macht, vorher in Foren Hilfe zu suchen. DNS kann ein komplexes Thema sein, und die meisten Anbieter posten zwar Preislisten aber keine Tips. Die daraus resultierende Downtime von bis zu einigen Tagen kann unangenehm sein, und wäre mit ein paar Informationen und ein wenig Planung sehr einfach vermeidbar.

    Der Knackpunkt war ohne npddp habe ich auf eth0 nicht mal Pakete an die wg0 IP ankommen sehen (TCPDump), aus dem Grund wundere ich mich gerade etwas was bei mir Routen auf dem System ausrichten sollen...

    Wireguard arbeitet meines Wissens auf Layer 3, ist also auf Routen angewiesen.

    Ich würde also verstehen, wenn über das wg0 ohne ndpdp nichts ankäme - wenn aber schon auf eth0 nichts ankommt, hast Du irgendwo in der Konfiguration vorher schon einen Knick gehabt.

    Ich gebe zu, bei der Routing Nummer via Link-Local stehe ich etwas auf dem Schlauch...

    Die Geschichte mit den LLAs ist so simpel, wie sie zunächst ungewohnt ist. Bei IPv4 gibt es das ARP (Address Resolution Protocol), das Dir für das Internet Protokoll den Bezug von IP-Adresse zu MAC-Adresse herstellt. Bei IPv6 hat man dieses Protokoll neu geschaffen und als NDP (Neigbor Discovery Protocol) im Wege von ICMPv6 realisiert. Es erfüllt im Grunde dieselbe Aufgabe wie ARP, kann aber mehr. Damit aber ICMP gesendet werden kann, benötigt man eine IP-Adresse: Ein Henne-Ei-Problem. Das wird in IPv6 einfach mit Linklokalen Addressen umschifft. Eine Linklokale Adresse ist pro Interface (pro Link - daher Link-Lokal) gültig.

    Sie setzt sich folglich aus dem Prefix fe80::/10 ergänzt um die MAC-Adresse in EUI64-Notation und einem Interface-Identifier zusammen.

    z.B.: fe80::[EUI64 der MAC-Adresse]%eth0.

    Da die MAC-Adresse pro Link jedenfalls eindeutig ist [Annahme], hat man mit IPv6 IMMER eine auch IP-Verbindung auf dem Link. Über diese IP-Verbindung kann man dann Nachbar-Informationen, Router-Informationen usw austauschen, aber auch routen (!).

    Damit aber so ein Routing von AUSSEN funktioniert, muss auch eine öffentliche IPv6-Adresse (meist ein Prefix mit /64, obwohl /128 auch genügen würde) auf dem Interface oder auf dem Router present sein, denn diese Adresse dient bei Paketen, die nach außen gehen, als Absenderadresse, an die sodann die Antwortpakete geschickt werden.

    fe80::1 ist im einfachsten Fall ein Alias für eine linklokale Adresse, meist verwendet man aber den Alias fe80::1 zur Ankündigung von redundanten Gateways etwa über Protokolle wie CARP (oder für Ciscoianer: HSRP oder in der Welt von Ascend Communications, DEC, IBM, Microsoft und Nokia: VRRP) - so auch in Hostingumgebungen.

    fe80::1 kann man seinerseits über SLAAC/radvd mittels Router Advertisment bekannt machen.

    Zur Funktionsweise eines NDP Proxy siehe: https://docs.paloaltonetworks.com/pan-os/8-0/pan-os-admin/networking/nptv6/ndp-proxy.html#

    Meiner Meinung nach ist ein NDP Proxy dann nicht erforderlich, wenn die Adresszuweisung aus dem Prefix korrekt gemacht ist. Wireguard müsste, wenn ICMPv6 funktioniert, Nachbarn korrekt auflösen und den mittels radvd delegierten Prefix an die Clients verteilen, sodass stets richtig geroutet wird, weil der Bezug von externem Prefix und LLA/Route stets aufgelöst werden wird. Wenn ich da einen Denkfehler haben sollte, lasse ich mich -bitte- gerne belehren.

    Root-Server:

    https://www.netcup.de/vserver/

    Plesk-Lizenzen:

    https://www.netcup.de/bestellen/softwareangebote.php

    Alternativ eventuell:

    https://www.netcup.de/professional/managed-server/

    Die Hosting-Angebote von netcup scheinen auf einem mit dem CCP verwobenen Plesk aufzubauen - und da ist die Domainverwaltung im CCP.

    Ein einzelner DNS-Server ist übrigens keine Lösung. Die meisten Registries wollen mindestens zwei in unterschiedlichen Netzen. Man könnte das mit einer zweiten IP-Adresse faken, aber der Redundanz dient das nicht.

    Wenn Du das Thema weiterverfolgen möchtest, mach bitte einen neuen Thread auf, denn, was Du möchtest ist das Gegenteil der Frage.

    Die Anleitung spricht von einem Caching-Nameserver, der, soweit ich es beim bescheidenen Überfliegen der Konfiguration erkennen kann mit recursion yes im view any offen ist, wie ein Scheunentor. Zumindest hinsichtlich DNS Amplification Attacks. Man berichtige mich, wenn ich es übersehen habe.

    cerial1 bitte erklär noch einmal genau, was Du wirklich möchtest. Ich denke, es hat nicht wirklich etwas mit diesem Thread zu tun.

    Das erste IPv6 Netz einer KVM-Maschine bei netcup wird nicht geroutet, sondern "geswitcht". Dass bedeutet eben auch, dass du dich mit der Neighbour Discovery rumschlagen musst.

    Ich stimme da nicht ganz zu. Innerhalb der Broadcastdomain, über die auch die Linklokalen Adressen (hier des eth0) laufen - wie Du sagst „geswitched“ - läuft die Linklokale Kommunikation ab - wobei der Host nur sein Gateway fe80::1 kennen muss, über das auch sein öffentlicher Prefix geroutet wird. Und an diese Adresse wird dann ein etwaiges zusätzliches Netz geroutet.

    Bei he.net ist das nicht grundsätzlich anders. An die Stelle der Broadcast-Domain tritt ein SIT-Tunnel, innerhalb dessen zwar mit dem Linknetz (auch ein /64) gearbeitet wird. Das Linknetz liegt an jedem Tunnel-Endpoint mit einer Hostadresse - im Grunde /128 an, wobei auch hier eine LLA existieren muss. Das Routing erfolgt dann ebenfalls an die zugeteilte Adresse - mit dem Unterschied, dass es hier die Hostadresse des lokalen Endpunkts ist.

    3. Wenn Du einen VPS mit eigener Plesk-Lizenz hast, und die Domains über Plesk verwalten wolltest, wirst Du zunächst mehr als einen Nameserver benötigen, da Registries, üblicherweise mindestens zwei Hosts, die in unterschiedlichen Netzen liegen, verlangen.Existieren diese Server, ist bei der jeweiligen Registry (über den Registrar) ein Set von „NS“-Einträgen, die auf Deine Server verweisen, zu hinterlegen. Weiters sind Glue-Records dort zu hinterlegen (A+AAAA), wenn die Server Namen haben, die inner-/unterhalb derselben Domain liegen.

    Weiterführende Infos finden sich in der Plesk-Dokumentation: https://docs.plesk.com/de-DE/onyx/adm…e-domain.69433/

    1. Die Domainverwaltung für Domains, die Du zu netcup transferiert hast, machst Du über das CCP, richtig. Du wirst einen A (für IPv4) und AAAA (für IPv6) auf den Webhost anlegen müssen, das ist soweit auch richtig. Insbesondere, wenn unter der die Domain selbst, ohne "www" ein Ergebnis zurückgeliefert werden soll.

    Für Hostnamen wie "www" unterhalb Deiner Domain reicht mitunter ein CNAME auf den Hostnamen Deines shared Hostingservers. Für E-Mails muss freilich auch ein MX-Eintrag, der dem Mail-Hosting-Server entspricht, vorhanden sein.


    2. Plesk weiß aufgrund der DNS-Information allein aber noch nicht, dass es für die Domain zuständig ist. Es fehlt ein „Serveralias“. Den muss man noch anlegen, indem man die Domain dem Hosting zuweist. Siehe https://www.netcup-wiki.de/wiki/Domains_CCP#Verwaltung

    Für Domains, die noch nicht bei netcup verwaltet werden, passiert das über eine „externe Domain“, die im CCP angelegt wird.

    https://www.netcup-news.de/2015/01/21/auf…hosting-tarife/

    https://www.netcup-wiki.de/wiki/Produkte_CCP#Externe_Domains

    Für Domains, die netcup verwaltet, ist zu unterscheiden, ob es sich um eine Domain handelt, deren Gebühr über den Hostingtarif abgegolten wird (Inklusivdomain) oder um eine schlicht über netcup gegen Gebühr separat bezogene Domain (zusätzliche Domain) handelt.

    Im Fall der Inklusivdomain ist die Zuweisung nur an den Webhostingtarif möglich, mit dem sie registriert/zu dem sie transferiert wurde. Möchte man sie davon lösen, ist eine -in aller Regel entgeltliche- Interaktion mit dem Support erforderlich, sie würde dann zur „zusätzlichen Domain“. Zusätzliche Domains kann man einem beliebigen Hosting zuweisen.

    daß sie das Hantieren mit Bargeld auch beherrschen,

    wenn sie schon damit Kosten verursachen;

    Das ist pure Demagogie, denn Bargeld ist die Grundform des Zahlungsverkehrs. Bargeld funktioniert übrigens auch stromlos. Als Kassier sollte man auch in der Lage sein, mit einem Münzbrett statt einer Computerkassa umgehen zu können. Die Kosten redet man Dir -offenbar erfolgreich- nur ein.