Das längste Thema

  • das ist die Frage, habe von PTB als Antwort erhalten, dass es Absicht ist,

    dass uhr.ptb.de per ICMPv6 nicht reagiert;

    ich hab auf meinem vServer bei einem Apache-vHost der hat eine eigene IPv6 Adresse, in den ip6tables icmpv6 explizit gedropt

    kommt aber dennoch per HTTPS auf den vHost;

    wo kann noch der Pferdefuß sein, dass ich auf


    uhr.ptb.de per IPv6 nicht hinkomme (HTTPS) sehr wohl aber auf

    uhr.ptb.info und die sind beide innerhalb des selben IPv6 Prefixes;


    KB19 kannst Du das bei Dir nachvollziehen?

    Du hast ja auch einen HE-Tunnel, oder?

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • KB19 kannst Du das bei Dir nachvollziehen?

    Du hast ja auch einen HE-Tunnel, oder?

    Jein, HE habe ich auch, aber nicht als Primärtunnel. Kann ich bei Bedarf aber gerne über HE testen. Ich bin allerdings gerade unterwegs und kann erst in der Nacht oder morgen nachsehen. Wenn die ICMPv6 wirklich komplett (!) von außen blockieren, könnte es auch ein MTU-Problem sein. Wie bereits von H6G angedeutet.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • H6G  KB19

    so sieht das sit1 Device am Router aus

    Code
    sit1      Link encap:IPv6-in-IPv4
              inet6 addr: tunnel-prefix::2/64 Scope:Global
              inet6 addr: fe80::c0a8:80fe/128 Scope:Link
              UP POINTOPOINT RUNNING NOARP  MTU:1480  Metric:1
              RX packets:18756513 errors:0 dropped:0 overruns:0 frame:0
              TX packets:7588781 errors:376 dropped:0 overruns:0 carrier:0
                 collisions:0 txqueuelen:0
              RX bytes:23927960249 (22.2 GiB)  TX bytes:624938733 (595.9 MiB)

    bzw. in der Config

    Code
    # IPv6-in-IPv4 tunnel
    TYPE=SIT
    NAME=sit1
    ONBOOT=yes
    DEVICE=sit1
    BOOTPROTO=none
    IPV6INIT=yes
    IPV6TUNNELIPV4=IPv4remote
    IPV6TUNNELIPV4LOCAL=IPv4local
    IPV6ADDR=tunnel-prefix::2
    Code
    bzw.
    NETWORKING="yes"
    NETWORKING_IPV6="yes"
    HOSTNAME="router.home.arpa"
    IPV6FORWARDING="yes"
    IPV6_DEFAULTGW=tunnel-prefix::1
    IPV6_DEFAULTDEV=sit1

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • H6G killerbees19

    so sieht das sit1 Device am Router aus

    Also uhr.ptb.de - die senden nicht einmal ein ICMP type 2 zurück. Ich würde ja noch verstehen, wenn sie echo replies verwerfen... völlig kaputt.

    mainziman: mit iproute2 könntest Du für TCP-Verbindungen die MSS der defaultroute des Tunnels ankündigen (advmss x | x=MTU - 40 - 20 für IPv6). ip -6 r c default dev sit1 via tunnel-prefix::2 mtu 1480 advmss 1420 ... oder ähnlich. Damit könnten zumindest die HTTPS-Verbindungen wieder klappen, solange die MTU-Werte in beide Richtungen symmetrisch sind.

  • Wer sich für die Microsoft Spam-Problematik interessiert kann ja mal hier mit Druck ausüben. :)


    github


    Das liest sich wie Verzweiflung ein technisches Wording anstatt klarer Hilfestellung via technischer Kompetenz. :D

    "Security is like an onion - the more you dig in the more you want to cry"

  • Bekommst du auch eine MTU von 1480 durch? Evtl. geht die PTB von 1500 Byte breiten Frames aus.

    sollte eigentlich so funktionieren

    Code
    # ping6 -s 1481 netcup-vserver -M do                                                                      
    PING netcup-vserver(IPV6) 1481 data bytes
    ping: local error: Message too long, mtu=1480
    ...

    ich weiß es jetzt nicht warum, aber hier kann ich bei -s ... maximal 1432 angeben


    Code
    # ping6 -s 1432 netcup-vserver -M do                                                                      
    PING netcup-vserver(IPv6) 1432 data bytes
    1440 bytes from IPv6: icmp_seq=1 ttl=60 time=43.7 m
    ...

    60 Bytes durch das IPv6-in-IPv4?

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • KB19  H6G  eripek

    Nachtrag: auf des muss ma ja mal kommen,

    auf allen Kisten (VMs) die IPv6 verwenden folgendes konfigurieren

    MTU=1480

    aber nur f. IPv6, dann geht des

    (ich frag mich gerade, was dann evtl. dann nicht mehr geht)


    irgendwie eine bescheuerte Lsg.

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • was sagt Ihr eigtl zur "Intel Optane M.2 H10" - überlege ich die für meinen PC hole :/

    Ein reiner Windows-PC? Für Linux gibt es derzeit ja wohl keine Unterstützung dafür (vgl. hier). Hier gibt es einen recht kritischen Test zum Intel Optane Memory H10.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Betreibt hier jemand ein OpenVPN mit Site to Site Routing?

    Ich möchte gerne an meinem NAS (Client im VPN, welches auf einem VPS läuft) den Traffic, der auf tun0 reinkommt, in mein Proxmox Netz (ebenfalls auf dem besagten NAS) routen.


    Ich mag praktisch von 172.21.0.0/16@tun0 nach 172.25.0.0/16@vmbr0 routen.

    Ich pushe die Routen über den VPN Server und die sind dann auch korrekt bei den Clients eingetragen, aber weder vom VPN Server, noch von anderen VPN Clients aus, ist das Netz zu erreichen.


    Ich kann problemlos zwischen ProxMox Netz <--> Heimnetz kommunizieren und komme auch vom ProxMox Netz ins VPN rein. Aber vom VPN komme ich nicht in dieses verfluchte ProxMox Netz. Woran kann sowas denn nur liegen? Ich verzweifel hier grad echt. :s

    Traceroute von VPN Clients geht immer bis zum VPN Server und dann ist Schluss. Traceroute vom VPN Server selbst geht gleich ins leere.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • nach 172.25.0.0/16@vmbr0 routen.

    Wissen denn die Clients im Proxmox Netz, wie sie 172.21.0.0/16 erreichen können?

    Gibt es eine konfigurierte Rückroute?


    Edit:

    Code
    /sbin/iptables -t nat -A POSTROUTING -s $udp_net -o $pve_int -j MASQUERADE # VPN Netz(e) -> PVE Netz # Das hier geht nicht
    /sbin/iptables -t nat -A POSTROUTING -s $pve_net -o $udp_int -j MASQUERADE # PVE Netz -> VPN Netz(e)
    /sbin/iptables -A FORWARD -i $udp_int -o $pve_int -j ACCEPT
    /sbin/iptables -A FORWARD -i $pve_int -o $udp_int -j ACCEPT

    NAT oder Forward. Mit beidem wirst du nicht glücklich.

    Wieso nattest du zwischen den Netzen?

  • /sbin/iptables -t nat -A POSTROUTING -s $udp_net -o $pve_int -j MASQUERADE # VPN Netz(e) -> PVE Netz # Das hier geht nicht
    /sbin/iptables -t nat -A POSTROUTING -s $pve_net -o $udp_int -j MASQUERADE # PVE Netz -> VPN Netz(e)
    /sbin/iptables -A FORWARD -i $udp_int -o $pve_int -j ACCEPT
    /sbin/iptables -A FORWARD -i $pve_int -o $udp_int -j ACCEPT

    Gibt es eine konfigurierte Rückroute?

    Öhm. Na die markierte da, das müsste ja zeitgleich auch die Rückroute sein.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Öhm. Na die markierte da, das müsste ja zeitgleich auch die Rückroute sein.

    Das ist keine Rückroute, das ist ein SNAT, ein SNAT hält automatisch den Rückkanal offen, für eine gewisse Zeit.

    Mit Rückroute meine ich, dass das Proxmox Netz auch weiß, über welchen Weg es das OpenVPN Netz erreichen kann.


    Aber ein NAT da drinne macht es nicht unbedingt leichter.