Ich möchte kein TLS-Break machen
Tust aber genau das in deiner Config ... ? Wenn per KI generiert, empfehle ich sie selbst anhand der squid Doku zu bauen, so kompliziert ist das nicht. https://www.squid-cache.org/Doc/
Beiträge von Mixus
-
-
Kann ich bestaetigen, meine Loesung ist nen Ping laufen zu lassen und so lange zu re-connecten bis ich eine gute route bekomme.
Ich gehe teils auch Zuhause > DUS > FRA , statt Zuhause > FRA
Der Support meinte damals bereits es ist noch im rahmen....
Ich lande immer in 62.xx.xx.xx oder 195.xx.xx.xx je nach dem , es passiert mir aber in beiden Ranges.. Hab leider keine andere Loesung als die oben genannte weshalb ich immer versuche den Router so lange wie moeglich laufen zu lassen um teils nicht 10x mal re-connecten zu muessen.
Trotz des nervigen "Fehlers" ist mir easybell immer noch lieber als jeder andere ISP.
Man kann eine "Route" erzwingen, Anschlüsse bei Easybell terminieren random in DUS oder in FRA. Wo man gelandet ist, erkennt man am Gateway und nicht am IP Addresskreis. Einfach so lange reconnecten bis man auf einem Gateway am gewünschten Standort rauskommt.
Meinen beobachtungen nach kommen die Gateways 62.27.x.140-146 in FRA raus, und die Gateways 195.78.x.140-146 in DUS.
Die Gateways in DUS sind eigentlich immer schlechter von der Latenz her, da hier sehr viel einfach trotzdem über FRA läuft.
-
Frage ist halt, ist netplan überhaupt gewollt, oder versehentlich in der ISO gelandet?
Aus https://wiki.debian.org/Netplan/FAQ :
Is Netplan available anywhere else?
[...] It's also used as the default network stack in Debian cloud-images, as of the "Bookworm" release [...]
Betrifft also aktuell nur die cloud-init images.
-
Das klingt gut. Auf welcher Unterseite kann man das machen lassen? Hab die nicht gefunden?
Unten im Footer auf "Submit a data correcton".
-
Neben der von dir genannten Möglichkeit über sysctl gibt es auch noch die Möglichkeit IPv6 über den Kernel zu deaktivieren.
Dazu einfach "ipv6.disable=1" an die Kernel Cmdline anhängen. Über den Bootloader grub würdest du das in /etc/default/grub unter dem Konfigurationsparameter GRUB_CMDLINE_LINUX="ipv6.disable=1" eintragen und mit update-grub scharfschalten.
Dadurch wird IPv6 komplett deaktiviert.
Dass das ganze keine gute Idee ist, haben dir meine Vorredner ja bereits mitgeteilt. Ich gebe hier außerdem noch zu Beachten, dass einige Software sich anfängt merkwürdig, bis hin zu instabil zu verhalten, oder schlicht komplett den Dienst verweigert wenn du den IPv6 Stack deaktivierst.
Gerade in Verbindung mit Docker führt dies sehr häufig zu Mehrarbeit, wenn der Dienst innerhalb des Containers konfiguriert wurde sich auf IPv4 und IPv6 zu binden.
EDIT: kleiner Nachtrag, nach update-grub ist natürlich noch ein reboot notwendig.
-
This is a customer forum, not a support forum. Nobody here can answer inquiries. Please stick to the official support channels (phone, mail, contact form from within the CCP).
-
Bei besagtem Hoster würde ich persönlich rein gar nichts mieten
https://www.heise.de/news/Webhoster…st-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
Alles anzeigen#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.
