Beiträge von Mixus

Zitat von mainziman

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.

Zitat von nickel01202

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)

Zitat von White

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.

Zitat von Valkyrie

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)

pasted-from-clipboard.png

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.

Zitat von KB19

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

Zitat von shack

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.

#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

Zitat von geekmonkey

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.

Zitat von geekmonkey

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

mca-cli
set-inform http://[DDNS/IP des Heimanschlusses]:8080/inform

Zitat von geekmonkey

Traffic 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.

Zitat von TBT

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.

Zitat von TBT

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.

Zitat von TBT

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.

Zitat von TBT

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.

Zitat von cltrmx

Wir schreiben per PN.

Der Anbieter würde mich durchaus auch interessieren

Zitat von MeisterYoda

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?

Bei meinen letzten Setups hier bei netcup war ein ndppd notwendig, da die Netze zu dem Zeitpunkt eben *nicht* gerouted waren.

Versuchs in deiner ndppd.conf mal mit:

rule 2a03:4000:2:XXXX:c0de::2/128 {
                static
        }

statt iface br0, nach meiner Erfahrung funktionieren weder auto noch iface direktiven beim ndppd.

Meine config sah damals so aus und damit ließ sich ein inkludiertes /64 problemlos auch hinter einem VPN Tunnel nutzen:

route-ttl 30000
address-ttl 30000

proxy eth0 {
        router no
        timeout 500   
        autowire yes
        keepalive yes
        retries 3
        promiscuous yes
        ttl 30000

        rule 2a03:4000::xxxx/80 {
                static
        }
        rule 2a03:4000::yyyy/80 {
                static
        }
        rule 2a03:4000::zzzz/80 {
                static
        }
}

Du kannst die inklusiv IPs der einzelnen Rootserver eingehend (Internet => Rootserver) nicht einfach über die pfSense routen. Diese sind fest an deine Rootserver gebunden und netcup routet diese auch auf Anfrage nicht über deine pfSense.

Ausgehenden Verkehr (Rootserver => Internet) kannst du aber nach belieben über die pfSense routen durchs Cloud vLAN.

Für dein Vorhaben brauchst du entweder ein geroutetes Netz, oder einzelne Zusatz-IPs die auf deine pfSense geroutet werden. Ob netcup solche Produkte anbietet kann ich dir aber Ad-Hoc nicht sagen.