Der ping ist aber keine dauerhafte Lösung. IPV6 ist nur sporadisch verfügbar.
Dem Support habe ich das vor einer Woche gemeldet.
Gegebenenfalls äußert sich das Problem an verschiedenen Nodes unterschiedlich - oder wir haben unterschiedliche Probleme. Bei mir funktioniert IPv6 seit 6 Tagen nach dem letzten Reboot durchgehend.
Habe ein ähnliches Phänomen festgestellt. Habe ein paar vserver bzw. root-server auf verschiedenen Accounts. Bisher hat IPv6 nach Neubestellung und Neuinstallation von minimal-Systemen problemlos funktioniert.
Vergangene Woche habe ich einen weiteren vserver bestellt und IPv6 hat erstmal nicht funktioniert. Nach ein bisschen hin- und herprobieren (hauptsächlich einfach einen ping6 auf netcup.de laufen lassen) war die IPv6-Konnektivität auf einmal da und nach einem Reboot wieder weg.
Ich habe dann das System ins Rescue gebootet - IPv6 ging auch hier nicht. Dann widerrum erneut Ubuntu 18 minimal installiert und wieder die gleichen Probleme.
Support habe ich bisher noch nicht kontaktiert, da ich momentan wenig Zeit habe mich da lange drum zu kümmern (man wird wahrscheinlich erstmal davon ausgehen, dass der Kunde den Fehler macht, was ja auch häufig der Fall ist. Die Tage hatte ich aber zu viel um die Ohren um alles nochmal sauber zu dokumentieren und den Support zu kontaktieren).
Lange Rede, kurzer Sinn:
Wenn IPv6 auf der Maschine nicht geht, in der Shell einen ping6 auf netcup.de absetzen und warten. Bei meinen Tests hat es i.d.R. zwischen 5 und 15 Minuten gedauert, bis der erste Ping beantwortet wurde und damit IPv6 funktioniert. Falls jemand Zeit und Lust hat, kann er den Support auch gerne auf diesen Thread verweisen. Ab dem Wochenende sollte ich ggf. mal ein bisschen mehr Zeit haben, um die Erkenntnisse nochmal sauber zu dokumentieren.
Sorry for my mistake. I do have the same problem with a newly installed vserver.
My solution was to ping netcup.de via ping6 until the ipv6 connectivity worked. After a reboot the connectivity is gone again which means you need to ping any ipv6-host again. This usually takes between 5 and 15 minutes until the first ping gets answered..
Edit: My original message in german:
Habe ein ähnliches Phänomen festgestellt. Habe ein paar vserver bzw. root-server auf verschiedenen Accounts. Bisher hat IPv6 nach Neubestellung und Neuinstallation von minimal-Systemen problemlos funktioniert.
Vergangene Woche habe ich einen weiteren vserver bestellt und IPv6 hat erstmal nicht funktioniert. Nach ein bisschen hin- und herprobieren (hauptsächlich einfach einen ping6 auf netcup.de laufen lassen) war die IPv6-Konnektivität auf einmal da und nach einem Reboot wieder weg.
Ich habe dann das System ins Rescue gebootet - IPv6 ging auch hier nicht. Dann widerrum erneut Ubuntu 18 minimal installiert und wieder die gleichen Probleme.
Support habe ich bisher noch nicht kontaktiert, da ich momentan wenig Zeit habe mich da lange drum zu kümmern (man wird wahrscheinlich erstmal davon ausgehen, dass der Kunde den Fehler macht, was ja auch häufig der Fall ist. Die Tage hatte ich aber zu viel um die Ohren um alles nochmal sauber zu dokumentieren und den Support zu kontaktieren).
Lange Rede, kurzer Sinn:
Wenn IPv6 auf der Maschine nicht geht, in der Shell einen ping6 auf netcup.de absetzen und warten. Bei meinen Tests hat es i.d.R. zwischen 5 und 15 Minuten gedauert, bis der erste Ping beantwortet wurde und damit IPv6 funktioniert. Falls jemand Zeit und Lust hat, kann er den Support auch gerne auf diesen Thread verweisen. Ab dem Wochenende sollte ich ggf. mal ein bisschen mehr Zeit haben, um die Erkenntnisse nochmal sauber zu dokumentieren.
Hat jemand schon IPs gefunden?
https://www.netcup.de/vserver/root-server-erweiterungen.php
Eine IPv4 für 1€/Monat ohne Setupkosten
Ohne mich genauer mit der vlan-Option ausseinander gesetzt zu haben: Besteht hier Layer-2 Konnektivität? Falls ja, könnte man das Setup ersteinmal folgend prüfen:
- sudo apt install arping
- sudo arping 192.168.xxx.2
(falls das nicht tut, kannst du mit -i ens6 noch das Interface angeben)
- Falls es weiterhin nicht tut, kannst du zunächst noch prüfen, ob der Server überhaupt die MAC-Adresse des anderen Systems gelernt hat:
arp | grep 192.168.xxx.2
Edit: Alternativ mal die Firewall für eine Minute abschalten und schauen, ob der Ping dann ankommt ;o)
Ich habe kein Webhostingpaket (daher ohne Gewähr), gehe aber davon aus, dass das WCP immer über den Host, welcher auch die Webseiten ausliefert, auf Port 8843 erreichbar ist?
Technisch ist es dann notwendig, dass die Administrationoberfläche auf einem anderen, als den Standardports (80 & 443) erreichbar ist. Man könnte das sicher auch so hinbiegen, dass das Panel über den Standardwebserver ausgeliefert wird, halte es aber für sinnvoller, wie netcup das hier löst. Kurzum: Du wirst nicht drum rum kommen, deine Verbindung irgendwie zu "tunneln". Sei es über VPN, wie Lucan bereits vorschlägt - oder mit einer anderen Variante. Falls du irgendwo einen Server zur Verfügung hast, bei dem Verbindungen via SSH möglich sind, könntest du die Verbindung darüber schicken. Das geht z.B. auch mit Putty (ab Schritt 7).
Normalerweise setzt man als Host den Selektor, also z.B.
Quotev20154803._domainkey
und als Inhalt dann den Key, aber nicht in der Form wie angegeben, sondern:
v=DKIM1; p=MIIBIjANBdIBCgKCAQEAwJ8g3d5kuCAMIIBCgKCAQEAwJ8g3d5kuC5pAFw72bczJmLkf1RIBCgKCAQEAwJ8g3d5kuCBDkUXU5Wdg6NZ9W6Stk9k7JrtretomSOskuDhZWbuvPIAK6/gAtsHpw+4k3gvCpgsBHsgdrGp5jEPijsjht/Wz9/6yu3zC5YHYIxiEs kann auch sein, dass die Clients eine Unterbrechung mit Anführungszeichen akzeptieren (schonmal gesehen), verlassen würde ich mich darauf aber nicht - daher lieber so in einem Stück reinkopieren
Danach kannst du mit der Linux Konsole mal testen, ob das alles so passt, z.B.
xxx@mail:~$ dig TXT main._domainkey.xxx.de
; <<>> DiG 9.9.5-3ubuntu0.17-Ubuntu <<>> TXT main._domainkey.xxx.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23660
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;main._domainkey.xxx.de. IN TXT
;; ANSWER SECTION:
main._domainkey.xxx.de. 86400 IN TXT "v=DKIM1\; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzBMWlPUHoTuxXO+5/ije21lPior6bxd2Doq7Ef8P3Cva1gtQd4c9qTIV6a2CmxmmEcZ5J2pAYQLLRdNpROeaWXJm7kX8LU7vPW7VqBIngVF1SK2VytwTIAmG+ShI/Lv2lAx8mdhBrGs+c2GVh2gFzo6v9NAa9vKmn+e+59sSIjOGHSfcUi2NeQRx1+fLaQIjdVvhiJEZ" "uDqZ6gNurRGVHfeyZZBBOJQ1QaCkdP6zmR+LYkJgvboTTulfiA5WkdS2Zi3TsDlpUFMkdIzQwqCtcF0lx8clRmaKxbuPSrrTOmQJmldMP19+/sspD1vB07iWo0SZ90FwTIy42FRiGqKRuwIDAQAB"
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53
;; WHEN: Wed Jul 04 19:02:22 CEST 2018
;; MSG SIZE rcvd: 475Wenn der Hinweis mit dem Abweisen von anderen Subnetzen korrekt ist, wäre meines Erachtens ein Destination NAT auf dem Raspberry die einfachste Lösung..
Ich meinte natürlich ein Source NAT. Sorry..
Das macht der Raspberry ja auch bereits, wenn ich das richtig sehe:
sudo iptables -t nat -A POSTROUTING -o eth0 -s 10.8.0.0/24 -j MASQUERADE
Wenn dann ein Datenpaket aus 10.8.0.0/24 ankommt, wird es vom Raspberry mit der eigenen IP maskiert. Das sollte soweit passen.
Das klingt nach einem MTU Problem. Ich würde testweise den Tunnel mal mit MTU 1400 und MSS 1300 laufen lassen. Der Overhead eines OpenVPN Paketes sollte bei ca 70 bytes pro Paket liegen. Dann könntest du dich mit MSS an 1330 rantasten. Angaben ohne Gewähr und aus dem Kopf, in der Regel testet man die maximale MTU-Größe zwischen den Anschlüssen mit ping und den entsprechenden Paketgrößen aus. Dann den Overhead (kann auch weniger als 70bytes sein) vom MTU-Wert abziehen und den MSS-Wert setzen.
tun-mtu 1400
mssfix 1300Hintergrund: http://doc-tcpip.org/Tcp-ip/mtu.mss.html
https://www.rationallyparanoid.com/articles/tcpdump.html
Dieses Cheat-Sheet hilft dir da denke ich relativ schnell weiter. Erste Prüfung -> Datenpakete auf tun0. Zweite Prüfung -> Gehen die Datenpakete über eth0 raus und werden diese von 192.169.1.2 beantwortet? So würde ich das mal angehen
Wenn der Hinweis mit dem Abweisen von anderen Subnetzen korrekt ist, wäre meines Erachtens ein Destination NAT auf dem Raspberry die einfachste Lösung..
Kannst du mal die routen auf dem Raspberry Pi prüfen? In der Server-Config legst du folgendes fest:
Quote
- # Route zum Heimnetz allen Clients mitteilen
- push "route 192.168.1.0 255.255.255.0"
Diese Route könnt mit der Heimnetz-Route auf dem Raspberry kollidieren (je nachdem, welche Distance gesetzt wird).
Desweiteren würde ich im nächsten Schritt per tcpdump die Datenpakete vom Tunnel kommend auf das Netzwerkinterface in Richtung IP des Netgear Routers und TCP-Port 445 prüfen. Entsprechend natürlich auch die Antworten.
Daran wird es liegen:
006b6 6e8ef xxxxxxxxxxxxxxxxxx - 2017-11-30T20:04:37+00:00 WARN (4): Tinebase_Server_Json::_handleException::368 Tinebase_Exception_Backend -> No base path (filesdir) configured or path not writeable
006b6 6e8ef xxxxxxxxxxxxxxxxxx - 2017-11-30T20:04:37+00:00 ERR (3): Tinebase_Exception::log::104 Tinebase_Exception_Backend -> No base path (filesdir) configured or path not writeableWelcher Wert steht in der config.inc.php für "filesdir" ?
Ps.: Bitte schau die Datei nochmal durch, da sind Pfadangaben drin - dort sieht man dann auch deinen Usernamen bzw. Host.
Nachdem hier für mich noch etwas Hoffnung aufkam, hatte ich gerade wieder einen 5-10minütigen Ausfall. Traceroute vom Server selbst per VNC zeigt 80-90% Packet Loss (im problematischen Zeitraum kam aber kein Paket durch, die anderen Pakete kamen vorher und nachher an).
Das Rettungssystem bootet nun schon seit 10 Minuten... Ich gehe dann wohl mal von einem Host-Problem oder ähnlichem aus. Mal schauen, ob der Support das jetzt auch so sieht...
Bisher ist es bei mir auch ruhig, mich würde mal interessieren ob die "Änderung der Netzwerkinfrastruktur" auch Auswirkungen für andere Kunde (z.B. mich hatte). Wenn dem so wäre, bin ich natürlich super happy 
fisi: Schonmal diesen Tipp "Undelivered Mail Returned to Sender" an Microsoft getestet?
Die oben in der gezeigten Meldung genannte AS-Nummer(AS3150) steht nicht für ein autonomes System (ist verwirrend, da sind schon einige drüber gestolpert), sondern um eine interne Bezeichnung von Microsoft für den Fehler..
Du solltest bei Microsoft ein Ticket aufmachen. Du bekommst als Erstes vom Support-Bot eine automatische Antwort. Auf diese bitte antworten und mitteilen, dass dein Problem nicht gelöst ist und deine IP weiterhin nicht an Outlook/Live zustellen darf. Das Ticket kommt dann zu einem Agent. Normalerweise ist nach diesem Schritt eine Zustellung wieder möglich, in manchen Fällen muss man erneut auf das Ticket antworten.
Das ist die Standard-Prozedur, welche auch vom Microsoft Mitarbeiter Michael Wise auf diversen Mailinglisten immer genannt wird. Normalerweise führt das zum Erfolg, wenn es nicht hilft die Ticket ID an Michael Wise schicken (E-Mail Adresse kann ich dir per PN zukommen lassen)
Hi,
ich verweise mal auf meinen Thread:
https://forum.netcup.de/admini…ot-nicht-mehr-erreichbar/
Dort habe ich ähnliches festgestellt (wenn man den kurzen "Schluckauf" gestern mittag ausnimmt) und zwar seit dem 28ten in der Nacht. Heute hat mir mein Monitoring um 5:00 Uhr und gegen 10:50 Uhr Packet Loss gemeldet.
Kann natürlich auch Zufall sein, aber es wäre nett, wenn du die Antwort vom Support mal hier postest. (Natürlich in eigenen Worte ) Ich hatte bisher noch nicht die Möglichkeit ins Rettungssystem zu booten.
Vielen Dank an Felix für die Rückmeldung. Ich gehe nun davon aus, dass ich die vorher bemerkten Probleme gesondert von heute betrachten sollte. Mal schauen, ob und wann es wieder auftritt.
