UND
diese IPv6 ist NICHT per ICMP aber per HTTP(S) erreichbar und kann
mir zum Test einen URL verraten?
reicht wenn IPMPv6 per drop gesperrt ist? Wenn ja, ziehe ich dir kurz einen Container hoch
UND
diese IPv6 ist NICHT per ICMP aber per HTTP(S) erreichbar und kann
mir zum Test einen URL verraten?
reicht wenn IPMPv6 per drop gesperrt ist? Wenn ja, ziehe ich dir kurz einen Container hoch
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?
https://www.techspot.com/news/…bility-stats-q2-2019.html
(Seagate vulgo Seetor liefert schlechte Festplatten)
Du hast ja auch einen HE-Tunnel, oder?
Was bekommst du denn ohne Fragmentierung in ein Paket?
https://www.techspot.com/news/…bility-stats-q2-2019.html
(Seagate vulgo Seetor liefert schlechte Festplatten)
Ich bin gerade mal meine verbauten Festplatten durchgegangen. Mir sind nur drei von Seagate in den Sinn gekommen, aber die hängen in einem RAID5, sind selten in Betrieb und halten (meines Wissens) gerade gar keine Daten
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.
so sieht das sit1 Device am Router aus
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
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.
so sieht das sit1 Device am Router aus
Bekommst du auch eine MTU von 1480 durch? Evtl. geht die PTB von 1500 Byte breiten Frames aus.
Das liest sich wie Verzweiflung ein technisches Wording anstatt klarer Hilfestellung via technischer Kompetenz.
Bekommst du auch eine MTU von 1480 durch? Evtl. geht die PTB von 1500 Byte breiten Frames aus.
sollte eigentlich so funktionieren
# 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
# 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?
was sagt Ihr eigtl zur "Intel Optane M.2 H10" - überlege ich die für meinen PC hole
m_ueberall deshalb bin auch am Zögern, weil überall findet man für M.2 nur die H10, nicht aber die anderen.
Da ich leider nur noch einen M.2 Slot frei habe und keinen PCIe.
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.
Netzwerkconfig NAS:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 70:85:c2:85:8f:a9 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.15/24 brd 192.168.178.255 scope global enp3s0
valid_lft forever preferred_lft forever
inet6 fe80::7285:c2ff:fe85:8fa9/64 scope link
valid_lft forever preferred_lft forever
3: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 46:de:f8:c8:b8:b7 brd ff:ff:ff:ff:ff:ff
inet 172.25.0.1/16 brd 172.25.255.255 scope global vmbr0
valid_lft forever preferred_lft forever
inet6 fe80::47a:e4ff:fef6:eb3a/64 scope link
valid_lft forever preferred_lft forever
5: veth100i0@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr100i0 state UP group default qlen 1000
link/ether fe:9c:1d:d5:ca:ba brd ff:ff:ff:ff:ff:ff link-netnsid 0
6: fwbr100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 62:69:3b:99:59:49 brd ff:ff:ff:ff:ff:ff
7: fwpr100p0@fwln100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
link/ether 46:de:f8:c8:b8:b7 brd ff:ff:ff:ff:ff:ff
8: fwln100i0@fwpr100p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr100i0 state UP group default qlen 1000
link/ether 62:69:3b:99:59:49 brd ff:ff:ff:ff:ff:ff
10: veth101i0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr101i0 state UP group default qlen 1000
link/ether fe:22:f5:49:42:ca brd ff:ff:ff:ff:ff:ff link-netnsid 1
11: fwbr101i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 5e:b5:26:15:a4:d0 brd ff:ff:ff:ff:ff:ff
12: fwpr101p0@fwln101i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
link/ether 86:5c:c1:2c:4d:47 brd ff:ff:ff:ff:ff:ff
13: fwln101i0@fwpr101p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr101i0 state UP group default qlen 1000
link/ether 5e:b5:26:15:a4:d0 brd ff:ff:ff:ff:ff:ff
15: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 172.21.0.2/16 brd 172.21.255.255 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::13bd:db41:8752:e9b0/64 scope link stable-privacy
valid_lft forever preferred_lft forever
Alles anzeigen
Firewallabschnitt für das Routing:
### Interface configuration ###
# external interface
ext_int='enp3s0'
# udp tunnel interface of the VPN server
udp_int='tun0'
# pve interface
pve_int="vmbr0"
### Network configuration ###
udp_net='172.21.0.0/16'
local_net='192.168.178.0/24'
pve_net='172.25.0.0/16'
### Routing ins Proxmox Netz ###
/sbin/iptables -t nat -A POSTROUTING -s $local_net -o $pve_int -j MASQUERADE # lokales Netz -> PVE Netz
/sbin/iptables -t nat -A POSTROUTING -s $pve_net -o $ext_int -j MASQUERADE # PVE Netz -> lokales Netz
/sbin/iptables -A FORWARD -i $ext_int -o $pve_int -j ACCEPT
/sbin/iptables -A FORWARD -i $pve_int -o $ext_int -j ACCEPT
/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
Alles anzeigen
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.
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:
/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.
Ö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.