Posts by Mixus
-
-
Bei besagtem Hoster würde ich persönlich rein gar nichts mieten
https://www.heise.de/news/Webh…und-erpresst-2777957.html -
stehen da irgendwo 70 GBit/s Backplane?
Nein, sind sogar 87 Gbit/s an Layer 2 switching capacity, die dort angegeben werden
-
Das eingebaute DDNS von Mikrotik kannst du nicht nutzen?
Zu finden unter IP -> Cloud und dann anschließend einen CNAME deiner Domain hier auf Netcup auf den unter "DNS Name" angezeigten FQDN setzen.
-
Allerdings musste ich feststellen, dass der Internet Zugriff durch den IPv6 S2S Wireguard VPN Tunnel auf verschiedene Internet Dienste (z.B. twitch.tv) extrem langsam ist, und der Zugriff manchmal auch gar nicht funktioniert.
Hast du MSS clamping für TCP Traffic aktiviert? (via iptables auf dem Server)
-
und hier Server A zu Server B (A läuft im Rescue System): https://pastebin.com/J8fNKhXk
Meiner Meinung nach ist das MTR bereits aussagekräftig genug, die Pakete gehen unregelmäßig bereits am ersten Netcup Gateway (gw02) flöten (>66% über 500 Pakete ist schon krass ...).
Hier muss netcup dann eigentlich so langsam mal tätig werden.
Vielleicht noch mal etwas deutlicher im Ticket hervorheben, dass auch aus dem Rescue heraus getestet schon am ersten Gateway Pakete in unregelmäßigen Abständen verloren gehen und dieses MTR dann entsprechend anhängen. Vielleicht auch eine Ticket-Eskalation nach weiter oben versuchen ...
-
Wenn "netplan apply" die Internetverbindung auch nicht wiederherstellt und ggf. fehler wirft, solltest du via
ip link set up dev eth0
ip addr add 202.61.241.240/22 dev eth0
ip route add default via 202.61.240.1 dev eth0
zumindest temporär das Interface mit der IPv4 Adresse wieder hochbringen können.
Danach kannst du dich dann entweder um die Behebung des grundlegenden Problems kümmern (durch Logauswertungen o.ä.), oder aber ein Backup deiner wichtigen Daten ziehen und anschließend die Kiste neu installieren, denn du scheinst aktuell nicht mal zu wissen welcher Dienst bei der Kiste für das Herstellen der Netzwerkverbindung verantwortlich ist.
-
Meine .wtf Domain kostet mittlerweile das dreifache wie vor 6 Jahren
Bei Cloudflare zahl ich nicht mal die hälfte davon ... wtf (im wahrsten Sinne des Wortes)
-
Okay also im Grunde nur ne Point to Point Verbindung. Dann musst du in deiner Wireguard Config auf dem VPS nur die Direktive "AllowedIPs = 0.0.0.0/0" ändern.
Von jetzt 0.0.0.0/0 auf das innerhalb von Wireguard benutzte Netz. In deinem oben geschilderten Fall also 10.66.66.X/YY.
Damit routest du dann nicht mehr den gesamten Traffic des VPS zu deinem Heimserver, sondern nur noch das Netz innerhalb von Wireguard.
Da wie du schreibst noch weitere Clients darauf zugreifen sollen, musst du diese entsprechend auch in die AllowedIPs aufnehmen, entweder als Netz, oder als /32 EinzelIPs.
Beispiel
AllowedIPs = 10.66.66.0/30, 10.77.77.0/24, 10.88.88.8/32
Sofern noch nicht geschehen, muss außerdem das IPv4 Forwarding auf deinem Heimserver aktiv sein, damit mehr als nur der Traffic Heimserver <=> VPS geroutet wird.
-
Was genau ist denn dein Vorhaben? Einfach nur ein Point to Point Tunnel zwischen Heimserver und VPS, oder wirklich den VPS über deinen Heimanschluss erreichbar zu machen?
-
Auf Clientseite
Sprich idealerweise auf dem Router. -
Vielleicht doch ein MTU-Problem?
Das klingt in der Tat schon sehr danach. ICMP geblockt und SSL Handshake funktioniert nicht mehr sind sehr typische Symptome für ein MTU Problem. Da das ganze bei mainziman über einen Tunnel geht (wo die MTU verringert ist), würde ich dort mal ansetzen.
Vielleicht könnte man mal probieren via iptables die MSS runterzudrehen
ip6tables -t mangle -A FORWARD -o **TUNNEL** -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1281:1536 -j TCPMSS --set-mss 1280
-
Ich muss korrigieren! Klappt nicht mehr, sobald ich ich wieder auf "internet.v6.telekom" umstelle.
Wie schon mehrfacht im Thread erwähnt:
Wenn du nur eine IPv6 Adresse im Mobilfunk bekommst, muss auf dem Client die Zeile "Endpoint = 185.207.105.144:51820" auf die IPv6 Adresse des Servers abgeändert werden. Also z.B. "Endpoint = [2a03:4000:1e:742:a85f:b7ff:fe5f:c8cc]:51820".
Möchte man es umgehen ständig die Endpoint Direktive zu ändern, kann man das durch Nutzung einer (Sub-)Domain umgehen.(A Record 185.207.105.144; AAAA Record 2a03:4000:1e:742:a85f:b7ff:fe5f:c8cc) Danach bei Endpoint dann vpn.domain.xyz:51820 verwenden. Der Client nimmt sich dann die Adresse, mit der er Umgehen kann.
Der Vorschlag wurde auch bereits mehrfach im Thread geäußert, du bist aber leider bisher nicht darauf eingegangen.
EDIT:
Und nun gehe bitte als nächstes das Thema Abschottung deiner PiHole an. Die löst weiterhin fröhlich für die ganze Welt auf.
-
Nicht wirklich on-topic, aber bitte sorge unbedingt dafür, dass deine PiHole nicht allen im Internet antwortet. Wenn du es nicht bereits bist, dann landest du sehr wahrscheinlich bald auf einer DNS Reflection DDoS Liste.
Code
Display More#dig google.com @2a03:4000:1e:742:a85f:b7ff:fe5f:c8cc ; <<>> DiG 9.16.1-Ubuntu <<>> google.com @2a03:4000:1e:742:a85f:b7ff:fe5f:c8cc ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40173 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 300 IN A 172.217.16.142 ;; Query time: 31 msec ;; SERVER: 2a03:4000:1e:742:a85f:b7ff:fe5f:c8cc#53(2a03:4000:1e:742:a85f:b7ff:fe5f:c8cc) ;; WHEN: Wed Sep 29 16:51:11 CEST 2021 ;; MSG SIZE rcvd: 55 ============================================================================================= # dig google.com @185.207.105.144 ; <<>> DiG 9.16.1-Ubuntu <<>> google.com @185.207.105.144 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63384 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 89 IN A 172.217.16.142 ;; Query time: 15 msec ;; SERVER: 185.207.105.144#53(185.207.105.144) ;; WHEN: Wed Sep 29 16:54:42 CEST 2021 ;; MSG SIZE rcvd: 55 -
funktioniert das auch mit ner Domain statt ner IP?
Ja, das war mit DDNS(DynDNS) gemeint, sorry. Ohne wirds dann doch etwas nervig ständig die IP im AP zu ändern.
-
Geht um die reine Konfiguration, ohne Traffic Monitoring etc.
Da auf der UDM ein vollwertiger UniFi Controller läuft, wüsste ich nicht was dagegen spricht.
Auf der UDM die Ports fürs Inform freischalten (default ist das 8080) und im AP im Restaurant via SSH die inform URL entsprechend setzen.
Die Befehle dafür sind
Codemca-cli set-inform http://[DDNS/IP des Heimanschlusses]:8080/informTraffic Monitoring würde wohl eh ohne UDM oder USG vor Ort nicht funktionieren, oder irre ich?
Das ist korrekt. Könnte mir aber vorstellen, dass man das durch einen VPN Tunnel zwischen AP und UDM irgendwie doch abbildbar wäre.
-
Ich lese diesen Thread mit zunehmendem Unverständnis.
Ich auch, aber eher in die umgekehrte Richtung. Wie sich einige hier echauffieren das von MeisterYoda angedachte Setup auseinanderzunehmen geht eigentlich gar nicht. Netcup ist ein Anbieter für mietbare Ressourcen (e.g. vServer), was der- oder diejenige dann letztenendes damit macht bleibt völlig dem Kunden überlassen.
Daraus abgeleitet hier so Stimmung gegen Netcup zu machen, ist imho nicht in Ordnung, denn Dir wurde nie etwas anderes gesagt oder versprochen. Warum und wieso Netcup sich auf 64er Netzwerke beschränkt ist da doch völlig irrelevant.
Man darf netcup hier aber sehr wohl den Finger dafür in die Wunde legen, dass hier keine Rücksicht auf das architectuelle Design von IPv6 Rücksicht genommen wird und man entgegen der Empfehungen von z.B. rfc6177 und der Registries agiert.
Netcup ist ein Server- und kein "Gateway-für-Homenetzwerke"-Anbieter. Daher braucht der Anbieter imho hier keine Rücksicht zu nehmen.
Und ein Server kann also kein "Gateway-für-Homenetzwerke" sein? Das musst du mir bitte ein mal genauer erläutern wo da technisch der Unterschied besteht. Auch darfst du mir gerne erklären wer oder was dir das Recht gibt festzulegen zu welchem Zweck die mietbaren Ressourcen verwendet werden dürfen.
Vermutlich bist Du der einzige, der sowas über Netcup abziehen will. Und es macht halt für eine Firma nunmal keinen wirtschaftlichen Sinn, auf Einzelbedürfnisse so spezifisch einzugehen.
Gerade im Hinblick auf die zunehmende Verbreitung von DS-Lite wirst du dich wundern wie viele sich auf die hier beschriebene Weise dazu verhelfen eine öffentliche IPv4 am heimischen Anschluss zu bekommen. Ich habe selbst lange Zeit bei Netcup entsprechende Gateways für Freunde und Bekannte, die CGN geplagte Vodafone/Kabel Deutschland Kunden sind, betrieben. Mangels größerer Netze bedeutete das allerdings keine IPv6 Anbindung über netcup aus den entsprechenden Heimnetzen, da z.B. sämtliche Android Geräte weiterhin kein DHCPv6 unterstützen und auch vmtl. nie unterstützen werden.
Die Gateways sind inzwischen alle zu einem Anbieter gewandet, der ohne Aufstand ein größeres Netz bereitstellen kann.
Weiterhin nutzen auch einige von der Peering Politik der Telekom geplagten User netcup als günstiges Gateway zu einem nicht verstopften Internet.
Ebenfalls ein valider use-case.
Nur weil dir keine (sinnvollen) Gründe einfallen soetwas zu betreiben, heißt es nicht, dass es sie nicht gibt.
-
Wir schreiben per PN.
Der Anbieter würde mich durchaus auch interessieren
-
Die Schmerzgrenze läge da bei mir irgendwo bei 2-3€ (für ein /48)
Da bist du aber ganz weit von der Realität entfernt was die Preise für ein /48 angeht. Das kann von der doppelten Schmerzgrenze bis hin zum fünffachen selbiger gehen, je nach dem wo du anfragst.
Nahezu kostenlos verschleudern tut diese großen Netze leider niemand mehr, wie es anfänglich (= wo die Hosting Unternehmen so nach und nach angefangen haben IPv6 bereitzustellen) der Fall gewesen ist.
Ich bin da aber bei dir, jedes Hostingunternehmen sollte anfangen mindestens ein /56 an Server zu binden. Notfalls auch via dynamischer Zuordnung an mehrere Server. Die nötigen Einsatzzwecke gibt es definitiv.
-
Wurde das MTR während eines solchen "Ausfalls" gemacht? Wenn nein, dann hat es keinerlei Aussagekraft, denn auf den von dir angehängten Bildern sind keine Paketverluste o.ä. erkennbar. In dem Fall dann das MTR bitte noch mal anfertigen während es zu Verbindungsproblemen kommt.
Die Kolleg:innen haben unterschiedliche ISPs, oder sind auch alle bei Vodafone?
