DSM 7.1 i logika routingu
: pn lut 16, 2026 4:21 pm
Cześć!
Posiadam DS218+ z DSM w wersji 7.1.1-42962 Update 9.
Zainstalowałem WireGuard, który utworzył dodatkowy interfejs o nazwie "wg0" z adresem 10.0.0.201.
Istniejący port LAN to interfejs o nazwie "eth0" z adresem 192.168.1.200.
Aplikacja WireGuard została skonfigurowana jako klient VPN do serwera WireGuard hostowanego w innej lokalizacji. AllowedIPs to "0.0.0.0/1,128.0.0.0/1". AllowedIPs po stronie serwera to "10.0.0.201/32, 192.168.1.200/32".
Serwer NAS poprawnie nawiązuje połączenie z serwerem WireGuard.
Ping ze strony serwera WireGuard do adresu zdalnego 10.0.0.201 serwera NAS:
Jak widać serwer NAS poprawnie odpowiada interfejsem wg0.
Ping ze strony serwera WireGuard do adresu lokalnego 192.168.1.200 serwera NAS:
Jak widać wyżej zapytanie ping pojawia się na interfejsie wg0, ale serwer NAS nie odpowiada na niego interfejsem wg0, lecz...
Serwer NAS odpowiada na ping interfejsem eth0 pomimo faktu, że zapytanie przyszło interfejsem wg0!
Tablica routingu na serwerze NAS:
192.168.1.254 to lokalna bramka (router).
W tej samej sieci lokalnej posiadam inne urządzenie (Rasbperry Pi z Raspbian), które również działa jako klient WireGuard. Ping z serwera WireGuard do lokalnego adresu Raspberry Pi działa (Raspberry Pi odpowiada na ping tym samym interfejsem - wg0 - z którego przyszło zapytanie i pomimo faktu, że adres lokalny należy do podsieci interfejsu eth0).
Efekt oczekiwany to taki, w którym serwer NAS poprawnie odpowiada na pingi z sieci VPN do adresu lokalnego serwera NAS.
Wydaje mi się, że to problem w DSM, a dokładniej tego jak DSM routuje pakiety.
Prosiłbym o pomoc jak rozwiązać ten problem.
Posiadam DS218+ z DSM w wersji 7.1.1-42962 Update 9.
Zainstalowałem WireGuard, który utworzył dodatkowy interfejs o nazwie "wg0" z adresem 10.0.0.201.
Istniejący port LAN to interfejs o nazwie "eth0" z adresem 192.168.1.200.
Aplikacja WireGuard została skonfigurowana jako klient VPN do serwera WireGuard hostowanego w innej lokalizacji. AllowedIPs to "0.0.0.0/1,128.0.0.0/1". AllowedIPs po stronie serwera to "10.0.0.201/32, 192.168.1.200/32".
Serwer NAS poprawnie nawiązuje połączenie z serwerem WireGuard.
Ping ze strony serwera WireGuard do adresu zdalnego 10.0.0.201 serwera NAS:
Kod: Zaznacz cały
nitz@VPS:~$ ping 10.0.0.201 -c 5
PING 10.0.0.201 (10.0.0.201) 56(84) bytes of data.
64 bytes from 10.0.0.201: icmp_seq=1 ttl=64 time=8.37 ms
64 bytes from 10.0.0.201: icmp_seq=2 ttl=64 time=8.77 ms
64 bytes from 10.0.0.201: icmp_seq=3 ttl=64 time=10.8 ms
64 bytes from 10.0.0.201: icmp_seq=4 ttl=64 time=9.03 ms
64 bytes from 10.0.0.201: icmp_seq=5 ttl=64 time=8.14 ms
--- 10.0.0.201 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 8.136/9.020/10.794/0.939 ms
Kod: Zaznacz cały
nitz@NAS:~$ sudo tcpdump -i wg0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
16:05:55.448182 IP 10.0.0.254 > 10.0.0.201: ICMP echo request, id 24998, seq 1, length 64
16:05:55.448250 IP 10.0.0.201 > 10.0.0.254: ICMP echo reply, id 24998, seq 1, length 64
16:05:56.449305 IP 10.0.0.254 > 10.0.0.201: ICMP echo request, id 24998, seq 2, length 64
16:05:56.449365 IP 10.0.0.201 > 10.0.0.254: ICMP echo reply, id 24998, seq 2, length 64
16:05:57.451854 IP 10.0.0.254 > 10.0.0.201: ICMP echo request, id 24998, seq 3, length 64
16:05:57.451896 IP 10.0.0.201 > 10.0.0.254: ICMP echo reply, id 24998, seq 3, length 64
16:05:58.452998 IP 10.0.0.254 > 10.0.0.201: ICMP echo request, id 24998, seq 4, length 64
16:05:58.453057 IP 10.0.0.201 > 10.0.0.254: ICMP echo reply, id 24998, seq 4, length 64
16:05:59.454139 IP 10.0.0.254 > 10.0.0.201: ICMP echo request, id 24998, seq 5, length 64
16:05:59.454179 IP 10.0.0.201 > 10.0.0.254: ICMP echo reply, id 24998, seq 5, length 64
Ping ze strony serwera WireGuard do adresu lokalnego 192.168.1.200 serwera NAS:
Kod: Zaznacz cały
nitz@VPS:~$ ping 192.168.1.200 -c 5
PING 192.168.1.200 (192.168.1.200) 56(84) bytes of data.
--- 192.168.1.200 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4101ms
Kod: Zaznacz cały
nitz@NAS:~$ sudo tcpdump -i wg0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
16:07:35.151610 IP 10.0.0.254 > 192.168.1.200: ICMP echo request, id 25015, seq 1, length 64
16:07:36.181559 IP 10.0.0.254 > 192.168.1.200: ICMP echo request, id 25015, seq 2, length 64
16:07:37.205734 IP 10.0.0.254 > 192.168.1.200: ICMP echo request, id 25015, seq 3, length 64
16:07:38.229903 IP 10.0.0.254 > 192.168.1.200: ICMP echo request, id 25015, seq 4, length 64
16:07:39.254093 IP 10.0.0.254 > 192.168.1.200: ICMP echo request, id 25015, seq 5, length 64
Kod: Zaznacz cały
nitz@NAS:~$ sudo tcpdump -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:12:19.053548 IP lipa-nas.lan > 10.0.0.254: ICMP echo reply, id 25101, seq 1, length 64
16:12:20.057527 IP lipa-nas.lan > 10.0.0.254: ICMP echo reply, id 25101, seq 2, length 64
16:12:21.077418 IP lipa-nas.lan > 10.0.0.254: ICMP echo reply, id 25101, seq 3, length 64
16:12:22.101561 IP lipa-nas.lan > 10.0.0.254: ICMP echo reply, id 25101, seq 4, length 64
16:12:23.125715 IP lipa-nas.lan > 10.0.0.254: ICMP echo reply, id 25101, seq 5, length 64
Tablica routingu na serwerze NAS:
Kod: Zaznacz cały
nitz@NAS:~$ ip route show
0.0.0.0/1 dev wg0 scope link
default via 192.168.1.254 dev eth0 src 192.168.1.200
128.0.0.0/1 dev wg0 scope link
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.22.0.0/16 dev docker-69d54514 proto kernel scope link src 172.22.0.1 linkdown
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.200
W tej samej sieci lokalnej posiadam inne urządzenie (Rasbperry Pi z Raspbian), które również działa jako klient WireGuard. Ping z serwera WireGuard do lokalnego adresu Raspberry Pi działa (Raspberry Pi odpowiada na ping tym samym interfejsem - wg0 - z którego przyszło zapytanie i pomimo faktu, że adres lokalny należy do podsieci interfejsu eth0).
Efekt oczekiwany to taki, w którym serwer NAS poprawnie odpowiada na pingi z sieci VPN do adresu lokalnego serwera NAS.
Wydaje mi się, że to problem w DSM, a dokładniej tego jak DSM routuje pakiety.
Prosiłbym o pomoc jak rozwiązać ten problem.